Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal,
disabling SPI leads to messages like when suspending:
Powerdomain (core_pwrdm) didn't enter target state 0
and according to /sys/kernel/debug/pm_debug/count off state is not
entered. That was not connected to SPI during the discussion
of disabling SPI. See:
https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/
The reason is that SPI is per default in slave mode. Linux driver
will turn it to master per default. It slave mode, the powerdomain seems to
be kept active if active chip select input is sensed.
Fix that by explicitly disabling the SPI3 pins which used to be muxed by
the bootloader since they are available on an optionally fitted header
which would require dtb overlays anyways.
Fixes: a622310f7f ("ARM: dts: gta04: fix excess dma channel usage")
CC: stable@vger.kernel.org
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20241204174152.2360431-1-andreas@kemnade.info
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Ensure correct handling of "endianness"
for word-sized data in amd756_access
- Convert word data into little-endian using cpu_to_le16
- Convert word data from little-endian
to cpu native format using le16_to_cpu
This fixes poteential issues on big-endian systems and
ensure proper byte ordering for SMBus word transacitions
Signed-off-by: Atharva Tiwari <evepolonium@gmail.com>
Link: https://lore.kernel.org/r/20250101103422.30523-1-evepolonium@gmail.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
LPI2C support master controller and target controller enabled
simultaneously. Both controllers share the same SDA/SCL lines
and interrupt source but has a separate control and status
registers. When target is enabled and an interrupt has been
triggered, target register status will be checked to determine
IRQ source. Then enter the corresponding interrupt handler
function of master or target to handle the interrupt event.
This patch supports basic target data read/write operations in
7-bit target address. LPI2C target mode can be enabled by using
I2C slave backend. I2C slave backend behaves like a standard I2C
client. For simple use and test, Linux I2C slave EEPROM backend
can be used.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Link: https://lore.kernel.org/r/20241230033846.2302500-1-carlos.song@nxp.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Avoid repeating the error handling pattern:
geni_se_resources_off(&gi2c->se);
clk_disable_unprepare(gi2c->core_clk);
return;
Introduce a single 'goto' exit label for cleanup in case of
errors. While there are currently two distinct exit points, there
is no overlap in their handling, allowing both branches to
coexist cleanly.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Link: https://lore.kernel.org/r/20241227223230.462395-3-andi.shyti@kernel.org
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Replace classical dev_err with dev_err_probe in the probe
function for better error reporting. Also, use dev_err_probe in
cases where the error number is clear (e.g., -EIO or -EINVAL) to
maintain consistency.
Additionally, remove redundant logging to simplify the code.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Link: https://lore.kernel.org/r/20241227223230.462395-2-andi.shyti@kernel.org
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Add samsung,exynos8895-hsi2c dedicated compatible for representing
I2C of Exynos8895 SoC. Since there are I2C buses that aren't implemented
as a part of USIv1 blocks, they only require a single clock.
Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20241228111509.896502-2-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Add eDMA mode support for LPI2C.
There are some differences between TX DMA mode and RX DMA mode.
LPI2C MTDR register is Controller Transmit Data Register.
When lpi2c send data, it is tx cmd register and tx data fifo.
When lpi2c receive data, it is just a rx cmd register. LPI2C MRDR
register is Controller Receive Data Register, received data are
stored in this.
MTDR[8:10] is CMD field and MTDR[0:7] is DATA filed.
+-----------+-------------------------------+
| C M D | D A T A |
+---+---+---+---+---+---+---+---+---+---+---+
| 10| 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+---+---+---+---+---+---+---+---+---+---+---+
MRDR is Controller Receive Data Register.
MRDR[0:7] is DATA filed.
+-------------------------------+
| D A T A |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+---+---+---+---+---+---+---+---+
When the LPI2C controller needs to send data, tx cmd and 8-bit data
should be written into MTDR:
CMD: 000b: Transmit the value in DATA[7:0].
DATA: 8-bit data.
If lpi2c controller needs to send N 8-bit data, just write N times
(CMD(W) + DATA(u8)) to MTDR.
When the LPI2C controller needs to receive data, rx cmd should be
written into MTDR, the received data will be stored in the MRDR.
MTDR(CMD): 001b: Receive (DATA[7:0] + 1) 8-bit data.
MTDR(DATA): byte counter.
MRDR(DATA): 8-bit data.
So when lpi2c controller needs to receive N 8-bit data,
1. N <= 256:
Write 1 time (CMD(R) + BYTE COUNT(N-1)) into MTDR and receive data from
MRDR.
2. N > 256:
Write N/256 times (CMD(R) + BYTE COUNT(255)) + 1 time (CMD(R) + BYTE
COUNT(N%256)) into MTDR and receive data from MRDR.
Due to these differences, when lpi2c is in DMA TX mode, only enable TX
channel to send data. But when lpi2c is in DMA RX mode, TX and RX channel
are both enabled, TX channel is used to send RX cmd and RX channel is
used to receive data.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Frank Li <frank.li@nxp.com>
Link: https://lore.kernel.org/r/20241125142909.1613245-1-carlos.song@nxp.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Replace comma between expressions with semicolons.
Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.
Found by inspection.
No functional change intended.
Compile tested only.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://lore.kernel.org/r/20241126023839.251922-1-nichen@iscas.ac.cn
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Rework the read and write code paths in the driver to support operation
in atomic contexts.
Similar changes have been implemented in other drivers, including:
commit 3a5ee18d2a ("i2c: imx: implement master_xfer_atomic callback")
commit 445094c8a9 ("i2c: exynos5: add support for atomic transfers")
commit ede2299f71 ("i2c: tegra: Support atomic transfers")
commit fe402bd090 ("i2c: meson: implement the master_xfer_atomic
callback")
Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20241210095242.1982770-3-manikanta.guntupalli@amd.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
The AMBA bus header files do not generate compilation errors even
when the AMBA bus is not enabled in Kconfig via ARM_AMBA.
This allows the Nomadik driver to be compiled for testing
purposes with the COMPILE_TEST option enabled.
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20241210221641.2661577-1-andi.shyti@kernel.org
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Document support for the I2C Bus Interface (RIIC) found in the Renesas
RZ/G3E (R9A09G047) SoC. This IP is compatible with Renesas RZ/V2H
(R9A09G057) RIIC IP.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20241216202436.185773-1-biju.das.jz@bp.renesas.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Return -EPROBE_DEFER when dma_request_slave_channel() because DMA driver
have not ready yet.
Move i2c_imx_dma_request() before registering I2C adapter to avoid
infinite loop of .probe() calls to the same driver, see "e8c220fac4
Revert "i2c: imx: improve the error handling in i2c_imx_dma_request()""
and "Documentation/driver-api/driver-model/driver.rst".
Use CPU mode to avoid stuck registering i2c adapter when DMA resources
are unavailable.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Acked-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20241226062521.1004809-1-carlos.song@nxp.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Nuvoton slave enable was in user space API call master_xfer, so it is
subject to delays from the OS scheduler. If the BMC is not enabled for
slave mode in time for master to send response, then it will NAK the
address match. Then the PLDM request timeout occurs.
If the slave enable is moved to the EOB interrupt service routine, then
the BMC can be ready in slave mode by the time it needs to receive a
response.
Signed-off-by: Charles Boyer <Charles.Boyer@fii-usa.com>
Signed-off-by: Vivekanand Veeracholan <vveerach@google.com>
Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Tali Perry <tali.perry1@gmail.com>
Link: https://lore.kernel.org/r/20241219090859.18722-5-kfting@nuvoton.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Modify i2c frequency from table parameters for NPCM i2c modules.
Supported frequencies are:
1. 100KHz
2. 400KHz
3. 1MHz
The original equations were tested on a variety of chips and base clocks.
Since we added devices that use higher frequencies of the module we
saw that there is a mismatch between the equation and the actual
results on the bus itself, measured on scope.
Meanwhile, the equations were not accurate to begin with.
They are an approximation of the ideal value. The ideal value is
calculated per frequency of the core module.
So instead of using the equations we did an optimization per module
frequency, verified on a device.
Most of the work was focused on the rise time of the SCL and SDA,
which depends on external load of the bus and PU.
Different PCB designs, or specifically to this case: the number
and type of targets on the bus, impact the required values for
the timing registers.
Users can recalculate the numbers for each bus and get an even better
optimization, but our users chose not to.
We manually picked values per frequency that match the entire valid
range of targets (from 1 to max number). Then we check against the
AMR described in SMB spec and make sure that none of the values
is exceeding.
This process was led by the chip architect and included a lot of testing.
Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Tali Perry <tali.perry1@gmail.com>
Link: https://lore.kernel.org/r/20241219090859.18722-4-kfting@nuvoton.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Store the client address earlier since it might get called in
the i2c_recover_bus() logic flow at the early stage of
npcm_i2c_master_xfer().
Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Tali Perry <tali.perry1@gmail.com>
Link: https://lore.kernel.org/r/20241219090859.18722-3-kfting@nuvoton.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
The users want to connect a lot of masters on the same bus.
This timeout is used to determine the time it takes to take bus ownership.
The transactions are very long, so waiting 35ms is not enough.
Increase the timeout and treat it as the total timeout, including retries.
The total timeout is 2 seconds now.
The i2c core layer will have chances to retry to call the i2c driver
transfer function if the i2c driver reports that the bus is busy and
returns -EAGAIN.
Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Tali Perry <tali.perry1@gmail.com>
Link: https://lore.kernel.org/r/20241219090859.18722-2-kfting@nuvoton.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Switch different pinctrl state in different system power status.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20241223034343.544002-1-carlos.song@nxp.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Put runtime PM to resume state between suspend() and suspend_noirq(),
resume_noirq() and resume(), because some I2C devices need the controller
on to perform communication during this period.
The controller can't be woken up once runtime pm is disabled and in
runtime autosuspended state.
The problem can be easily reproduced on the I.MX8MQ platform:
the PMIC needs to be used to enable regulator when the system resumes.
When the PMIC uses the I2C controller, I2C runtime pm has not been enabled,
so in i2c xfer(), pm_runtime_resume_and_get() will return an error,
which causes data transfer to fail. Therefore, regulators cannot
be enabled and system resume hangs.
Here is resume error log:
[ 53.888902] galcore 38000000.gpu3d: PM: calling genpd_resume_noirq @ 529, parent: platform
[ 53.897203] i2c_imx_xfer, pm_runtime_resume_and_get is -13
[ 53.902713] imx-pgc imx-pgc-domain.5: failed to enable regulator: -EACCES
[ 53.909518] galcore 38000000.gpu3d: PM: genpd_resume_noirq returned 0 after 12331 usecs
[ 53.917545] mxc_hantro 38300000.vpu: PM: calling genpd_resume_noirq @ 529, parent: soc@0
[ 53.925659] i2c_imx_xfer, pm_runtime_resume_and_get is -13
[ 53.931157] imx-pgc imx-pgc-domain.6: failed to enable regulator: -EACCES
I.MX8MQ system resume normally after applying the fix. Here is resume log:
[ 71.068807] galcore 38000000.gpu3d: PM: calling genpd_resume_noirq @ 530, parent: platform
[ 71.077103] i2c_imx_xfer, pm_runtime_resume_and_get is 0
[ 71.083578] galcore 38000000.gpu3d: PM: genpd_resume_noirq returned 0 after 6490 usecs
[ 71.091526] mxc_hantro 38300000.vpu: PM: calling genpd_resume_noirq @ 530, parent: soc@0
[ 71.099638] i2c_imx_xfer, pm_runtime_resume_and_get is 0
[ 71.106091] mxc_hantro 38300000.vpu: PM: genpd_resume_noirq returned 0 after 6458 usecs
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20241125142108.1613016-1-carlos.song@nxp.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Add "i2c_clk_rate / 2" check to avoid "divide by zero warning".
i2c_clk_rate may be zero if i2c clock is disabled.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
No need to check the argument of i2c_unregister_device() because the
function itself does it.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
When debugging issues that might be related to the DMC wakelock code, it
might be useful to compare runs with the lock acquired while DC states
are enabled vs the regular case. If issues disappear with the former, it
might be a symptom of something wrong in our code. Support having this
"always locked" behavior with enable_dmc_wl=3.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-5-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
When debugging issues that might be related to the DMC wakelock code, it
is sometimes useful to compare runs when we match any register offset vs
the regular case. If issues disappear when we take the wakelock for any
register, it might indicate that we are missing some offset to be
tracked. Support matching any register offset with enable_dmc_wl=2.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-4-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
We already provide the value resulting from sanitization of
enable_dmc_wl in dmesg, however the reader will need to either have the
meanings memorized or look them up in the parameter's documentation.
Let's make things easier by providing a short human-readable name for
the parameter in dmesg.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-3-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Currently, after sanitization, enable_dmc_wl will behave like a boolean
parameter (enabled vs disabled). However, in upcoming changes, we will
allow more values for debugging purposes. For that, let's make the
sanitized value an enumeration.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-2-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
In SNP guest environment with Secure TSC enabled, unlike other clock sources
(such as HPET, ACPI timer, APIC, etc), the RDTSC instruction is handled
without causing a VM exit, resulting in minimal overhead and jitters. Even
when the host CPU's TSC is tampered with, the Secure TSC enabled guest keeps
on ticking forward. Hence, mark Secure TSC as the only reliable clock source,
bypassing unstable calibration.
[ bp: Massage. ]
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Peter Gonda <pgonda@google.com>
Link: https://lore.kernel.org/r/20250106124633.1418972-10-nikunj@amd.com
The hypervisor should not be intercepting RDTSC/RDTSCP when Secure TSC is
enabled. A #VC exception will be generated if the RDTSC/RDTSCP instructions
are being intercepted. If this should occur and Secure TSC is enabled,
guest execution should be terminated as the guest cannot rely on the TSC
value provided by the hypervisor.
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Peter Gonda <pgonda@google.com>
Link: https://lore.kernel.org/r/20250106124633.1418972-9-nikunj@amd.com
The hypervisor should not be intercepting GUEST_TSC_FREQ MSR(0xcOO10134)
when Secure TSC is enabled. A #VC exception will be generated otherwise. If
this should occur and Secure TSC is enabled, terminate guest execution.
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20250106124633.1418972-8-nikunj@amd.com
Secure TSC enabled guests should not write to the MSR_IA32_TSC (0x10) register
as the subsequent TSC value reads are undefined. On AMD, MSR_IA32_TSC is
intercepted by the hypervisor by default. MSR_IA32_TSC read/write accesses
should not exit to the hypervisor for such guests.
Accesses to MSR_IA32_TSC need special handling in the #VC handler for the
guests with Secure TSC enabled. Writes to MSR_IA32_TSC should be ignored and
flagged once with a warning, and reads of MSR_IA32_TSC should return the
result of the RDTSC instruction.
[ bp: Massage commit message. ]
Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20250106124633.1418972-7-nikunj@amd.com
The interrupt handler for bandwidth notifications, pcie_bwnotif_irq(),
dereferences a "data" pointer.
On unbind, that pointer is set to NULL by pcie_bwnotif_remove(). However
the interrupt handler may still be invoked afterwards and will dereference
that NULL pointer.
That's because the interrupt is requested using a devm_*() helper and the
driver core releases devm_*() resources *after* calling ->remove().
pcie_bwnotif_remove() does clear the Link Bandwidth Management Interrupt
Enable and Link Autonomous Bandwidth Interrupt Enable bits in the Link
Control Register, but that won't prevent execution of pcie_bwnotif_irq():
The interrupt for bandwidth notifications may be shared with AER, DPC,
PME, and hotplug. So pcie_bwnotif_irq() may be executed as long as the
interrupt is requested.
There's a similar race on bind: pcie_bwnotif_probe() requests the
interrupt when the "data" pointer still points to NULL. A NULL pointer
deref may thus likewise occur if AER, DPC, PME or hotplug raise an
interrupt in-between the bandwidth controller's call to devm_request_irq()
and assignment of the "data" pointer.
Drop the devm_*() usage and reorder requesting of the interrupt to fix the
issue.
While at it, drop a stray but harmless no_free_ptr() invocation when
assigning the "data" pointer in pcie_bwnotif_probe().
Ilpo points out that the locking on unbind and bind needs to be symmetric,
so move the call to pcie_bwnotif_disable() inside the critical section
protected by pcie_bwctrl_setspeed_rwsem and pcie_bwctrl_lbms_rwsem.
Evert reports a hang on shutdown of an ASUS ROG Strix SCAR 17 G733PYV.
The issue is no longer reproducible with the present commit.
Evert found that attaching a USB-C monitor prevented the hang. The
machine contains an ASMedia USB 3.2 controller below a hotplug-capable
Root Port. So one possible explanation is that the controller gets
hot-removed on shutdown unless something is connected. And the ensuing
hotplug interrupt occurs exactly when the bandwidth controller is
unregistering. The precise cause could not be determined because the
screen had already turned black when the hang occurred.
Link: https://lore.kernel.org/r/ae2b02c9cfbefff475b6e132b0aa962aaccbd7b2.1736162539.git.lukas@wunner.de
Fixes: 665745f274 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller")
Reported-by: Evert Vorster <evorster@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219629
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Evert Vorster <evorster@gmail.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The SDCA specification allows for controls to be deferred. In the case
of a deferred control the device will return COMMAND_IGNORED to the
8-bit operation that would cause the value to commit. Which is the
final 8-bits on a write, or the first 8-bits on a read. In the case of
receiving a defer, the regmap will poll the SDCA function busy bit,
after which the transaction will be retried, returning an error if the
function busy does not clear within a chip specific timeout. Since
this is common SDCA functionality which is the 99% use-case for MBQs
it makes sense to incorporate this functionality into the register
map. If no MBQ configuration is specified, the behaviour will default
to the existing behaviour.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
SoundWire MBQ register maps typically contain a variety of register
sizes, which doesn't map ideally to the regmap abstraction which
expects register maps to have a consistent size. Currently the MBQ
register map only allows 16-bit registers to be defined, however
this leads to complex CODEC driver implementations with an 8-bit
register map and a 16-bit MBQ, every control will then have a custom
get and put handler that allows them to access different register
maps. Further more 32-bit MBQ quantities are not currently supported.
Add support for additional MBQ sizes and to avoid the complexity
of multiple register maps treat the val_size as a maximum size for
the register map. Within the regmap use an ancillary callback to
determine how many bytes to actually read/write to the hardware for
a specific register. In the case that no callback is defined the
behaviour defaults back to the existing behaviour of a fixed size
register map.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
Update the list of entity_0 controls to better match version v1.0 of the
SDCA specification. Remove both INTSTAT_CLEAR and INT_ENABLE as these are
no longer used, and add some missing controls and bits into the enum. Also
rename the SDCA_CONTROL prefix to SDCA_CTL because this better matches the
macros in the sdw_registers.h header, and the names can get quite long so
saving a few characters is definitely a plus.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Compliment the existing macro to construct an SDCA control address
with macros to extract the constituent parts, and validation of such
an address. Also update the masks for the original macro to use
GENMASK to make mental comparisons with the included comment on the
address format easier.
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250107154408.814455-2-ckeepax@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a garbage value problem in fbnic_mac_get_sensor_asic(). 'fw_cmpl'
is uninitialized which makes 'sensor' and '*val' to be stored garbage
value. Revert commit d85ebade02 ("eth: fbnic: Add hardware monitoring
support via HWMON interface") to avoid this problem.
Fixes: d85ebade02 ("eth: fbnic: Add hardware monitoring support via HWMON interface")
Signed-off-by: Su Hui <suhui@nfschina.com>
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Suggested-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Link: https://patch.msgid.link/20250106023647.47756-1-suhui@nfschina.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Calculate dividers fractional parts to optimally modulate output frequency.
Clocking wizard supports having multiplier m and divisors d and o.
Currently the fractional parts of m and o are not utilised.
For the pixel clock usecases a higher accuracy is needed..
Adding support for m and o to have fractional values.
Co-developed-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Tested-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
Link: https://lore.kernel.org/r/20250106082937.29555-1-shubhrajyoti.datta@amd.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
It is marked as optional as some of the ZynqMP designs are having vcu_reset
(reset pin of VCU IP) driven by proc_sys_reset, proc_sys_reset is another
PL IP driven by the PS pl_reset. So, here the VCU reset is not driven by
axi_gpio or PS GPIO so there will be no GPIO entry.
Signed-off-by: Rohit Visavalia <rohit.visavalia@amd.com>
Link: https://lore.kernel.org/r/20250107044038.100945-3-rohit.visavalia@amd.com
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The selftest runner currently allows selecting tests via the -t
option. This patch adds a new -l option that lists all available tests,
providing users with an overview of the tests they can choose from. This
enhancement is especially useful for scripting and automation purposes,
making it easier to discover and run tests.
Signed-off-by: Shizhao Chen <shichen@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
This update include:
- support for the SAMA7D65 SoC
- clock IDs for for the slow clock controller
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCZ3qS6QAKCRCejrg/N2X7
/TB9AP4sHkmqt/fSF37cfAfRB4KhaREp+F3QGRU0k4ZUbpTRmQEA1KRSntSbegk+
de49iMhGKabMKbhIDOGECt/kEngENQ0=
=XycM
-----END PGP SIGNATURE-----
Merge tag 'clk-microchip-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-microchip
Pull Microchip clk driver updates from Claudiu Beznea:
- Support for the SAMA7D65 SoC
- Clock IDs for for the slow clock controller
* tag 'clk-microchip-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
clk: at91: sama7d65: add sama7d65 pmc driver
dt-bindings: clock: Add SAMA7D65 PMC compatible string
dt-bindings: clocks: atmel,at91sam9x5-sckc: add sama7d65
clk: at91: sckc: Use SCKC_{TD, MD}_SLCK IDs for clk32k clocks
dt-bindings: clk: at91: Add clock IDs for the slow clock controller
Add support for Secure TSC in SNP-enabled guests. Secure TSC allows guests
to securely use RDTSC/RDTSCP instructions, ensuring that the parameters used
cannot be altered by the hypervisor once the guest is launched.
Secure TSC-enabled guests need to query TSC information from the AMD Security
Processor. This communication channel is encrypted between the AMD Security
Processor and the guest, with the hypervisor acting merely as a conduit to
deliver the guest messages to the AMD Security Processor. Each message is
protected with AEAD (AES-256 GCM).
[ bp: Zap a stray newline over amd_cc_platform_has() while at it,
simplify CC_ATTR_GUEST_SNP_SECURE_TSC check ]
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20250106124633.1418972-6-nikunj@amd.com
of_thermal_zone_find() calls of_parse_phandle_with_args(), but does not
release the OF node reference obtained by it.
Add a of_node_put() call when the call is successful.
Fixes: 3fd6d6e2b4 ("thermal/of: Rework the thermal device tree initialization")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Link: https://patch.msgid.link/20241224031809.950461-1-joe@pf.is.s.u-tokyo.ac.jp
[ rjw: Changelog edit ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Convert socfpga-system.txt to altr,socfpga-sys-mgr.yaml and move to
soc directory.
Add platform names in description for clarity. ARM(32-bit) platforms
Cyclone5, Arria5 and Arria10 is using "altr,sys-mgr" compatible,
while ARM64 is using "altr,sys-mgr-s10" compatible.
Removed "cpu1-start-addr" for ARM64 as it is not required.
Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
Link: https://lore.kernel.org/r/20250107105129.2784203-1-niravkumar.l.rabara@intel.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Merge series from wangweidong.a@awinic.com:
Add the awinic,aw88083 property to support the aw88083 chip.
The driver is for amplifiers aw88083 of Awinic Technology
Corporation. The AW88083 is an intelligent digital audio
amplifier with low noise.
acpi_dev_irq_override() gets called approx. 30 times during boot (15 legacy
IRQs * 2 override_table entries). Of these 30 calls at max 1 will match
the non DMI checks done by acpi_dev_irq_override(). The dmi_check_system()
check is by far the most expensive check done by acpi_dev_irq_override(),
make this call the last check done by acpi_dev_irq_override() so that it
will be called at max 1 time instead of 30 times.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20241228165253.42584-1-hdegoede@redhat.com
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
