Skip to content

L
linux
Switch branch/tag
  1. 11 Mar, 2024 9 commits
  3. 10 Mar, 2024 1 commit
  5. 08 Mar, 2024 7 commits
  7. 07 Mar, 2024 18 commits
  9. 05 Mar, 2024 5 commits
    • Jani Nikula's avatar
      drm: Add CONFIG_DRM_WERROR · f89632a9
      Jani Nikula authored 
      Add kconfig to enable -Werror subsystem wide. This is useful for
development and CI to keep the subsystem warning free, while avoiding
issues outside of the subsystem that kernel wide CONFIG_WERROR=y might
hit.

v2: Don't depend on COMPILE_TEST

Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> # v1
Reviewed-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
Acked-by: default avatarMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/afe5ed943414f7ec3044c1547503b9941686a867.1709629403.git.jani.nikula@intel.comSigned-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      f89632a9
    • Jani Nikula's avatar
      drm: enable (most) W=1 warnings by default across the subsystem · a61ddb43
      Jani Nikula authored 
      At least the i915 and amd drivers enable a bunch more compiler warnings
than the kernel defaults.

Extend most of the W=1 warnings to the entire drm subsystem by
default. Use the copy-pasted warnings from scripts/Makefile.extrawarn
with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare and
keep up with them in the future.

This is similar to the approach currently used in i915.

Some of the -Wextra warnings do need to be disabled, just like in
Makefile.extrawarn, but take care to not disable them for W=2 or W=3
builds, depending on the warning.

There are too many -Wformat-truncation warnings to cleanly fix up front;
leave that warning disabled for now.

v3:
- Drop -Wmissing-declarations (already enabled by default)
- Drop -Wmissing-prototypes (already enabled by default)

v2:
- Drop -Wformat-truncation (too many warnings)
- Drop -Wstringop-overflow (already enabled by default)

Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Pan
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Sean Paul <sean@poorly.run>
Cc: Marijn Suijten <marijn.suijten@somainline.org>
Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
Acked-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
Acked-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
Acked-by: default avatarSui Jingfeng <sui.jingfeng@linux.dev>
Acked-by: default avatarDanilo Krummrich <dakr@redhat.com>
Acked-by: default avatarMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/a50f1a69d5af72e913996179a75bc3a71d81ebea.1709629403.git.jani.nikula@intel.comSigned-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      a61ddb43
    • Karol Herbst's avatar
      drm/nouveau: move more missing UAPI bits · 460be1d5
      Karol Herbst authored 
      Those are already de-facto UAPI, so let's just move it into the uapi
header.
Signed-off-by: default avatarKarol Herbst <kherbst@redhat.com>
Reviewed-by: default avatarLyude Paul <lyude@redhat.com>
Reviewed-by: default avatarDanilo Krummrich <dakr@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240305133853.2214268-2-kherbst@redhat.com
      460be1d5
    • Jagan Teki's avatar
      drm/bridge: Document bridge init order with pre_enable_prev_first · 113cc3ad
      Jagan Teki authored 
      In order to satisfy the MIPI DSI initialization sequence the bridge
init order has been altered with the help of pre_enable_prev_first
in pre_enable and post_disable bridge operations.

Document the affected bridge init order with an example on the
bridge operations helpers.
Signed-off-by: default avatarJagan Teki <jagan@amarulasolutions.com>
Reviewed-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: default avatarRobert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-2-jagan@amarulasolutions.com
      113cc3ad
    • Jagan Teki's avatar
      drm/bridge: Fix improper bridge init order with pre_enable_prev_first · e18aeeda
      Jagan Teki authored 
      For a given bridge pipeline if any bridge sets pre_enable_prev_first
flag then the pre_enable for the previous bridge will be called before
pre_enable of this bridge and opposite is done for post_disable.

These are the potential bridge flags to alter bridge init order in order
to satisfy the MIPI DSI host and downstream panel or bridge to function.
However the existing pre_enable_prev_first logic with associated bridge
ordering has broken for both pre_enable and post_disable calls.

[pre_enable]

The altered bridge ordering has failed if two consecutive bridges on a
given pipeline enables the pre_enable_prev_first flag.

Example:
- 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

In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.

The logic looks for a bridge which enabled pre_enable_prev_first flag
on each iteration and assigned the previou bridge to limit pointer
if the bridge doesn't enable pre_enable_prev_first flags.

If control found Bridge 2 is pre_enable_prev_first then the iteration
looks for Bridge 3 and found it is not pre_enable_prev_first and assigns
it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3
and Bridge 2 and assign iter pointer with limit which is Bridge 4.

Here is the actual problem, for the next iteration control look for
Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
moved to Bridge 4 so this iteration skips the Bridge 4. The iteration
found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned
to Encoder. From next iteration Encoder skips as it is the last bridge
for reverse order pipeline.

So, the resulting pre_enable bridge order would be,
- Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.

This patch fixes this by assigning limit to next pointer instead of
previous bridge since the iteration always looks for bridge that does
NOT request prev so assigning next makes sure the last bridge on a
given iteration what exactly the limit bridge is.

So, the resulting pre_enable bridge order with fix would be,
- Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
  Encoder.

[post_disable]

The altered bridge ordering has failed if two consecutive bridges on a
given pipeline enables the pre_enable_prev_first flag.

Example:
- 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

In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.

The logic looks for a bridge which enabled pre_enable_prev_first flags
on each iteration and assigned the previou bridge to next and next to
limit pointer if the bridge does enable pre_enable_prev_first flag.

If control starts from Bridge 6 then it found next Bridge 5 is
pre_enable_prev_first and immediately the next assigned to previous
Bridge 6 and limit assignments to next Bridge 6 and call post_enable
of Bridge 6 even though the next consecutive Bridge 5 is enabled with
pre_enable_prev_first. This clearly misses the logic to find the state
of next conducive bridge as everytime the next and limit assigns
previous bridge if given bridge enabled pre_enable_prev_first.

So, the resulting post_disable bridge order would be,
- Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
  Panel.

This patch fixes this by assigning next with previou bridge only if the
bridge doesn't enable pre_enable_prev_first flag and the next further
assign it to limit. This way we can find the bridge that NOT requested
prev to disable last.

So, the resulting pre_enable bridge order with fix would be,
- Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1,
  Panel.

Validated the bridge init ordering by incorporating dummy bridges in
the sun6i-mipi-dsi pipeline

Fixes: 4fb912e5 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
Signed-off-by: default avatarJagan Teki <jagan@amarulasolutions.com>
Tested-by: default avatarMichael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: default avatarRobert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-1-jagan@amarulasolutions.com
      e18aeeda
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7