summaryrefslogtreecommitdiff
path: root/drivers/soc/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2021-08-26soc: xilinx: versal: Add soc_xilinx_versal driverT Karthik Reddy1-0/+1
soc_xilinx_versal driver allows identification of family & revision of versal SoC. This driver is selected by CONFIG_SOC_XILINX_VERSAL. Probe this driver using platdata U_BOOT_DEVICE structure which is defined at mach-versal/cpu.c. Add this config to xilinx_versal_virt_defconfig & xilinx_versal_mini_ospi_defconfig file to select this driver. Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com> Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-08-26soc: xilinx: zynqmp: Add soc_xilinx_zynqmp driverT Karthik Reddy1-0/+1
soc_xilinx_zynqmp driver allows identification of family & revision of zynqmp SoC. This driver is selected by CONFIG_SOC_XILINX_ZYNQMP. Add this config to xilinx_zynqmp_virt_defconfig file. Probe this driver using platdata U_BOOT_DEVICE structure which is specified in mach-zynqmp/cpu.c. Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com> Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-07-25dm: soc: Introduce soc_ti_k3 driver for TI K3 SoCsDave Gerlach1-0/+1
Introduce an soc_ti_k3_driver that allows identification and selection of SoC specific data based on the JTAG ID register for device identification, as described for AM65x[0] and J721E[1] devices. [0] http://www.ti.com/lit/ug/spruid7e/spruid7e.pdf [1] http://www.ti.com/lit/ug/spruil1a/spruil1a.pdf Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-25test: Add tests for SOC uclassDave Gerlach1-0/+1
Add a sandbox SOC driver, and some tests for the SOC uclass. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-25dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matchingDave Gerlach1-0/+1
Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-24Revert "Merge tag 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm"Tom Rini1-3/+0
This reverts commit 5d3a21df6694ebd66d5c34c9d62a26edc7456fc7, reversing changes made to 56d37f1c564107e27d873181d838571b7d7860e7. Unfortunately this is causing CI failures: https://travis-ci.org/github/trini/u-boot/jobs/711313649 Signed-off-by: Tom Rini <trini@konsulko.com>
2020-07-20dm: soc: Introduce soc_ti_k3 driver for TI K3 SoCsDave Gerlach1-0/+1
Introduce an soc_ti_k3_driver that allows identification and selection of SoC specific data based on the JTAG ID register for device identification, as described for AM65x[0] and J721E[1] devices. [0] http://www.ti.com/lit/ug/spruid7e/spruid7e.pdf [1] http://www.ti.com/lit/ug/spruil1a/spruil1a.pdf Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-20test: Add tests for SOC uclassDave Gerlach1-0/+1
Add a sandbox SOC driver, and some tests for the SOC uclass. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2020-07-20dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matchingDave Gerlach1-0/+1
Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2019-04-12soc: keystone: Merge into ti specific directoryVignesh R1-1/+0
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-12soc: ti: k3: add navss ringacc driverGrygorii Strashko1-0/+1
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>
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini1-3/+1
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>
2016-02-06Use correct spelling of "U-Boot"Bin Meng1-1/+1
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>
2015-11-10Various Makefiles: Add SPDX-License-Identifier tagsTom Rini1-0/+2
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>
2014-10-23soc: keystone_serdes: create a separate SGMII SerDes driverKhoronzhuk, Ivan1-0/+5
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>