include CROSS_COMPILE
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

The configuration was installing the kernel headers from version 4.4
but we were using 2.6.39 and now we are using 3.16.37. Fix this
by configuring the 3.16.37 as Linux versin to use to get headers
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

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

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

It happens that headers have different sources: buildroot and our own kernel.
For the standard path we have headers from buildroot which include also
some kernel header. For the kernel, we have direct access to those headers.

this means that we mya have conflict in our user-space programs. This patch
does not solve the problem but it just reduce its effects.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The Linux kernel 3.16.37 does not export, or does not have, anymore some
hardware headers. Here I copy all the values we need.

The real fix should be to create a set of WRS headers with all the symbols
we need so that we do not depend anymore on other projects.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

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

The USB gadget framework has changed from Linux v2.6.39. As far as I
understood it's now more modular, so it's not anymore enough to load
just the g_serial.ko driver. Now we have to load also it's
dependencies.

I'm not an expert about USB gadget, this patch is the result of my
understanding in debugging the loading failure of the g_serial.ko
module. Perhaps it will be necessary some adjustments to make it
work the way we want. But for the time begin I will leave it like
this until is clear what we have to adjust.

Note that these dependecies depends also on the configfs file-system.
I had problems to get this work because apparently by using a different
corss-compiler some symbols where removed from the kernel, so our
modules were not able to load because of "undefined symbols".
Using the toolchain compiled within this project solved this issue.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The aim of this module is to register all the FPGA devices
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Actually, this is not what I want. I would like to just use an IRQ
resource with the correct IRQ number. What I want is to hide the IRQ
domain knowledge elsewhere. For instance, in the wrs_device module
that register all our devices. But, since I have to update the kernel
with the least number of changes I will leave this for the future.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Copy the vic IRQ controller from the coht-vic repository.
The maintainer prefers to have a copy instead of a submodule.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Many mach headers has been moved out of scope. Of course they are still
accessible by in an ugly way. Here I'm following the ugly way in order
to get something working.

What to do with this headers, perhaps, needs a discussion. I personally
think that we need our local headers with hardware definitions. The
reason is that we saw that in future kernel version some of these
headers complitely disappear. The hardware definitions never change so
we can safely copy them and remove a dependency with an external project.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Instead of using clocksource_register() we use
clocksource_register_hz() as suggested

From kernel patch c7f798e3722610d486e951f04bbc00b6ba124d62
    clocksource: Get rid of clocksource_calc_mult_shift()

    No one is using this, so encourage the use of
    clocksource_register_hz/khz(), and drop this helper.

    Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
    [jstultz: tweaked commit message]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

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

The version 3.16.37 is going to be supporter until 2020
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Also remove link to at91_softpwm.h
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

By this we drop support of wrs < 3.30. At least its fan.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

On modern switches the fan are driver by a dedicated FPGA core
that does the PWM. This module is not necessary anymore and not even
the kernel patches to make this module work.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Our software runs only on a single kind of CPU, so we don't need to calculate
it at every boot. The way how daemons are spawned at boot changed
since the function shw_udelay_init was written. Before daemons were spawned one
after another, now they are spawned at the same time and compete during
initialization phase for the CPU.
The loop calculating loops_per_msec was interrupted by few context switches.
When using the kernel 2.6.39, the problem was not visible and usually
loops_per_msec was estimated correctly.
However, introduction new kernel 3.16 lowered probability of getting
correct results. Probably due to the different behaviour of the scheduler.
Bug was found because HAL was not able to detect SFP with
vn=ZyXEL
pn=SFP-BX1310-10-D
vs=S131151000226
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Explicitly define which version of buildroot should be used.

It solves problem when there is more than one directory matching build/buildroot-2*
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

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

The variable is unused because there is no need to use it. The color is
white by default; indeed, this variable was set to "WHITE" everytime, but
then not used.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Today it is not really important to do this because all our modules are
within the project itself. But, at somepoint, we may use submodules
in order to integrate drivers from external sources; so, we need to export
our default values because we will not have control over the other projects
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

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

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

We want '/dev/shm' to be empty at boot time. It may happen that
while working with rootfs over NFS this directory is not empty.

With this patch we remove all files from this directory because
they should not be there at all.

What if I put something there on purpose? When using tmpfs,
files in '/dev/shm' will be automatically removed on shutdown.
We are keeping the same behavior. Put your own development files
in '/dev/shm' after the execution of this script by copying them
from another location.

Again, if we use rootfs over NFS and if tmpfs does not work then
the system will use the NFS and the system should continue to work.
In this case the performances will be much worst
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

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

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

This way, next time we want to update the kernel we have just to change
the version without touching too much the code
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The kernel version is hardcoded here. Take it at runtime by using
`uname -r`. This will reduce incompatibilities on kernel updates
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Complement of a commit:
02bb6153 rootfs: use /etc/ppsi.conf not /wr/etc/ppsi.conf
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

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

Make clear what kind of resolution get_monotonic_tics function returns (micro
seconds).
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Fix the bug introduced by a commit:
291a32c7 userspace/wrsw_hal: use get_monotonic_* instead of clock_gettime

get_monotonic_tics() return a value in us resolution, so to get ms it has to be
divided by 1000, not multiplied.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

--Read DOM (Diagnostic Monitoring data) data from SFPs
--Fix the write to SFPs eeprom
--store DOM data in the HAL's shmem
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

The SFP documentation "INF-8047.pdf" states:
"The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for
the ATMEL AT24C01A/02/04 family of components."

Upon reading that datasheet, some important details stand out:
1) The eeprom can only write in pages, with pages being 8 or 16 bytes. Assuming
   the smallest device, you can only write 8 bytes at a time. To be safe, I'm
   assuming a pagesize of 8 bytes.

   This explains why we only saw stuff change in the first 8 bytes, I guess.

2) A write needs to be preceded by the byte address which is a single byte for
   these devices, and then up to 8 (or 16) data bytes to be written at that
   location. If there are more bytes, or if the data wraps around the page
   binary, it will still only end up on the page belonging to that first
   address.

3) After writing, you need to poll the eeprom to see if it has finished writing
   the byte. At the moment, I'm not doing that yet, instead I'm doing a 10ms
   wait which seems sufficient.
Signed-off-by: Paul Boven <boven@jive.eu>
Acked-by: Adam Wujek <adam.wujek@cern.ch>

Kconfig:
--add CONFIG_READ_SFP_DIAG_ENABLE
libwr:
--add the function shw_sfp_update_dom to update only needed values in the future
--increase HAL_SHMEM_VERSION due to the changes in structures
wrs_dump_shmem
--add new fields
HAL:
--read DOM (Diagnostic Monitoring data) from SFP's eeprom at plug and once
  per second
PPSI:
--uplift hal shmem header
wrs_sfp_dump:
--support reading SFP's DOM from HAL
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>