There is no general convention among drivers to define a variable with
some path as a value. Some use `$(shell pwd) and some not. Thus, make
everything uniform.
Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

Variable name 'LINUX' is very ambiguous for its purpose in the makefile.
Also, this project builds as a part of COHT project which uses another
variable name 'KERNELSRC' for the same purpose. Hence, this change makes
this project uniform with others.
Signed-off-by: Vaibhav Gupta <vaibhav.gupta@cern.ch>

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

dev.fwnode was not set to NULL after deallocation which could wrong
memory accesses.
Signed-off-by: Mathis MARION <mathis.marion@grenoble-inp.org>

1.1.2 - 2021-07-29
==================
https://www.ohwr.org/project/general-cores/tags/v1.1.2

Fixed
-----
- sw: improve compatibility with newer (> 3.10) Linux kernel versions

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

When creating an IRQ domain, the code used to store a device struct
pointer in the `of_node` field of the irq_domain struct returned by
`irq_domain_add_linear`. This was done by casting to a void pointer and
passing as the first argument of the function.

In the SPEC repository (and supposedly other depending repositories),
we would then get back the irq_domain struct by calling `irq_find_host`
with again a device struct pointer casted to a void pointer as the
argument. The function would compare the addresses of the 2 device
structs and return the right irq_domain.

This trick was most likely due to the fact that the IRQ domain API was
conceived around OpenFirmware before version 4.4, and that the project
should work for ACPI.
A workaround for kernel 4.7 was written, which involved using a `select`
function, and passing the address of the device struct as a parameter.
It was particularly ugly as it would require getting around the
`irq_find_host` to call immediately `irq_find_matching_fwspec` and pass
in the address of the wanted device struct as a parameter in a hacky way
to fit it inside two 32 bit integers.

Kernel version 4.4 introduced fwnodes, which would make easier working
with ACPI. Instead of repeating the hacky workaround (which would result
in a kernel error on later kernels when calling irq_domain_add_linear),
I allocated a fwnode_handle struct before creating a new IRQ domain.
Then I used the new irq_domain_create_* API to get an irq_domain using
this fwnode. I also took care of disallocating the fwnode_handle.

On the other end, we can just call `irq_find_matching_fwnode` and pass
dev.fwnode as a parameter.
Signed-off-by: Gwenhael GOAVEC <gwenhael.goavec@femto-st.fr>
Signed-off-by: Mathis MARION <mathis.marion@grenoble-inp.org>

`i2c_new_device` disappeared in kernel 5.2 and onwards.
It is now required to use `i2c_new_client_device`, which
works the same way except for error checking.
Signed-off-by: Mathis MARION <mathis.marion@grenoble-inp.org>

When creating an IRQ domain, the code used to store a device struct
pointer in the `of_node` field of the irq_domain struct returned by
`irq_domain_add_linear`. This was done by casting to a void pointer and
passing as the first argument of the function.

In the SPEC repository (and supposedly other depending repositories),
we would then get back the irq_domain struct by calling `irq_find_host`
with again a device struct pointer casted to a void pointer as the
argument. The function would compare the addresses of the 2 device
structs and return the right irq_domain.

This trick was most likely due to the fact that the IRQ domain API was
conceived around OpenFirmware before version 4.4, and that the project
should work for ACPI.
A workaround for kernel 4.7 was written, which involved using a `select`
function, and passing the address of the device struct as a parameter.
It was particularly ugly as it would require getting around the
`irq_find_host` to call immediately `irq_find_matching_fwspec` and pass
in the address of the wanted device struct as a parameter in a hacky way
to fit it inside two 32 bit integers.

Kernel version 4.4 introduced fwnodes, which would make easier working
with ACPI. Instead of repeating the hacky workaround (which would result
in a kernel error on later kernels when calling irq_domain_add_linear),
I allocated a fwnode_handle struct before creating a new IRQ domain.
Then I used the new irq_domain_create_* API to get an irq_domain using
this fwnode. I also took care of disallocating the fwnode_handle.

On the other end, we can just call `irq_find_matching_fwnode` and pass
dev.fwnode as a parameter.
Signed-off-by: Gwenhael GOAVEC <gwenhael.goavec@femto-st.fr>
Signed-off-by: Mathis MARION <mathis.marion@grenoble-inp.org>

`i2c_new_device` disappeared in kernel 5.2 and onwards.
It is now required to use `i2c_new_client_device`, which
works the same way except for error checking.
Signed-off-by: Mathis MARION <mathis.marion@grenoble-inp.org>

Adding condition to warn about 0 divider value.
It was observed while accessing svec-flash, if frequency for flash is not defined correctly i.e
in operation range of chip and host(i.e vme or pci), divider value 0 doesn't allow flash transfers.

Signed-off-by Mamta Shukla <mamta.ramendra.shukla@cern.ch>
Suggested-by: Federico Vaga <federico.vaga@cern.ch>

So that in one read access, the software can read both the status and
the value and can decide if the value is correct.  This avoids race
issues.

Simplify the code and avoid possible glitches.

The goal is to make sure that files in the common directory don't
depend on things defined elsewhere. With these changes, the only
remaining issue is gc_delay_line that uses generic_dpram from
genrams
Signed-off-by: Olof Kindgren <olof.kindgren@gmail.com>

Fixes to the latest proposed_master merge

See merge request !11

1.1.1 - 2020-09-14
==================

Fixed
-----
- sw: fix SPI driver to update the spi_message->actual_length

1.1.1 - 2020-09-14
==================

Fixed
-----
- sw: fix SPI driver to update the spi_message->actual_length

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

The spi-ocore driver was not updating the actual_length field in the
spi_message structure. This field could be used by SPI users to see if
all bytes have been transferred.

In particular we found the problem because the m25p80 driver uses the
actual_length to determine if there are transmission errors (-EIO).
Signed-off-by: Mamta Shukla <mamta.ramendra.shukla@cern.ch>
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The response should not be EXOKAY unless an atomic access is requested
by the master using the LOCK signals.  This bridge does not even
support atomic accesses (it's an AXI4-Lite slave and does not have the
LOCK signals) so it's required to respond OKAY even if the master
does attempt an atomic access (this is how the master knows that the
slave does not support atomic accesses).  The AXI4-Lite specification
clearly states that the EXOKAY response is not supported in AXI4-Lite.

The BVALID signal must be asserted once the write operation is
completed.  The master is not required to assert BREADY before this
happens.  The old code happened to work if the master tied BREADY
high, which is allowed but not required.

Conflicts:
	modules/wishbone/wb_fine_pulse_gen/xwb_fine_pulse_gen.vhd

wb_fine_pulse_gen: implement separate serdes/PLL reset and lock indicator (required to maintain correct phase of the output pulses)