Commit graph

17 commits

Author SHA1 Message Date
Simon Glass
f7ae49fc4f common: Drop log.h from common header
Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:18 -04:00
Simon Glass
90526e9fba common: Drop net.h from common header
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.

Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 17:33:31 -04:00
Masahiro Yamada
9d86b89c59 dma-mapping: move dma_map_(un)single() to <linux/dma-mapping.h>
The implementation of dma_map_single() and dma_unmap_single() is
exactly the same for all the architectures that support them.

Factor them out to <linux/dma-mapping.h>, and make all drivers to
include <linux/dma-mapping.h> instead of <asm/dma-mapping.h>.

If we need to differentiate them for some architectures, we can
move the generic definitions to <asm-generic/dma-mapping.h>.

Add some comments to the helpers. The concept is quite similar to
the DMA-API of Linux kernel. Drivers are agnostic about what is
going on behind the scene. Just call dma_map_single() before the
DMA, and dma_unmap_single() after it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-02-19 21:27:30 +08:00
Simon Glass
336d4615f8 dm: core: Create a new header file for 'compat' features
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05 19:33:46 -07:00
Simon Glass
61b29b8268 dm: core: Require users of devres to include the header
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
2020-02-05 19:33:46 -07:00
Vignesh Raghavendra
ec0aeacf0b soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle
Instead of looking getting reference to SYSFW device using name which
is not guaranteed to be constant, use phandle supplied in the DT node to
get reference to SYSFW

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-20 10:10:28 +05:30
Vignesh Raghavendra
9d32a94bce soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop
Flush caches when pushing an element to ring and invalidate caches when
popping an element from ring in Exposed Ring mode. Otherwise DMA
transfers don't work properly in R5 SPL (with caches enabled) where the
core is not in coherency domain.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-01-20 10:10:28 +05:30
Vignesh Raghavendra
62a9620135 soc: ti: k3-navss-ringacc: fix k3_nav_ringacc_ring_reset_dma
In case dma_ring_reset_quirk is not set the k3_ringacc_ring_reset_dma will
just exit without ring reset. Fix it, by adding ring reset call in case
dma_ring_reset_quirk is not.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2019-09-13 11:56:08 -04:00
Vignesh R
91dba55ca6 soc: keystone: Merge into ti specific directory
Merge drivers/soc/keystone/ into drivers/soc/ti/
and convert CONFIG_TI_KEYSTONE_SERDES into Kconfig.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2019-04-11 20:07:12 -04:00
Grygorii Strashko
432f66fe73 soc: ti: k3: add navss ringacc driver
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.

The RINGACC converts constant-address read and write accesses to equivalent
read or write accesses to a circular data structure in memory. The RINGACC
eliminates the need for each DMA controller which needs to access ring
elements from having to know the current state of the ring (base address,
current offset). The DMA controller performs a read or write access to a
specific address range (which maps to the source interface on the RINGACC)
and the RINGACC replaces the address for the transaction with a new address
which corresponds to the head or tail element of the ring (head for reads,
tail for writes). Since the RINGACC maintains the state, multiple DMA
controllers or channels are allowed to coherently share the same rings as
applicable. The RINGACC is able to place data which is destined towards
software into cached memory directly.

Supported ring modes:
 - Ring Mode
 - Messaging Mode
 - Credentials Mode
 - Queue Manager Mode

TI-SCI integration:

Texas Instrument's System Control Interface (TI-SCI) Message Protocol now
has control over Ringacc module resources management (RM) and Rings
configuration.

The Ringacc driver manages Rings allocation by itself now and requests
TI-SCI firmware to allocate and configure specific Rings only. It's done
this way because, Linux driver implements two stage Rings allocation and
configuration (allocate ring and configure ring) while TI-SCI Message
Protocol supports only one combined operation (allocate+configure).

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
2019-04-11 20:07:12 -04:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Bin Meng
a187559e3d Use correct spelling of "U-Boot"
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
2016-02-06 12:00:59 +01:00
Tom Rini
da58dec866 Various Makefiles: Add SPDX-License-Identifier tags
After consulting with some of the SPDX team, the conclusion is that
Makefiles are worth adding SPDX-License-Identifier tags too, and most of
ours have one.  This adds tags to ones that lack them and converts a few
that had full (or in one case, very partial) license blobs into the
equivalent tag.

Cc: Kate Stewart <kstewart@linuxfoundation.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
2015-11-10 09:19:52 -05:00
Khoronzhuk, Ivan
496191c7ab soc: keystone_serdes: generalize configuration mechanism
The cmu, comlane, lane configuration mechanism are similar for sub
systems as well such as PCI or sRIO, but they have different values
based on input clock and output bus rate. According to this compact
driver to simplify adding different configuration settings based
on clock and rate.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00
Hao Zhang
92a16c81f5 soc: keystone_serdes: generalize to be used by other sub systems
SerDes driver is used by other sub systems like PCI, sRIO etc.
So modify it to be more general. The SerDes driver provides common
API's that can also be extended for other peripherals SerDes
configurations.

Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00
Hao Zhang
95f74dad91 soc: keystone_serdes: enhance to use cmu/comlane/lane specific configurations
Enhance the driver to use cmu/comlane/lane specific configurations
instead of 1 big array of configuration.

Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00
Khoronzhuk, Ivan
a43febde44 soc: keystone_serdes: create a separate SGMII SerDes driver
This patch split the Keystone II SGMII SerDes related code from
Ethernet driver and create a separate SGMII SerDes driver.
The SerDes driver can be used by others keystone subsystems
like PCI, sRIO, so move it to driver/soc/keystone directory.

Add soc specific drivers directory like in the Linux kernel.
It is going to be used by keysotone soc specific drivers.

Signed-off-by: Hao Zhang <hzhang@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
2014-10-23 11:27:28 -04:00