summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-03drm/virtio: Spelling fixesAndy Shevchenko
While making a spelling mistake myself for `git grep kvalloc` I found that the only file has such a typo. Fix it and update to the standard de facto of how we refer to the functions. Also spell usr-out as user-out, it seems this driver uses its own terminology nobody else can decypher, make it more readable. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219151955.2477488-1-andriy.shevchenko@linux.intel.com
2024-01-02drm/debugfs: drop unneeded DEBUG_FS guardDario Binacchi
The Makefile enables/disables the file compilation depending on CONFIG_DEBUG_FS. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231223183301.78332-1-dario.binacchi@amarulasolutions.com
2024-01-02drm/vkms: Avoid reading beyond LUT arrayHarry Wentland
When the floor LUT index (drm_fixp2int(lut_index) is the last index of the array the ceil LUT index will point to an entry beyond the array. Make sure we guard against it and use the value of the floor LUT index. v3: - Drop bits from commit description that didn't contribute anything of value Fixes: db1f254f2cfa ("drm/vkms: Add support to 1D gamma LUT") Signed-off-by: Harry Wentland <harry.wentland@amd.com> Cc: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108163647.106853-6-harry.wentland@amd.com
2024-01-02drm/vkms: Create separate Kconfig file for VKMSHarry Wentland
This aligns with most other DRM drivers and will allow us to add new VKMS config options without polluting the DRM Kconfig. v3: - Change SPDX to GPL-2.0-only to match DRM KConfig SPDX (Simon) Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108163647.106853-4-harry.wentland@amd.com
2024-01-02drm: Don't treat 0 as -1 in drm_fixp2int_ceilHarry Wentland
Unit testing this in VKMS shows that passing 0 into this function returns -1, which is highly counter- intuitive. Fix it by checking whether the input is >= 0 instead of > 0. Fixes: 64566b5e767f ("drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil") Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108163647.106853-2-harry.wentland@amd.com
2024-01-02drm/vc4: plane: check drm_gem_plane_helper_prepare_fb() return valueSimon Ser
Bubble up any error to the caller. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Maxime Ripard <mripard@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231216141518.242811-1-contact@emersion.fr
2024-01-01drm/ssd130x: Add support for the SSD133x OLED controller familyJavier Martinez Canillas
The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot matrix OLED panels, add a modesetting pipeline to support the chip family. The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths but only the 256-color mode (DRM_FORMAT_RGB332) is implemented for now. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-5-javierm@redhat.com
2024-01-01dt-bindings: display: Add SSD133x OLED controllersJavier Martinez Canillas
Add a Device Tree binding schema for the OLED panels based on the Solomon SSD133x family of controllers. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-4-javierm@redhat.com
2024-01-01dt-bindings: display: ssd132x: Add vendor prefix to width and heightJavier Martinez Canillas
Commit 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers") used the wrong properties for width and height, instead of the correct "solomon,width" and "solomon,height" properties. Fix this by adding the vendor prefix to the width and height properties. Fixes: 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers") Reported-by: Conor Dooley <conor@kernel.org> Closes: https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-3-javierm@redhat.com
2024-01-01dt-bindings: display: ssd1307fb: Add vendor prefix to width and heightJavier Martinez Canillas
The commit 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width and height values") used the wrong properties for width and height, instead of the correct "solomon,width" and "solomon,height" properties. Fix this by adding the vendor prefix to the width and height properties. Fixes: 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width and height values") Reported-by: Conor Dooley <conor@kernel.org> Closes: https://lore.kernel.org/dri-devel/20231218-example-envision-b41ca8efa251@spud/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-2-javierm@redhat.com
2023-12-30drm/rockchip: inno_hdmi: Split power mode settingAlex Bee
This splits setting the power mode of the controller / phy in two functions. It's done in preparation of setting up the phy based on the pixelclock. No functional changes intended. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-23-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Don't power up the phy after resettingAlex Bee
inno_hdmi_reset is only ever called when initializing the controller. At this point it’s completely uneccessary to power up the PHY, since all what has to work at this point is the DDC bus. The phy will be powered up correctly when a mode is set in inno_hdmi_encoder_enable and disabled in inno_hdmi_encoder_disable. Set it to LOWER_PWR after resetting the controller. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-22-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Correctly setup HDMI quantization rangeAlex Bee
The display controller will always give full range RGB regardless of the mode set, but HDMI requires certain modes to be transmitted in limited range RGB. This is especially required for HDMI sinks which do not support non-standard quantization ranges. This enables color space conversion for those modes and sets the quantization range accordingly in the AVI infoframe. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-21-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Subclass connector stateAlex Bee
The data which is currently hold in hdmi_data should not be part of device itself but of the connector state. Introduce a connector state subclass and move the data from hdmi_data in there. Suggested-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-20-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove useless includeAlex Bee
The inclusion syscon.h isn't used anywhere. Remove it. Signed-off-by: Alex Bee <knaerzche@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-19-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Drop irq struct memberAlex Bee
The struct member irq isn't used anywhere. Drop it. Signed-off-by: Alex Bee <knaerzche@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-18-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove unused drm device pointerMaxime Ripard
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM device but is never used anywhere in the driver. Let's remove it. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-17-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Switch to infoframe typeMaxime Ripard
The inno_hdmi driver relies on its own internal infoframe type matching the hardware. This works fine, but in order to make further reworks easier, let's switch to the HDMI spec definition of those types. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-16-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Move infoframe disable to separate functionMaxime Ripard
The code to upload infoframes to the controller uses a weird construct which, based on the previous function call return code, will either disable or enable that infoframe. In order to get rid of that argument, let's split the function to disable the infoframe into a separate function and make it obvious what we are doing in the error path. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-15-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Drop HDMI Vendor Infoframe supportMaxime Ripard
The HDMI vendor infoframe is only meant to be sent with 4k60 modes and higher, but the controller doesn't support them. Let's drop them from the kernel. Suggested-by: Johan Jonker <jbx6244@gmail.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-14-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove tmds rate from structureMaxime Ripard
The tmds_rate field in the inno_hdmi structure is used mostly to configure the internal i2c controller divider through a call to the inno_hdmi_i2c_init() function. We can simply make that rate an argument to that function, which also removes a workaround to initialize the divider at probe time when we don't have a mode yet. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-13-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove YUV-based csc coefficentsAlex Bee
Now that the unneeded support for YUV based input formats is gone, the csc coefficients for those formats can be dropped as well. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-12-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove useless input formatMaxime Ripard
The driver has a lot of logic to deal with multiple input formats, but hardcodes it to RGB. This means that most of that code has been dead code, so let's get rid of it. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> [made checkpatch happy] Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-11-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove unneeded has audio flagMaxime Ripard
The sink_has_audio flag is not used anywhere in the driver so let's get rid of it. It's redundant with drm_display_info.has_audio anyway. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-10-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: no need to store vicMaxime Ripard
The mode's VIC is only ever used in the inno_hdmi_setup() function so there's no need to store it in the main structure. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> [made checkpatch happy] Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-9-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Get rid of mode_setMaxime Ripard
We're not doing anything special in atomic_mode_set so we can simply merge it into atomic_enable. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-8-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Switch encoder hooks to atomicMaxime Ripard
The inno_hdmi encoder still uses the !atomic variants of enable, disable and modeset. Convert to their atomic equivalents. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-7-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove useless copy of drm_display_modeMaxime Ripard
The driver maintains a copy of the adjusted mode but doesn't use it anywhere. Remove it. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-6-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Remove useless mode_fixupMaxime Ripard
The mode_fixup implementation doesn't do anything, so we can simply remove it. Signed-off-by: Maxime Ripard <mripard@kernel.org> Tested-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-5-knaerzche@gmail.com
2023-12-30drm/rockchip: inno_hdmi: Fix video timingAlex Bee
The controller wants the difference between *total and *sync_start in the HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for certain non-VIC modes. See downstream commit [0]. [0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support") Co-developed-by: Zheng Yang <zhengyang@rock-chips.com> Signed-off-by: Zheng Yang <zhengyang@rock-chips.com> Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-4-knaerzche@gmail.com
2023-12-30drm/rockchip: vop: Add output selection registers for RK312xAlex Bee
In contrast to RK3036, RK312x SoCs have multiple output channels such as RGB (i.e. LVDS TTL), LVDS, DSI and HDMI. In order to support that, this splits output from RK3036 and defines an separate one for RK3126 with the registers required to enable the appropriate output and setup the correct polarity. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-3-knaerzche@gmail.com
2023-12-28drm/tilcdc: request and mapp iomem with devresPhilipp Stanner
tilcdc currently just ioremaps its iomem, without doing the (a bit more robust) request on the memory first. The devm_ functions provide a handy way to both request and ioremap the memory with automatic cleanup. Replace the manual ioremap with the devm_ version. Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi> Tested-by: Jyri Sarha <jyri.sarha@iki.fi> Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/20231222115216.19218-2-pstanner@redhat.com
2023-12-22dt-bindings: panel: lvds: Append edt,etml0700z9ndha in panel-lvdsRaphael Gallais-Pou
List EDT ETML0700Z9NDHA in the LVDS panel enumeration. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231221124339.420119-2-raphael.gallais-pou@foss.st.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231221124339.420119-2-raphael.gallais-pou@foss.st.com
2023-12-20accel/qaic: Order pci_remove() operations in reverse of probe()Jeffrey Hugo
In probe() we create the drm_device, and then register the MHI controller. In remove(), we should unregister the controller first, then remove the drm_device. Update the remove() operations to match. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231208163457.1295993-8-quic_jhugo@quicinc.com
2023-12-20accel/qaic: Leverage DRM managed APIs to release resourcesPranjal Ramajor Asha Kanojiya
Offload the balancing of init and destroy calls to DRM managed APIs. mutex destroy for ->cntl_mutex is not called during device release and destroy workqueue is not called in error path of create_qdev(). So, use DRM managed APIs to manage the release of resources and avoid such problems. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231208163457.1295993-7-quic_jhugo@quicinc.com
2023-12-18drm/panel-edp: Add several generic edp panelsXuxin Xiong
Add support for the following 3 panels: 1. BOE NV116WHM-N49 V8.0 2. BOE NV122WUM-N41 3. CSO MNC207QS1-1 Signed-off-by: Xuxin Xiong <xuxinxiong@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231218095933.2487360-1-xuxinxiong@huaqin.corp-partner.google.com
2023-12-18drm/panel-edp: Add some panels with conservative timingsPin-yen Lin
These panels are used by Mediatek MT8173 Chromebooks, and they used to work with the downstream v4.19 kernel without any specified delay. Back in the v4.19 kernel, they used the "little white lie" approach, which is making the devicetree claim a specific panel's compatible string for many different panels. That was a common solution before the generic edp-panel driver. After we uprevved the device to a newer kernel and used the edp-panel driver, we saw multiple devices reporting warnings of using an unknown panel and falling back to the conservative timings, which means that they turn on/off much more slowly than they should. We tried to fill in the timings for those panels, but we failed to find all the data sheets for them. Therefore, instead of having them use the default conservative timings, update them with less-conservative timings from other panels of the same vendor. The panels should still work under those timings, and we can save some delays and suppress the warnings. Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231214152817.2766280-4-treapking@chromium.org
2023-12-18drm/edp-panel: Add panels delay entriesPin-yen Lin
Add panels used by Mediatek MT8173 Chromebooks. Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231214152817.2766280-3-treapking@chromium.org
2023-12-18drm/panel-edp: Add powered_on_to_enable delayPin-yen Lin
Add the support of powered_on_to_enable delay as the minimum time that needs to have passed between the panel powered on and enable may begin. This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8 in the eDP timing diagrams. Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231214152817.2766280-2-treapking@chromium.org
2023-12-18drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=mVille Syrjälä
The original rationale for commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko") was that depot_save_stack() (which is what we used back then) wasn't exported. stack_depot_save() (which is what we use now) is exported however, so relax the dependency allow CONFIG_DRM_MM_DEBUG with DRM=m. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231215111129.9559-1-ville.syrjala@linux.intel.com Acked-by: Javier Martinez Canillas <javierm@redhat.com>
2023-12-18drm/todo: Add entry to rename drm_atomic_stateMaxime Ripard
The name of the structure drm_atomic_state is confusing. Let's add an entry to our todo list to rename it. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20231214100917.277842-5-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-18drm/atomic: Make the drm_atomic_state documentation less ambiguousMaxime Ripard
The current documentation of drm_atomic_state says that it's the "global state object". This is confusing since, while it does contain all the objects affected by an update and their respective states, if an object isn't affected by this update it won't be part of it. Thus, it's not truly a "global state", unlike object state structures that do contain the entire state of a given object. Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://lore.kernel.org/r/20231214100917.277842-4-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-18drm/atomic: Rework the object doc a bitMaxime Ripard
Commits 63e83c1dba54 ("drm: Consolidate connector arrays in drm_atomic_state"), b8b5342b699b ("drm: Consolidate plane arrays in drm_atomic_state") and 5d943aa6c0d4 ("drm: Consolidate crtc arrays in drm_atomic_state") moved the object pointer and their state pointer to an intermediate structure storing both. The CRTC commit didn't update the doc of the crtcs field to reflect that, and the doc for the planes and connectors fields mention that they are pointers to an array of structures with per-$OBJECT data. The private_objs field was added later on by commit b430c27a7de3 ("drm: Add driver-private objects to atomic state") reusing the same sentence than the crtcs field, probably due to copy and paste. While these fields are indeed pointers to an array, each item of that array contain a pointer to the object structure affected by the update, and its old and new state. There's no per-object data there, and there's more than just a pointer to the objects. Let's rephrase those fields a bit to better match the current situation. Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20231214100917.277842-3-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-18drm/atomic: Remove inexistent referenceMaxime Ripard
Commit 63e83c1dba54 ("drm: Consolidate connector arrays in drm_atomic_state") removed the connector_states field but didn't remove its mention in the num_connectors documentation. Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20231214100917.277842-2-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-18drm/atomic: Move the drm_atomic_state field doc inlineMaxime Ripard
Some fields of drm_atomic_state have been documented in-line, but some were documented in the main kerneldoc block before the structure. Since the former is the preferred option in DRM, let's move all the fields to an inline documentation. Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Link: https://lore.kernel.org/r/20231214100917.277842-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-12-18fbdev/vesafb: Use screen_info pointer from deviceThomas Zimmermann
Use the screen_info instance from the device instead of dereferencing the global screen_info state. Decouples the driver from per-architecture code. Duplicated the screen_info data, so that vesafb can modify it at will. v2: * comment on devm_kmemdup() usage (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-5-tzimmermann@suse.de
2023-12-18fbdev/vesafb: Replace references to global screen_info by local pointerThomas Zimmermann
Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-4-tzimmermann@suse.de
2023-12-18fbdev/efifb: Use screen_info pointer from deviceThomas Zimmermann
Use the screen_info instance from the device instead of dereferencing the global screen_info state. Decouples the driver from per-architecture code. Duplicated the screen_info data, so that efifb can modify it at will. v2: * comment on devm_kmemdup() usage (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-3-tzimmermann@suse.de
2023-12-18fbdev/efifb: Replace references to global screen_info by local pointerThomas Zimmermann
Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-15accel/qaic: Call drm_gem_create_mmap_offset() once for each BOPranjal Ramajor Asha Kanojiya
Every time QAIC_MMAP_BO ioctl is called for a BO, drm_gem_create_mmap_offset() is called. Calling drm_gem_create_mmap_offset() more then once for a BO seems redundant. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231208163457.1295993-6-quic_jhugo@quicinc.com