Changes in Makefile

2449efaa - soc: ti: Mover power-domain drivers to the genpd dir

Wed, 05 Jul 2023 22:57:21 +0000

soc: ti: Mover power-domain drivers to the genpd dirTo simplify with maintenance let's move the ti power-domain drivers to thenew genpd directory. Going forward, patches are intended to be managedthrough a separate git tree, according to MAINTAINERS.Cc: Nishanth Menon Cc: Santosh Shilimkar Cc: Tero Kristo Cc: Tony Lindgren Reviewed-by: Nishanth Menon Reviewed-by: Tony Lindgren Signed-off-by: Ulf Hansson List of files: /linux-6.15/drivers/soc/ti/Makefile

bca815d6 - PM: AVS: smartreflex Move driver to soc specific drivers

Tue, 06 Oct 2020 16:05:15 +0000

PM: AVS: smartreflex Move driver to soc specific driversThe avs drivers are all SoC specific drivers that doesn't share any code.Instead they are located in a directory, mostly to keep similarfunctionality together. From a maintenance point of view, it makes bettersense to collect SoC specific drivers like these, into the SoC specificdirectories.Therefore, let's move the smartreflex driver for OMAP to the ti directory.Signed-off-by: Ulf Hansson Reviewed-by: Nishanth Menon Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/soc/ti/Makefile

dc112956 - soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs

Sat, 12 Sep 2020 04:43:34 +0000

soc: ti: pruss: Add a platform driver for PRUSS in TI SoCsThe Programmable Real-Time Unit - Industrial CommunicationSubsystem (PRU-ICSS) is present on various TI SoCs such asAM335x or AM437x or the Keystone 66AK2G. Each SoC can haveone or more PRUSS instances that may or may not be identical.For example, AM335x SoCs have a single PRUSS, while AM437x hastwo PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 beinga cut-down version of the PRUSS1.The PRUSS consists of dual 32-bit RISC cores called theProgrammable Real-Time Units (PRUs), some shared, data andinstruction memories, some internal peripheral modules, andan interrupt controller. The programmable nature of the PRUsprovide flexibility to implement custom peripheral interfaces,fast real-time responses, or specialized data handling.The PRU-ICSS functionality is achieved through three differentplatform drivers addressing a specific portion of the PRUSS.Some sub-modules of the PRU-ICSS IP reuse some of the existingdrivers (like davinci mdio driver or the generic syscon driver).This design provides flexibility in representing the differentmodules of PRUSS accordingly, and at the same time allowing thePRUSS driver to add some instance specific configuration withinan SoC.The PRUSS platform driver deals with the overall PRUSS and isused for managing the subsystem level resources like variousmemories and the CFG module. It is responsible for the creationand deletion of the platform devices for the child PRU devicesand other child devices (like Interrupt Controller, MDIO nodeand some syscon nodes) so that they can be managed by specificplatform drivers. The PRUSS interrupt controller is managed byan irqchip driver, while the individual PRU RISC cores aremanaged by a PRU remoteproc driver.The driver currently supports the AM335x SoC, and support forother TI SoCs will be added in subsequent patches.Signed-off-by: Suman Anna Signed-off-by: Andrew F. Davis Signed-off-by: Tero Kristo Signed-off-by: Grzegorz Jaszczyk Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

907a2b7e - soc: ti: add k3 platforms chipid module driver

Thu, 28 May 2020 03:39:14 +0000

soc: ti: add k3 platforms chipid module driverThe Texas Instruments K3 Multicore SoC platforms have chipid module whichis represented by CTRLMMR_xxx_JTAGID register and contains informationabout SoC id and revision. Bits: 31-28 VARIANT Device variant 27-12 PARTNO Part number 11-1 MFG Indicates TI as manufacturer (0x17) 1 Always 1This patch adds corresponding driver to identify the TI K3 SoC family andrevision, and registers this information with the SoC bus. It is availableunder /sys/devices/soc0/ for user space, and can be checked, where needed,in Kernel using soc_device_match().Identification is done by:- checking MFG to be TI ID - retrieving Device variant (revision) - retrieving Part number and convert it to the family - retrieving machine from DT "/model"Example J721E: # cat /sys/devices/soc0/{machine,family,revision} Texas Instruments K3 J721E SoC J721E SR1.0Example AM65x: # cat /sys/devices/soc0/{machine,family,revision} Texas Instruments AM654 Base Board AM65X SR1.0Cc: Arnd Bergmann Signed-off-by: Grygorii Strashko Reviewed-by: Lokesh Vutla Reviewed-by: Tero Kristo Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

3277e8aa - soc: ti: k3: add navss ringacc driver

Wed, 15 Jan 2020 18:07:27 +0000

soc: ti: k3: add navss ringacc driverThe Ring Accelerator (RINGACC or RA) provides hardware acceleration toenable 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 equivalentread or write accesses to a circular data structure in memory. The RINGACCeliminates the need for each DMA controller which needs to access ringelements from having to know the current state of the ring (base address,current offset). The DMA controller performs a read or write access to aspecific address range (which maps to the source interface on the RINGACC)and the RINGACC replaces the address for the transaction with a new addresswhich corresponds to the head or tail element of the ring (head for reads,tail for writes). Since the RINGACC maintains the state, multiple DMAcontrollers or channels are allowed to coherently share the same rings asapplicable. The RINGACC is able to place data which is destined towardssoftware into cached memory directly.Supported ring modes:- Ring Mode- Messaging Mode- Credentials Mode- Queue Manager ModeTI-SCI integration:Texas Instrument's System Control Interface (TI-SCI) Message Protocol nowhas control over Ringacc module resources management (RM) and Ringsconfiguration.The corresponding support of TI-SCI Ringacc module RM protocolintroduced as option through DT parameters:- ti,sci: phandle on TI-SCI firmware controller DT node- ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware specif both parameters present - Ringacc driver will configure/free/reset Ringsusing TI-SCI Message Ringacc RM Protocol.The Ringacc driver manages Rings allocation by itself now and requestsTI-SCI firmware to allocate and configure specific Rings only. It's donethis way because, Linux driver implements two stage Rings allocation andconfiguration (allocate ring and configure ring) while TI-SCI MessageProtocol supports only one combined operation (allocate+configure).Signed-off-by: Grygorii Strashko Signed-off-by: Peter Ujfalusi Reviewed-by: Tero Kristo Tested-by: Keerthy Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

3e99cb21 - soc: ti: add initial PRM driver with reset control support

Wed, 09 Oct 2019 15:55:36 +0000

soc: ti: add initial PRM driver with reset control supportAdd initial PRM (Power and Reset Management) driver for TI OMAP classSoCs. Initially this driver only supports reset control, but can beextended to support rest of the functionality, like powerdomaincontrol, PRCM irq support etc.Signed-off-by: Tero Kristo Reviewed-by: Philipp Zabel Reviewed-by: Tony Lindgren Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

49b32315 - soc: ti: Add MSI domain bus support for Interrupt Aggregator

Tue, 30 Apr 2019 10:12:28 +0000

soc: ti: Add MSI domain bus support for Interrupt AggregatorWith the system coprocessor managing the range allocation of theinputs to Interrupt Aggregator, it is difficult to representthe device IRQs from DT.The suggestion is to use MSI in such cases where devices wantsto allocate and group interrupts dynamically.Create a MSI domain bus layer that allocates and frees MSIs fora device.APIs that are implemented:- ti_sci_inta_msi_create_irq_domain() that creates a MSI domain- ti_sci_inta_msi_domain_alloc_irqs() that creates MSIs for the specified device and resource.- ti_sci_inta_msi_domain_free_irqs() frees the irqs attached to the device.- ti_sci_inta_msi_get_virq() for getting the virq attached to a specific event.Signed-off-by: Lokesh Vutla Signed-off-by: Marc Zyngier List of files: /linux-6.15/drivers/soc/ti/Makefile

afe761f8 - soc: ti: Add pm33xx driver for basic suspend support

Fri, 23 Feb 2018 15:43:57 +0000

soc: ti: Add pm33xx driver for basic suspend supportAM335x and AM437x support various low power modes as documentedin section 8.1.4.3 of the AM335x Technical Reference Manual andsection 6.4.3 of the AM437x Technical Reference Manual.DeepSleep0 mode offers the lowest power mode with limitedwakeup sources without a system reboot and is mapped asthe suspend state in the kernel. In this state, MPU andPER domains are turned off with the internal RAM held inretention to facilitate the resume process. As part ofthe boot process, the assembly code is copied over to OCMCRAMso it can be executed to turn of the EMIF and put DDR into selfrefresh.Both platforms have a Cortex-M3 (WKUP_M3) which assists the MPUin DeepSleep0 entry and exit. WKUP_M3 takes careof the clockdomain and powerdomain transitions based on theintended low power state. MPU needs to load the appropriateWKUP_M3 binary onto the WKUP_M3 memory space before it canleverage any of the PM features like DeepSleep. This loadingis handled by the remoteproc driver wkup_m3_rproc.Communication with the WKUP_M3 is handled by a wkup_m3_ipcdriver that exposes the specific PM functionality to be usedthe PM code.In the current implementation when the suspend processis initiated, MPU interrupts the WKUP_M3 to let it know aboutthe intent of entering DeepSleep0 and waits for an ACK. Whenthe ACK is received MPU continues with its suspend processto suspend all the drivers and then jumps to assembly inOCMC RAM. The assembly code puts the external RAM in self-refreshmode, gates the MPU clock, and then finally executes the WFIinstruction. Execution of the WFI instruction with MPU clock gatedtriggers another interrupt to the WKUP_M3 which then continueswith the power down sequence wherein the clockdomain andpowerdomain transition takes place. As part of the sleep sequence,WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFIexecution on WKUP_M3 causes the hardware to disable the mainoscillator of the SoC and from here system remains in sleep stateuntil a wake source brings the system into resume path.When a wakeup event occurs, WKUP_M3 starts the power-upsequence by switching on the power domains and finallyenabling the clock to MPU. Since the MPU gets powered downas part of the sleep sequence in the resume path ROM codestarts executing. The ROM code detects a wakeup from sleepand then jumps to the resume location in OCMC which waspopulated in one of the IPC registers as part of the suspendsequence.Code is based on work by Vaibhav Bedia.Signed-off-by: Dave Gerlach Acked-by: Santosh Shilimkar Signed-off-by: Tony Lindgren List of files: /linux-6.15/drivers/soc/ti/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/soc/ti/Makefile

52835d59 - soc: ti: Add ti_sci_pm_domains driver

Tue, 04 Apr 2017 15:59:27 +0000

soc: ti: Add ti_sci_pm_domains driverIntroduce a ti_sci_pm_domains driver to act as a generic pm domainprovider to allow each device to attach and associate it's ti-sci-id sothat it can be controlled through the TI SCI protocol.This driver implements a simple genpd where each device node has aphandle to the power domain node and also must provide an index whichrepresents the ID to be passed with TI SCI representing the device usinga single phandle cell. The driver manually parses the phandle to get thecell value. Through this interface the genpd dev_ops start and stophooks will use TI SCI to turn on and off each device as determined bypm_runtime usage.Reviewed-by: Kevin Hilman Acked-by: Santosh Shilimkar Reviewed-by: Ulf Hansson Signed-off-by: Keerthy Signed-off-by: Nishanth Menon Signed-off-by: Dave Gerlach Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

cdd5de50 - soc: ti: Add wkup_m3_ipc driver

Wed, 23 Sep 2015 00:14:54 +0000

soc: ti: Add wkup_m3_ipc driverIntroduce a wkup_m3_ipc driver to handle communication between the MPUand Cortex M3 wkup_m3 present on am335x.This driver is responsible for actually booting the wkup_m3_rproc andalso handling all IPC which is done using the IPC registers in the controlmodule, a mailbox, and a separate interrupt back from the wkup_m3. A smallAPI is exposed for executing specific power commands, which includeconfiguring for low power mode, request a transition to a low power mode,and status info on a previous transition.Signed-off-by: Dave Gerlach Signed-off-by: Tony Lindgren List of files: /linux-6.15/drivers/soc/ti/Makefile

df351f1e - soc: ti: knav_qmss_queue: makefile tweak to build as dynamic module

Thu, 29 Jan 2015 21:23:51 +0000

soc: ti: knav_qmss_queue: makefile tweak to build as dynamic moduleCurrently configuring qmss and dma as dynamic module creates three .kofiles. knav_qmss_acc.ko and knav_qmss_queue.ko both can't be insmodbecause of circular dependency. So combine these two into one moduleby changing the makefile.Signed-off-by: Murali Karicheri Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

88139ed0 - soc: ti: add Keystone Navigator DMA support

Sun, 30 Mar 2014 21:29:04 +0000

soc: ti: add Keystone Navigator DMA supportThe Keystone Navigator DMA driver sets up the dma channels and flows forthe QMSS(Queue Manager SubSystem) who triggers the actual data movementsacross clients using destination queues. Every client modules likeNETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTOEngines has its own instance of packet dma hardware. QMSS has alsoan internal packet DMA module which is used as an infrastructureDMA with zero copy.Initially this driver was proposed as DMA engine driver but since thehardware is not typical DMA engine and hence doesn't comply with typicalDMA engine driver needs, that approach was naked. Link to thatdiscussion - https://lkml.org/lkml/2014/3/18/340As aligned, now we pair the Navigator DMA with its companion NavigatorQMSS subsystem driver.Cc: Greg Kroah-Hartman Cc: Kumar Gala Cc: Olof Johansson Cc: Arnd Bergmann Cc: Grant Likely Cc: Rob Herring Cc: Mark Rutland Signed-off-by: Sandeep Nair Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile

41f93af9 - soc: ti: add Keystone Navigator QMSS driver

Fri, 28 Feb 2014 15:47:50 +0000

soc: ti: add Keystone Navigator QMSS driverThe QMSS (Queue Manager Sub System) found on Keystone SOCs is one ofthe main hardware sub system which forms the backbone of the KeystoneMulti-core Navigator. QMSS consist of queue managers, packed-data structureprocessors(PDSP), linking RAM, descriptor pools and infrastructurePacket DMA.The Queue Manager is a hardware module that is responsible for acceleratingmanagement of the packet queues. Packets are queued/de-queued by writing orreading descriptor address to a particular memory mapped location. The PDSPsperform QMSS related functions like accumulation, QoS, or event management.Linking RAM registers are used to link the descriptors which are stored indescriptor RAM. Descriptor RAM is configurable as internal or external memory.The QMSS driver manages the PDSP setups, linking RAM regions,queue pool management (allocation, push, pop and notify) and descriptorpool management. The specifics on the device tree bindings forQMSS can be found in: Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txtCc: Greg Kroah-Hartman Cc: Kumar Gala Cc: Olof Johansson Cc: Arnd Bergmann Cc: Grant Likely Cc: Rob Herring Cc: Mark Rutland Signed-off-by: Sandeep Nair Signed-off-by: Santosh Shilimkar List of files: /linux-6.15/drivers/soc/ti/Makefile