| Age | Commit message (Collapse) | Author |
|---|
|
Add SoC identification for the RZ/V2N SoC using the System Controller
(SYS) block.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250415085438.83856-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add pinctrl support for the Renesas RZ/V2N SoC by reusing the existing
RZ/V2H(P) pin configuration data. The PFC block is nearly identical, with
the only difference being the absence of `PCIE1_RSTOUTB` on RZ/V2N.
To handle this, the rzv2h_dedicated_pins array is refactored into a common
and pcie1 subset. This enables reuse of the common portion across both
SoCs, while excluding PCIE1_RSTOUTB for RZ/V2N.
This change allows the pinctrl-rzg2l driver to support RZ/V2N without
duplicating large parts of the RZ/V2H configuration.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250415130854.242227-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Use the str_on_off() helper instead of open-coding the same operation.
Note that this does change the case of the flags, which doesn't matter
much for debug messages.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/622f8554dcb815c8fc73511a1a118c1724570fa9.1745840497.git.geert+renesas@glider.be
|
|
Most structures in this driver are not modified.
Constifying these structures moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers. (This is the case for see meson_ee_pwrc_domain_desc)
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
8924 3832 0 12756 31d4 drivers/pmdomain/amlogic/meson-ee-pwrc.o
After:
=====
text data bss dec hex filename
12396 336 0 12732 31bc drivers/pmdomain/amlogic/meson-ee-pwrc.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/edc560afe2a8763c93341d161daeb8b33ba606c6.1746199917.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Add driver for BOE TD4320 DSI panel, used in Xiaomi Redmi Note 7
mobile phone.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250430-lavender-panel-v3-2-7625e62d62b2@mainlining.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250430-lavender-panel-v3-2-7625e62d62b2@mainlining.org
|
|
The "media: atomisp: Add support for sensors with a separate ISP
v4l2_subdev" combined with some pending drivers/media/i2c/mt9m114.c changes
makes the atomisp work nicely with the standard V4L2 mt9m114.c driver,
avoiding the need for the atomisp specific atomisp-mt9m114 driver.
The normal driver actually works better since the atomisp-mt9m114 driver
does not have working exposure control, leading to a much too dark image.
Remove the no longer necessary atomisp-mt9m114 driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Some sensors have an ISP inside the sensor which the sensor driver models
as a separate v4l2-subdev, like the mt9m114 sensor-driver does.
Since the atomisp driver emulates a standard /dev/video# v4l2-device
without requiring the application to be aware of media-controller centric
/dev/video# devices this requires some special handling in the driver.
Add support for this setup to the atomisp driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
When a (sensor) v4l2_subdev has its state_lock member set to non NULL,
then all v4l2_subdev_state-s for the sensor share the same lock.
atomisp_init_sensor() calls v4l2_subdev_lock_and_get_active_state() and
then later on also tries to lock a separate v4l2_subdev_state used for try
calls (rather then changing the active state), while still holding
the active state lock.
Since this try v4l2_subdev_state shares a lock with the active state this
results in a deadlock.
Skip locking try_sd_state when sensor->state_lock is set to avoid this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The camera v4l2_subdev pointer in struct atomisp_input_subdev points to
an image sensor, rename camera to sensor to make this more clear.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The atomisp_compat_ioctl32() function was deleted in commit b4c650f1af68
("media: atomisp: remove compat_ioctl32 code"), so this header file is no
longer needed.
Additionally, the definition of atomisp_compat_ioctl32() in atomisp_ioctl.h
is unused as well. Delete the declaration from the header.
Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250421052804.11721-1-hardevsinh.palaniya@siliconsignals.io
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Fix indentation to use TAB instead of spaces.
Signed-off-by: Thomas Andreatta <thomasandreatta2000@gmail.com>
Link: https://lore.kernel.org/r/20250426193033.483124-1-thomas.andreatta2000@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
When a value has been tested for NULL in an expression, a
second NULL test on the same value in another expression
is unnecessary when the value has not been assigned NULL.
Remove unnecessary duplicate NULL tests on the same value that
has previously been NULL tested.
Found by Coccinelle.
Signed-off-by: Abraham Samuel Adekunle <abrahamadekunle50@gmail.com>
Link: https://lore.kernel.org/r/26990d4a9d4419f9d4155a40595bc213acb671a0.1743685415.git.abrahamadekunle50@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Replace spaces with TAB to comply with kernel coding style.
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Link: https://lore.kernel.org/r/20250407123608.366190-1-gshahrouzi@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Fix the coefficients spelling error in ia_css_sdis2_types.h.
Signed-off-by: Liu Jing <liujing@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20241209064022.4342-1-liujing@cmss.chinamobile.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
hrt_isp_css_irq_sw_pin_0 has a different enum type than
irq_sw_channel_id_t.
Replace it with the actual value of hrt_isp_css_irq_sw_pin_0 to avoid
arithmetic operations between different enum types (and make the
compiler happy).
It is required to build with llvm 19 without these warnings:
.../sh_css_hrt.c:68:19: warning: arithmetic between different enumeration types ('irq_sw_channel_id_t' and 'enum hrt_isp_css_irq') [-Wenum-enum-conversion]
.../sh_css.c:1233:40: warning: arithmetic between different enumeration types ('irq_sw_channel_id_t' and 'enum hrt_isp_css_irq') [-Wenum-enum-conversion]
.../sh_css.c:1237:40: warning: arithmetic between different enumeration types ('irq_sw_channel_id_t' and 'enum hrt_isp_css_irq') [-Wenum-enum-conversion]
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://lore.kernel.org/r/20241202-fix-llvm9-v1-2-2a50f5acfd0b@chromium.org
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
atomisp_try_fmt() is limiting the width of the requested resolution to 1920
before calling the sensor's try_fmt() method. But it is not limiting
the height. In case of the old mode-list based t4ka3 driver which has
a mode list of:
736x496
896x736
1936x1096
3280x2464
This results in 3280x2464 being selected when try_fmt is called
with a requested resolution of 3280x2464, which is not supported because
its width > 1920 .
Fix this by also limiting the height when in preview mode.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241211173516.350779-1-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The GMIN code has support for sensors using external regulators enabled
by GPIOS, rather then using regulators build into the PMIC.
With the exception of the Trekstor ST70408-4 (1) tablet there are no known
devices which actually use external regulators for the sensors and the code
for this is using deprecated old style GPIO numbers support for which is
going away.
Remove the GPIO driven regulator support so that the gmin code no longer
depends on deprecated GPIO APIs.
1) The GMIN support itself is also deprecated and all sensor drivers still
using it are being moved over to use ACPI + runtime-pm and the ST70408-4
shipped with Android as factory OS and thus will have broken ACPI tables
for the sensors, so like other Android factory OS tablets it will need
a bespoke solution anyways.
Reported-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20241107221134.596149-1-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The Asus T100TA quirks set the same values as the defaults,
so they are not necessary. Remove them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20241104123832.5539-1-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Merge mainline to pick up bcachefs poly1305 patch 4bf4b5046de0
("bcachefs: use library APIs for ChaCha20 and Poly1305"). This
is a prerequisite for removing the poly1305 shash algorithm.
|
|
Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To
prevent signal distortion from excessive power increases, a dynamic
antenna power table limits the maximum adjustable TX power.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250430055157.13623-3-pkshih@realtek.com
|
|
Newer firmware will notify driver of the Packet Detection (PD)
value on the channel after switch channels during FW scan.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250430055157.13623-2-pkshih@realtek.com
|
|
Internally wiphy writes to individual channels in this structure,
so we must not share one static definition of channel list between
multiple device instances, because that causes hard to debug
breakage.
For example, with two rtw89 driven devices in the system, channel
information may get incoherent, preventing channel use.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250429122916.1734879-3-megi@xff.cz
|
|
The code can be simplified by using device managed memory
allocations. Simplify it.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250429122916.1734879-2-megi@xff.cz
|
|
A link bound to HW band 0 was previously always assumed to exist, because
it's true on non-MLD connection, and MLO connection is not supported yet.
Now, start to consider MLO cases and prepare to enable MLO support in the
following. Add skeleton of designated link. For single-link cases, helper
returns the one. For multi-link cases, priorities can be scheduled. Then,
drop assumption of link bound to HW band 0.
One exception is that MCC doesn't work with MLD yet, so it still expects
link on HW band 0 somewhere.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-11-pkshih@realtek.com
|
|
Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link
which deals with the ROC process. Before enabling MLO support, it's fine
to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on
HW-0) is always active. But, for the impending enablement of MLO support,
tweak the leaf functions to dynamically handle ROC link instance index.
Besides, in the follow-up, ROC caller will get a designated link and will
then drop RTW89_ROC_BY_LINK_INDEX.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-10-pkshih@realtek.com
|
|
For MLO connections, RX link ID is required to do address conversion.
Fill it in by the hardware info.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-9-pkshih@realtek.com
|
|
Add MLD capabilities so association requests can carry multi-link
element with correct content.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-8-pkshih@realtek.com
|
|
The join_info H2C command is used to indicate a station is connected and
tell FW to create/maintain an instance for it. Extend to fill MLO fields.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com
|
|
Previously only the first band is used for scanning. With MLO, update
scan parameters accordingly by so we can choose to scan from either band.
C2H event return value reflects current scanning band, mask it out so
we don't treat correct return value as fail.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-6-pkshih@realtek.com
|
|
After impending MLO support, TX Qsel would come from other HW band rather
than HW-0. For example, when working on HW-1, TX release report may fill
QSEL_XX_1 and cause warning "Cannot map qsel to dma: ...". So, extend the
mapping to recognize multiple HW bands.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-5-pkshih@realtek.com
|
|
Adjust mapping of management packets accordingly to send it on the
second hardware band. Previously only single band is used and we
plan to enable MLO, so the second band will be needed. Data packets
will be steered by hardware so no related changes are required.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-4-pkshih@realtek.com
|
|
8922A doesn't support broadcast/multicast traffic under MLO mode.
So let mac80211 do the encryption/decryption for us when the
connection is in MLO mode. Future BE ICs fixes this issue.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-3-pkshih@realtek.com
|
|
The RX DCK in firmware could retry 3 times if calibration value is not
stable. Roughly each calibration can be done within 16 ms, so expect
16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it
will do calibration on two path, so multiply 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-2-pkshih@realtek.com
|
|
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "struct rtw89_reg2_def *" but the returned type,
while technically matching, will be const qualified. As there isn't a
general way to discard "const" qualifiers, adjust the returned type to
match the assigned type. No change in allocation size results.
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org
|
|
The last use of rtl_bb_delay() was removed in 2014's
commit 5c99f04fec93 ("rtlwifi: rtl8723be: Update driver to match Realtek
release of 06/28/14")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-4-linux@treblig.org
|
|
rtl92d_phy_ap_calibrate(),
rtl92du_phy_ap_calibrate(),
rtl92ee_phy_ap_calibrate(), and
rtl8821ae_phy_ap_calibrate()
are all empty function stubs that are never called anywhere.
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-3-linux@treblig.org
|
|
rtl_usb_resume() and rtl_usb_suspend() are trivial stubs that were
added in 2011's
commit 2ca20f79e0d8 ("rtlwifi: Add usb driver")
but aren't wired up anywhere (though commit 442888c706e9 ("rtlwifi:
rtl8192cu: Add routines dm, fw, led and sw") added commented
out assignments).
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-2-linux@treblig.org
|
|
Add a small SOC bus driver to parse the chip ID and revision made
available on VIA/WonderMedia SoCs via their system configuration
controller's SCC_ID register.
This is intended to select appropriate sets of on-chip device quirks
at runtime, as it has been found that even within the same SoC
version there can be register-incompatible differences, such as
with the SDMMC controller on WM8505 rev. A0-A1 vs. rev. A2.
The list of SoC versions is compiled from various vendor source dumps
and not all of them have corresponding mainline driver support.
Some of them also have been seen with varying on-chip markings while
sharing the same hardware chip ID's (as is the case with e.g. WM8850
vs. WM8950). In such cases the selection of names to use here among
those seen in various source dumps and chip markings was arbitrary.
Suggested by Krzysztof at [1] - thanks a lot!
[1] https://lore.kernel.org/all/14de236b-e2a7-4bde-986d-1e5ffddd01b4@kernel.org/
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20250503-wmt-soc-driver-v3-2-2daa9056fa10@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
|
Fix incorrect value mask for register write. Register values are 8-bit,
not 9. If this function was called with a value > 0xFF and an even addr,
it would cause writing to the next register.
Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Angelo Dureghello <adureghello@baylibre.com>
Link: https://patch.msgid.link/20250428-iio-adc-ad7606_spi-fix-write-value-mask-v1-1-a2d5e85a809f@baylibre.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add a module param to disable ACD which will help to quickly rule it
out for any GPU issues.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649349/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Fix the following for qmp_get() errors:
1. Correctly handle probe defer for A6x GPUs
2. Ignore other errors because those are okay when GPU ACD is
not required. They are checked again during gpu acd probe.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Patchwork: https://patchwork.freedesktop.org/patch/649346/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
When ACD feature is enabled, it triggers some internal calibrations
which result in a pretty long delay during the first HFI perf vote.
So, increase the HFI response timeout to match the downstream driver.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Patchwork: https://patchwork.freedesktop.org/patch/649344/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
ACD a.k.a Adaptive Clock Distribution is a feature which helps to reduce
the power consumption. In some chipsets, it is also a requirement to
support higher GPU frequencies. This patch adds support for GPU ACD by
sending necessary data to GMU and AOSS. The feature support for the
chipset is detected based on devicetree data.
Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Tested-by: Maya Matuszczyk <maccraft123mc@gmail.com>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649342/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Really the only purpose of this was to limit the address space size to
4GB to avoid 32b rollover problems in 64b pointer math in older sqe fw.
So replace the address_space_size with a quirk limiting the address
space to 4GB. In all other cases, use the SMMU input address size (IAS)
to determine the address space size.
v2: Properly account for vm_start
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/649467/
|
|
If the GMU takes too long to respond to an HFI message, we may return
early. If the GMU does eventually respond, and then we send a second
message, we will see the response for the first, throw another error,
and keep going. But we don't currently wait for the interrupt from the
GMU again, so if the second response isn't there immediately we may
prematurely return. This can cause a continuous cycle of missed HFI
messages, and for reasons I don't quite understand the GMU does not shut
down properly when this happens.
Fix this by waiting for the GMU interrupt when we see an empty queue. If
the GMU never responds then the queue really is empty and we quit. We
can't wait for the interrupt when we see a wrong response seqnum because
the GMU might have already queued both responses by the time we clear
the interrupt the first time so we do need to check the queue before
waiting on the interrupt again.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/650013/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:
Unable to handle kernel paging request at virtual address 0000000000014110
pc : a6xx_gpu_busy+0x1c/0x58 [msm]
lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
Call trace:
a6xx_gpu_busy+0x1c/0x58 [msm] (P)
devfreq_simple_ondemand_func+0x3c/0x150
devfreq_update_target+0x44/0xd8
qos_max_notifier_call+0x30/0x84
blocking_notifier_call_chain+0x6c/0xa0
pm_qos_update_target+0xd0/0x110
freq_qos_apply+0x3c/0x74
apply_constraint+0x88/0x148
__dev_pm_qos_update_request+0x7c/0xcc
dev_pm_qos_update_request+0x38/0x5c
devfreq_cooling_set_cur_state+0x98/0xf0
__thermal_cdev_update+0x64/0xb4
thermal_cdev_update+0x4c/0x58
step_wise_manage+0x1f0/0x318
__thermal_zone_device_update+0x278/0x424
__thermal_cooling_device_register+0x2bc/0x308
thermal_of_cooling_device_register+0x10/0x1c
of_devfreq_cooling_register_power+0x240/0x2bc
of_devfreq_cooling_register+0x14/0x20
msm_devfreq_init+0xc4/0x1a0 [msm]
msm_gpu_init+0x304/0x574 [msm]
adreno_gpu_init+0x1c4/0x2e0 [msm]
a6xx_gpu_init+0x5c8/0x9c8 [msm]
adreno_bind+0x2a8/0x33c [msm]
...
At this point we haven't initialized the GMU at all yet, so we cannot read
the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag
accordingly. This means the df->suspended flag does not match the actual
devfreq state after initialization and msm_devfreq_get_dev_status() will
end up accessing GMU registers, causing the crash.
Fix this by setting df->suspended correctly during initialization.
Cc: stable@vger.kernel.org
Fixes: 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/650772/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
The current s3cp implementation does not work anymore after the
migration, and instead of fixing it and propagating the fix down to us,
it's simpler to directly use curl. Uprev mesa [1][2] to adapt these
changes. Also replace broken s3cp command with a curl wrapper call in
drm-ci.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Patchwork: https://patchwork.freedesktop.org/patch/645597/
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC fixes from Borislav Petkov:
- Test the correct structure member when handling correctable errors
and avoid spurious interrupts, in altera_edac
* tag 'edac_urgent_for_v6.15_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
EDAC/altera: Set DDR and SDMMC interrupt mask before registration
EDAC/altera: Test the correct error reg offset
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Ingo Molnar:
- Prevent NULL pointer dereference in msi_domain_debug_show()
- Fix crash in the qcom-mpm irqchip driver when configuring
interrupts for non-wake GPIOs
* tag 'irq-urgent-2025-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs
genirq/msi: Prevent NULL pointer dereference in msi_domain_debug_show()
|
|
Fix 18-bit raw read for 18-bit chips by applying a mask to the value
we receive from the SPI controller.
SPI controllers either return 1, 2 or 4 bytes per word depending on the
bits_per_word. For 16-bit chips, there was no problem since they raw
data fit exactly in the 2 bytes received from the SPI controller. But
now that we have 18-bit chips and we are using bits_per_word = 18, we
cannot assume that the extra bits in the 32-bit word are always zero.
In fact, with the AXI SPI Engine controller, these bits are not always
zero which caused the raw values to read 10s of 1000s of volts instead
of the correct value. Therefore, we need to mask the value we receive
from the SPI controller to ensure that only the 18 bits of real data
are used.
Fixes: f3838e934dff ("iio: adc: ad7606: add support for AD7606C-{16,18} parts")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250502-iio-adc-ad7606-fix-raw-read-for-18-bit-chips-v1-1-06caa92d8f11@baylibre.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
