License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license 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 binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the 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 cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base 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 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately 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 license
identifiers 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 the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version 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 correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 08:07:57 -06:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2005-11-10 07:26:51 -07:00
|
|
|
#
|
|
|
|
|
# Makefile for the linux kernel.
|
|
|
|
|
#
|
|
|
|
|
|
2016-04-06 02:14:08 -06:00
|
|
|
ccflags-y := -I$(srctree)/$(src)/include \
|
2013-01-11 12:24:20 -07:00
|
|
|
-I$(srctree)/arch/arm/plat-omap/include
|
|
|
|
|
|
2005-11-10 07:26:51 -07:00
|
|
|
# Common support
|
2016-10-20 07:42:19 -06:00
|
|
|
obj-y := id.o io.o control.o devices.o fb.o timer.o pm.o \
|
2016-11-21 10:26:27 -07:00
|
|
|
common.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
|
2017-08-11 07:49:10 -06:00
|
|
|
omap_device.o omap-headsmp.o sram.o
|
2009-05-25 12:26:47 -06:00
|
|
|
|
2013-02-10 11:22:23 -07:00
|
|
|
hwmod-common = omap_hwmod.o omap_hwmod_reset.o \
|
2012-10-21 01:01:10 -06:00
|
|
|
omap_hwmod_common_data.o
|
2015-03-02 08:06:59 -07:00
|
|
|
clock-common = clock.o
|
2012-10-21 01:01:10 -06:00
|
|
|
secure-common = omap-smc.o omap-secure.o
|
2012-09-11 19:09:14 -06:00
|
|
|
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
|
2013-11-16 08:15:25 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(hwmod-common) $(secure-common)
|
2014-09-15 15:15:02 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += $(hwmod-common)
|
2013-11-16 08:15:25 -07:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(hwmod-common) $(secure-common)
|
2013-05-27 08:35:41 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common)
|
2013-11-16 08:15:25 -07:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(hwmod-common) $(secure-common)
|
2012-09-11 19:09:14 -06:00
|
|
|
|
2018-12-17 05:21:37 -07:00
|
|
|
ifneq ($(CONFIG_SND_SOC_OMAP_MCBSP),)
|
2012-03-09 01:23:27 -07:00
|
|
|
obj-y += mcbsp.o
|
|
|
|
|
endif
|
2008-07-03 03:24:40 -06:00
|
|
|
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
|
|
|
|
|
obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
|
2010-12-10 10:21:05 -07:00
|
|
|
|
2009-04-28 09:22:05 -06:00
|
|
|
# SMP support ONLY available for OMAP4
|
2012-04-28 08:27:32 -06:00
|
|
|
|
2016-06-22 02:59:39 -06:00
|
|
|
smp-$(CONFIG_SMP) += omap-smp.o
|
2013-04-30 14:24:50 -06:00
|
|
|
smp-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
|
2013-06-24 02:13:45 -06:00
|
|
|
omap-4-5-common = omap4-common.o omap-wakeupgen.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) $(smp-y) sleep44xx.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) $(smp-y) sleep44xx.o
|
2013-05-27 08:35:41 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common)
|
2013-11-15 09:27:29 -07:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o
|
2010-03-11 00:33:46 -07:00
|
|
|
|
2008-07-03 03:24:38 -06:00
|
|
|
# Functions loaded to SRAM
|
2011-01-27 17:39:40 -07:00
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += sram243x.o
|
2008-07-03 03:24:38 -06:00
|
|
|
|
2012-10-29 20:56:07 -06:00
|
|
|
# Restart code (OMAP4/5 currently in omap4-common.c)
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += omap2-restart.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += omap2-restart.o
|
2015-01-14 18:37:16 -07:00
|
|
|
obj-$(CONFIG_SOC_TI81XX) += ti81xx-restart.o
|
2013-01-23 14:02:40 -07:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += am33xx-restart.o
|
2014-02-28 12:43:45 -07:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += omap4-restart.o
|
2012-10-29 20:56:07 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += omap3-restart.o
|
2013-05-27 08:35:19 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += omap4-restart.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP5) += omap4-restart.o
|
2013-07-09 01:32:15 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += omap4-restart.o
|
2012-10-29 20:56:07 -06:00
|
|
|
|
2009-01-28 12:27:37 -07:00
|
|
|
# SMS/SDRC
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
|
|
|
|
|
# obj-$(CONFIG_ARCH_OMAP3) += sdrc3xxx.o
|
|
|
|
|
|
2010-12-09 08:13:46 -07:00
|
|
|
# OPP table initialization
|
|
|
|
|
ifeq ($(CONFIG_PM_OPP),y)
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
|
2010-12-09 08:13:47 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += opp4xxx_data.o
|
2010-12-09 08:13:46 -07:00
|
|
|
endif
|
|
|
|
|
|
2006-04-02 10:46:27 -06:00
|
|
|
# Power Management
|
2016-07-04 00:29:45 -06:00
|
|
|
omap-4-5-pm-common = omap-mpuss-lowpower.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common)
|
2016-11-07 16:50:10 -07:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-pm-common)
|
2012-11-14 09:40:00 -07:00
|
|
|
|
2008-10-06 06:49:15 -06:00
|
|
|
ifeq ($(CONFIG_PM),y)
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
|
2016-07-04 00:29:45 -06:00
|
|
|
omap-4-5-pm-common += pm44xx.o
|
2014-09-09 11:15:33 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common)
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-pm-common)
|
|
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-pm-common)
|
2018-02-23 08:43:56 -07:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += pm33xx-core.o sleep33xx.o
|
|
|
|
|
obj-$(CONFIG_SOC_AM43XX) += pm33xx-core.o sleep43xx.o
|
2009-05-28 11:56:16 -06:00
|
|
|
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
|
2012-04-24 00:08:50 -06:00
|
|
|
|
2012-04-25 05:13:17 -06:00
|
|
|
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_POWER_AVS_OMAP_CLASS3) += smartreflex-class3.o
|
2010-02-12 13:26:46 -07:00
|
|
|
|
2008-10-06 06:49:15 -06:00
|
|
|
endif
|
2006-04-02 10:46:27 -06:00
|
|
|
|
2012-05-10 04:02:57 -06:00
|
|
|
ifeq ($(CONFIG_CPU_IDLE),y)
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o
|
2014-09-09 11:15:33 -06:00
|
|
|
omap-4-5-idle-common = cpuidle44xx.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-idle-common)
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-idle-common)
|
|
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-idle-common)
|
2012-05-10 04:02:57 -06:00
|
|
|
endif
|
|
|
|
|
|
2009-09-03 11:14:02 -06:00
|
|
|
# PRCM
|
2012-10-29 20:59:29 -06:00
|
|
|
obj-y += prm_common.o cm_common.o
|
2012-10-21 01:01:11 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += prm2xxx_3xxx.o prm2xxx.o cm2xxx.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += prm2xxx_3xxx.o prm3xxx.o cm3xxx.o
|
2012-09-11 19:09:15 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o
|
2014-10-27 09:39:25 -06:00
|
|
|
omap-prcm-4-5-common = cminst44xx.o prm44xx.o \
|
2012-06-05 04:51:32 -06:00
|
|
|
prcm_mpu44xx.o prminst44xx.o \
|
2012-10-21 01:01:10 -06:00
|
|
|
vc44xx_data.o vp44xx_data.o
|
2012-09-11 19:09:15 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common)
|
2012-06-05 04:51:32 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(omap-prcm-4-5-common)
|
2013-07-03 00:08:50 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common)
|
2014-06-15 16:02:17 -06:00
|
|
|
am33xx-43xx-prcm-common += prm33xx.o cm33xx.o
|
2015-01-26 10:26:32 -07:00
|
|
|
obj-$(CONFIG_SOC_TI81XX) += $(am33xx-43xx-prcm-common)
|
2014-06-15 16:02:17 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common)
|
|
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \
|
|
|
|
|
$(am33xx-43xx-prcm-common)
|
2011-03-10 22:17:45 -07:00
|
|
|
|
|
|
|
|
# OMAP voltage domains
|
2012-10-21 01:01:10 -06:00
|
|
|
voltagedomain-common := voltage.o vc.o vp.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += voltagedomains2xxx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += voltagedomains3xxx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common)
|
2013-05-27 08:35:41 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(voltagedomain-common)
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(voltagedomain-common)
|
2013-05-29 10:38:12 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += voltagedomains54xx_data.o
|
2014-01-10 02:25:28 -07:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(voltagedomain-common)
|
2010-12-21 20:01:17 -07:00
|
|
|
|
|
|
|
|
# OMAP powerdomain framework
|
2012-10-21 01:01:10 -06:00
|
|
|
powerdomain-common += powerdomain.o powerdomain-common.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(powerdomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_data.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx_3xxx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(powerdomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += powerdomains3xxx_data.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += powerdomains2xxx_3xxx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common)
|
ARM: OMAP AM33xx: powerdomains: add AM335x support
Add offset & mask fields to struct powerdomain
In case of AM33xx family of devices, there is no consistency between
PWRSTCTRL & PWRSTST register offsers in PRM space, for example -
PRM_XXX PWRSTCTRL PWRSTST
=======================================
PRM_PER_MOD: 0x0C, 0x08
PRM_WKUP_MOD: 0x04, 0x08
PRM_MPU_MOD: 0x00, 0x04
PRM_DEVICE_MOD: NA, NA
And also, there is no consistency between bit-offsets inside
PWRSTCTRL & PWRSTST register, for example -
PRM_XXX LOGICRET MEMON MEMRET
=======================================
GFX_PWRCTRL: 2, 17, 6
PER_PWRCTRL: 3, 25, 29
MPU_PWRCTRL: 2, 18, 22
WKUP_PWRCTRL: 3, NA, NA
This means, we need to maintain and pass on all this information
in powerdomain handle; so adding fields for,
- PWRSTCTRL/ST register offset
- Logic retention state mask
- mem_on/ret/pwrst/retst mask
Currently, this fields is only applicable and used for AM33XX devices.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: this patch is a combination of "Add offset & mask fields to
struct powerdomain" and the powerdomain portions of "ARM: OMAP3+: am33xx:
Add powerdomain & PRM support"; updated for 3.5]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-06-18 00:47:27 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o
|
2013-05-27 08:35:41 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(powerdomain-common)
|
2013-10-12 04:16:28 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += powerdomains43xx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(powerdomain-common)
|
2013-05-29 10:38:12 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += powerdomains54xx_data.o
|
2013-07-03 00:08:50 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(powerdomain-common)
|
2013-07-09 01:32:13 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += powerdomains7xx_data.o
|
2009-09-03 11:14:02 -06:00
|
|
|
|
2010-12-21 20:01:20 -07:00
|
|
|
# PRCM clockdomain control
|
2012-10-21 01:01:10 -06:00
|
|
|
clockdomain-common += clockdomain.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o
|
2011-09-14 16:01:21 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += clockdomains2420_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += clockdomains2430_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(clockdomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += clockdomains2xxx_3xxx_data.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += clockdomains3xxx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common)
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common)
|
2012-06-18 00:47:27 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o
|
2015-01-26 10:26:32 -07:00
|
|
|
obj-$(CONFIG_SOC_TI81XX) += $(clockdomain-common)
|
|
|
|
|
obj-$(CONFIG_SOC_TI81XX) += clockdomains81xx_data.o
|
2013-05-27 08:35:41 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common)
|
2013-10-12 04:16:28 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += clockdomains43xx_data.o
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(clockdomain-common)
|
2013-05-29 10:38:12 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += clockdomains54xx_data.o
|
2013-07-03 00:08:50 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(clockdomain-common)
|
2013-07-09 01:32:12 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += clockdomains7xx_data.o
|
2011-02-25 15:39:28 -07:00
|
|
|
|
2008-03-18 06:41:40 -06:00
|
|
|
# Clock framework
|
2015-03-03 01:58:56 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common)
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_dpllcore.o
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_virt_prcm_set.o
|
2015-03-02 05:33:54 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP2) += clkt2xxx_dpll.o
|
2015-03-04 02:56:22 -07:00
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += $(clock-common)
|
2013-07-18 07:04:00 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += $(clock-common)
|
2015-03-03 04:27:48 -07:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += $(clock-common)
|
2012-10-21 01:01:10 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += $(clock-common)
|
2014-01-10 02:20:18 -07:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += $(clock-common)
|
2015-03-03 04:27:48 -07:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += $(clock-common)
|
OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family. To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL
clkops structure. The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it. (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
2010-02-22 22:09:20 -07:00
|
|
|
|
|
|
|
|
# OMAP2 clock rate set data (old "OPP" data)
|
2011-01-27 17:39:40 -07:00
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
|
2008-03-18 06:41:40 -06:00
|
|
|
|
2010-02-22 22:09:32 -07:00
|
|
|
# hwmod data
|
2014-07-05 17:44:57 -06:00
|
|
|
obj-y += omap_hwmod_common_ipblock_data.o
|
2012-04-28 08:27:32 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_ipblock_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_3xxx_ipblock_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_interconnect_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2420_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_ipblock_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_3xxx_ipblock_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2xxx_interconnect_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2430) += omap_hwmod_2430_data.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_2xxx_3xxx_ipblock_data.o
|
|
|
|
|
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
|
2012-07-25 13:51:13 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_data.o
|
2013-10-12 04:14:46 -06:00
|
|
|
obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_interconnect_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_ipblock_data.o
|
2013-10-12 04:16:28 -06:00
|
|
|
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_interconnect_data.o
|
|
|
|
|
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o
|
2015-01-26 10:26:32 -07:00
|
|
|
obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o
|
2010-05-12 09:54:36 -06:00
|
|
|
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
|
2013-05-29 10:38:12 -06:00
|
|
|
obj-$(CONFIG_SOC_OMAP5) += omap_hwmod_54xx_data.o
|
2013-07-09 01:32:16 -06:00
|
|
|
obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o
|
2008-03-18 06:41:40 -06:00
|
|
|
|
2012-05-08 17:23:33 -06:00
|
|
|
# OMAP2420 MSDI controller integration support ("MMC")
|
|
|
|
|
obj-$(CONFIG_SOC_OMAP2420) += msdi.o
|
|
|
|
|
|
2005-11-10 07:26:51 -07:00
|
|
|
# Specific board support
|
2013-09-25 16:44:39 -06:00
|
|
|
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o pdata-quirks.o
|
2009-08-28 11:51:38 -06:00
|
|
|
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
|
2011-08-23 00:57:23 -06:00
|
|
|
|
2009-03-23 19:34:06 -06:00
|
|
|
# Platform specific device init code
|
2011-08-23 00:57:23 -06:00
|
|
|
|
|
|
|
|
omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o
|
|
|
|
|
obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y)
|
|
|
|
|
|
2011-07-10 03:22:20 -06:00
|
|
|
obj-y += omap_phy_internal.o
|
|
|
|
|
|
2009-08-28 11:51:37 -06:00
|
|
|
obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o
|
2018-02-23 08:43:56 -07:00
|
|
|
|
ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2
<generated/ti-pm-asm-offsets.h> is only generated and included by
arch/arm/mach-omap2/, so it does not need to reside in the globally
visible include/generated/.
I renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix
'ti-' is just redundant in mach-omap2/.
My main motivation of this change is to avoid the race condition for
the parallel build (-j) when CONFIG_IKHEADERS is enabled.
When it is enabled, all the headers under include/ are archived into
kernel/kheaders_data.tar.xz and exposed in the sysfs.
In the parallel build, we have no idea in which order files are built.
- If ti-pm-asm-offsets.h is built before kheaders_data.tar.xz,
the header will be included in the archive. Probably nobody will
use it, but it is harmless except that it will increase the archive
size needlessly.
- If kheaders_data.tar.xz is built before ti-pm-asm-offsets.h,
the header will not be included in the archive. However, in the next
build, the archive will be re-generated to include the newly-found
ti-pm-asm-offsets.h. This is not nice from the build system point
of view.
- If ti-pm-asm-offsets.h and kheaders_data.tar.xz are built at the
same time, the corrupted header might be included in the archive,
which does not look nice either.
This commit fixes the race.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-22 20:58:08 -06:00
|
|
|
$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE
|
2018-02-23 08:43:56 -07:00
|
|
|
$(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__)
|
|
|
|
|
|
ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2
<generated/ti-pm-asm-offsets.h> is only generated and included by
arch/arm/mach-omap2/, so it does not need to reside in the globally
visible include/generated/.
I renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix
'ti-' is just redundant in mach-omap2/.
My main motivation of this change is to avoid the race condition for
the parallel build (-j) when CONFIG_IKHEADERS is enabled.
When it is enabled, all the headers under include/ are archived into
kernel/kheaders_data.tar.xz and exposed in the sysfs.
In the parallel build, we have no idea in which order files are built.
- If ti-pm-asm-offsets.h is built before kheaders_data.tar.xz,
the header will be included in the archive. Probably nobody will
use it, but it is harmless except that it will increase the archive
size needlessly.
- If kheaders_data.tar.xz is built before ti-pm-asm-offsets.h,
the header will not be included in the archive. However, in the next
build, the archive will be re-generated to include the newly-found
ti-pm-asm-offsets.h. This is not nice from the build system point
of view.
- If ti-pm-asm-offsets.h and kheaders_data.tar.xz are built at the
same time, the corrupted header might be included in the archive,
which does not look nice either.
This commit fixes the race.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-22 20:58:08 -06:00
|
|
|
$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h
|
2018-12-22 02:50:34 -07:00
|
|
|
|
|
|
|
|
targets += pm-asm-offsets.s
|
ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2
<generated/ti-pm-asm-offsets.h> is only generated and included by
arch/arm/mach-omap2/, so it does not need to reside in the globally
visible include/generated/.
I renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix
'ti-' is just redundant in mach-omap2/.
My main motivation of this change is to avoid the race condition for
the parallel build (-j) when CONFIG_IKHEADERS is enabled.
When it is enabled, all the headers under include/ are archived into
kernel/kheaders_data.tar.xz and exposed in the sysfs.
In the parallel build, we have no idea in which order files are built.
- If ti-pm-asm-offsets.h is built before kheaders_data.tar.xz,
the header will be included in the archive. Probably nobody will
use it, but it is harmless except that it will increase the archive
size needlessly.
- If kheaders_data.tar.xz is built before ti-pm-asm-offsets.h,
the header will not be included in the archive. However, in the next
build, the archive will be re-generated to include the newly-found
ti-pm-asm-offsets.h. This is not nice from the build system point
of view.
- If ti-pm-asm-offsets.h and kheaders_data.tar.xz are built at the
same time, the corrupted header might be included in the archive,
which does not look nice either.
This commit fixes the race.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-22 20:58:08 -06:00
|
|
|
clean-files += pm-asm-offsets.h
|
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
Support has been added to the OMAP IOMMU driver to fix a boot hang
issue on OMAP remoteprocs with AMMU/Unicache, caused by an improper
AMMU/Unicache state upon initial deassertion of the processor reset.
The issue is described in detail in the next three paragraphs.
All the Cortex M3/M4 IPU processor subsystems in OMAP SoCs have a
AMMU/Unicache IP that dictates the memory attributes for addresses
seen by the processor cores. The AMMU/Unicache is configured/enabled
by the SCACHE_CONFIG.BYPASS bit - a value of 1 enables the cache and
mandates all addresses accessed by M3/M4 be defined in the AMMU. This
bit is not programmable from the host processor. The M3/M4 boot
sequence starts out with the AMMU/Unicache in disabled state, and
SYS/BIOS programs the AMMU regions and enables the Unicache during
one of its initial boot steps. This SCACHE_CONFIG.BYPASS bit is
however enabled by default whenever a RET reset is applied to the IP,
irrespective of whether it was previously enabled or not. The AMMU
registers lose their context whenever this reset is applied. The reset
is effective as long as the MMU portion of the subsystem is enabled
and clocked. This behavior is common to all the IPU and DSP subsystems
that have an AMMU/Unicache.
The IPU boot sequence involves enabling and programming the MMU, and
loading the processor and releasing the reset(s) for the processor.
The PM setup code currently sets the target state for most of the
power domains to RET. The L2 MMU can be enabled, programmed and
accessed properly just fine with the domain in hardware supervised
mode, while the power domain goes through a RET->ON->RET transition
during the programming sequence. However, the ON->RET transition
asserts a RET reset, and the SCACHE_CONFIG.BYPASS bit gets auto-set.
An AMMU fault is thrown immediately when the M3/M4 core's reset is
released since the first instruction address itself will not be
defined in any valid AMMU regions. The ON->RET transition happens
automatically on the power domain after enabling the iommu due to
the hardware supervised mode.
This patch adds and invokes the .set_pwrdm_constraint pdata ops, if
present, during the OMAP IOMMU enable and disable functions to resolve
the above boot hang issue. The ops will allow to invoke a mach-omap2
layer API pwrdm_set_next_pwrst() in a multi-arch kernel environment.
The ops also returns the current power domain state while enforcing
the constraint so that the driver can store it and use it to set back
the power domain state while releasing the constraint. The pdata ops
implementation restricts the target power domain to ON during enable,
and back to the original power domain state during disable, and thereby
eliminating the conditions for the boot issue. The implementation is
effective only when the original power domain state is either RET or
OFF, and is a no-op when it is ON or INACTIVE.
The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.
Note that the current issue is seen only on kernels with the affected
power domains programmed to enter RET. For eg., IPU1 on DRA7xx is in a
separate domain and is susceptible to this bug, while the IPU2 subsystem
is within CORE power domain, and CORE RET is not supported on this SoC.
IPUs on OMAP4 and OMAP5 are also susceptible since they are in CORE power
domain, and CORE RET is a valid power target on these SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-07 02:26:45 -06:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
|