History log of /freebsd-current/sys/arm/ti/ti_cpuid.h
Revision Date Author Comments
# 95ee2897 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix


# af3dc4a7 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys/arm: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.


# 69d14913 12-Sep-2017 Olivier Houchard <cognet@FreeBSD.org>

Some devices come with the same name as TI devices, so we can't rely on the
"probe" method of those drivers to mean we're on e TI SoC. Introduce a new
function, ti_soc_is_supported(), and use it to be sure we're really a TI
system.

PR: 222250


# cbfebd9a 19-Nov-2016 Olivier Houchard <cognet@FreeBSD.org>

The only remaining offender that used ti_chip() without checking for
compatibility first was the gpio code, so change that, and re-assert
that the TI chip is a known chip


# 80d2898d 19-Nov-2016 Olivier Houchard <cognet@FreeBSD.org>

Don't panic if it's not a TI chip, this code can be called when it is not.


# 31a2ddf2 18-Nov-2016 Olivier Houchard <cognet@FreeBSD.org>

Guess the TI chip based on the PLATFORM infos, instead of relying on the
kernel config file.


# 56d8b96c 13-Oct-2014 Andrew Turner <andrew@FreeBSD.org>

Start removing the omap3 support. In base it was only ever a header and a
few changes to drivers, no kernel config was added. As the SoCs are quite
old and the code is unmaintained start the process of removing support by
deleting the header file and code that depends on it along with the macro
SOC_OMAP3. Other Ti SoCs shouldn't be affected, other than for us to have
less code to maintain.

Differential Revision: https://reviews.freebsd.org/D936
Reviewed by: rpaulo, loos


# 5c79e1dd 07-Jan-2013 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Identify more devices for OMAP4 SoC (up to OMAP4470)
- Whitespace fixes


# e53470fe 15-Aug-2012 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

Merging of projects/armv6, part 10

- Support for Texas Instruments SoCs:
- AM335x
- OMAP4

- Kernel configs, DTS for Beaglebone and Pandaboard

Submitted by: Ben Gray, Damjan Marion