- 09 Dec, 2022 15 commits
-
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20221118224540.619276-32-uwe@kleine-koenig.orgSigned-off-by:
Robert Foss <robert.foss@linaro.org>
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
- 08 Dec, 2022 25 commits
-
-
Stefan Eichenberger authored
Enable hot plug detection when it is available on the HDMI port. Without this connecting to a different monitor with incompatible timing before the 10 seconds poll period will lead to a broken display output. Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by:
Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by:
Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Noralf Trønnes authored
Add missing vmalloc.h include. Fixes: c17d0486 ("drm/gud: Use the shadow plane helper") Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221207-gud-missing-include-v1-0-c5b32c9c59da@tronnes.org
-
Dave Stevenson authored
The exact behaviour of DSI host controllers is not specified, therefore define it. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by:
Maxime Ripard <maxime@cerno.tech>
-
Dave Stevenson authored
Mapping to the drm_bridge flag pre_enable_prev_first, add a new flag prepare_prev_first to drm_panel to allow the panel driver to request that the upstream bridge should be pre_enabled before the panel prepare. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20221205173328.1395350-6-dave.stevenson@raspberrypi.comSigned-off-by:
-
Dave Stevenson authored
DSI sink devices typically want the DSI host powered up and configured before they are powered up. pre_enable is the place this would normally happen, but they are called in reverse order from panel/connector towards the encoder, which is the "wrong" order. Add a new flag pre_enable_prev_first that any bridge can set to swap the order of pre_enable (and post_disable) for that and the immediately previous bridge. Should the immediately previous bridge also set the pre_enable_prev_first flag, the previous bridge to that will be called before either of those which requested pre_enable_prev_first. eg: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. Signed-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
-
Sam Ravnborg authored
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no users left and we have atomic variants that should be used. Drop them so they do not gain new users. Adjust a few comments to avoid references to the dropped functions. Signed-off-by:Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
-
Dave Stevenson authored
Commit f70ac097 ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") added usage of the drm_bridge_chain_ functions which are to be deprecated. Replace with the drm_atomic_bridge_chain_ variants using the current state. Signed-off-by:
-
Sam Ravnborg authored
The atomic variants of enable/disable in drm_bridge_funcs are the preferred operations - introduce these. The ps8640 driver used the non-atomic variants of the drm_bridge_chain_pre_enable/ drm_bridge_chain_post_disable - convert these to the atomic variants. v2: - Init state operations in drm_bridge_funcs (Laurent) Signed-off-by:
-
Maxime Ripard authored
Now that we have VC4-specific tests in place, let's document them properly. Reviewed-by:
Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-20-4615a663a84a@cerno.techSigned-off-by:
-
Maxime Ripard authored
The HVS to PixelValve muxing code is fairly error prone and has a bunch of arbitrary constraints due to the hardware setup. Let's create a test suite that makes sure that the possible combinations work and the invalid ones don't. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Maxime Ripard authored
Accessing a register when running under kunit is a bad idea since our device is completely mocked. Fail the current test if we ever access any of our hardware registers. Reviewed-by:
-
Maxime Ripard authored
In order to test the current atomic_check hooks we need to have a DRM device that has roughly the same capabilities and layout that the actual hardware. We'll also need a bunch of functions to create arbitrary atomic states. Let's create some helpers to create a device that behaves like the real one, and some helpers to maintain the atomic state we want to check. Reviewed-by:
-
Maxime Ripard authored
We'll need to initialize the HVS structure without a backing device to create a mock we'll use for testing. Split the structure initialization part into a separate function. Reviewed-by:
-
Maxime Ripard authored
We'll need a function that looks up an encoder by its vc4_encoder_type. Such a function is already present in the CRTC code, so let's make it public so that we can reuse it in the unit tests. Reviewed-by:
-
Maxime Ripard authored
The current vc4_crtc_init() helper assumes that we will be using hardware planes and calls vc4_plane_init(). While it's a reasonable assumption, we'll want to mock the plane and thus provide our own. Let's create a helper that will take the plane as an argument. Reviewed-by:
-
Maxime Ripard authored
In order to introduce unit tests for the HVS state computation, we'll need access to the vc4_hvs_state struct definition and its associated helpers. Let's move them in our driver header. Reviewed-by:
-
Maxime Ripard authored
DRM-managed actions are supposed to be ran whenever the device is released. Let's introduce a basic unit test to make sure it happens. Reviewed-by:
-
Maxime Ripard authored
Some tests will need to provide their own drm_driver instead of relying on the dumb one in the helpers, so let's create a helper that allows to do so. Reviewed-by:
-
Maxime Ripard authored
The current helper to allocate a DRM device doesn't allow for any subclassing by drivers, which is going to be troublesome as we work on getting some kunit testing on atomic modesetting code. Let's use a similar pattern to the other allocation helpers by providing the structure size and offset as arguments. Reviewed-by:
-
Maxime Ripard authored
The device managed resources are freed when the device is detached, so it has to be bound in the first place. Let's create a fake driver that we will bind to our fake device to benefit from the device managed cleanups in our tests. Reviewed-by:
-
Maxime Ripard authored
The device managed resources are ran if the device has bus, which is not the case of a root_device. Let's use a platform_device instead. Reviewed-by:
-
Maxime Ripard authored
We'll need in some tests to control when the device needs to be added and removed, so let's split the device creation from the DRM device creation function. Reviewed-by:
-
Maxime Ripard authored
The device name isn't really useful, we can just define it instead of exposing it in the API. Reviewed-by:
-
Maxime Ripard authored
The name doesn't really fit the conventions for the other helpers in DRM/KMS, so let's rename it to make it obvious that we allocate a new DRM device. Reviewed-by:
-
