- 08 Aug, 2021 4 commits
-
-
Thomas Zimmermann authored
The _set_plls() functions compute a pixel clock's PLL values and program the hardware accordingly. This happens during atomic commits. For atomic modesetting, it's better to separate computation and programming from each other. This will allow to compute the PLL value during atomic checks and catch unsupported modes early. Split the PLL setup into a compute and an update functions, and call them one after the other. Computed PLL values are store in struct mgag200_pll_values. There are four parameters for the PLL, m, n, p and s. Every compute function stores a value for each of these parameters, and the rsp update function makes the register bits from them. The values stored by the compute function are either plain values or register bits. An additional change is required to always store plain values. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210714142240.21979-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
Replace P_ARRAY_SIZE by array pre-initializing and ARRAY_SIZE(). No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Return -EINVAL if there's no PLL configuration for the given pixel clock. The returned errors are currently ignored by the caller, but the errno codes will become useful when the compute functions run during atomic checks. v2: * give a rational for this change (Sam) Signed-off-by:
-
Thomas Zimmermann authored
Put the clock-selection code into each of the PLL-update functions to make them select the correct pixel clock. Instead of copying the code, introduce a new helper WREG_MISC_MASKED, which does masked writes into <MISC>. Use it from each individual PLL update function. The pixel clock for video output was not actually set before programming the clock's values. It worked because the device had the correct clock pre-set. v2: * don't duplicate <MISC> update code (Sam) Signed-off-by:
-
- 06 Aug, 2021 2 commits
-
-
Xin Ji authored
IVO panel require less input video clock variation than video clock variation in DP CTS spec. This patch decreases the K value of ANX7625 which will shrink eDP Tx video clock variation to meet IVO panel's requirement. Acked-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210806104407.2208538-1-xji@analogixsemi.com
-
Robert Foss authored
The return value of drm_bridge_attach() is ignored during the it66121_bridge_attach() call, which is incorrect. Fixes: 988156dc ("drm: bridge: add it66121 driver") Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210805185039.402178-1-robert.foss@linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210805185039.402178-1-robert.foss@linaro.org
-
- 05 Aug, 2021 9 commits
-
-
Søren Andersen authored
Add support for the LOGIC Technologies, Inc LTTD800480070-L6WH-RT Signed-off-by:
Søren Andersen <san@skov.dk> Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
-
Sam Ravnborg authored
The Multi Innotechnology is a 10.1" 1280x800 panel. The datasheet did not specify specific values for sync, back, front porch. The values are a best guess based on values for similar panels. Signed-off-by:
Ulrich Ölmann <u.oelmann@pengutronix.de> Signed-off-by:
-
Randy Dunlap authored
Fix build errors and warnings when CONFIG_DRM_NOUVEAU_BACKLIGHT is not set ../drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_sor_atomic_disable’: ../drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:52: error: ‘struct nouveau_connector’ has no member named ‘backlight’ struct nouveau_backlight *backlight = nv_connector->backlight; ^~ ../drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:28: error: dereferencing pointer to incomplete type ‘struct nouveau_backlight’ if (backlight && backlight->uses_dpcd) { and then fix subsequent build warnings after the above are fixed: ../drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_sor_atomic_disable’: ../drivers/gpu/drm/nouveau/dispnv50/disp.c:1669:6: warning: unused variable ‘ret’ [-Wunused-variable] int ret; ^~~ ../drivers/gpu/drm/nouveau/dispnv50/disp.c:1662:22: warning: unused variable ‘drm’ [-Wunused-variable] struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev); ^~~ Fixes: 6eca310e ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau") Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: Lyude Paul <lyude@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Desmond Cheong Zhi Xi authored
In drm_is_current_master_locked, accessing drm_file.master should be protected by either drm_file.master_lookup_lock or drm_device.master_mutex. This was previously awkward to assert with lockdep. Following patch ("locking/lockdep: Provide lockdep_assert{,_once}() helpers"), this assertion is now convenient. So we add in the assertion and explain this lock design in the kerneldoc. Signed-off-by:Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Acked-by:
Boqun Feng <boqun.feng@gmail.com> Acked-by:
Waiman Long <longman@redhat.com> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210802105957.77692-3-desmondcheongzx@gmail.com
-
Peter Zijlstra authored
Extract lockdep_assert{,_once}() helpers to more easily write composite assertions like, for example: lockdep_assert(lockdep_is_held(&drm_device.master_mutex) || lockdep_is_held(&drm_file.master_lookup_lock)); Signed-off-by: -
Dillon Min authored
This driver combines tiny/ili9341.c mipi_dbi_interface driver with mipi_dpi_interface driver, can support ili9341 with serial mode and parallel rgb interface mode by different dts bindings. Signed-off-by:
Dillon Min <dillon.minfei@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
-
Dillon Min authored
Add documentation for "ilitek,ili9341" panel. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/lkml/1626853288-31223-2-git-send-email-dillon.minfei@gmail.com/Signed-off-by:
-
Artjom Vejsel authored
The Gopher 2b LCD panel is used in Gopher 2b handhelds. It's simple panel with NewVision NV3047 driver, but SPI lines are not connected. It has no specific name, since it's unique to that handheld. lot name at AliExpress: 4.3 inch 40PIN TFT LCD Screen COG NV3047 Drive IC 480(RGB)*272 No Touch 24Bit RGB Interface Signed-off-by:
Artjom Vejsel <akawolf0@gmail.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210804002353.76385-4-akawolf0@gmail.com
-
Artjom Vejsel authored
Add DT bindings for QiShenglong Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel. Signed-off-by:
-
- 02 Aug, 2021 9 commits
-
-
Thomas Zimmermann authored
Abstract the framebuffer details by mappings its BOs with a call to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunamp(). Before, the output address with stored as raw pointer in the priv field of struct drm_writeback_job. Introduce the new type struct vkms_writeback_job, which holds the output mappings addresses while the writeback job is active. The patchset also cleans up some internal casting an setup of the output addresses. No functional changes. v3: * free instances of struct vkms_writeback_job on cleanup or errors Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
-
Thomas Zimmermann authored
Abstract the framebuffer details by mapping its BOs with a call to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunmap(). The call to drm_gem_fb_vmap() ensures that all BOs are mapped correctly. Gud still only supports single-plane formats. No functional changes. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
-
Thomas Zimmermann authored
Set the returned mapping address to NULL if a framebuffer plane does not have a BO associated with it. Likewise, ignore mappings of NULL during framebuffer unmap operations. Allows users of the functions to perform unmap operations of certain BOs by themselfes. Signed-off-by:
-
Thomas Zimmermann authored
Move framebuffer vmap code from shadow-buffered plane state into the new interfaces drm_gem_fb_vmap() and drm_gem_fb_vunmap(). These functions provide mappings of a framebuffer's BOs into kernel address space. No functional changes. v4: * remove duplicated blank line v2: * using [static N] for array parameters enables compile-time checks * include <drm/drm_fourcc.h> for DRM_FORMAT_MAX_PLANES (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
DRM uses a magic number of 4 for the maximum number of planes per color format. Declare this constant via DRM_FORMAT_MAX_PLANES and update the related code. Some code depends on the length of arrays that are now declared with DRM_FORMAT_MAX_PLANES. Convert it from '4' to ARRAY_SIZE. v2: * mention usage of ARRAY_SIZE() in the commit message (Maxime) * also fix error handling in drm_gem_fb_init_with_funcs() (kernel test robot) * include <drm/drm_fourcc.h> for DRM_FORMAT_MAX_PLANES Signed-off-by:
-
Simon Ser authored
It's not obvious what the fields mean and how they should be used. The most important detail is the link to drm_property.flags, which describes how property types work. v2: document enum drm_mode_property_enum, add ref to "Modeset Base Object Abstraction" (Daniel) Signed-off-by:
Simon Ser <contact@emersion.fr> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
-
Daniel Vetter authored
I've added a new check to make sure that drivers which insepct the damage property have it set up correctly, but somehow missed that this borke the damage selftest in the CI result noise. Fix it up by mocking enough of drm_device and drm_plane so we can call drm_plane_enable_fb_damage_clips() to make the new check happy. Since there's a lot of duplicated mock code already copy-pasted into each test I've also refactored this a bit to trim it down. v2: Squash in fixup from 0day for drivers/gpu/drm/selftests/test-drm_damage_helper.c:15:19: warning: symbol 'mock_device' was not declared. Should it be static? drivers/gpu/drm/selftests/test-drm_damage_helper.c:16:30: warning: symbol 'mock_obj_props' was not declared. Should it be static? drivers/gpu/drm/selftests/test-drm_damage_helper.c:17:18: warning: symbol 'mock_plane' was not declared. Should it be static? drivers/gpu/drm/selftests/test-drm_damage_helper.c:18:21: warning: symbol 'mock_prop' was not declared. Should it be static? Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Fixes: c7fcbf25 ("drm/plane: check that fb_damage is set up when used") Cc: José Roberto de Souza <jose.souza@intel.com> (v1) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210730095251.4343-1-daniel.vetter@ffwll.ch Link: https://patchwork.freedesktop.org/patch/msgid/20210730141948.GA11955@243d74413310
-
Cai Huoqing authored
fix typo for drm v1->v2: respin with the change "iff ==> implies that" Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
Simon Ser authored
Mention that connectors need to be referenced manually if they are to be accessed after the iteration has progressed or ended. Signed-off-by:
-
- 01 Aug, 2021 2 commits
-
-
Gregory Williams authored
Removed space before comma, fixed if statements by putting trailing statements on new line, fixed unsigned int declaration, and removed not needed else statement after return. Signed-off-by:
Gregory Williams <gregwills85@gmail.com> Signed-off-by:
-
Alistair Francis authored
Add support for the 10.3" E Ink panel described at: https://www.eink.com/product.html?type=productdetail&id=7Signed-off-by:
Alistair Francis <alistair@alistair23.me> Acked-by:
-
- 31 Jul, 2021 7 commits
-
-
Cai Huoqing authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
-
Douglas Anderson authored
The Samsung ATNA33XC20 panel is an AMOLED eDP panel that has backlight control over the DP AUX channel. This panel is _almost_ able to be controlled in a "simple" way (and it originally was implemented in panel-simple.c), but it's really impossible to get the backlight semantics right there without adding wacky special-case code to panel-simple. Let's give up and clone the parts of panel-simple that we need and implement the power sequence that this panel needs. NOTE: we'll still leave the devicetree bindings alone. Even though the power-sequencing is non-standard the bindings are still "simple". Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Douglas Anderson authored
This reverts commit 18a1488b. Those delays were added to support the Samsung ATNA33XC20 panel. However, we've moving that to its own panel driver and out of panel-simple. That means we don't need the ability to specify this delay. NOTE: it's unlikely we want to keep this delay "just in case" some other panel needs it. The enable-gpio and the power supply are really supposed to be different ways to specify the same thing: the main enable of the panel. Supporting a delay between them doesn't really make sense. Signed-off-by:
-
Douglas Anderson authored
This reverts commit 4bfe6c8f. This panel's power sequencing really can't be handled properly by panel-simple because of the special sequencing needed for the EL_ON3 GPIO. The only way it was sorta working in the past was by trying to jam that signal into the "enable-gpio", but that really wasn't a good fit. We'll add a custom panel driver for this panel to do it right. Signed-off-by:
-
Douglas Anderson authored
The manual has always said that we need 100 us delays in a few places. Though it hasn't seemed to be a big deal to skip these, let's add them in case it makes something happier. NOTE: this fixes no known issues but it seems good to make it right. Fixes: a095f15c ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by:
-
Douglas Anderson authored
When testing with a panel that's apparently a little more persnickety about the correct power sequence (specifically Samsung ATNA33XC20), we found that the ti-sn65dsi86 was doing things just slightly wrong. Looking closely at the ti-sn65dsi86's datasheet, the power off sequence is supposed to be: 1. Clear VSTREAM_ENABLE bit 2. Stop DSI stream from GPU. DSI lanes must be placed in LP11 state. 3. Program the ML_TX_MODE to 0x0 (OFF) 4. Program the DP_NUM_LANES register to 0x0 5. Clear the DP_PLL_EN bit. 6. Deassert the EN pin. 7. Remove power from supply pins Since we were doing the whole sequence in the "disable", I believe that step #2 (stopping the DSI stream from the GPU) wasn't happening. We also weren't setting DP_NUM_LANES to 0. Let's fix this. NOTE: things are a little asymmetric now. For instance, we turn the PLL on in "enable" but now we're not turning it off until "post_disable". It would seem to make sense to move the PLL turning on to "pre_enable" to match. Unfortunately, I don't believe that's allowed. It looks as if (in the non-refclk mode which probably nobody is using) we have to wait until the MIPI clock is there before we can enable the PLL. In any case, the way it is here won't really hurt--it'll just leave the PLL on a little longer. Fixes: a095f15c ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by:
-
Douglas Anderson authored
The function drm_edp_backlight_init() is defined such that the "driver_pwm_freq_hz" parameter is optional--it's 0 if you don't want to futz with it. If you follow this variable through, you'll find out that if it's 0 we won't ever set the "bl->pwmgen_bit_count", leaving it as 0. That means that before using it in drm_edp_backlight_enable() we need to check to see if it's non-zero. Programming this field to zero was confusing the panel I tested with (Samsung ATNA33XC20). The backlight still worked somewhat but the brightness values didn't correspond to what they should have been. Fixes: 867cf9cd ("drm/dp: Extract i915's eDP backlight code into DRM helpers") Signed-off-by:
-
- 30 Jul, 2021 5 commits
-
-
Desmond Cheong Zhi Xi authored
The kerneldoc in drm_lease.c is unused because none of the functions are driver interfaces as the symbols are not exported. Since they aren't used and much of the existing comments don't provide any insights (e.g. they just repeat the function name or list out the function parameters), they should be removed to make them easier to maintain and to make useful info more obvious. As a note, many of the comments mention whether idr_mutex should be held, but these are mostly redundant in cases where the function contains lockdep assertions or grabs the mutex. To simplify review, here's the reasoning behind each update. drm_lease_owner: function name is self-descriptive _drm_find_lessee: function name is self-descriptive _drm_lease_held_master: function name and signature are self-descriptive _drm_has_leased: kerneldoc is summarized into a comment because the function name could be interpreted ambiguously (check if the object has been leased VS check if the master has a lease on the object) _drm_lease_held: Retain the idr_mutex comment because the function does not directly grab the mutex or use a lockdep assertion. Otherwise, the function name is self-descriptive. drm_lease_held: function name is self-descriptive drm_lease_filter_crtcs: Kerneldoc is summarized into a comment because the function name could be interpreted ambiguously (filter leases based on crtcs mask VS filter crtcs mask based on leases) drm_lease_create: Kerneldoc removed. Useful function details such as atomic leasing are retained. Errno interpretations are useful and retained. drm_lease_destroy: function name is self-descriptive. Additional information is also removed as they're already present as comments inside the function. _drm_lease_revoke: function name is self-descriptive drm_lease_revoke: function name is self-descriptive drm_mode_create_lease_ioctl: Kerneldoc removed, but useful function details retained. drm_mode_list_lessees_ioctl: function name is self-descriptive. Additional details restate what the code does. drm_mode_get_lease_ioctl: Function summary retained to clarify that it's the leased objects that are returned, not the lease structure. drm_mode_revoke_lease_ioctl: Kerneldoc removed, but useful function details retained. Signed-off-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.15-2021-07-29' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.15-2021-07-29: amdgpu: - VCN/JPEG power down sequencing fixes - Various navi pcie link handling fixes - Clockgating fixes - Yellow Carp fixes - Beige Goby fixes - Misc code cleanups - S0ix fixes - SMU i2c bus rework - EEPROM handling rework - PSP ucode handling cleanup - SMU error handling rework - AMD HDMI freesync fixes - USB PD firmware update rework - MMIO based vram access rework - Misc display fixes - Backlight fixes - Add initial Cyan Skillfish support - Overclocking fixes suspend/resume amdkfd: - Sysfs leak fix - Add counters for vm faults and migration - GPUVM TLB optimizations radeon: - Misc fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210730033455.3852-1-alexander.deucher@amd.com
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
An early pull for v5.15 (there'll be more coming in a week or two), consisting of the drm/scheduler conversion and a couple other small series that one was based one. Mostly sending this now because IIUC danvet wanted it in drm-next so he could rebase on it. (Daniel, if you disagree then speak up, and I'll instead include this in the main pull request once that is ready.) This also has a core patch to drop drm_gem_object_put_locked() now that the last use of it is removed. [airlied: add NULL to drm_sched_init] Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v5.15: UAPI Changes: - Add modifiers for arm fixed rate compression. Cross-subsystem Changes: - Assorted dt binding fixes. - Convert ssd1307fb to json-schema. - Update a lot of irc channels to point to OFTC, as everyone moved there. - Fix the same divide by zero for asilantfb, kyro, rivafb. Core Changes: - Document requirements for new atomic properties. - Add drm_gem_fb_(begin/end)_cpu_access helpers, and use them in some drivers. - Document drm_property_enum.value for bitfields. - Add explicit _NO_ for MIPI_DSI flags that disable features. - Assorted documentation fixes. - Update fb_damage handling, and move drm_plane_enable_fb_damage_clips to core. - Add logging and docs to RMFB ioctl. - Assorted small fixes to dp_mst, master handling. - Clarify drm lease usage. Driver Changes: - Assorted small fixes to panfrost, hibmc, bridge/nwl-dsi, rockchip, vc4. - More drm -> linux irq conversions. - Add support for some Logic Technologies and Multi-Inno panels. - Expose phy-functionality for drm/rockchip, to allow controlling from the media subsystem. - Add support for 2 AUO panels. - Add damage handling to ssd1307fb. - Improve FIFO handling on mxsfb. - Assorted small fixes to vmwgfx, and bump version to 2.19 for the new ioctls. - Improve sony acx424akp backlight handling. Signed-off-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
- R-Car DU shutdown fixes - R-Car DU conversion to bridge connector helper - Misc small fixes Signed-off-by:
-
- 29 Jul, 2021 2 commits
-
-
Maxime Ripard authored
Commit 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") removed the references to the vc4_hdmi_audio_component_drv structure, but not the structure itself resulting in a warning. Remove it. Fixes: 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") Reported-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707093632.1468127-2-maxime@cerno.tech
-
Maxime Ripard authored
The vc4_hdmi_audio_prepare function and the functions it's calling have in several occurences multiple dereferences of either the sample rate or the number of channels. It turns out that these variables are also passed through the hdmi codec parameters structure. Convert all the users to use this structure, and if it's used multiple times use a variable to store it instead of dereferencing it every time. Reviewed-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by:
-
