- 30 May, 2022 5 commits
-
-
Christian König authored
dma_fence_chain containers cleanup signaled fences automatically, so filter those out from arrays as well. v2: fix missing walk over the array v3: massively simplify the patch and actually update the description. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-4-christian.koenig@amd.com
-
Christian König authored
Move the code from the inline functions into exported functions. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-3-christian.koenig@amd.com
-
Christian König authored
The selftests, fix the error handling, remove unused functions and stop leaking memory in failed tests. v2: fix the memory leak correctly. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-2-christian.koenig@amd.com
-
Yunhao Tian authored
In __spi_validate, there's a validation that no partial transfers are accepted (xfer->len % w_size must be zero). When max_chunk is not a multiple of bpw (e.g. max_chunk = 65535, bpw = 16), the transfer will be rejected. This patch aligns max_chunk to 2 bytes (the maximum value of bpw is 16), so that no partial transfer will occur. Fixes: d23d4d4d ("drm/tinydrm: Move tinydrm_spi_transfer()") Signed-off-by: Yunhao Tian <t123yh.xyz@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510030219.2486687-1-t123yh.xyz@gmail.com
-
Christian König authored
Use unrcu_pointer() instead of the manual cast. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518085446.31338-1-christian.koenig@amd.com
-
- 27 May, 2022 1 commit
-
-
Ville Syrjälä authored
Make the PNPID decoding available for other users. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-15-ville.syrjala@linux.intel.com
-
- 26 May, 2022 12 commits
-
-
Alyssa Rosenzweig authored
The most important Valhall-specific quirks have been handled, so add the Valhall compatible and probe. v2: Use arm,mali-valhall-jm compatible. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-10-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
Add the features, issues, and GPU ID for Mali-G57, a first-generation Valhall GPU. Other first- and second-generation Valhall GPUs should be similar. v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was fixed in r0p1. Unfortunately, MT8192 has a r0p0, so we do need to handle TTRX_3485. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-9-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs define slightly different MAX_READS and MAX_WRITES fields, which throttle outstanding reads and writes when set to non-zero values. When left as zero, reads and writes are not throttled. Both kbase and panfrost always zero these registers. Per discussion with Steven Price, there are two reasons these quirks may be used: 1. Simulating slower memory subsystems. This use case is only of interest to system-on-chip designers; it is not relevant to mainline. 2. Working around broken memory subsystems. Hopefully we never see this case in mainline. If we do, we'll need to set this register based on an SoC-compatible, rather than generally matching on the GPU model. To the best of our knowledge, these fields are zero at reset, so the write is not necessary. Let's remove the write to aid porting to new Mali GPUs, which have different layouts for the L2_MMU_CONFIG register. Suggested-by: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-8-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually tried to port the logic from kbase, trivial jobs raised Data Invalid Faults, so this may depend on other coherency details. It's still useful to have the bit to record the feature bit when adding new models. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-7-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
TTRX_3485 requires the infamous "dummy job" workaround. I have this workaround implemented in a local branch, but I have not yet hit a case that requires it so I cannot test whether the implementation is correct. In the mean time, add the quirk bit so we can document which platforms may need it in the future. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-6-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
Some Valhall GPUs require resets when encountering bus faults due to occlusion query writes. Add the issue bit for this and handle it. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-5-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
Logically, this function is free of side effects, so any pointers it takes should be const. Needed to avoid a warning in the next patch. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-4-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported from kbase. kbase lists this workaround as used on Mali-G57. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-3-alyssa.rosenzweig@collabora.com
-
Alyssa Rosenzweig authored
From the kernel's perspective, (pre-CSF, "Job Manager") Valhall is more or less compatible with Bifrost, although they differ to userspace. Add a compatible for Valhall to the existing Bifrost bindings documentation. As the first SoC with a Valhall GPU receiving mainline support, add a specific compatible for the MediaTek MT8192, which instantiates a Mali-G57. v2: Change compatible to arm,mali-valhall-jm (Daniel Stone). CC: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-2-alyssa.rosenzweig@collabora.com
-
Jonathan Liu authored
The code from [1] sets SYS_CTRL_1 to different values depending on the desired clock phase (0, 1/4, 1/2 or 3/4). A clock phase of 0 aligns the positive edge of the clock with the pixel data while other values delay the clock by a fraction of the clock period. A clock phase of 1/2 aligns the negative edge of the clock with the pixel data. The driver currently hard codes SYS_CTRL_1 to 0x88 which corresponds to aligning the positive edge of the clock with the pixel data. This won't work correctly for panels that require aligning the negative edge of the clock with the pixel data. Adjust the clock phase to 0 if DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE is present in bus_flags, otherwise adjust the clock phase to 1/2 as appropriate for DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE. [1] https://github.com/tdjastrzebski/ICN6211-ConfiguratorSigned-off-by: Jonathan Liu <net147@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220523130144.444225-1-net147@gmail.com
-
Rob Herring authored
While 'ddc-i2c-bus' is a common property, it should be in a connector node rather than the HDMI bridge node as the I2C bus goes to a connector and not the HDMI block. Drop it from the example. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220525205626.2482584-1-robh@kernel.org
-
Fabio Estevam authored
ADV7511_REG_CEC_RX_FRAME_HDR[] and ADV7511_REG_CEC_RX_FRAME_LEN[] are only used inside adv7511_cec.c. Move their definitions to this file to avoid the following build warnings when CONFIG_DRM_I2C_ADV7511_CEC is not selected: drivers/gpu/drm/bridge/adv7511/adv7511.h:229:17: warning: 'ADV7511_REG_CEC_RX_FRAME_HDR' defined but not used [-Wunused-const-variable=] drivers/gpu/drm/bridge/adv7511/adv7511.h:235:17: warning: 'ADV7511_REG_CEC_RX_FRAME_LEN' defined but not used [-Wunused-const-variable=] Reported-by: kernel test robot <lkp@intel.com> Fixes: ab0af093 ("drm: bridge: adv7511: use non-legacy mode for CEC RX") Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220525215316.1133057-1-festevam@gmail.com
-
- 25 May, 2022 2 commits
-
-
André Almeida authored
Since commit ba420afa ("drm/vkms: Bugfix racing hrtimer vblank handle") the work is scheduled at vkms_vblank_simulate() and since commit 5ef8100a ("drm/vkms: flush crc workers earlier in commit flow") the work is flushed at vkms_atomic_commit_tail(). Update function commment to reflect that. Signed-off-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220521191342.23520-1-andrealmeid@igalia.com
-
Niels Dossche authored
Other callers of drmm_kzalloc already return -ENOMEM on allocation failure. Change EINVAL to ENOMEM for consistency. Signed-off-by: Niels Dossche <dossche.niels@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220521234104.88410-1-dossche.niels@gmail.com
-
- 24 May, 2022 1 commit
-
-
Gao Chao authored
drm/panel: Fix build error when CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m If CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m, bulding fails: drivers/gpu/drm/panel/panel-samsung-atna33xc20.o: In function `atana33xc20_probe': panel-samsung-atna33xc20.c:(.text+0x744): undefined reference to `drm_panel_dp_aux_backlight' make: *** [vmlinux] Error 1 Let CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20 select DRM_DISPLAY_DP_HELPER and CONFIG_DRM_DISPLAY_HELPER to fix this error. Fixes: 32ce3b32 ("drm/panel: atna33xc20: Introduce the Samsung ATNA33XC20 panel") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Gao Chao <gaochao49@huawei.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220524024551.539-1-gaochao49@huawei.com
-
- 23 May, 2022 13 commits
-
-
Guo Zhengkui authored
There has already been NULL check in clk_prepare_enable() and clk_disable_unprepare(), so remove needless NULL check before calling them. Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519072950.128268-1-guozhengkui@vivo.com
-
Julia Lawall authored
Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Lyude Paul <lyude@redhat.com> [also fix double space] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220521111145.81697-57-Julia.Lawall@inria.fr
-
Mark Menzynski authored
Resources needed for output poll workers are destroyed in nouveau_fbcon_fini() before output poll workers are cleared in nouveau_display_fini(). This means there is a time between fbcon_fini() and display_fini(), where if output poll happens, it crashes. This patch introduces another output poll clearing before fbcon resources are destroyed. BUG: KASAN: use-after-free in __drm_fb_helper_initial_config_and_unlock.cold+0x1f3/0x291 [drm_kms_helper] Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Mark Menzynski <mmenzyns@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220523113541.10562-1-mmenzyns@redhat.com
-
Robert Foss authored
This reverts commit 7328736d. This patch depends on the patches just aplied to the media tree, and will not build without them, which leaves drm-misc-next in a broken state. Let's revert the two latter patches until rc1 has been branched, and rc1 has been backmerged into drm-misc-next. Signed-off-by: Robert Foss <robert.foss@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220523161520.354687-2-robert.foss@linaro.org
-
Robert Foss authored
This reverts commit a77c2af0. This patch depends on the patches just aplied to the media tree, and will not build without them, which leaves drm-misc-next in a broken state. Let's revert the two latter patches until rc1 has been branched, and rc1 has been backmerged into drm-misc-next. Signed-off-by: Robert Foss <robert.foss@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220523161520.354687-1-robert.foss@linaro.org
-
Javier Martinez Canillas authored
The SPI core always reports a "MODALIAS=spi:<foo>", even if the device was registered via OF. This means that the st7735r.ko module won't autoload if a DT has a node with a compatible "okaya,rh128128t" string. In that case, kmod expects a "MODALIAS=of:N*T*Cokaya,rh128128t" uevent but instead will get a "MODALIAS=spi:rh128128t", which is not present in the list of aliases: $ modinfo drivers/gpu/drm/tiny/st7735r.ko | grep alias alias: of:N*T*Cokaya,rh128128tC* alias: of:N*T*Cokaya,rh128128t alias: of:N*T*Cjianda,jd-t18003-t01C* alias: of:N*T*Cjianda,jd-t18003-t01 alias: spi:jd-t18003-t01 To workaround this issue, add in the SPI table an entry for that device. Fixes: d1d511d5 ("drm: tiny: st7735r: Add support for Okaya RH128128T") Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220520091602.179078-1-javierm@redhat.com
-
John Stultz authored
In commit 19cf41b6 ("lontium-lt9611: check a different register bit for HDMI sensing"), the bit flag used to detect HDMI cable connect was switched from BIT(2) to BIT(0) to improve compatibility with some monitors that didn't seem to set BIT(2). However, with that change, I've seen occasional issues where the detection failed, because BIT(2) was set, but not BIT(0). Unfortunately, as I understand it, the bits and their function was never clearly documented. So lets instead check both (BIT(2) | BIT(0)) when checking the register. Cc: Yongqin Liu <yongqin.liu@linaro.org> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Peter Collingbourne <pcc@google.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: kernel-team@android.com Fixes: 19cf41b6 ("lontium-lt9611: check a different register bit for HDMI sensing") Signed-off-by: John Stultz <jstultz@google.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220511012612.3297577-2-jstultz@google.com
-
John Stultz authored
This patch simply consolidates the duplicated detection functionality in the driver. Cc: Yongqin Liu <yongqin.liu@linaro.org> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Peter Collingbourne <pcc@google.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: kernel-team@android.com Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: John Stultz <jstultz@google.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220511012612.3297577-1-jstultz@google.com
-
Marek Vasut authored
Add of_node_put call on the endpoint node after it is not needed. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Xin Ji <xji@analogixsemi.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220519112337.62198-1-marex@denx.de
-
Marek Vasut authored
Handle empty data-lanes = < >; property, which translates to dsi_lanes = 0 as invalid. Fixes: ceb515ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220518233844.248504-1-marex@denx.de
-
Bhanuprakash Modem authored
As drm_connector already have the display_info, instead of creating "output_bpc" debugfs in vendor specific driver, move the logic to the drm layer. This patch will also move "Current" bpc to the crtc debugfs from connector debugfs, since we are getting this info from crtc_state. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519095149.3560034-4-bhanuprakash.modem@intel.com
-
Bhanuprakash Modem authored
This new debugfs will expose the currently using bpc by crtc. It is very useful for verifying whether we enter the correct output color depth from IGT. This patch will also add the connector's max supported bpc to "i915_display_info" debugfs. Example: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc Current: 8 Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519095149.3560034-3-bhanuprakash.modem@intel.com
-
Bhanuprakash Modem authored
It's useful to know the connector's max supported bpc for IGT testing. Expose it via a debugfs file on the connector "output_bpc". Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc V2: * Fix typo in comments (Harry) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519095149.3560034-2-bhanuprakash.modem@intel.com
-
- 21 May, 2022 4 commits
-
-
Borislav Petkov authored
Fix: drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’: drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce to an integer constant case R128_PM4_64BM_64VCBM_64INDBM: ^~~~ drivers/gpu/drm/r128/r128_cce.c:418:2: error: case label does not reduce to an integer constant case R128_PM4_64PIO_64VCPIO_64INDPIO: ^~~~ See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory details as to why it triggers with older gccs only. Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220405151517.29753-5-bp@alien8.de
-
Marek Vasut authored
The Refclk may be supplied by SoC clock output instead of crystal oscillator, make sure the clock are enabled before any other action is performed with the bridge chip, otherwise it may either fail to operate at all, or miss reset GPIO toggle. Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Fixes: 7caff0fc ("drm/bridge: tc358767: Add DPI to eDP bridge driver") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220520121543.11550-1-marex@denx.de
-
Marek Vasut authored
The DSI-to-e(DP) mode is now supported, update the driver comment to reflect this. No functional change. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Fixes: 3080c21a ("drm/bridge: tc358767: Add DSI-to-(e)DP mode support") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220519095137.11896-2-marex@denx.de
-
Marek Vasut authored
Handle empty data-lanes = < >; property, which translates to dsi_lanes = 0 as invalid. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Fixes: bbfd3190 ("drm/bridge: tc358767: Add DSI-to-DPI mode support") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220519095137.11896-1-marex@denx.de
-
- 20 May, 2022 2 commits
-
-
Douglas Anderson authored
While working on the DP AUX bus code I found a few small things that should be fixed. Namely the non-devm version of of_dp_aux_populate_ep_devices() was missing an export. There was also an extra blank line in a kerneldoc and a kerneldoc that incorrectly documented a return value. Fix these. Fixes: aeb33699 ("drm: Introduce the DP AUX bus") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.1.Ia91f4849adfc5eb9da1eb37ba79aa65fb3c95a0f@changeid
-
Douglas Anderson authored
When doing DP AUX transfers there are two actors that need to be powered in order for the DP AUX transfer to work: the DP source and the DP sink. Commit bacbab58 ("drm: Mention the power state requirement on side-channel operations") added some documentation saying that the DP source is required to power itself up (if needed) to do AUX transfers. However, that commit doesn't talk anything about the DP sink. For full fledged DP the sink isn't really a problem. It's expected that if an external DP monitor isn't plugged in that attempting to do AUX transfers won't work. It's also expected that if a DP monitor is plugged in (and thus asserting HPD) then AUX transfers will work. When we're looking at eDP, however, things are less obvious. Let's add some documentation about expectations. Here's what we'll say: 1. We don't expect the DP AUX transfer function to power on an eDP panel. If an eDP panel is physically connected but powered off then it makes sense for the transfer to fail. 2. We'll document that the official way to power on a panel is via the bridge chain, specifically by making sure that the panel's prepare function has been called (which is called by panel_bridge_pre_enable()). It's already specified in the kernel doc of drm_panel_prepare() that this is the way to power the panel on and also that after this call "it is possible to communicate with any integrated circuitry via a command bus." 3. We'll also document that for code running in the panel driver itself that it is legal for the panel driver to power itself up however it wants (it doesn't need to officially call drm_panel_pre_enable()) and then it can do AUX bus transfers. This is currently the way that edp-panel works when it's running atop the DP AUX bus. NOTE: there was much discussion of all of this in response to v1 [1] of this patch. A summary of that is: * With the Intel i195 driver, apparently eDP panels do get powered up. We won't forbid this but it is expected that code that wants to run on a variety of platforms should ensure that the drm_panel's prepare() function has been called. * There is at least a reasonable amount of agreement that the transfer() functions itself shouldn't be responsible for powering the panel. It's proposed that if we need the DP AUX dev nodes to be robust for eDP that the code handling the DP AUX dev nodes could handle powering the panel by ensuring that the panel's prepare() call was made. Potentially drm_dp_aux_dev_get_by_minor() could be a good place to do this. This is left as a future exercise. Until that's fixed the DP AUX dev nodes for eDP are probably best just used for debugging. * If a panel could be in PSR and DP AUX via the dev node needs to be reliable then we need to be able to pull the panel out of PSR. On i915 this is also apparently handled as part of the transfer() function. [1] https://lore.kernel.org/r/20220503162033.1.Ia8651894026707e4fa61267da944ff739610d180@changeidSigned-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220509161733.v2.1.Ia8651894026707e4fa61267da944ff739610d180@changeid
-