This adds node for E5010 JPEG Encoder which is a stateful JPEG Encoder
present in AM62A SoC [1], supporting baseline encoding of semiplanar based
YUV420 and YUV422 raw video formats to JPEG encoding, with resolutions
supported from 64x64 to 8kx8k.
E5010 JPEG Encoder IP is present in main domain, so this also adds address
range for core and mmu regions of E5010 IP in cbass_main node.
Link: https://www.ti.com/lit/pdf/spruj16 [1]
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20240826162250.380005-2-devarsht@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
CAN instances 0 and 1 in the mcu domain and 0 in the main domain are
brought on the evm through headers J5, J8 and J10 respectively. Thus,
add their respective transceiver's 0, 1 and 2 dt nodes as well as
add the required pinmux to add support for these CAN instances.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://lore.kernel.org/r/20240827105644.575862-2-b-kapoor@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
wkup_uart0 is a reserved node that is used by Device Manager firmware.
Only TX and RX pins are required for the firmware and enabling pinctrl
for CTS and RTS breaks the wakeup functionality of wkup_uart0. Drop the
conflicting muxes.
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240826-am62p-v1-1-b713b48628d1@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The remoteproc firmware like of R5F and DSPs in the MAIN voltage domain
use timers. Therefore, change the status of the timer nodes to
"reserved" to avoid any clash. Usage is described as below:
+===================+=============+
| Remoteproc node | Timer Node |
+===================+=============+
| main_r5fss0_core0 | main_timer2 |
+-------------------+-------------+
| main_r5fss0_core1 | main_timer3 |
+-------------------+-------------+
| main_r5fss1_core0 | main_timer4 |
+-------------------+-------------+
| main_r5fss1_core1 | main_timer5 |
+-------------------+-------------+
| c71_0 | main_timer0 |
+-------------------+-------------+
| c71_1 | main_timer1 |
+-------------------+-------------+
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826104821.1516344-6-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The remoteproc firmware like of R5F and DSPs in the MAIN voltage domain
use timers. Therefore, change the status of the timer nodes to
"reserved" to avoid any clash. Usage is described as below:
+===================+=============+
| Remoteproc node | Timer Node |
+===================+=============+
| main_r5fss0_core0 | main_timer2 |
+-------------------+-------------+
| main_r5fss0_core1 | main_timer3 |
+-------------------+-------------+
| main_r5fss1_core0 | main_timer4 |
+-------------------+-------------+
| main_r5fss1_core1 | main_timer5 |
+-------------------+-------------+
| c71_0 | main_timer0 |
+-------------------+-------------+
| c71_1 | main_timer1 |
+-------------------+-------------+
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826104821.1516344-5-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The remoteproc firmware like of R5F and DSPs in the MAIN voltage domain
use timers. Therefore, change the status of the timer nodes to
"reserved" to avoid any clash. Usage is described as below:
+===================+==============+
| Remoteproc node | Timer Node |
+===================+==============+
| main_r5fss0_core0 | main_timer12 |
+-------------------+--------------+
| main_r5fss0_core1 | main_timer13 |
+-------------------+--------------+
| main_r5fss1_core0 | main_timer14 |
+-------------------+--------------+
| main_r5fss1_core1 | main_timer15 |
+-------------------+--------------+
| c66_0 | main_timer0 |
+-------------------+--------------+
| c66_1 | main_timer1 |
+-------------------+--------------+
| c71_0 | main_timer2 |
+-------------------+--------------+
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826104821.1516344-4-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The remoteproc firmware like of R5F and DSPs in the MAIN voltage domain
use timers. Therefore, change the status of the timer nodes to
"reserved" to avoid any clash. Usage is described as below:
+===================+==============+
| Remoteproc node | Timer Node |
+===================+==============+
| main_r5fss0_core0 | main_timer12 |
+-------------------+--------------+
| main_r5fss0_core1 | main_timer13 |
+-------------------+--------------+
| main_r5fss1_core0 | main_timer14 |
+-------------------+--------------+
| main_r5fss1_core1 | main_timer15 |
+-------------------+--------------+
| c66_0 | main_timer0 |
+-------------------+--------------+
| c66_1 | main_timer1 |
+-------------------+--------------+
| c71_0 | main_timer2 |
+-------------------+--------------+
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826104821.1516344-3-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The remoteproc firmware of R5F in the MAIN voltage domain use timers.
Therefore, change the status of the timer nodes to "reserved" to avoid
any clash. Usage is described as below:
+===================+==========================+
| Remoteproc node | Timer Node |
+===================+==========================+
| main_r5fss0_core0 | main_timer0, main_timer2 |
+-------------------+--------------------------+
| main_r5fss0_core1 | main_timer1 |
+-------------------+--------------------------+
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826104821.1516344-2-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI AM69 SK board has three R5F clusters in the MAIN domain, and all
of these are configured for LockStep mode at the moment. Switch all of
these R5F clusters to Split mode by default to maximize the number of
R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-8-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI J784S4 EVM board has three R5F clusters in the MAIN domain, and
all of these are configured for LockStep mode at the moment. Switch
all of these R5F clusters to Split mode by default to maximize the
number of R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-7-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI AM68 SK board has two R5F clusters in the MAIN domain, and both
of these are configured for LockStep mode at the moment. Switch both of
these R5F clusters to Split mode by default to maximize the number of
R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-6-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI J721S2 EVM board has two R5F clusters in the MAIN domain, and
both of these are configured for LockStep mode at the moment. Switch
both of these R5F clusters to Split mode by default to maximize the
number of R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-5-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI J721E SK board has two R5F clusters in the MAIN domain, and both
of these are configured for LockStep mode at the moment. Switch both of
these R5F clusters to Split mode by default to maximize the number of
R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-4-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI J721E EVM board has two R5F clusters in the MAIN domain, and
both of these are configured for LockStep mode at the moment. Switch
both of these R5F clusters to Split mode by default to maximize the
number of R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-3-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI J7200 EVM board has one R5F cluster in the MAIN domain, and it is
configured for LockStep mode at the moment. Switch the MAIN R5F cluster
to Split mode by default to maximize the number of R5F cores.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20240826093024.1183540-2-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
External interfaces should be disabled at the SoC DTSI level, since
the node is incomplete. Disable Ethernet switch and ports in SoC DTSI
and enable them in the board DTS. If the board DTS includes a SoM DTSI
that completes the node description, enable the Ethernet switch and
ports in SoM DTSI.
Reflect this change in SoM DTSIs by removing ethernet port disable.
Signed-off-by: Logan Bristol <logan.bristol@utexas.edu>
Acked-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Acked-by: Josua Mayer <josua@solid-run.com>
Link: https://lore.kernel.org/r/20240809135753.1186-1-logan.bristol@utexas.edu
Signed-off-by: Nishanth Menon <nm@ti.com>
The DMA carveout for the C6x core 0 is at 0xa6000000 and core 1 is at
0xa7000000. These are reversed in DT. While both C6x can access either
region, so this is not normally a problem, but if we start restricting
the memory each core can access (such as with firewalls) the cores
accessing the regions for the wrong core will not work. Fix this here.
Fixes: fae14a1cb8 ("arm64: dts: ti: Add k3-j721e-beagleboneai64")
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240801181232.55027-2-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The DMA carveout for the C6x core 0 is at 0xa6000000 and core 1 is at
0xa7000000. These are reversed in DT. While both C6x can access either
region, so this is not normally a problem, but if we start restricting
the memory each core can access (such as with firewalls) the cores
accessing the regions for the wrong core will not work. Fix this here.
Fixes: f46d16cf5b ("arm64: dts: ti: k3-j721e-sk: Add DDR carveout memory nodes")
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240801181232.55027-1-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The PCIe0 instance of the PCIe controller on J784S4 SoC supports up to 4
lanes. Additionally, all 4 lanes of PCIe0 can be utilized on J784S4-EVM
via SERDES1. Since SERDES1 is not being used by any peripheral apart
from PCIe0, use all 4 lanes of SERDES1 for PCIe0.
Fixes: 27ce26fe52 ("arm64: dts: ti: k3-j784s4-evm: Enable PCIe0 and PCIe1 in RC Mode")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://lore.kernel.org/r/20240720110455.3043327-1-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
There are 2 mux-controller nodes in J7200 which are responsible for
transferring can signals to the can phy but same node names for both
the mux-controllers led to errors while setting up both mux-controllers
for can phys simultaneously.
Thus, update node names for these mux-controller.
Fixes: da23e8d112 ("arm64: dts: ti: k3-j7200-som-p0: Add support for CAN instance 0 in main domain")
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://lore.kernel.org/r/20240729063411.1570930-3-b-kapoor@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
There are 2 mux-controller nodes in J721S2 which are responsible for
transferring can signals to the can phy but same node names for both
the mux-controllers led to errors while setting up both mux-controllers
for can phys simultaneously.
Thus, update node names for these mux-controller.
Fixes: 98f3b667e1 ("arm64: dts: ti: k3-j721s2: Add support for CAN instances 3 and 5 in main domain")
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20240729063411.1570930-2-b-kapoor@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit 5e5c50964e ("arm64: dts: ti: k3-j722s: Add gpio-ranges
properties") introduced pinmux range definition for gpio-ranges, however
missed a hole within gpio-range for main_pmx0. As a result, automatic
mapping of GPIO to pin control for gpios within the main_pmx0 domain is
broken. Fix this by correcting the gpio-range.
Fixes: 5e5c50964e ("arm64: dts: ti: k3-j722s: Add gpio-ranges properties")
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Link: https://lore.kernel.org/r/20240801210414.715306-4-j-mcarthur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit d72d73a44c ("arm64: dts: ti: k3-am62p: Add gpio-ranges
properties") introduced pinmux range definition for gpio-ranges, however
missed a hole within gpio-range for main_pmx0. As a result, automatic
mapping of GPIO to pin control for gpios within the main_pmx0 domain is
broken. Fix this by correcting the gpio-range.
Fixes: d72d73a44c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties")
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Link: https://lore.kernel.org/r/20240801210414.715306-3-j-mcarthur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit d72d73a44c ("arm64: dts: ti: k3-am62p: Add gpio-ranges
properties") introduced pinmux range definition for gpio-ranges, however
missed introducing the range description for the mcu_gpio node. As a
result, automatic mapping of GPIO to pin control for mcu gpios is
broken. Fix this by introducing the proper ranges.
Fixes: d72d73a44c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties")
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Link: https://lore.kernel.org/r/20240801210414.715306-2-j-mcarthur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Late fixes towards v6.11-rc1
First patch fixes warning splat seen on J784S4 due to overlapping
serdes0 lane. Second patch cleans up the serdes0 references for readability
Signed-off-by: Nishanth Menon <nm@ti.com>
Pull Kbuild fixes from Masahiro Yamada:
- Fix RPM package build error caused by an incorrect locale setup
- Mark modules.weakdep as ghost in RPM package
- Fix the odd combination of -S and -c in stack protector scripts,
which is an error with the latest Clang
* tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: Fix '-S -c' in x86 stack protector scripts
kbuild: rpm-pkg: ghost modules.weakdep file
kbuild: rpm-pkg: Fix C locale setup
This simplifies the min_t() and max_t() macros by no longer making them
work in the context of a C constant expression.
That means that you can no longer use them for static initializers or
for array sizes in type definitions, but there were only a couple of
such uses, and all of them were converted (famous last words) to use
MIN_T/MAX_T instead.
Cc: David Laight <David.Laight@aculab.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 3a7e02c040 ("minmax: avoid overly complicated constant
expressions in VM code") added the simpler MIN_T/MAX_T macros in order
to avoid some excessive expansion from the rather complicated regular
min/max macros.
The complexity of those macros stems from two issues:
(a) trying to use them in situations that require a C constant
expression (in static initializers and for array sizes)
(b) the type sanity checking
and MIN_T/MAX_T avoids both of these issues.
Now, in the whole (long) discussion about all this, it was pointed out
that the whole type sanity checking is entirely unnecessary for
min_t/max_t which get a fixed type that the comparison is done in.
But that still leaves min_t/max_t unnecessarily complicated due to
worries about the C constant expression case.
However, it turns out that there really aren't very many cases that use
min_t/max_t for this, and we can just force-convert those.
This does exactly that.
Which in turn will then allow for much simpler implementations of
min_t()/max_t(). All the usual "macros in all upper case will evaluate
the arguments multiple times" rules apply.
We should do all the same things for the regular min/max() vs MIN/MAX()
cases, but that has the added complexity of various drivers defining
their own local versions of MIN/MAX, so that needs another level of
fixes first.
Link: https://lore.kernel.org/all/b47fad1d0cf8449886ad148f8c013dae@AcuMS.aculab.com/
Cc: David Laight <David.Laight@aculab.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull UBI and UBIFS updates from Richard Weinberger:
- Many fixes for power-cut issues by Zhihao Cheng
- Another ubiblock error path fix
- ubiblock section mismatch fix
- Misc fixes all over the place
* tag 'ubifs-for-linus-6.11-rc1-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs:
ubi: Fix ubi_init() ubiblock_exit() section mismatch
ubifs: add check for crypto_shash_tfm_digest
ubifs: Fix inconsistent inode size when powercut happens during appendant writing
ubi: block: fix null-pointer-dereference in ubiblock_create()
ubifs: fix kernel-doc warnings
ubifs: correct UBIFS_DFS_DIR_LEN macro definition and improve code clarity
mtd: ubi: Restore missing cleanup on ubi_init() failure path
ubifs: dbg_orphan_check: Fix missed key type checking
ubifs: Fix unattached inode when powercut happens in creating
ubifs: Fix space leak when powercut happens in linking tmpfile
ubifs: Move ui->data initialization after initializing security
ubifs: Fix adding orphan entry twice for the same inode
ubifs: Remove insert_dead_orphan from replaying orphan process
Revert "ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path"
ubifs: Don't add xattr inode into orphan area
ubifs: Fix unattached xattr inode if powercut happens after deleting
mtd: ubi: avoid expensive do_div() on 32-bit machines
mtd: ubi: make ubi_class constant
ubi: eba: properly rollback inside self_check_eba
After a recent change in clang to stop consuming all instances of '-S'
and '-c' [1], the stack protector scripts break due to the kernel's use
of -Werror=unused-command-line-argument to catch cases where flags are
not being properly consumed by the compiler driver:
$ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument
clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument]
This results in CONFIG_STACKPROTECTOR getting disabled because
CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set.
'-c' and '-S' both instruct the compiler to stop at different stages of
the pipeline ('-S' after compiling, '-c' after assembling), so having
them present together in the same command makes little sense. In this
case, the test wants to stop before assembling because it is looking at
the textual assembly output of the compiler for either '%fs' or '%gs',
so remove '-c' from the list of arguments to resolve the error.
All versions of GCC continue to work after this change, along with
versions of clang that do or do not contain the change mentioned above.
Cc: stable@vger.kernel.org
Fixes: 4f7fd4d7a7 ("[PATCH] Add the -fstack-protector option to the CFLAGS")
Fixes: 60a5317ff0 ("x86: implement x86_32 stack protector")
Link: 6461e53781 [1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
