On R-Car:
OF: /sound: Read of boolean property 'simple-audio-card,bitclock-master' with a value.
OF: /sound: Read of boolean property 'simple-audio-card,frame-master' with a value.
or:
OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'bitclock-master' with a value.
OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.
The use of of_property_read_bool() for non-boolean properties is
deprecated in favor of of_property_present() when testing for property
presence.
Replace testing for presence before calling of_property_read_u32() by
testing for an -EINVAL return value from the latter, to simplify the
code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/db10e96fbda121e7456d70e97a013cbfc9755f4d.1737533954.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
The functions:
mt6358_mtkaif_calibration_disable()
mt6358_mtkaif_calibration_enable()
mt6358_set_mtkaif_calibration_phase()
were added in the 2019
commit 6a8d4198ca ("ASoC: mediatek: mt6358: add codec driver")
but never used.
Remove them.
This leaves mt6358_set_dcxo(), mt6358_set_clksq(),
mt6358_set_aud_global_bias(), also unused.
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://patch.msgid.link/20250128005243.295977-1-linux@treblig.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use krealloc_array() to replace krealloc() with multiplication.
krealloc_array() has multiply overflow check, which will be safer.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20250117014343.451503-1-zhangheng@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Add interconnect framework support to set required audio bandwidth
based on PCM device usage. The maximum bandwidth is determined by
the number of APE PCM devices and maximum audio format supported.
If interconnect property is not defined or INTERCONNECT config
is not enabled then the audio usecase will still function.
Validate bandwidth updates by reading the interconnect summary sysfs
node during PCM device open and close operations.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20250203105304.4155542-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now the MBQ regmap implementation handles multiple sizes, this driver
can combine its two register maps into one. So remove mbq_regmap and
combine all the registers into regmap.
Also as rt722_sdca_adc_mux_get/put() only exist to access mbq_regmap,
rather than doing any processing, these can now be dropped and the
normal DAPM helpers used.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250107154408.814455-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a few missing registers from the readable register callback.
Suggested-by: Shuming Fan <shumingf@realtek.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250107154408.814455-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
mtk_memif_set_rate() has been unused since it was added in the 2019
commit 9cdf85a19b ("ASoC: mediatek: common: add some helpers to control
mtk_memif")
Remove it.
(The _substream version is used, and is left in)
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://patch.msgid.link/20250201005021.447726-1-linux@treblig.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There are two registers in the hardware, one, "Select PWM",
is per-port configuration enabling PWM function instead of GPIO.
The other one is "PWM Select" is per-PWM selector to configure
PWM itself. Original code uses abbreviation of the latter
to describe the former. Rename it to follow the datasheet.
Fixes: e6cbbe4294 ("pinctrl: Add Cypress cy8c95x0 support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/20250203131506.3318201-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When regmap locking is disabled, debugfs is also disabled.
Enable locking for debug when CONFIG_DEBUG_PINCTRL is set.
Fixes: f71aba339a ("pinctrl: cy8c95x0: Use single I2C lock")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/20250203131506.3318201-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The checks for vrtual registers in the cy8c95x0_readable_register()
and cy8c95x0_writeable_register() are not aligned and broken.
Fix that by explicitly avoiding reserved registers to be accessed.
Fixes: 71e4001a04 ("pinctrl: pinctrl-cy8c95x0: Fix regcache")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/20250203131506.3318201-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The range_max is inclusive, so we need to use the number of
the last accessible register address.
Fixes: 8670de9fae ("pinctrl: cy8c95x0: Use regmap ranges")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/20250203131506.3318201-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With DEBUG_MMU_EMU enabled:
arch/m68k/sun3/mmu_emu.c: In function ‘mmu_emu_handle_fault’:
arch/m68k/sun3/mmu_emu.c:420:38: error: implicit declaration of function ‘get_fs’; did you mean ‘sget_fc’? [-Werror=implicit-function-declaration]
420 | pr_info("seg:%ld crp:%p ->", get_fs().seg, crp);
| ^~~~~~
[...]
arch/m68k/sun3/mmu_emu.c:420:46: error: request for member ‘seg’ in something not a structure or union
420 | pr_info("seg:%ld crp:%p ->", get_fs().seg, crp);
| ^
Fix this by reintroducing and using a helper to retrieve the current
value of the DFC register.
While at it, replace "%p" by "%px", as there is no point in printing
obfuscated pointers during debugging.
Fixes: 9fde034864 ("m68k: Remove set_fs()")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/b1d12a1d24b4aea9f98d905383ba932b2dc382e6.1737387419.git.geert@linux-m68k.org
RISC-V APLIC specification defines "hart index" in:
https://github.com/riscv/riscv-aia
Within a given interrupt domain, each of the domain’s harts has a unique
index number in the range 0 to 2^14 − 1 (= 16,383). The index number a
domain associates with a hart may or may not have any relationship to the
unique hart identifier (“hart ID”) that the RISC-V Privileged Architecture
assigns to the hart. Two different interrupt domains may employ entirely
different index numbers for the same set of harts.
Further, this document says in "4.5 Memory-mapped control region for an
interrupt domain":
The array of IDC structures may include some for potential hart index
numbers that are not actual hart index numbers in the domain. For example,
the first IDC structure is always for hart index 0, but 0 is not
necessarily a valid index number for any hart in the domain.
Support arbitrary hart indices specified in an optional APLIC property
"riscv,hart-indexes" which is specified as an array of u32 elements, one
per interrupt target. If this property is not specified, fallback to use
logical hart indices within the domain.
Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/all/20250129091637.1667279-3-vladimir.kondratiev@mobileye.com
Document optional property "riscv,hart-indexes"
The RISC-V APLIC specification defines "hart index" in:
https://github.com/riscv/riscv-aia
Within a given interrupt domain, each of the domain’s harts has a unique
index number in the range 0 to 2^14 − 1 (= 16,383). The index number a
domain associates with a hart may or may not have any relationship to the
unique hart identifier (“hart ID”) that the RISC-V Privileged Architecture
assigns to the hart. Two different interrupt domains may employ entirely
different index numbers for the same set of harts.
Further, this document says in "4.5 Memory-mapped control region for an
interrupt domain":
The array of IDC structures may include some for potential hart index
numbers that are not actual hart index numbers in the domain. For example,
the first IDC structure is always for hart index 0, but 0 is not
necessarily a valid index number for any hart in the domain.
Support arbitrary hart indexes specified in a optional APLIC property
"riscv,hart-indexes" which is specificed as an array of u32 elements, one
per interrupt target. If this property is not specified, fallback to use
the logical hart indices within the domain.
Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/all/20250129091637.1667279-2-vladimir.kondratiev@mobileye.com
At startup, vdo loads all the reference count data before the device
reports that it is ready. Using a pool of large metadata vios can
improve the startup speed of vdo. The pool of large vios is released
after the device is ready.
During normal operation, reference counts are updated 4kB at a time,
as before.
Signed-off-by: Ken Raeburn <raeburn@redhat.com>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
With larger-sized metadata vio pools, vdo will sometimes need to
issue I/O with a smaller size than the allocated size. Since
vio_reset_bio is where the bvec array and I/O size are initialized,
this reset interface must now specify what I/O size to use.
Signed-off-by: Ken Raeburn <raeburn@redhat.com>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Support pools with multiple data blocks per vio
Signed-off-by: Ken Raeburn <raeburn@redhat.com>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
This allows us to simplify the return_vio_to_pool interface.
Also, we don't need to use vdo_forget on local variables or arguments
that are about to go out of scope anyway.
Signed-off-by: Ken Raeburn <raeburn@redhat.com>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fix array initialization that triggers a warning:
error: initializer-string for array of ‘unsigned char’ is too long
[-Werror=unterminated-string-initialization]
Signed-off-by: Chung Chung <cchung@redhat.com>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Also remove MODULE_NAME and a BUG_ON check, both unneeded.
This fixes a warning about string truncation in snprintf that
will never happen in practice:
drivers/md/dm-vdo/vdo.c: In function ‘vdo_make’:
drivers/md/dm-vdo/vdo.c:564:5: error: ‘%s’ directive output may be truncated writing up to 55 bytes into a region of size 16 [-Werror=format-truncation=]
"%s%u", MODULE_NAME, instance);
^~
drivers/md/dm-vdo/vdo.c:563:2: note: ‘snprintf’ output between 2 and 66 bytes into a destination of size 16
snprintf(vdo->thread_name_prefix, sizeof(vdo->thread_name_prefix),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s%u", MODULE_NAME, instance);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reported-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
This patch adds documentation for new option introduced in commit
4441686b24 ("dm-crypt: Allow to specify the integrity key size as option").
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
This patch adds documentation for new 'I' mode for dm-integrity
introduced in commit
fb0987682c ("dm-integrity: introduce the Inline mode").
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
This patch adds documentation for options introduced in commit
f811b83879 ("dm-verity: introduce the options restart_on_error and panic_on_error").
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Now that the crc32() library function takes advantage of
architecture-specific optimizations, it is unnecessary to go through the
crypto API. Just use crc32(). This is much simpler, and it improves
performance due to eliminating the crypto API overhead. (However, this
only affects the TCW IV mode of dm-crypt, which is a compatibility mode
that is rarely used compared to other dm-crypt modes.)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Only look up the VBIOS mode during atomic_check if the display mode
changes. For page flips, the previous settings still apply. Avoids the
runtime overhead of looking up the VBIOS mode on each page flip.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-17-tzimmermann@suse.de
The type struct ast_vbios_mode_info used to store information about
the color format and display mode. It has outlived its purpose. Inline
its fields into struct ast_crtc_state and replace all instances.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-16-tzimmermann@suse.de
Replace the large switch statement with a look-up table when selecting
the mode index. Makes the code easier to read. The table is sorted by
resolutions; if run-time overhead from traversal becomes significant,
binary search would be a possible optimization.
The mode index requires a refresh-rate index to be added or subtracted,
which still requires a minimal switch. In the original code, some of
the indices did not contain this computation. Those cases would have been
equivalent to adding 0, so they are now all subsumed in the switch's
default branch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
v3:
- explain the semantics of the new switch statement (Jocelyn)
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-15-tzimmermann@suse.de
ASTDP requires a mode index, depending on the resolution. Move the
look-up code from ast_dp_set_mode() into a separate helper. Inline
the rest of the function into its only caller. Rename the variable
names and register constants to match the programming manual.
As before, the mode-index lookup still happens during the update's
atomic commit. Right now, there's no way of doing it during the atomic
check. The lookup requires the VBIOS mode, which is not available at
the atomic check's invocation. At least warn now if the mode index
could not be found.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-14-tzimmermann@suse.de
The helper ast_get_vbios_mode_info() retrieves hardware-specific format
and display-mode information. Inline the function into its only caller.
While at it, also replace a use of struct drm_format_info.cpp with the
correct DRM 4CC codes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-13-tzimmermann@suse.de
Test DRM display modes against the list of modes supported by the
VBIOS. The helper will respect the supported-modes flags in struct
ast_device. Hence only DRM display modes supported by the VBIOS
will be reported; without the current duplication of this information.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-12-tzimmermann@suse.de
Mode lines are independent from hardware Gen or TX chip, so hide all
VBIOS mode tables in ast_vbios.c.
Move the look-up code for VBIOS modes from ast_vbios_get_mode_info()
to ast_vbios_find_mode(). The new look-up function respects the
supported-mode flags in struct ast_device. For example, if a device
does not have struct ast_device.support_fullhd set, the helper does
not return a valid mode for 1920x1080. Taking the supported-mode flags
into account allows for making the VBIOS tables the single reference
for validating and setting display modes against hardware capabilities.
v2:
- replace mode switch with look-up table (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-11-tzimmermann@suse.de
VBIOS mode tables are terminated by an entry with a refresh rate of
0xff. The code is hard to read and fragile to use. Therefore create
an empty entry with AST_VBIOS_MODE_INVALID to terminate each mode list.
Stop at the invalid entry when searching for modes in the tables.
Instead of testing for refresh == 0xff, test with a helper function if
the mode's size and refresh have meaningful values.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-10-tzimmermann@suse.de
The ast driver looks up supplied display modes from an internal list of
display modes supported by the VBIOS.
Do not use the crtc_-prefixed display values from struct drm_display_mode
for looking up the VBIOS mode. The fields contain raw values that the
driver programs to hardware. They are affected by display settings like
double-scan or interlace.
Instead use the regular vdisplay and hdisplay fields for lookup. As the
programmed values can now differ from the values used for lookup, set
struct drm_display_mode.crtc_vdisplay and .crtc_hdisplay from the VBIOS
mode.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-9-tzimmermann@suse.de
The ast driver matches DRM display modes against an internal list of
modes supported by the VBIOS. Matching H/V sync flags between modes is
preferred, but optional. If sync flags are not matching, the driver
would program the VBIOS settings to hardware and let the display handle
the difference.
DRM modes are generated from attached displays or standard mode lines.
Therefore differences to the VBIOS modes are not just cosmetical, but
signal possible incompatibility with the display hardware.
Hence make matching H/V sync flags mandatory. If the VBIOS does not
support a certain mode, we should report it as unsupported. Note that
the VBIOS mode tables all appear to refer to standard modes.
(If sync flags really make no difference to the VBIOS, the ast driver
shouldn't match them in the first place.)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-8-tzimmermann@suse.de
Detect support for 1920x1200 (WUXGA) in ast_detect_widescreen(). The
flag is cleared by default. The test logic has been taken from existing
code in ast_crtc_helper_mode_valid(). The code in that function is being
replaced by the new flag.
v2:
- move shared detection code into helper (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-7-tzimmermann@suse.de
Detect support for 1920x1080 (FullHD) in ast_detect_widescreen(). The
flag is cleared by default. The test logic has been taken from existing
code in ast_crtc_helper_mode_valid(). The code in that function is being
replaced by the new flag.
For Gen3, a new branch duplicates the Gen2 logic and adds a test for
AST2200. Gen2 adds a test for AST2100.
v2:
- use fullhd flag for setting max width/height
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-6-tzimmermann@suse.de
Testing for support of widescreen modes mixes up various hardware
Gens. First branch by hardware Gen, then do specific tests for each
Gen. By default, widesscreen support is disabled.
Later patches will add more specific tests for each Gen.
v2:
- move shared detection code into helper (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-5-tzimmermann@suse.de
Nothing in this source file requires <linux/fb.h>. Remove the include
statement.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20250131095235.125533-3-tzimmermann@suse.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Nothing in this source file requires <linux/fb.h>. Remove the include
statement.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20250131095235.125533-2-tzimmermann@suse.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
This patch extends the mlxbf-bootctl driver's sysfs entries
to support read access for the board's RTC battery status.
A successful read from this attribute returns the status of
the board's RTC battery. The RTC battery status register is
also cleared upon successful read operation.
Signed-off-by: Xiangrong Li <xiangrongl@nvidia.com>
Reviewed-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20250124144655.48564-1-xiangrongl@nvidia.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
commit 767d83361a ("Input: ads7846 - Convert to use software nodes")
has simplified the code but accidentially converted a devm_gpiod_get()
to gpiod_get(). This leaves the gpio reserved on module remove and the
driver can no longer be loaded again.
Fixes: 767d83361a ("Input: ads7846 - Convert to use software nodes")
Cc: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/6e9b143f19cdfda835711a8a7a3966e5a2494cff.1738410204.git.hns@goldelico.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
For hs400(es) mode, the 'hs400-ds-delay' is typically configured in the
dts. However, some projects may only define 'mediatek,hs400-ds-dly3',
which can lead to initialization failures in hs400es mode. CMD13 reported
response crc error in the mmc_switch_status() just after switching to
hs400es mode.
[ 1.914038][ T82] mmc0: mmc_select_hs400es failed, error -84
[ 1.914954][ T82] mmc0: error -84 whilst initialising MMC card
Currently, the hs400_ds_dly3 value is set within the tuning function. This
means that the PAD_DS_DLY3 field is not configured before tuning process,
which is the reason for the above-mentioned CMD13 response crc error.
Move the PAD_DS_DLY3 field configuration into msdc_prepare_hs400_tuning(),
and add a value check of hs400_ds_delay to prevent overwriting by zero when
the 'hs400-ds-delay' is not set in the dts. In addition, since hs400(es)
only tune the PAD_DS_DLY1, the PAD_DS_DLY2_SEL bit should be cleared to
bypass it.
Fixes: c4ac38c653 ("mmc: mtk-sd: Add HS400 online tuning support")
Signed-off-by: Andy-ld Lu <andy-ld.lu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250123092644.7359-1-andy-ld.lu@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit 941a7abd46.
This commit uses presence of device-tree properties vmmc-supply and
vqmmc-supply for deciding whether to enable a quirk affecting timing of
clock and data.
The intention was to address issues observed with eMMC and SD on AM62
platforms.
This new quirk is however also enabled for AM64 breaking microSD access
on the SolidRun HimmingBoard-T which is supported in-tree since v6.11,
causing a regression. During boot microSD initialization now fails with
the error below:
[ 2.008520] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
[ 2.115348] mmc1: error -110 whilst initialising SD card
The heuristics for enabling the quirk are clearly not correct as they
break at least one but potentially many existing boards.
Revert the change and restore original behaviour until a more
appropriate method of selecting the quirk is derived.
Fixes: 941a7abd46 ("mmc: sdhci_am654: Add sdhci_am654_start_signal_voltage_switch")
Closes: https://lore.kernel.org/linux-mmc/a70fc9fc-186f-4165-a652-3de50733763a@solid-run.com/
Cc: stable@vger.kernel.org
Signed-off-by: Josua Mayer <josua@solid-run.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20250127-am654-mmc-regression-v2-1-9bb39fb12810@solid-run.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
