- Jun 02, 2022
-
-
Patrik Jakobsson authored
We're moving all uses of ddc_bus to drm_connector where they belong. The initialization of the gma_i2c_chan for Oaktrail is a bit backwards so it required improvements. Also cleanup the error handling in oaktrail_lvds_init(). Since this is the last user of gma_encoder->ddc_bus we can remove it. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-8-patrik.r.jakobsson@gmail.com
-
Patrik Jakobsson authored
We're moving all uses of ddc_bus to drm_connector where they belong. Also cleanup the error handling in cdv_intel_crt_init(). Signed-off-by:
-
Patrik Jakobsson authored
We're moving all uses of ddc_bus to drm_connector where they belong. Also cleanup the error handling in psb_intel_lvds_init() and remove unused ddc_bus in psb_intel_lvds_priv. Signed-off-by:
-
Patrik Jakobsson authored
We're moving all uses of ddc_bus from gma_encoder to drm_connector where they belong. Also, cleanup the error handling in cdv_hdmi_init() and remove unused i2c pointer in mid_intel_hdmi_priv. Signed-off-by:
-
Patrik Jakobsson authored
We're moving all uses of ddc_bus to drm_connector where they belong. Also, add missing call to destroy ddc bus when destroying the connector and cleanup the error handling in cdv_intel_lvds_init(). Signed-off-by:
-
Patrik Jakobsson authored
This makes it easier to get at the full gma_i2c_chan when having an i2c_adapter from eg. drm_connector->ddc. Signed-off-by:
-
Patrik Jakobsson authored
psb_intel_i2c_chan is used by all chips so use the correct prefix. Signed-off-by:
-
Javier Martinez Canillas authored
The kernel test robot reports a compile warning due the ssd130x_spi_table variable being defined but not used. This happen when ssd130x-spi driver is built-in instead of being built as a module, i.e: CC drivers/gpu/drm/solomon/ssd130x-spi.o AR drivers/base/firmware_loader/built-in.a AR drivers/base/built-in.a CC kernel/trace/trace.o drivers/gpu/drm/solomon/ssd130x-spi.c:155:35: warning: ‘ssd130x_spi_table’ defined but not used [-Wunused-const-variable=] 155 | static const struct spi_device_id ssd130x_spi_table[] = { | ^~~~~~~~~~~~~~~~~ The driver shouldn't need a SPI device ID table and only have an OF device ID table, but the former is needed to workaround an issue in the SPI core. This always reports a MODALIAS of the form "spi:<device>" even for devices registered through Device Trees. But the table is only needed when the driver built as a module to populate the .ko alias info. It's not needed when the driver is built-in the kernel. Fixes: 74373977 ("drm/solomon: Add SSD130x OLED displays SPI support") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220530140246.742469-1-javierm@redhat.com
-
- Jun 01, 2022
-
-
Tom Rix authored
sparse reports drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol 'gv100_fifo_runlist' was not declared. Should it be static? gv100_fifo_runlist is only used in gv100.c, so change it to static. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
- May 31, 2022
-
-
Saurabh Sengar authored
There were two different approaches getting used in this driver to allocate vram: 1. VRAM allocation from PCI region for Gen1 2. VRAM alloaction from MMIO region for Gen2 First approach limilts the vram to PCI BAR size, which is 64 MB in most legacy systems. This limits the maximum resolution to be restricted to 64 MB size, and with recent conclusion on fbdev issue its concluded to have similar allocation strategy for both Gen1 and Gen2. This patch unifies the Gen1 and Gen2 vram allocation strategy. Signed-off-by:
Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by:
Deepak Rawat <drawat.floss@gmail.com> Signed-off-by:
-
- May 30, 2022
-
-
Christian König authored
The unwrap merge function is now intended for this use case. 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-6-christian.koenig@amd.com
-
Christian König authored
Introduce a dma_fence_unwrap_merge() macro which allows to unwrap fences which potentially can be containers as well and then merge them back together into a flat dma_fence_array. v2: rename the function, add some more comments about how the wrapper is used, move filtering of signaled fences into the unwrap iterator, add complex selftest which covers more cases. v3: fix signaled fence filtering once more Signed-off-by: -
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 authored
Move the code from the inline functions into exported functions. Signed-off-by:
-
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:
-
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:
-
- May 28, 2022
-
-
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
-
- May 26, 2022
-
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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-Configurator Signed-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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
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:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
-
- May 25, 2022
-
-
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:
-
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:
-
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:
-
- May 24, 2022
-
-
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:
-
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:
-
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:
-
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 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:
-
- May 23, 2022
-
-
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:
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:
-
