Over the past ten years, new machine support was based on device tree,
and an initial set of about 400 boards using ATAGS with boardfile
for booting were grandfathered in, with about half of them either
removed or converted to DT over time.
Based on the recent mailing list discussion I started, I have now
turned the findings into a set of patches that marks most board files as
'depends on UNUSED_BOARD_FILES', leaving only 38 of the 196 boards.
For the boards that are marked as unused, there are two final chances
for potential users: The removal is scheduled to take place after the
longterm stable kernel at the end of 2022, so users can stay on that
version for another few years, and if anyone still has one of these
machines and is planning to keep updating kernels beyond that version,
they can speak up now to have their boards taken off the list again.
Waiting for the LTS release also makes sure that there will be at
least one longterm kernel that contains the recent multiplatform
conversion along while still supporting all legacy boards.
The short summary of the current status is:
- The s3c24xx, cns3xxx, iop32x and mv78xx0 platforms have no known
users and will be removed entirely.
- The mmp and davinci platforms have DT support for the important
machines and will become DT-only after this.
- s3c64xx, dove, orion5x, and pxa keep some board files to allow
those to be migrated over to DT more easily, but most board files
are getting removed now. DT support on these platforms is partially
working but requires changes to additional drivers for the other
boards.
- omap1, ep93xx, sa1100, footbridge and rpc have no DT support at
the moment but have some boards with known users. Removing the board
files that nobody uses should make it easier to try a DT conversion
if anyone cares.
There is no explicit timeline what happens with the boards that remain
after this removal, but I expect to revisit this in the future, and
with most boards gone, there will be a good time to do a treewide
review of platform drivers that never gained DT support and have no
remaining in-tree board files.
Link: https://lore.kernel.org/linux-arm-kernel/CAK8P3a0Z9vGEQbVRBo84bSyPFM-LF+hs5w8ZA51g2Z+NsdtDQA@mail.gmail.com/
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLo+30ACgkQmmx57+YA
GNnibw//anM6PmfEX9Oeh2sJb7B7scUOMYrhUiw7e//pJ3kD68thviWwkMC0O8x6
05bjFscnCo+AXuZ6TKChFHDrZxJXdJzEpFmGaKVu9LAZjVBGjWaXVeI5xiTGn01b
Og9tqPsRqHFfeo3MzrubVUmOv/lbceXoqrep7i+MHfYvmAMWwfGg54JChmABvYSZ
6si4NNLj1U+Eav0uj9Ge2ucBfzN6z1nJeo6I68GXTuAjZcrtlgAEcgTK0X6yMnTF
Sv3TzX/B3QG7t0Jib+PSYrDDVxqMJM+e+m8d/qyHFW5am/9ML/fSn2OyPYigfs1+
0/dgh0+Qu6GG+Xjr+wx5DY7EE/uM9AqvdJiKhGWPfGv++K5H2r/wMeIvbmXlzlrr
JRWpKXUHCPdcGKyouJlDOiT3XfBU7X1gfMUK6Os/WYLxLgPo+9+syQtJBMA2PtnJ
USlS31vLJbitInDgj9DWtXagBvDvzaUdW9NBwHtE2I3FqsvSZXCqvTpNgkmX7a1v
qYJuoMHeppFP6Ylq4Lcu+5DHR9rDfG4z35BC7KWC/7EIkzOapqtYjuzwZg5N5HM2
NOm7gLigOmQl4Jue+2ziUGllo6knPNZdcnRZXUWt+pF77smQS+BSGXAm4xjuwn6B
lPD8CQUN83QZdZtVkkvrC9rDGp3ZJCkII9XzvSBf/Cl+C+6ejqY=
=wd/l
-----END PGP SIGNATURE-----
Merge tag 'arm-boardfiles-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM boardfile deprecation from Arnd Bergmann:
"Over the past ten years, new machine support was based on device tree,
and an initial set of about 400 boards using ATAGS with boardfile for
booting were grandfathered in, with about half of them either removed
or converted to DT over time.
Based on the recent mailing list discussion I started, I have now
turned the findings into a set of patches that marks most board files
as 'depends on UNUSED_BOARD_FILES', leaving only 38 of the 196 boards.
For the boards that are marked as unused, there are two final chances
for potential users: The removal is scheduled to take place after the
longterm stable kernel at the end of 2022, so users can stay on that
version for another few years, and if anyone still has one of these
machines and is planning to keep updating kernels beyond that version,
they can speak up now to have their boards taken off the list again.
Waiting for the LTS release also makes sure that there will be at
least one longterm kernel that contains the recent multiplatform
conversion along while still supporting all legacy boards.
The short summary of the current status is:
- The s3c24xx, cns3xxx, iop32x and mv78xx0 platforms have no known
users and will be removed entirely.
- The mmp and davinci platforms have DT support for the important
machines and will become DT-only after this.
- s3c64xx, dove, orion5x, and pxa keep some board files to allow
those to be migrated over to DT more easily, but most board files
are getting removed now. DT support on these platforms is partially
working but requires changes to additional drivers for the other
boards.
- omap1, ep93xx, sa1100, footbridge and rpc have no DT support at the
moment but have some boards with known users. Removing the board
files that nobody uses should make it easier to try a DT conversion
if anyone cares.
There is no explicit timeline what happens with the boards that remain
after this removal, but I expect to revisit this in the future, and
with most boards gone, there will be a good time to do a treewide
review of platform drivers that never gained DT support and have no
remaining in-tree board files"
Link: https://lore.kernel.org/linux-arm-kernel/CAK8P3a0Z9vGEQbVRBo84bSyPFM-LF+hs5w8ZA51g2Z+NsdtDQA@mail.gmail.com/
* tag 'arm-boardfiles-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
ARM: cns3xxx: add CONFIG_UNUSED_BOARD_FILES dependency
ARM: iop32x: mark as unused
ARM: s3c: mark most board files as unused
ARM: omap1: add Kconfig dependencies for unused boards
ARM: sa1100: mark most boards as unused
ARM: footbridge: mark cats board for removal
ARM: mmp: mark all board files for removal
ARM: ep93xx: mark most board files as unused
ARM: davinci: mark all ATAGS board files as unused
ARM: orion: add ATAGS dependencies
ARM: pxa: add Kconfig dependencies for ATAGS based boards
ARM: add CONFIG_UNUSED_BOARD_FILES
ARM: add ATAGS dependencies to non-DT platforms
From an earlier discussion, it appears that the davinci da8xx machines
that are still functional have already been converted to DT, while the
remaining board files are only kept because nobody has stepped up to
remove them.
Mark all these boards as 'depends on UNUSED_BOARD_FILES' with the
plan to remove them in early 2023 after the next longterm supported
kernel is out.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The interest of maintaining the DaVinci DM644x board files seems
very low. Patches to convert the EVM board to use GPIO descriptors
has not been reviewed, tested or merged for several merge
windows in a row, see link below.
When I look in the logs for the board files I see nothing but
generic kernel maintenance and no testing on real hardware for
years.
I conclude the DM646x board files are unused and can be deleted.
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Matt Porter <mporter@konsulko.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/linux-arm-kernel/20220507124536.171930-2-linus.walleij@linaro.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The interest of maintaining the DaVinci DM644x board files seems
very low. Patches to convert the EVM board to use GPIO descriptors
has not been reviewed, tested or merged for several merge
windows in a row, see link below.
When I look in the logs for the board files I see nothing but
generic kernel maintenance and no testing on real hardware for
years.
I conclude the DM644x board files are unused and can be deleted.
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Matt Porter <mporter@konsulko.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/linux-arm-kernel/20220507124536.171930-1-linus.walleij@linaro.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Choosing big-endian vs little-endian kernels in Kconfig has not worked
correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long
time ago.
The problems is that CONFIG_BIG_ENDIAN depends on
ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform
in the config, but would actually have to be supported by all
of them.
This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and
tend to just work aside from problems in nonportable device drivers.
For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM
were never set together, so this was disabled on all those machines
except for IXP4xx.
As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to
formalize this logic: all ARMv4/v5 platforms get an explicit dependency
on being either big-endian (ixp4xx) or little-endian (the rest). We may
want to fix ixp4xx in the future to support both, but it does not work
in LE mode at the moment.
For the ARMv6/v7 platforms, there are two ways this could be handled
a) allow both modes only for platforms selecting
'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the
others, given that these were added intentionally at some
point.
b) allow both modes everwhere, given that it was already possible
to build that way by e.g. selecting ARCH_VIRT, and that the
list is not an accurate reflection of which platforms may or
may not work.
Out of these, I picked b) because it seemed slighly more logical
to me.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
supported.
As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac
("ide: remove the legacy ide driver"), there is no need to mention
HAVE_IDE in all those arch-specific Kconfig files.
The issue was identified with ./scripts/checkkconfigsymbols.py.
Fixes: b7fb14d3ac ("ide: remove the legacy ide driver")
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210728182115.4401-1-lukas.bulwahn@gmail.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
ARM is the only architecture that defines CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
which in turn enables memmap_valid_within() function that is intended to
verify existence of struct page associated with a pfn when there are holes
in the memory map.
However, the ARCH_HAS_HOLES_MEMORYMODEL also enables HAVE_ARCH_PFN_VALID
and arch-specific pfn_valid() implementation that also deals with the holes
in the memory map.
The only two users of memmap_valid_within() call this function after
a call to pfn_valid() so the memmap_valid_within() check becomes redundant.
Remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL and memmap_valid_within() and rely
entirely on ARM's implementation of pfn_valid() that is now enabled
unconditionally.
Link: https://lkml.kernel.org/r/20201101170454.9567-9-rppt@kernel.org
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greg Ungerer <gerg@linux-m68k.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Michael Schmitz <schmitzmic@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
[nsekhar@ti.com: drop obsolete hawkboard.org URL completeley
fixup subject line prefix]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Support for TI DaVinci SoCs depends on ARCH_MULTI_V5, and thus on
ARCH_MULTIPLATFORM.
As the latter selects TIMER_OF, there is no need for MACH_DA8XX_DT to
select TIMER_OF.
Link: https://lore.kernel.org/r/20200505150722.1575-9-geert+renesas@glider.be
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Selecting RESET_CONTROLLER is actually required, otherwise we
can get a link failure in the clock driver:
drivers/clk/davinci/psc.o: In function `__davinci_psc_register_clocks':
psc.c:(.text+0x9a0): undefined reference to `devm_reset_controller_register'
drivers/clk/davinci/psc-da850.o: In function `da850_psc0_init':
psc-da850.c:(.text+0x24): undefined reference to `reset_controller_add_lookup'
Link: https://lore.kernel.org/r/20191210195202.622734-1-arnd@arndb.de
Fixes: f962396ce2 ("ARM: davinci: support multiplatform build for ARM v5")
Cc: <stable@vger.kernel.org> # v5.4
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Add modifications necessary to make davinci part of the ARM v5
multiplatform build.
Move the arch-specific configuration out of arch/arm/Kconfig and
into mach-davinci/Kconfig. Remove the sub-menu for DaVinci
implementations (they'll be visible directly under the system type.
Select all necessary options not already selected by ARCH_MULTI_V5.
Update davinci_all_defconfig. Explicitly include the mach-specific
headers in mach-davinci/Makefile.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The cp-intc driver has now been cleaned up. Move it to drivers/irqchip
where it belongs.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The aintc driver has now been cleaned up. Move it to drivers/irqchip
where it belongs. There's no device-tree support for any dm* board so
there's no IRQCHIP_OF_DECLARE() - there's only the exported init
function called from machine code.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
This adds device tree support to the davinci timer so that when clocks
are moved to device tree, the timer will still work.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The common clock framework will take care of disabling unused clocks when
we switch from the legacy davinci clocks and having this enabled will
cause compile errors after we switch, so remove it now.
Signed-off-by: David Lechner <david@lechnology.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
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>
The davinci platform has tried to get support for the EEPROM right,
but failed to get a clean build so far. At the moment, we get
a warning whenever CONFIG_SYSFS is disabled, as that is needed by
EEPROM_AT24:
warning: (MACH_DAVINCI_EVM && MACH_SFFSDR && MACH_DAVINCI_DM6467_EVM && MACH_DAVINCI_DM365_EVM && MACH_DAVINCI_DA830_EVM && MACH_MITYOMAPL138 && MACH_MINI2440) selects EEPROM_AT24 which has unmet direct dependencies (I2C && SYSFS)
Kevin Hilman initially added the 'select' to ensure that EEPROM_AT24
is always enabled in machines that really want it for normal operation
(i.e. for reading the MAC address). This broke when I2C was disabled,
and Russell King followed up with another patch to select that as
well.
I now see that the SYSFS dependency is still missing, which leaves
us with three options:
a) add 'select SYSFS' in addition to the others
b) change AT24_EEPPROM to work without sysfs (should be possible)
c) remove all those selects again and get the files to build when
I2C is disabled.
I would really hate to do a) because adding select statements that
hardwire user-selectable symbols is generally a bad idea. I first
tried b) but then ended up redoing the patch from scratch to approach
c), so we can also remove the other selects.
I checked that CONFIG_I2C is still enabled with davinci_all_defconfig,
so that does not have to change.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 45b146d746 ("ARM: Davinci: Fix I2C build errors")
Fixes: 22ca466847 ("davinci: kconfig: select at24 eeprom for selected boards")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We already forbid that combination when AUTO_ZRELADDR is disabled,
for the same reason that the two have their RAM at different
physical addresses as seen from the CPU.
This does the same change for PATCH_PHYS_VIRT: if you disable
either of the options, Kconfig now enforces that you have to
pick one or the other SoC family.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
When da8xx-dt.c is built with onlu DA830 support but not DA850
support enabled, we get a compiler warning about unused symbols:
arch/arm/mach-davinci/da8xx-dt.c:28:20: warning: 'da8xx_init_irq' defined but not used [-Wunused-function]
static void __init da8xx_init_irq(void)
arch/arm/mach-davinci/da8xx-dt.c:33:30: warning: 'da850_auxdata_lookup' defined but not used [-Wunused-variable]
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
Obviously none of the file make sense for DA830, so we should not
even attempt this, so we can avoid the warning by ensuring it is
only built for 850, not 830.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The DA830 chip only works if the dcache is in writethrough mode,
but that produces a harmless Kconfig warning if the cache happens
to be disabled:
warning: (ARCH_DAVINCI_DA830) selects CPU_DCACHE_WRITETHROUGH which has unmet direct dependencies ((CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_FA526) && !CPU_DCACHE_DISABLE)
This makes the select conditional so we don't have to worry
about the warning in randconfig builds any more.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Now that we have wlcore device-tree bindings in place
(for both wl12xx and wl18xx), remove the legacy
wl12xx_platform_data struct, and move its members
into the platform device data (that is passed to wlcore)
Davinci 850 is the only platform that still set
the platform data in the legacy way (and doesn't
have DT bindings), so remove the relevant
code/Kconfig option from the board file (as suggested
by Sekhar Nori)
Since no one currently uses wlcore_spi, simply remove its
platform data support (DT bindings will have to be added
if someone actually needs it)
Signed-off-by: Luciano Coelho <luca@coelho.fi>
Signed-off-by: Eliad Peller <eliad@wizery.com>
Tested-by: Nikita Kiryanov <nikita@compulab.co.il>
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The davinci DA8xx and DMx families have incompatible zreladdr
settings, and attempting to build a kernel with both enabled
results in an error unless AUTO_ZRELADDR is set:
multiple zreladdrs: 0xc0008000 0x80008000
This needs CONFIG_AUTO_ZRELADDR to be set
This patch changes Kconfig to make the two families mutually
exclusive when this is unset.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
This config exists entirely to hide the cpufreq menu from the
kernel configuration unless a platform has selected it. Nothing
is actually built if this config is 'Y' and it just leads to more
patches that add a select under a platform Kconfig so that some
other CPUfreq option can be chosen. Let's remove the option so
that we can always enable CPUfreq drivers on ARM platforms.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Lots of changes specific to one of the SoC families. Some that
stick out are:
* mach-qcom gains new features, most importantly SMP support for
the newer chips (Stephen Boyd, Rohit Vaswani)
* mvebu gains support for three new SoCs: Armada 375, 380 and 385
(Thomas Petazzoni and Free-electrons team)
* SMP support for Rockchips (Heiko Stübner)
* Lots of i.MX changes (Shawn Guo)
* Added support for BCM5301x SoC (Hauke Mehrtens)
* Multiplatform support for Marvell Kirkwood and Dove
(Andrew Lunn and Sebastian Hesselbarth doing the final part
of a long journey)
* Unify davinci platforms and remove obsolete ones (Sekhar Nori,
Arnd Bergmann)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUz/yT2CrR//JCVInAQJN8A/9Ft1rfp4LEe8Lpr9yAZydG4UaJKy8Hh7Z
fmohMAuy88J+8jzdwQKKCeEiId+nIf+WmFIQDn9YRDev1/T2v32Ax49XuGtY47JX
4loIC2wR0+j1aSwhEVOmlM03lX7Hbu6iNDkxaLkDKTRrt3DhDNA6cPZYwNOT273W
Yx7hIDpvsoOVN3zbPwqhwLrXgywsaNB9E7ly1GixRd1thdg46kMRcM0LJSXPH3we
pyx7sZbILTVMeUx79XUTvBDJYsbjJWFZknVDYXGkrS5YxAASVsVW2KW9fP9E+UXE
wTmOxg6spsHGgCezwy8NL5UmfaAOXL3mm6ginFwWpyz7Iu+P5IvfR1W+8UA/O8tp
K9y8wLA64chPQJkAGaPQBqUPq9QkNHodZWgaPKxKuuv3qF481DCnQKkFRz+sl7mu
oQVGnoMCnTY6L6yYcIq/GpgiJ731vwefirAwPR8FEBN/gw/gC01b+DDchx/5inPJ
6V6dCEtPZxXMOsIaYBWFauk3pMFU3E8coklmteyYDQg7eb+55Zq3vsNEpu/vb6ll
M660AQzzbkZ7lgsSBdNODEvkNH15kC35G2UCfwy99uCE4k/0Vi7reJ1BzXkc+dtJ
+maBtA6NMALXQ/EI+B+fZLccI4Hv7avwFy1rQJaf+TLiFvTd9yp0qUX8JjXWDPgu
pPWQOC4a9mU=
=AGpV
-----END PGP SIGNATURE-----
Merge tag 'soc-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC specific changes from Arnd Bergmann:
"Lots of changes specific to one of the SoC families. Some that stick
out are:
- mach-qcom gains new features, most importantly SMP support for the
newer chips (Stephen Boyd, Rohit Vaswani)
- mvebu gains support for three new SoCs: Armada 375, 380 and 385
(Thomas Petazzoni and Free-electrons team)
- SMP support for Rockchips (Heiko Stübner)
- Lots of i.MX changes (Shawn Guo)
- Added support for BCM5301x SoC (Hauke Mehrtens)
- Multiplatform support for Marvell Kirkwood and Dove (Andrew Lunn
and Sebastian Hesselbarth doing the final part of a long journey)
- Unify davinci platforms and remove obsolete ones (Sekhar Nori, Arnd
Bergmann)"
* tag 'soc-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (126 commits)
ARM: sunxi: Select HAVE_ARM_ARCH_TIMER
ARM: cache-tauros2: remove ARMv6 code
ARM: mvebu: don't select CONFIG_NEON
ARM: davinci: fix DT booting with default defconfig
ARM: configs: bcm_defconfig: enable bcm590xx regulator support
ARM: davinci: remove tnetv107x support
MAINTAINERS: Update ARM STi maintainers
ARM: restrict BCM_KONA_UART to ARCH_BCM_MOBILE
ARM: bcm21664: Add board support.
ARM: sunxi: Add the new watchog compatibles to the reboot code
ARM: enable ARM_HAS_SG_CHAIN for multiplatform
ARM: davinci: remove da8xx_omapl_defconfig
ARM: davinci: da8xx: fix multiple watchdog device registration
ARM: davinci: add da8xx specific configs to davinci_all_defconfig
ARM: davinci: enable da8xx build concurrently with older devices
ARM: BCM5301X: workaround suppress fault
ARM: BCM5301X: add early debugging support
ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU
ARM: mach-bcm: Remove GENERIC_TIME
ARM: shmobile: APMU: Fix warnings due to improper printk formats
...
The DAVINCI_DA850_EVM board uses an unusual method to
enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
which leads to the dependencies on these symbols being
ignored. As GPIO_PCA953X actually requires I2C, that
can lead to build failures when I2C is disabled.
This patch removes the duplicate symbol definitions
and instead enables them from the davinci_all_defconfig
file.
A different question whether we actually want to automatically
enable them at all or rather put them into defconfig,
but that should be a separate patch.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source@linux.davincidsp.com
The tnetv107x support does not compile, and seems to have been broken
for a while with nobody caring to fix it. So far everyone I asked
said it's probably dead and completely unused and will never again
be needed in a future kernel release, so let's delete it.
If someone finds a use for this code later and is able to get it
to work again, we can always revert the removal.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
CONFIG_CPU_FREQ_TABLE will be always enabled when cpufreq framework is used, as
cpufreq core depends on it. So, we don't need this CONFIG option anymore as it
is not configurable. Remove CONFIG_CPU_FREQ_TABLE and update its users.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CPUFreq driver of this platform uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
For DT, DaVinci platform can use pinctrl-single driver for handling
padconf registers.
Enable PINCTRL Kconfig for MACH_DA8XX_DT platform. Add required
pinctrl DT entries in da850 dts file.
Test procedure
1)Populate DT file with NAND node information.
2)Populate board DT file with pinmux information for NAND.
3)Boot and confirm NAND is detected by the kernel.
4)cat /proc/mtd to show partitions.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add support for booting DA850 using flattened device
tree to describe the hardware. At this time only the
very basic bootup using a serial console is supported.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
As suggested by Andrew Morton:
This is a pet peeve of mine. Any time there's a long list of items
(header file inclusions, kconfig entries, array initalisers, etc) and
someone wants to add a new item, they *always* go and stick it at the
end of the list.
Guys, don't do this. Either put the new item into a randomly-chosen
position or, probably better, alphanumerically sort the list.
lets sort all our select statements alphanumerically. This commit was
created by the following perl:
while (<>) {
while (/\\\s*$/) {
$_ .= <>;
}
undef %selects if /^\s*config\s+/;
if (/^\s+select\s+(\w+).*/) {
if (defined($selects{$1})) {
if ($selects{$1} eq $_) {
print STDERR "Warning: removing duplicated $1 entry\n";
} else {
print STDERR "Error: $1 differently selected\n".
"\tOld: $selects{$1}\n".
"\tNew: $_\n";
exit 1;
}
}
$selects{$1} = $_;
next;
}
if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or
/^endif/ or /^endchoice/)) {
foreach $k (sort (keys %selects)) {
print "$selects{$k}";
}
undef %selects;
}
print;
}
if (%selects) {
foreach $k (sort (keys %selects)) {
print "$selects{$k}";
}
}
It found two duplicates:
Warning: removing duplicated S5P_SETUP_MIPIPHY entry
Warning: removing duplicated HARDIRQS_SW_RESEND entry
and they are identical duplicates, hence the shrinkage in the diffstat
of two lines.
We have four testers reporting success of this change (Tony, Stephen,
Linus and Sekhar.)
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Include the expander settings to select VPIF peripheral on
UI card and add registration call in EVM init. Also add platform
data to configure display and capture devices.
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Pull trivial tree from Jiri Kosina:
"Trivial updates all over the place as usual."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (29 commits)
Fix typo in include/linux/clk.h .
pci: hotplug: Fix typo in pci
iommu: Fix typo in iommu
video: Fix typo in drivers/video
Documentation: Add newline at end-of-file to files lacking one
arm,unicore32: Remove obsolete "select MISC_DEVICES"
module.c: spelling s/postition/position/g
cpufreq: Fix typo in cpufreq driver
trivial: typo in comment in mksysmap
mach-omap2: Fix typo in debug message and comment
scsi: aha152x: Fix sparse warning and make printing pointer address more portable.
Change email address for Steve Glendinning
Btrfs: fix typo in convert_extent_bit
via: Remove bogus if check
netprio_cgroup.c: fix comment typo
backlight: fix memory leak on obscure error path
Documentation: asus-laptop.txt references an obsolete Kconfig item
Documentation: ManagementStyle: fixed typo
mm/vmscan: cleanup comment error in balance_pgdat
mm: cleanup on the comments of zone_reclaim_stat
...
Add irq domain support for DaVinci cp_intc.
Boot tested on AM18x EVM. Also tested with GPIO IRQ support on
AM18x EVM.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
[nsekhar@ti.com: add commit description, select IRQ_DOMAIN for CP_INTC
in Kconfig]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
Add support for the WLAN capabilities of this expansion board.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Several Davinci platforms select the I2C EEPROM support, but don't
select I2C support. This causes I2C EEPROM support to be built into
the kernel, but I2C support may not be configured to be built in.
This leads to linker errors due to missing I2C symbols.
Arrange for I2C to be selected whenever EEPROM_AT24 is selected.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Use the mach-davinci/Kconfig to enable gpio-keys-polled as default when
da850-evm machine is enabled.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
CC: Kevin Hilman <khilman@deeprootsystems.com>
CC: "Nori, Sekhar" <nsekhar@ti.com>
CC: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Ensure that the at24 eeprom driver is selected for certain boards that
need boot data (e.g. MAC address) from EEPROM.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Change the mach-davinci Kconfig file so that GPIO_PCA953X is default when
MACH_DAVINCI_DA850_EVM is set instead of always selecting. This allows users
to compile pca953x as a module.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
CC: Sergei Shtylyov <sshtylyov@mvista.com>
CC: Nori, Sekhar <nsekhar@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch adds initial support for the Hawkboard-L138 system
It is under the machine name "omapl138_hawkboard".
This system is based on the da850 davinci CPU architecture.
Information on these system may be found at http://www.hawkboard.org.
Basic support for the UART console is included in this patch.
It's tested with latest Angstrom File Systems like ramdisk
from http://alturl.com/imb45.
Signed-off-by: Victor Rodriguez <victor.rodriguez@sasken.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
on Module (SOM) under the machine name "mityomapl138". These SOMs are based
on the da850 davinci CPU architecture. Information on these SOMs may be
found at http://www.mitydsp.com.
Basic support for the console UART, NAND, and EMAC (MII interface) is
included in this patch.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The Sitara AM17x SoCs from TI are an OMAP-L137 pin-to-pin
compatible ARM9 microprocessor offering from TI.
The Sitara AM18x SoCs from TI are an OMAP-L138 pin-to-pin
compatible ARM9 microprocessor offering from TI.
More information about these processors available at:
www.ti.com/am1x
Because of their compatibiliy with OMAP-L1x, the kernel
support for OMAP-L1x is fully relevant to AM1x processors.
This patch updates the Kconfig prompt and help text to include
the AM1x part names to help users select configurations required
for these parts easily.
Also, the hardware information that shows up in /proc/cpuinfo
is updated to show applicability of the respective OMAP-L1x EVMs
for AM1x parts.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
In arch/arm/mach-davinci/Kconfig, some of the configuration
items are indented with multiple spaces instead of tabs.
Also, in couple of places, two spaces are used in the middle
of help text where one should do.
This patch fixes both issues.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Added support for tnetv107x evaluation module.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
TNETV107X is a Texas Instruments SOC that shares a number of common features
with the Davinci architecture. Some of the key differences between
traditional Davincis and this new SOC are as follow:
1. The SOCs clock architecture includes a new spread-spectrum PLL. Some
elements of the clock architecture are reused from Davinci (e.g. LPSC), but
the PLL related code is overridden using existing interfaces in "struct clk".
2. The MMR layout on this SOC is substantially different from Davinci.
Consequently, the fixed I/O map is a whole lot more convoluted (more so than
DA8xx). The net impact here is that IO_ADDRESS() will not work on this SoC,
and therefore all mappings have to be through ioremap().
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Preliminary modification prior to adding support for TNETV107X based on
ARM1176. This change allows for CPUs other than ARM926T to be used for Davinci
derivative SoCs. Existing devices (DA8x and DMx) operate unchanged.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
DM6467T (T for Turbo) is a newer and faster DM6467
part from TI. The new part supports 1080p video and
has the ARM running at 495MHz. More SoC information:
http://focus.ti.com/docs/prod/folders/print/tms320dm6467t.html
Spectrum Digital, Inc has a new EVM for this part.
It is _mostly_ same as the older DM6467 EVM except
for a 33MHz crystal input and THS8200 video encoder
for 1080p support.
The meat of this patch is dedicated to initializing
the crystal frequency from EVM board file.
Additional notes:
I did consider some alternative ways to make the crystal
input board specific including - (1) having board code
initialize the crystal frequency using the first member
of soc_info->cpu_clks array (2) introducing a new ref_clk_rate
member in soc_info structure.
But, the current way seems to be the simplest and least
intruding considering that both the clock array and SoC
info structure are actually private to the SoC file. Also
the fact that davinci_common_init() initializes both the
soc_info and clocks in one go.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The Neuros OSD 2.0 is the hardware component of the Neuros Open
Internet Television Platform. Hardware is very close to Ti DM644X-EVM board.
It has: DM6446M02 module with 256MB NAND, 256MB RAM, TLV320AIC32 AIC,
USB, Ethernet, SD/MMC, UART, THS8200, TVP7000 for video.
Additionaly realtime clock, IR remote control receiver,
IR Blaster based on MSP430 (firmware although is different
from used in DM644X-EVM), internal ATA-6 3.5” HDD drive
with PATA interface, two muxed red-green leds.
For more information please refer to
http://wiki.neurostechnology.com/index.php/OSD_2.0_HD
Signed-off-by: Andrey Porodko <panda@chelcom.ru>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Get rid of DA850_UI_EXP config option since it is not used anywhere
else in code.
Instead make the UI expander choice menu dependent on the EVM
selection itself.
Also add help text indicating that UI board is actually detected
automatically.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Linus Torvalds