The drm_bridge structure contains an encoder pointer that is widely used
by bridge drivers. This pattern is largely documented as deprecated in
other KMS entities for atomic drivers.
However, one of the main use of that pointer is done in attach to just
call drm_bridge_attach on the next bridge to add it to the bridge list.
While this dereferences the bridge->encoder pointer, it's effectively
the same encoder the bridge was being attached to.
We can make it more explicit by adding the encoder the bridge is
attached to to the list of attach parameters. This also removes the need
to dereference bridge->encoder in most drivers.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-1-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Currently, mode_valid is defined only in drm_connector_helper_funcs.
When the bridge is attached with the 'DRM_BRIDGE_ATTACH_NO_CONNECTOR'
flag, the connector is not initialized, and so is the mode_valid
hook under connector helper funcs.
It also returns MODE_OK for all modes without actually checking the
modes.
So move the mode_valid hook to drm_bridge_funcs with proper clock
checks for maximum and minimum pixel clock supported by the bridge.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240613083805.439337-2-j-choudhary@ti.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
instantiation") removed the last call to i2c_mux_add_adapter() with a
non-null class argument. Therefore the class argument can be removed.
Note: Class-based device instantiation is a legacy mechanism which
shouldn't be used in new code, so we can rule out that this argument
may be needed again in the future.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
A null pointer dereference crash has been observed rarely on TI
platforms using sii9022 bridge:
[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x]
[ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x]
[ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm]
[ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
[ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
[ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm]
[ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
[ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
[ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
[ 53.326401] drm_client_register+0x5c/0xa0 [drm]
[ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
[ 53.336881] tidss_probe+0x128/0x264 [tidss]
[ 53.341174] platform_probe+0x68/0xc4
[ 53.344841] really_probe+0x188/0x3c4
[ 53.348501] __driver_probe_device+0x7c/0x16c
[ 53.352854] driver_probe_device+0x3c/0x10c
[ 53.357033] __device_attach_driver+0xbc/0x158
[ 53.361472] bus_for_each_drv+0x88/0xe8
[ 53.365303] __device_attach+0xa0/0x1b4
[ 53.369135] device_initial_probe+0x14/0x20
[ 53.373314] bus_probe_device+0xb0/0xb4
[ 53.377145] deferred_probe_work_func+0xcc/0x124
[ 53.381757] process_one_work+0x1f0/0x518
[ 53.385770] worker_thread+0x1e8/0x3dc
[ 53.389519] kthread+0x11c/0x120
[ 53.392750] ret_from_fork+0x10/0x20
The issue here is as follows:
- tidss probes, but is deferred as sii902x is still missing.
- sii902x starts probing and enters sii902x_init().
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
DRM's perspective.
- sii902x calls sii902x_audio_codec_init() and
platform_device_register_data()
- The registration of the audio platform device causes probing of the
deferred devices.
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
called.
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
However, the sii902x driver has not set up the i2c part yet, leading
to the crash.
Fix this by moving the drm_bridge_add() to the end of the
sii902x_init(), which is also at the very end of sii902x_probe().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Fixes: 21d808405f ("drm/bridge/sii902x: Fix EDID readback")
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240103-si902x-fixes-v1-1-b9fd3e448411@ideasonboard.com
With new connector model, sii902x will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and SoC driver will rely on format
negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
the case with older model.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-6-a-bhatia1@ti.com
Pull sound updates from Takashi Iwai:
"As the diffstat shows, we've had lots of developments in a wide range
at this time; the majority of changes are about ASoC, including
subsystem-wide cleanups, continued SOF / Intel updates and a bunch of
new drivers (as usual), while there have been some significant (but
almost invisible) improvements in ALSA core side, too.
Below are some highlights:
Core:
- Faster lookups of control elements with Xarray; normal user won't
notice, but on the devices with tons of control elements, it can be
visibly faster
- Support for input validation for controls; this will harden for
badly written drivers in general with a slight overhead
- Deferred async signal handling for working around the potential
deadlocks
- Cleanup / refactoring raw MIDI locking code
ASoC:
- Restructing of the set_fmt() callbacks for making things clearer in
situations like CODEC to CODEC links
- Clean up and modernizing the DAI naming scheme setups
- Merge of more of the Intel AVS driver stack, including some board
integrations
- New version 4 mechanism for communication with SOF DSPs
- Suppoort for dynamically selecting the PLL to use at runtime on
i.MX platforms
- Improvements for CODEC to CODEC support in the generic cards
- Support for AMD Jadeite and various machines, AMD RPL, Intel
MetorLake DSPs, Mediatek MT8186 DSPs and MT6366, nVidia Tegra
MDDRC, OPE and PEQ, NXP TFA9890, Qualcomm SDM845, WCD9335 and
WAS883x, and Texas Instruments TAS2780
HD- and USB-audio:
- Continued improvement for CS35L41 (sub)codec support
- More quirks for various devices (HP, Lenovo, Dell, Clevo)"
* tag 'sound-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (778 commits)
ALSA: hda/realtek: Add quirk for HP Spectre x360 15-eb0xxx
ALSA: line6: Replace sprintf() with sysfs_emit()
ALSA: hda: Replace sprintf() with sysfs_emit()
ALSA: pcm: Replace sprintf() with sysfs_emit()
ALSA: core: Replace scnprintf() with sysfs_emit()
ALSA: control-led: Replace sprintf() with sysfs_emit()
ALSA: aoa: Replace sprintf() with sysfs_emit()
ALSA: ac97: Replace sprintf() with sysfs_emit()
ALSA: hda/realtek: Add quirk for Clevo NV45PZ
ALSA: hda/realtek: Add quirk for Lenovo Yoga9 14IAP7
ALSA: control: Use deferred fasync helper
ALSA: pcm: Use deferred fasync helper
ALSA: timer: Use deferred fasync helper
ALSA: core: Add async signal helpers
ASoC: q6asm: use kcalloc() instead of kzalloc()
ACPI: scan: Add CLSA0101 Laptop Support
ALSA: hda: cs35l41: Support CLSA0101
ALSA: hda: cs35l41: Use the CS35L41 HDA internal define
ASoC: dt-bindings: use spi-peripheral-props.yaml
ASoC: codecs: va-macro: use fsgen as clock
...
As part of retiring the old defines used to specify DAI formats update the
hdmi_codec driver to use the modern names, including the variables in the
struct hdmi_codec_daifmt exported to the DRM drivers.
In updating this I did note that the only use of this information in DRM
drivers is to reject clock provider settings, thinking about what this
hardware is doing I rather suspect that there might not be any hardware
out there which needs the configuration so it may be worth considering
just having hdmi-codec support only clock consumer.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220602103029.3498791-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
voltage before the reset sequence is initiated. On most boards, this
assumption is true at boot-up, so initialization succeeds.
However, when we try to initialize the chip with incorrect supply
voltages, it will not respond to I2C requests. sii902x_probe() fails
with -ENXIO.
To resolve this, look for the "iovcc" and "cvcc12" regulators, and
make sure they are enabled before starting the reset sequence. If
these supplies are not available in devicetree, then they will default
to dummy-regulator. In that case everything will work like before.
This was observed on a STM32MP157C-DK2 booting in u-boot falcon mode.
On this board, the supplies would be set by the second stage
bootloader, which does not run in falcon mode.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[Fix checkpatch warnings]
Link: https://patchwork.freedesktop.org/patch/msgid/20201020221501.260025-2-mr.nuke.me@gmail.com
Pull sound updates from Takashi Iwai:
"This became wide and scattered updates all over the sound tree as
diffstat shows: lots of (still ongoing) refactoring works in ASoC,
fixes and cleanups caught by static analysis, inclusive term
conversions as well as lots of new drivers. Below are highlights:
ASoC core:
- API cleanups and conversions to the unified mute_stream() call
- Simplify I/O helper functions
- Use helper macros to retrieve RTD from substreams
ASoC drivers:
- Lots of fixes and cleanups in Intel ASoC drivers
- Lots of new stuff: Freescale MQS and i.MX6sx, Intel KeemBay I2S,
Maxim MAX98360A and MAX98373 SoundWire, various Mediatek boards,
nVidia Tegra 186 and 210, RealTek RL6231, Samsung Midas and Aries
boards, TI J721e EVM
ALSA core:
- Minor code refacotring for SG-buffer handling
HD-audio:
- Generalization of mute-LED handling with LED classdev
- Intel silent stream support for HDMI
- Device-specific fixes: CA0132, Loongson-3
Others:
- Usual USB- and HD-audio quirks for various devices
- Fixes for echoaudio DMA position handling
- Various documents and trivial fixes for sparse warnings
- Conversion to adopt inclusive terms"
* tag 'sound-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (479 commits)
ALSA: pci: delete repeated words in comments
ALSA: isa: delete repeated words in comments
ALSA: hda/tegra: Add 100us dma stop delay
ALSA: hda: Add dma stop delay variable
ASoC: hda/tegra: Set buffer alignment to 128 bytes
ALSA: seq: oss: Serialize ioctls
ALSA: hda/hdmi: Add quirk to force connectivity
ALSA: usb-audio: add startech usb audio dock name
ALSA: usb-audio: Add support for Lenovo ThinkStation P620
Revert "ALSA: hda: call runtime_allow() for all hda controllers"
ALSA: hda/ca0132 - Fix AE-5 microphone selection commands.
ALSA: hda/ca0132 - Add new quirk ID for Recon3D.
ALSA: hda/ca0132 - Fix ZxR Headphone gain control get value.
ALSA: hda/realtek: Add alc269/alc662 pin-tables for Loongson-3 laptops
ALSA: docs: fix typo
ALSA: doc: use correct config variable name
ASoC: core: Two step component registration
ASoC: core: Simplify snd_soc_component_initialize declaration
ASoC: core: Relocate and expose snd_soc_component_initialize
ASoC: sh: Replace 'select' DMADEVICES 'with depends on'
...
snd_soc_dai_digital_mute() is internally using both
mute_stream() (1) or digital_mute() (2), but the difference between
these 2 are only handling direction.
We can merge digital_mute() into mute_stream
int snd_soc_dai_digital_mute(xxx, int direction)
{
...
else if (dai->driver->ops->mute_stream)
(1) return dai->driver->ops->mute_stream(xxx, direction);
else if (direction == SNDRV_PCM_STREAM_PLAYBACK &&
dai->driver->ops->digital_mute)
(2) return dai->driver->ops->digital_mute(xxx);
...
}
For hdmi-codec, we need to update struct hdmi_codec_ops,
and all its users in the same time.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/87d055xxj2.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.
- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.
- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).
In order to solve these issues, ownership of the connector should be
moved to the display controller driver (where it can be implemented
using helpers provided by the core).
Extend the bridge API to allow disabling connector creation in bridge
drivers as a first step towards the new model. The new flags argument to
the bridge .attach() operation allows instructing the bridge driver to
skip creating a connector. Unconditionally set the new flags argument to
0 for now to keep the existing behaviour, and modify all existing bridge
drivers to return an error when connector creation is not requested as
they don't support this feature yet.
The change is based on the following semantic patch, with manual review
and edits.
@ rule1 @
identifier funcs;
identifier fn;
@@
struct drm_bridge_funcs funcs = {
...,
.attach = fn
};
@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
statement S, S1;
@@
int fn(
struct drm_bridge *bridge
+ , enum drm_bridge_attach_flags flags
)
{
... when != S
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ DRM_ERROR("Fix bridge driver to make connector optional!");
+ return -EINVAL;
+ }
+
S1
...
}
@ depends on rule1 @
identifier rule1.fn;
identifier bridge, flags;
expression E1, E2, E3;
@@
int fn(
struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags
) {
<...
drm_bridge_attach(E1, E2, E3
+ , flags
)
...>
}
@@
expression E1, E2, E3;
@@
drm_bridge_attach(E1, E2, E3
+ , 0
)
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
Maarten needs -rc4 backmerged so he can pull in the fbcon notifier
removal topic branch into drm-misc-next.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on 3 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [kishon] [vijay] [abraham]
[i] [kishon]@[ti] [com] this program is distributed in the hope that
it will be useful but without any warranty without even the implied
warranty of merchantability or fitness for a particular purpose see
the gnu general public license for more details
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [graeme] [gregory]
[gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
[kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
[hk] [hemahk]@[ti] [com] this program is distributed in the hope
that it will be useful but without any warranty without even the
implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1105 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
