| Age | Commit message (Collapse) | Author |
|---|
|
Between kexec and confidential VM support, handling the EFI memory maps
correctly on x86 is already proving to be rather difficult (as opposed
to other EFI architectures which manage to never modify the EFI memory
map to begin with)
EFI fake memory map support is essentially a development hack (for
testing new support for the 'special purpose' and 'more reliable' EFI
memory attributes) that leaked into production code. The regions marked
in this manner are not actually recognized as such by the firmware
itself or the EFI stub (and never have), and marking memory as 'more
reliable' seems rather futile if the underlying memory is just ordinary
RAM.
Marking memory as 'special purpose' in this way is also dubious, but may
be in use in production code nonetheless. However, the same should be
achievable by using the memmap= command line option with the ! operator.
EFI fake memmap support is not enabled by any of the major distros
(Debian, Fedora, SUSE, Ubuntu) and does not exist on other
architectures, so let's drop support for it.
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The call to radeon_vm_clear_freed might clear bo_va->bo, so
we have to check it before dereferencing it.
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Potential out of bounds access in dml2_calculate_rq_and_dlg_params()
because the value of out_lowest_state_idx used as an index for FCLKChangeSupport
array can be greater than 1.
[How]
Currently dml2 core specifies identical values for all FCLKChangeSupport
elements. Always use index 0 in the condition to avoid out of bounds access.
Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix 4k240 underflow on dcn351
Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Some of the panels does not have the refresh rate range info
in base EDID and only have the refresh rate range info in
DisplayID block.
It will cause the max/min freesync refresh rate set to 0.
[How]
Try to parse the refresh rate range info from DisplayID if the
max/min refresh rate is 0.
Reviewed-by: Sun peng Li <sunpeng.li@amd.com>
Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Description]
We need to ensure to take into account cursor prefetch BW in
mode support or we may pass ModeQuery but fail an actual flip
which will cause a hang. Flip may fail because the cursor_pre_bw
is populated during mode programming (and mode programming is
never called prior to ModeQuery).
Reviewed-by: Chaitanya Dhere <chaitanya.dhere@amd.com>
Reviewed-by: Nevenko Stupar <nevenko.stupar@amd.com>
Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Commit 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers
during probe") enabled runtime PM for all mediatek clock controllers,
but this introduced an issue on the resume path.
If a device resumes earlier than the clock controller and calls
clk_prepare() when runtime PM is enabled on the controller, it will end
up calling clk_pm_runtime_get(). But the subsequent
pm_runtime_resume_and_get() call will fail because the runtime PM is
temporarily disabled during suspend.
To workaround this, introduce a need_runtime_pm flag and only enable it
on mt8183-mfgcfg, which is the driver that observed deadlock previously.
Hopefully mt8183-cfgcfg won't run into the issue at the resume stage
because the GPU should have stopped rendering before the system calls
suspend.
Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe")
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Link: https://lore.kernel.org/r/20240613120357.1043342-1-treapking@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
[Why]
We only enable the VRR while monitor usable refresh rate range
is greater than 10 Hz.
But we did not check the range in DRM_EDID_FEATURE_CONTINUOUS_FREQ
case.
[How]
Add a refresh rate range check before set the freesync_capable flag
in DRM_EDID_FEATURE_CONTINUOUS_FREQ case.
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Sometimes the new_crtc_state->vrr_infopacket did not sync up with the
current state.
It will affect the update_freesync_state_on_stream() does not update
the state correctly.
[How]
Reset the freesync config before get_freesync_config_for_crtc() to
make sure we have the correct new_crtc_state for VRR.
Reviewed-by: Sun peng Li <sunpeng.li@amd.com>
Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-fixes
Pull one Allwinner SoC clk driver fix for 6.10
- Fix min/max rate clamping that caused a regression back in 6.9
* tag 'sunxi-clk-fixes-for-6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
clk: sunxi-ng: common: Don't call hw_to_ccu_common on hw without common
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
Pull cxl fixes from Dave Jiang:
- Fix no cxl_nvd during pmem region auto-assemble
- Avoid NULLL pointer dereference in region lookup
- Add missing checks to interleave capability
- Add cxl kdoc fix to address document compilation error
* tag 'cxl-fixes-6.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl:
cxl: documentation: add missing files to cxl driver-api
cxl/region: check interleave capability
cxl/region: Avoid null pointer dereference in region lookup
cxl/mem: Fix no cxl_nvd during pmem region auto-assembling
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fix from David Sterba:
"A fixup for a recent fix that prevents an infinite loop during block
group reclaim.
Unfortunately it introduced an unsafe way of updating block group list
and could race with relocation. This could be hit on fast devices when
relocation/balance does not have enough space"
* tag 'for-6.10-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: fix adding block group to a reclaim list and the unused list during reclaim
|
|
ON/OFF in the keys was swapped between the first and second argument of
the prctl. The prctl key is always PR_RISCV_SET_ICACHE_FLUSH_CTX, and
the second argument can be PR_RISCV_CTX_SW_FENCEI_ON or
PR_RISCV_CTX_SW_FENCEI_OFF.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Fixes: 6a08e4709c58 ("documentation: Document PR_RISCV_SET_ICACHE_FLUSH_CTX prctl")
Link: https://lore.kernel.org/r/20240628-fix_cmodx_example-v1-1-e6c6523bc163@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
updated compatible property to include "thead,th1520-spi" for the
TH1520 SoC SPI Controller.
Signed-off-by: Kanak Shilledar <kanakshilledar@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20240701121355.262259-3-kanakshilledar@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The pd-mapper driver uses auxiliary bus and Qualcomm PDR message format
data. Add missing dependencies to the driver's Kconfig entry.
Reported-by: Mark Brown <broonie@kernel.org>
Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Chris Lew <quic_clew@quicinc.com>
Link: https://lore.kernel.org/r/20240626-qcom-pd-mapper-fix-deps-v1-1-644678dc4663@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull asm-generic fix from Arnd Bergmann:
"This fixes up a last minute build regression from the previous set of
bug fixes"
* tag 'asm-generic-fixes-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
syscalls: fix sys_fanotify_mark prototype
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"A number of devicetree fixes came in for the rockchip platforms,
correcting some of the address information, and reverting a change to
the MMC controller configuration that caused regressions.
Four drivers have one code change each, addressing minor build issues
for the optee firmware driver, the litex SoC platform driver and two
reset drivers.
The riscv fixes as also simple, mainly turning off device nodes in the
canaan dts files unless they are actually usable on a particular
board.
Finally, Drew takes over maintaining the THEAD RISC-V SoC platform"
* tag 'arm-fixes-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
drivers/soc/litex: drop obsolete dependency on COMPILE_TEST
tee: optee: ffa: Fix missing-field-initializers warning
arm64: dts: rockchip: Add sound-dai-cells for RK3368
arm64: dts: rockchip: Fix the i2c address of es8316 on Cool Pi 4B
reset: hisilicon: hi6220: add missing MODULE_DESCRIPTION() macro
reset: gpio: Fix missing gpiolib dependency for GPIO reset controller
MAINTAINERS: thead: update Maintainer
arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E
riscv: dts: starfive: Set EMMC vqmmc maximum voltage to 3.3V on JH7110 boards
arm64: dts: rockchip: make poweroff(8) work on Radxa ROCK 5A
Revert "arm64: dts: rockchip: remove redundant cd-gpios from rk3588 sdmmc nodes"
ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
arm64: dts: rockchip: Fix the value of `dlg,jack-det-rate` mismatch on rk3399-gru
arm64: dts: rockchip: set correct pwm0 pinctrl on rk3588-tiger
riscv: dts: canaan: Disable I/O devices unless used
riscv: dts: canaan: Clean up serial aliases
arm64: dts: rockchip: Rename LED related pinctrl nodes on rk3308-rock-pi-s
arm64: dts: rockchip: Fix SD NAND and eMMC init on rk3308-rock-pi-s
arm64: dts: rockchip: Fix rk3308 codec@ff560000 reset-names
arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B
|
|
Both ACPI_PROCESSOR and HOTPLUG_CPU are needed by ACPI_HOTPLUG_CPU.
Otherwise, we can have compiling error with the following configurations.
CONFIG_HOTPLUG_CPU=n
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
arch/arm64/kernel/smp.c: In function ‘arch_unregister_cpu’:
arch/arm64/kernel/smp.c:563:9: error: implicit declaration of \
function ‘unregister_cpu’; did you mean ‘register_cpu’? \
[-Werror=implicit-function-declaration]
563 | unregister_cpu(c);
| ^~~~~~~~~~~~~~
| register_cpu
Fix it by enabling ACPI_HOTPLUG_CPU when both ACPI_PROCESSOR and
HOTPLUG_CPU are enabled, consistent with other architectures like
x86 and loongarch.
Fixes: 9d0873892f4d ("arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled.")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202406300437.XnuW0n34-lkp@intel.com/
Signed-off-by: Gavin Shan <gshan@redhat.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240701001132.1585153-1-gshan@redhat.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd fixes from Miquel Raynal:
- Rockchip NAND controller driver was not checking the timings properly
and the introduction of NV-DDR support broke it.
- The core was also misbehaving in some very specific cases: in case of
(unlikely) bitflips in the parameter page, the fallback might have
failed as well but for software reasons.
- Finally, the chosen ECC configuration was no longer properly
propagated to upper layers, mostly failing an info message at probe
time.
* tag 'mtd/fixes-for-6.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
mtd: rawnand: rockchip: ensure NVDDR timings are rejected
mtd: rawnand: Bypass a couple of sanity checks during NAND identification
mtd: rawnand: Fix the nand_read_data_op() early check
mtd: rawnand: Ensure ECC configuration is propagated to upper layers
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
"Misc:
- Don't misleadingly warn during filesystem thaw operations.
It's possible that a block device which was frozen before it was
mounted can cause a failing thaw operation if someone concurrently
tried to mount it while that thaw operation was issued and the
device had already been temporarily claimed for the mount (The
mount will of course be aborted because the device is frozen).
netfs:
- Fix io_uring based write-through. Make sure that the total request
length is correctly set.
- Fix partial writes to folio tail.
- Remove some xarray helpers that were intended for bounce buffers
which got defered to a later patch series.
- Make netfs_page_mkwrite() whether folio->mapping is vallid after
acquiring the folio lock.
- Make netfs_page_mkrite() flush conflicting data instead of waiting.
fsnotify:
- Ensure that fsnotify creation events are generated before fsnotify
open events when a file is created via ->atomic_open(). The
ordering was broken before.
- Ensure that no fsnotify events are generated for O_PATH file
descriptors. While no fsnotify open events were generated, fsnotify
close events were. Make it consistent and don't produce any"
* tag 'vfs-6.10-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
netfs: Fix netfs_page_mkwrite() to flush conflicting data, not wait
netfs: Fix netfs_page_mkwrite() to check folio->mapping is valid
netfs: Delete some xarray-wangling functions that aren't used
netfs: Fix early issue of write op on partial write to folio tail
netfs: Fix io_uring based write-through
vfs: generate FS_CREATE before FS_OPEN when ->atomic_open used.
fsnotify: Do not generate events for O_PATH file descriptors
fs: don't misleadingly warn during thaw operations
|
|
When boost is set for CPUs using acpi-cpufreq, the policy is not
updated which can cause boost to be incorrectly not reported.
Fixes: 218a06a79d9a ("cpufreq: Support per-policy performance boost")
Link: https://patch.msgid.link/20240626204723.6237-2-mario.limonciello@amd.com
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Suggested-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The behavior introduced in commit f37a4d6b4a2c ("cpufreq: Fix per-policy
boost behavior on SoCs using cpufreq_boost_set_sw()") sets up the boost
policy incorrectly when boost has been enabled by the platform firmware
initially even if a driver sets the policy up.
This is because policy_has_boost_freq() assumes that there is a frequency
table set up by the driver and that the boost frequencies are advertised
in that table. This assumption doesn't work for acpi-cpufreq or
amd-pstate. Only use this check to enable boost if it's not already
enabled instead of also disabling it if alreayd enabled.
Fixes: f37a4d6b4a2c ("cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw()")
Link: https://patch.msgid.link/20240626204723.6237-1-mario.limonciello@amd.com
Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Suggested-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Fix the following warnings when compiling dtbs with W=1:
../arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi:343.10-353.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/tps6598x@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
../arch/arm64/boot/dts/ti/k3-am62-main.dtsi:633.22-643.5: Warning (graph_child_address): /bus@f0000/dwc3-usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
Cc: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240626101520.1782320-3-d-gole@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Fix the following warnings that are thrown when building dtbs with W=1:
../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:367.10-376.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/usb-power-controller@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
../arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi:647.22-657.5: Warning (graph_child_address): /bus@f0000/usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
also defined at ../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:517.7-528.3
Cc: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240626101520.1782320-2-d-gole@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The AM67A/J722S/TDA4AEN platform is a derivative of AM62P platform
and we have no single 1:1 relation regarding index of GPIO and pin
controller. The GPIOs and pin controller registers have mapping and
holes in the map. These have been extracted from the J722S data
sheet. The MCU mapping is carried forward as is with J722S, however the
main GPIO block has differences that needs to be accounted for.
Mux mode input is selected as it is bi-directional. In case a specific
pull type or a specific pin level drive setting is desired, the board
device tree files will have to explicitly mux those pins for the GPIO
with the desired setting.
Ref: J722S Data sheet https://www.ti.com/lit/gpn/tda4aen-q1
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
On the AM62P platform we have no single 1:1 relation regarding index
of GPIO and pin controller. The GPIOs and pin controller registers
have mapping and holes in the map. These have been extracted from the
AM62P data sheet.
MCU pinctrl definition is shared as it is common between AM62P and
J722S, but that is not the case for main domain.
Ref: AM62P Data sheet https://www.ti.com/lit/gpn/am62p
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Introduce a GPIO mux mode macro for easier readability. All K3 devices
use mux mode 7 to switch to GPIO mux and this allows the gpio-ranges to
be defined for pinctrl-single clearly.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20240627162539.691223-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The WKUP system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-8-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The WKUP system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-7-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-6-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-5-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-4-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-3-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The MCU system controller address region contains an eFuse block with
MAC addresses to be used by the Ethernet controller. The property
“ti,syscon-efuse” contains a phandle to a syscon region and an offset
into this region where the MAC addresses can be found. Currently
"ti,syscon-efuse" points to the entire system controller address space
node with an offset to the eFuse IP address.
Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then
point the Ethernet controller directly to this region, no offset needed.
This makes it so the system controller memory area does not need to be one
big syscon area, describe this bus address area as the simple-bus it is.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240628151518.40100-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
NAND boot would require these nodes to be present at early stage.
Ensure that by adding "bootph-all" to relevant nodes.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240628-am642-evm-nand-bootph-v2-1-387bfa1533a6@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The phyCORE-AM62Ax [1] is a SoM (System on Module) featuring TI's AM62Ax SoC.
It can be used in combination with different carrier boards.
This module can come with different sizes and models for
DDR, eMMC, SPI NOR Flash and various SoCs from the AM62Ax family.
A development Kit, called phyBOARD-Lyra [2] is used as a carrier board
reference design with a mapper board being used to allow the phyCORE-AM62Ax
to fit the phyBOARD-Lyra.
Supported features:
* Debug UART
* SPI NOR Flash
* eMMC
* 2x Ethernet
* Micro SD card
* I2C EEPROM
* I2C RTC
* GPIO Expander
* LEDs
* USB
* HDMI
* USB-C
* Audio
For more details, see:
[1] Product page SoM: https://www.phytec.com/product/phycore-am62a
[2] Product page CB: https://www.phytec.com/product/phyboard-am62a
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240626155244.3311436-4-ggiordano@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add devicetree bindings for AM62Ax based phyCORE-AM62A7 SoM
and phyBOARD-Lyra RDK.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240626155244.3311436-3-ggiordano@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
PHYTECs phyBOARD-Lyra carrier board is able to accomidate multiple SoMs.
Refactor k3-am625-phyboard-lyra-rdk.dts into an include file so it can
be reused in combination with our phyCORE-AM62Ax SoM.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240626155244.3311436-2-ggiordano@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
On AM62a SoCs the AUDIO_REFCLKx clocks can be used as an input to
external peripherals when configured through CTRL_MMR, so add the
clock nodes.
Based on: Link: https://lore.kernel.org/lkml/20230807202159.13095-2-francesco@dolcini.it/
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Link: https://lore.kernel.org/r/20240626155244.3311436-1-ggiordano@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The audio support on J784S4-EVM is using PCM3168A[0] codec
connected to McASP0 serializers.
- Add the nodes for sound-card, audio codec, MAIN_I2C3 and
McASP0.
- Add pinmux for I2C3, McASP0 and AUDIO_EXT_REFCLK1.
- Add necessary GPIO hogs to route the MAIN_I2C3 lines and
McASP serializer.
- Add idle-state as 1 in mux1 to route McASP clock signals.
[0]: <https://www.ti.com/lit/gpn/pcm3168a>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20240626101645.36764-4-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
On J784S4 SoC, the AUDIO_REFCLK1 can be used as input to external
peripherals when configured through CTRL_MMR.
Add audio_refclk1 node which would be used as system clock for
audio codec PCM3168A.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20240626101645.36764-3-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add McASP 0-4 instances and keep them disabled because several
required properties are missing as they are board specific.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20240626101645.36764-2-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The NAND expansion card (PROC143E1) connects over the User/MCU/PRU
Expansion port on the am62-lp-sk EVM.
The following pins are shared between McASP1 and GPMC-NAND so
both cannot work simultaneously.
Pin name McASP1 function GPMC function
======== =============== =============
J17 MCASP1_AXR0 GPMC0_WEN
P21 MCASP1_AFSX GPMC0_WAIT0
K17 MCASP1_ACLKX GPMC0_BE0N_CLE
K20 MCASP1_AXR2 GPMC0_ADVN_ALE
The factory default sets the pins for McASP1 use. (i.e.
Resistor Array RA1 installed, RA4 not installed).
For NAND use, RA1 has to be removed and RA4 must be
installed.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240622-am62lp-sk-nand-v1-2-caee496eaf42@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add GPMC and ELM device tree nodes for AM62 SoC family.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240622-am62lp-sk-nand-v1-1-caee496eaf42@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The audio support on J722S-EVM is using TLV320AIC3106[0] codec
connected to McASP1 serializers.
- Add the nodes for sound-card, audio codec and McASP1.
- Add hog for TRC_MUX_SEL to select between McASP and TRACE signals
- Add hogs for GPIO_AUD_RSTn and MCASP1_FET_SEL which is used to
switch between HDMI audio and codec audio.
- Add pinmux for MCASP1 and AUDIO_EXT_REFCLK1.
[0]: <https://www.ti.com/lit/gpn/TLV320AIC3106>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20240625113301.217369-3-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
On J722S SoC, the AUDIO_REFCLK1 can be used as input to external
peripherals when configured through CTRL_MMR.
Add audio_refclk1 node which would be used as system clock for the
audio codec TLV320AIC3106.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20240625113301.217369-2-j-choudhary@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
AM68 SK has an OSPI NOR flash on its SOM connected to OSPI0 instance.
Enable support for the same. Also, describe the OSPI flash partition
information through the device tree, according to the offsets in the
bootloader.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20240622161835.3610348-1-u-kumar1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Add an overlay to change from the default OSPI NOR to QSPI NOR
for all am6xx-phycore-som boards.
The EEPROM on am6xx-phycore-soms contains information about the
configuration of the SOM. The standard configuration of the SOM
has an ospi nor, but if qspi nor is populated, the EEPROM will
indicate that change and we can use this overlay to cleanly change to
qspi nor.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Link: https://lore.kernel.org/r/20240621233143.2077941-1-nmorrisson@phytec.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
MIT license was added to the AM64x SoC DTSIs in commit 6248b20e3203
("arm64: dts: ti: k3-am64: Add MIT license along with GPL-2.0"). Apply
the same license change to the TQMa64xxL SoM and MBaX4XxL baseboard
Device Trees.
The copyright year is updated to indicate the license change.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/20240625110244.9881-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
In current configuration, nau8822 codec on development carrier board
provides distorted audio output. This happens due to reference clock
is fixed to 25MHz and no PLL is enabled. Following is the calculation
of deviation error for different frequencies:
44100Hz:
fs = 256 (fixed)
prescaler = 2
target frequency = 44100 * 256 * 2 = 22579200
deviation = 22579200 vs 25000000 = 9.6832%
48000Hz:
fs = 256 (fixed)
prescaler = 2
target frequency = 48000 * 256 * 2 = 24576000
deviation = 24576000 vs 25000000 = 1.696%
Enabling nau822 PLL via providing mclk-fs property to simple-audio-card
configures clocks properly, but also adjusts audio reference clock
(mclk), which in case of TI AM62 should be avoided, as it only
supports 25MHz output [1][2].
This change enables PLL on nau8822 by providing mclk-fs, and moves
away audio reference clock from DAI configuration, which prevents
simple-audio-card to adjust it before every playback [3].
[1]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1175479/processor-sdk-am62x-output-audio_ext_refclk0-as-mclk-for-codec-and-mcbsp/4444986#4444986
[2]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1188051/am625-audio_ext_refclk1-clock-output---dts-support/4476322#4476322
[3]: sound/soc/generic/simple-card-utils.c#L441
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240418105730.120913-1-andrejs.cainikovs@gmail.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
