The "label" property is not documented for the dlg,slg7xl45106. Nor is
it common to use for GPIO controllers. So drop it.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251216175914.2791200-1-robh@kernel.org
This reverts commit 06d22ed6b6.
OP-TEE logic in U-Boot automatically injects a reserved-memory
node along with optee firmware node to kernel device tree.
The injection logic is dependent on that there is no manually
defined optee node. Having the node in zynqmp.dtsi effectively
breaks OP-TEE's insertion of the reserved-memory node, causing
memory access violations during runtime.
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251125-revert-zynqmp-optee-v1-1-d2ce4c0fcaf6@vaisala.com
Since the following commit, the zynqmp clk driver uses the common
divider_round_rate() when determining the appropriate clock divider for a
requested clock frequency:
1fe15be1fb
This means that all the calculations will be in kHz when determining the
appropriate clock divider for a given cpufreq request. The problem with this
is that the zynqmp.dtsi and zynqmp-clk-ccf.dtsi files have frequency
definitions in Hz, so when dividing requested values in kHz, errors can occur
with the rounding.
For example, the current pss_ref_clk frequency is 33333333 Hz which generates
a cpufreq parent clock frequency of 1199999988 Hz which is the same as the
highest opp-table-cpu frequency in the zynqmp.dtsi.
But if a user requests the value 1199999 kHz as recommended in the available
frequencies:
root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
299999 399999 599999 1199999
root@zynqmp:/ # echo 1199999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
The calculation will be:
1199999988 / 1199999000 = 1.000001
This will get rounded up to a divider value of 2 giving the following result.
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999
Also, if a user tries to work around this calculation by using any larger
values, it still will not fix the problem because the driver will use the
largest opp in kHz which leads to the same calculation error.
User requests 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
Driver converts any value greater than 1199999 to the largest opp which is
1199999 and then calculates the divider value with the same calculation.
The calculation will still be:
1199999988 / 1199999000 = 1.000001
This will get rounded up to a divider value of 2 giving the following result.
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999
This means there is no way to configure the zynqmp for the fastest opp using
the current dtsi files.
To fix this issue, this patch updates the zynqmp opp-table-cpu and
pss_ref_clk, so the clock rates are calculated correctly.
root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
300000 400000 600000 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
1200000
Signed-off-by: Neal Frager <neal.frager@amd.com>
Acked-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251111070555.1169130-1-neal.frager@amd.com
Unlike zynq, which has a specific compatible for the Cadence spi
controller, zynqmp and versal-net do not have specific compatibles.
In order to "encourage" people to use soc-specific compatibles for new
devices using this IP, add specific compatibles for these devices, with
a fallback to the existing compatible for the r1p6 version of the IP so
that there will be no functional change.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251001-cheesy-shucking-c55431bbcae3@spud
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add ethernet aliases to CC (Carrier card) description to create a
connection which is used by U-BOOT (fdt_fixup_ethernet()) for updating
local-mac-address in DT.
On Kria SOM MAC address is read from i2c eeprom at start and based on it
environment variables are created. Without creating aliases U-Boot is not
able to inject local-mac-address DT property and OS won't get the same MAC
address unless another i2c read is happening in OS.
Also aliases are using string not phandle (because of dtso) that's why full
path has to be provided but that shouldn't be a big issue because location
of ethernet controller is fixed.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/72304150f87fd5e3338e31e2be8cf5d29955cc02.1756799774.git.michal.simek@amd.com
On a few zcu106 boards USB devices (Dell MS116 USB Optical Mouse, Dell USB
Entry Keyboard) are not enumerated on linux boot due to commit
'b8745e7eb488 ("arm64: zynqmp: Fix usb node drive strength and slew
rate")'.
To fix it as a workaround revert to working version and then investigate
at board level why drive strength from 12mA to 4mA and slew from fast to
slow is not working.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/85a70cb014ec1f07972fccb60b875596eeaa6b5c.1756799774.git.michal.simek@amd.com
The correct operating mode for the fan is inversed (1). The previous pwm
driver implementation had a bug and the polarity information was propagated
incorrectly to the kernel. The normal (0) polarity specified in the device
tree was incorrectly clearing the polarity bit in the counter control
register. After the bug fix, setting the polarity to inversed (1) in the
device tree will clear the polarity bit.
Also provide label for custom description based on this SOM.
Signed-off-by: Vishal Patel <vishal.patel@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e6dc9ce1e0b97c9d9b073c323cc94a5d7a88b94a.1752835502.git.michal.simek@amd.com
Add "cap-mmc-hw-reset" property to the eMMC DT node to perform the
eMMC device hardware reset.
Also, add "no-sd", "no-sdio" properties to eMMC DT node to skip
unwanted sd, sdio related commands during initialization for eMMC
device as this may lead to unnecessary register dump.
Signed-off-by: Paul Alvin <alvin.paulp@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/10132834c0509539b0d01ff5097591cd2e3ae125.1752835501.git.michal.simek@amd.com
As per the design specification
"The 16-bit Seconds Calibration Value represents the number of
Oscillator Ticks that are required to measure the largest time period
that is less than or equal to 1 second.
For an oscillator that is 32.768kHz, this value will be 0x7FFF."
Signed-off-by: Harini T <harini.t@amd.com>
Link: https://lore.kernel.org/r/20250710061309.25601-1-harini.t@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Firmware contants do not fit the purpose of bindings because they are not
independent IDs for abstractions. They are more or less just contants which
better to wire via header with DT which is using it. That's why copy header
to platform folder (align macro) and use it locally.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/c3f011812597f4c3095448726f5924b2334c7da1.1738600745.git.michal.simek@amd.com
Add clock-output-names property to clock nodes, so that the resulting
clock name do not change when clock node name is changed.
Also, replace underscores with hyphens in the clock node names as per
dt-schema rule.
Signed-off-by: Naman Trivedi <naman.trivedimanojbhai@amd.com>
Acked-by: Senthil Nathan Thangaraj <senthilnathan.thangaraj@amd.com>
Link: https://lore.kernel.org/r/20241122095712.1166883-1-naman.trivedimanojbhai@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add some thermal trip points. We can't undervolt the CPUs to save power
when we underclock them, so there isn't really a point in throttling
them until we are about to overheat. As such, the passive trip point is
right below the critical trip point.
The critical trip point is the extended/industrial-grade maximum
junction temperature of 100C minus the maximum temperature sensor error
of 3.5C (in the range -55C to 110C). Automotive- and military-grade
parts can go up to 125C, but as far as I can tell there is no way to
detect them at runtime. Userspace can adjust the trip points at runtime,
but this may not be viable when booting above 100C. I think it's
reasonable to ask automotive/military users to edit their device trees
to bump the trip points, but if that proves to be an issue we can
always go with no default temperatures. However, that wouldn't be too
nice for the majority of extended/industrial users.
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240812215129.3599832-4-sean.anderson@linux.dev
Signed-off-by: Michal Simek <michal.simek@amd.com>
Expose the AMS to userspace, allowing monitoring of internal voltages
and temperatures. For compatibility, we keep the node name the same as
on the SM-K26, and we keep the ZCU100 Rev C. around (since it is named
differently).
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240812215129.3599832-3-sean.anderson@linux.dev
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add PCIe phy bindings for the ZCU102.
Link: https://lore.kernel.org/r/20240531161337.864994-8-sean.anderson@linux.dev
Tested-by: Thippeswamy Havalige <thippeswamy.havalige@amd.com>
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Revision 2 is SW compatible with revision 1 but it is necessary to reflect
it in model and compatible properties which are parsed by user space.
Rev 2 has improved a power on boot reset and MIO34 shutdown glich
improvement done via an additional filter in the GreenPak chip.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/458698666fdfcaaac70967d9f755422a480bed99.1716802450.git.michal.simek@amd.com
Since the zynqmp pinctrl driver now includes support for the
tri-state registers, ensure that the pins needing output-enable
are correctly configured for SOMs.
Currently, there is an issue with the detection of the MMC for
the SOM kv260, resulting in the following error:
ZynqMP> mmc dev 1
Card did not respond to voltage select! : -110
To address this problem, configure the SDIO pins for output-enable
to enable MMC detection.
Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/540f83f7d88b80441c9fa3d771dd7b000b0710a4.1716802450.git.michal.simek@amd.com
Add coresight debug support to the device tree. This can be useful when
panicking, especially when a core is hung in EL3.
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240503153422.1958812-1-sean.anderson@linux.dev
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it before using split mode
dts. Both device-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20240412183708.4036007-4-tanmay.shah@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Here is the big set of tty/serial driver changes for 6.10-rc1. Included
in here are:
- Usual good set of api cleanups and evolution by Jiri Slaby to make
the serial interfaces move out of the 1990's by using kfifos instead
of hand-rolling their own logic.
- 8250_exar driver updates
- max3100 driver updates
- sc16is7xx driver updates
- exar driver updates
- sh-sci driver updates
- tty ldisc api addition to help refuse bindings
- other smaller serial driver updates
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZk4Cvg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymqpwCgnHU1NeBBUsvoSDOLk5oApIQ4jVgAn102jWlw
3dNDhA4i3Ay/mZdv8/Kj
=TI+P
-----END PGP SIGNATURE-----
Merge tag 'tty-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty / serial updates from Greg KH:
"Here is the big set of tty/serial driver changes for 6.10-rc1.
Included in here are:
- Usual good set of api cleanups and evolution by Jiri Slaby to make
the serial interfaces move out of the 1990's by using kfifos
instead of hand-rolling their own logic.
- 8250_exar driver updates
- max3100 driver updates
- sc16is7xx driver updates
- exar driver updates
- sh-sci driver updates
- tty ldisc api addition to help refuse bindings
- other smaller serial driver updates
All of these have been in linux-next for a while with no reported
issues"
* tag 'tty-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (113 commits)
serial: Clear UPF_DEAD before calling tty_port_register_device_attr_serdev()
serial: imx: Raise TX trigger level to 8
serial: 8250_pnp: Simplify "line" related code
serial: sh-sci: simplify locking when re-issuing RXDMA fails
serial: sh-sci: let timeout timer only run when DMA is scheduled
serial: sh-sci: describe locking requirements for invalidating RXDMA
serial: sh-sci: protect invalidating RXDMA on shutdown
tty: add the option to have a tty reject a new ldisc
serial: core: Call device_set_awake_path() for console port
dt-bindings: serial: brcm,bcm2835-aux-uart: convert to dtschema
tty: serial: uartps: Add support for uartps controller reset
arm64: zynqmp: Add resets property for UART nodes
dt-bindings: serial: cdns,uart: Add optional reset property
serial: 8250_pnp: Switch to DEFINE_SIMPLE_DEV_PM_OPS()
serial: 8250_exar: Keep the includes sorted
serial: 8250_exar: Make type of bit the same in exar_ee_*_bit()
serial: 8250_exar: Use BIT() in exar_ee_read()
serial: 8250_exar: Switch to use dev_err_probe()
serial: 8250_exar: Return directly from switch-cases
serial: 8250_exar: Decrease indentation level
...
The "arm,armv8-pmuv3" compatible is intended only for s/w models. Primarily,
it doesn't provide any detail on uarch specific events.
There's still remaining cases for CPUs without any corresponding PMU
definition and for big.LITTLE systems which only have a single PMU node
(there should be one per core type).
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Link: https://lore.kernel.org/r/20240417203853.3212103-1-robh@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
dwc3-xilinx.yaml defines 2 clocks which are not defined that's why define
them (bus_early clock is moved to bus_clk in glue logic).
With also describing kv260 assigned clock rates with assigned clocks.
Also add missing status property to standard dwc3 core.
Link: https://lore.kernel.org/r/aa4c65a8997c7a65f23da3a3088bb5eb64281307.1704728353.git.michal.simek@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
SMMU is disabled by default and not all masters can be enabled at the same
time because of limited number of entries. That's why comment all iommu
properties but keep them for reference in DT. In XEN case they should be
added back and Xen should have SMMU enabled by default.
Also add IDs for DP and DPDMA.
Link: https://lore.kernel.org/r/bdb012b1c86abb0d9aa88954196d886d1283e9b1.1704728353.git.michal.simek@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
gpio38 is used in SOM's kv260 to reset the Ethernet PHY.
At present, HW reset is not working properly as Tri-state
is enabled for MIO38, causing inappropriate PHY register reads.
Disabled Tri-state for MIO38 to make HW reset work.
Tri-state disable :
ZynqMP> md 0xFF180208 2
ff180208: 00bfe7a3 00000540
Tri-state enable :
ZynqMP> md 0xFF180208 2
ff180208: 00bfe7e3 00000540
Signed-off-by: Tejas Bhumkar <tejas.arvind.bhumkar@amd.com>
Link: https://lore.kernel.org/r/9f8a0687be407a8ffad610087074e94ebc4f5982.1704728353.git.michal.simek@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
