dri-devel February 2020

dri-devel@lists.freedesktop.org

302 participants
679 discussions

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
by Daniel Vetter 08 Apr '20

08 Apr '20

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. v3: Fix inverted WARN_ON (Pekka). References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Reviewed-by: Daniel Stone <daniels(a)collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 9ccfbf213d72..4c035abf98b8 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(!state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.24.1

2 5

[PATCH 00/15] amdgpu: remove load and unload callbacks (v3)
by Alex Deucher 08 Apr '20

08 Apr '20

These are deprecated and the drm will soon start warning when drivers still use them. It was a long and twisty road, but seems to work. v2: Add additional patch (13/15) which should fix the crash reported by Thomas Zimmermann. v3: Fix dp aux registration harder, add missing kconfig guard Alex Deucher (15): drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs drm/amdgpu/pm: move debugfs init into core amdgpu debugfs drm/amdgpu/sa: move debugfs init into core amdgpu debugfs drm/amdgpu/fence: move debugfs init into core amdgpu debugfs drm/amdgpu/gem: move debugfs init into core amdgpu debugfs drm/amdgpu/regs: move debugfs init into core amdgpu debugfs drm/amdgpu/firmware: move debugfs init into core amdgpu debugfs drm/amdgpu: don't call drm_connector_register for non-MST ports drm/amdgpu/display: move debugfs init into core amdgpu debugfs (v2) drm/amd/display: move dpcd debugfs members setup drm/amdgpu/display: add a late register connector callback drm/amdgpu/display: split dp connector registration (v2) drm/amdgpu/ring: move debugfs init into core amdgpu debugfs drm/amdgpu: drop legacy drm load and unload callbacks .../gpu/drm/amd/amdgpu/amdgpu_connectors.c | 17 ++++- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 69 ++++++++++++++++++- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ----- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 - drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 9 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 15 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 4 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 + drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 +-- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 1 - .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++---- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 + .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 13 ++-- 19 files changed, 140 insertions(+), 89 deletions(-) -- 2.24.1

5 24

[PATCH v2 1/3] gpu/drm: ingenic: Add trick to support 16bpp on 24-bit panels
by Paul Cercueil 08 Apr '20

08 Apr '20

If the panel interface is 24-bit but our primary plane is 16bpp, configure as if the panel was 18-bit. This tricks permits the display of 16bpp data on a 24-bit panel by wiring each color component to the MSBs of the 24-bit interface. v2: Check bytes-per-pixel count instead of fourcc format Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/gpu/drm/ingenic/ingenic-drm.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c index 6d47ef7b148c..5493a80d7d2f 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c @@ -400,6 +400,8 @@ static void ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode = &crtc_state->adjusted_mode; struct drm_connector *conn = conn_state->connector; struct drm_display_info *info = &conn->display_info; + struct drm_plane_state *plane_state = crtc_state->crtc->primary->state; + const struct drm_format_info *finfo = NULL; unsigned int cfg; priv->panel_is_sharp = info->bus_flags & DRM_BUS_FLAG_SHARP_SIGNALS; @@ -435,7 +437,21 @@ static void ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder, cfg |= JZ_LCD_CFG_MODE_GENERIC_18BIT; break; case MEDIA_BUS_FMT_RGB888_1X24: - cfg |= JZ_LCD_CFG_MODE_GENERIC_24BIT; + if (plane_state && plane_state->fb) + finfo = plane_state->fb->format; + + /* + * If the panel interface is 24-bit but our + * primary plane is 16bpp, configure as if the + * panel was 18-bit. This tricks permits the + * display of 16bpp data on a 24-bit panel by + * wiring each color component to the MSBs of + * the 24-bit interface. + */ + if (finfo && finfo->cpp[0] < 3) + cfg |= JZ_LCD_CFG_MODE_GENERIC_18BIT; + else + cfg |= JZ_LCD_CFG_MODE_GENERIC_24BIT; break; case MEDIA_BUS_FMT_RGB888_3X8: cfg |= JZ_LCD_CFG_MODE_8BIT_SERIAL; -- 2.25.0

2 5

[Bug 206519] New: [amdgpu] kernel NULL pointer dereference on shutdown
by bugzilla-daemon＠bugzilla.kernel.org 07 Apr '20

07 Apr '20

https://bugzilla.kernel.org/show_bug.cgi?id=206519 Bug ID: 206519 Summary: [amdgpu] kernel NULL pointer dereference on shutdown Product: Drivers Version: 2.5 Kernel Version: 5.5.1.arch1-1, 5.5.3-arch1-1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: shlomo(a)fastmail.com Regression: No Created attachment 287353 --> https://bugzilla.kernel.org/attachment.cgi?id=287353&action=edit shutdown screen photo When I try to power off my machine, it shows the usual shutdown messages and the screens turn off, but the machine is still powered on. The virtual console shows a kernel NULL pointer dereference at address 0. I run Arch Linux. The bug occurs even if I never run X. I can turn on the machine and immediately try to shut it down, and the same bug still occurs. This bug occurred since I upgraded linux 5.4.15.arch1-1 to 5.5.1.arch1-1. I now run linux 5.5.3.arch1-1 and the bug still exists. My graphics card is Gigabyte Radeon RX VEGA 56 GAMING OC 8G, connected to six monitors. A photo of the screen at shutdown is attached. I think these are the relevant lines for this bug: BUG: kernel NULL pointer dereference, address: 0 [...] RIP: 0010:queue_work_on+0x17/0x40 Code: fd ff ff 44 89 e0 5d 41 5c c3 [...] Call Trace: handle_hpd_rx_irq+0x26e/0x320 [amdgpu] ? _raw_spin_unlock_irq+0x1d/0x30 dm_irq_work_func+0x49/0x60 [amdgpu] process_one_work+0x1e1/0x3d0 [...] -- You are receiving this mail because: You are watching the assignee of the bug.

1 8

[Bug 202445] New: amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
by bugzilla-daemon＠bugzilla.kernel.org 07 Apr '20

07 Apr '20

https://bugzilla.kernel.org/show_bug.cgi?id=202445 Bug ID: 202445 Summary: amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering Product: Drivers Version: 2.5 Kernel Version: 5.0rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: libcg(a)protonmail.com Regression: No linux 5.0rc4 mesa 4aa64940c xf86-video-amdgpu a1b479c hardware: - R9 Fury - Samsung C27HG70 (1020.0 firmware, Freesync Ultimate Engine) I'm running the Unigine Valley benchmark extremely smoothly as long as the framerate stays in between 48-144fps. When it drops below that, I'm observing heavy stuttering and flickering in the darker parts of the image. The flickering also affects the loading screen when frames are rendered very infrequently. -- You are receiving this mail because: You are watching the assignee of the bug.

1 39

Re: [PATCH] dma-buf: support 32bit DMA_BUF_SET_NAME ioctl
by Martin Liu 07 Apr '20

07 Apr '20

On Tue, Jan 14, 2020 at 09:41:01PM +0800, Martin Liu wrote: CC more MLs for winder review. > This commit adds SET_NAME ioctl coversion to > support 32 bit ioctl. > > Signed-off-by: Martin Liu <liumartin(a)google.com> > --- > drivers/dma-buf/dma-buf.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index ce41cd9b758a..a73048b34843 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -25,6 +25,7 @@ > #include <linux/mm.h> > #include <linux/mount.h> > #include <linux/pseudo_fs.h> > +#include <linux/compat.h> > > #include <uapi/linux/dma-buf.h> > #include <uapi/linux/magic.h> > @@ -409,13 +410,32 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) > dma_resv_unlock(dmabuf->resv); > } > > +#ifdef CONFIG_COMPAT > +static long dma_buf_ioctl_compat(struct file *file, unsigned int cmd, > + unsigned long arg) > +{ > + switch (_IOC_NR(cmd)) { > + case _IOC_NR(DMA_BUF_SET_NAME): > + /* Fix up pointer size*/ > + if (_IOC_SIZE(cmd) == sizeof(compat_uptr_t)) { > + cmd &= ~IOCSIZE_MASK; > + cmd |= sizeof(void *) << IOCSIZE_SHIFT; > + } > + break; > + } > + return dma_buf_ioctl(file, cmd, (unsigned long)compat_ptr(arg)); > +} > +#endif > + > static const struct file_operations dma_buf_fops = { > .release = dma_buf_release, > .mmap = dma_buf_mmap_internal, > .llseek = dma_buf_llseek, > .poll = dma_buf_poll, > .unlocked_ioctl = dma_buf_ioctl, > - .compat_ioctl = compat_ptr_ioctl, > +#ifdef CONFIG_COMPAT > + .compat_ioctl = dma_buf_ioctl_compat, > +#endif > .show_fdinfo = dma_buf_show_fdinfo, > }; > > -- > 2.25.0.rc1.283.g88dfdc4193-goog >

3 2

[PATCH] Make the "Reducing compressed framebufer size" message be DRM_INFO_ONCE()
by Peter Jones 07 Apr '20

07 Apr '20

This was sort of annoying me: random:~$ dmesg | tail -1 [523884.039227] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. random:~$ dmesg | grep -c "Reducing the compressed" 47 This patch makes it DRM_INFO_ONCE() just like the similar message farther down in that function is pr_info_once(). Signed-off-by: Peter Jones <pjones(a)redhat.com> --- drivers/gpu/drm/i915/intel_fbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index b431b6733cc..88b013758da 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -585,7 +585,7 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc) if (!ret) goto err_llb; else if (ret > 1) { - DRM_INFO("Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.\n"); + DRM_INFO_ONCE("Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.\n"); } -- 2.17.1

3 2

[PATCH v5 00/25] drm: Kirin driver cleanups to prep for Kirin960 support
by John Stultz 07 Apr '20

07 Apr '20

Sending this out again (apologies!), to address a few issues Sam found. This patchset contains one fix (in the front, so its easier to eventually backport), and a series of changes from YiPing to refactor the kirin drm driver so that it can be used on both kirin620 based devices (like the original HiKey board) as well as kirin960 based devices (like the HiKey960 board). The full kirin960 drm support is still being refactored, but as this base kirin rework was getting to be substantial, I wanted to send out the first chunk, so that the review burden wasn't overwhelming. The full HiKey960 patch stack can be found here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey9… thanks -john New in v5: * Whitespace changes and few logic simplifications to get checkpatch.pl --strict to pass, as noted by Sam * Fix for one of my patches which broke building the kirin driver as a module. Again noted by Sam. Cc: Rongrong Zou <zourongrong(a)gmail.com> Cc: Xinliang Liu <z.liuxinliang(a)hisilicon.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel <dri-devel(a)lists.freedesktop.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Da Lv (1): drm: kirin: Fix for hikey620 display offset problem John Stultz (3): drm: kirin: Remove HISI_KIRIN_DW_DSI config option drm: kirin: Remove unreachable return drm: kirin: Move workqueue to ade_hw_ctx structure Xu YiPing (21): drm: kirin: Remove uncessary parameter indirection drm: kirin: Remove out_format from ade_crtc drm: kirin: Rename ade_plane to kirin_plane drm: kirin: Rename ade_crtc to kirin_crtc drm: kirin: Dynamically allocate the hw_ctx drm: kirin: Move request irq handle in ade hw ctx alloc drm: kirin: Move kirin_crtc, kirin_plane, kirin_format to kirin_drm_drv.h drm: kirin: Reanme dc_ops to kirin_drm_data drm: kirin: Move ade crtc/plane help functions to driver_data drm: kirin: Move channel formats to driver data drm: kirin: Move mode config function to driver_data drm: kirin: Move plane number and primay plane in driver data drm: kirin: Move config max_width and max_height to driver data drm: kirin: Move drm driver to driver data drm: kirin: Add register connect helper functions in drm init drm: kirin: Rename plane_init and crtc_init drm: kirin: Fix dev->driver_data setting drm: kirin: Make driver_data variable non-global drm: kirin: Add alloc_hw_ctx/clean_hw_ctx ops in driver data drm: kirin: Pass driver data to crtc init and plane init drm: kirin: Move ade drm init to kirin drm drv drivers/gpu/drm/hisilicon/kirin/Kconfig | 10 +- drivers/gpu/drm/hisilicon/kirin/Makefile | 3 +- .../gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 1 + .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 351 +++++++----------- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 250 +++++++++---- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 48 ++- 6 files changed, 367 insertions(+), 296 deletions(-) -- 2.17.1

3 28

gitlab.fd.o financial situation and impact on services
by Daniel Vetter 06 Apr '20

06 Apr '20

Hi all, You might have read the short take in the X.org board meeting minutes already, here's the long version. The good news: gitlab.fd.o has become very popular with our communities, and is used extensively. This especially includes all the CI integration. Modern development process and tooling, yay! The bad news: The cost in growth has also been tremendous, and it's breaking our bank account. With reasonable estimates for continued growth we're expecting hosting expenses totalling 75k USD this year, and 90k USD next year. With the current sponsors we've set up we can't sustain that. We estimate that hosting expenses for gitlab.fd.o without any of the CI features enabled would total 30k USD, which is within X.org's ability to support through various sponsorships, mostly through XDC. Note that X.org does no longer sponsor any CI runners themselves, we've stopped that. The huge additional expenses are all just in storing and serving build artifacts and images to outside CI runners sponsored by various companies. A related topic is that with the growth in fd.o it's becoming infeasible to maintain it all on volunteer admin time. X.org is therefore also looking for admin sponsorship, at least medium term. Assuming that we want cash flow reserves for one year of gitlab.fd.o (without CI support) and a trimmed XDC and assuming no sponsor payment meanwhile, we'd have to cut CI services somewhere between May and June this year. The board is of course working on acquiring sponsors, but filling a shortfall of this magnitude is neither easy nor quick work, and we therefore decided to give an early warning as soon as possible. Any help in finding sponsors for fd.o is very much appreciated. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

25 59

[PATCH] drm/panel: samsung: s6e8aa0: Add backlight control support
by Joonas Kylmälä 05 Apr '20

05 Apr '20

This makes the backlight brightness controllable from the userspace. Signed-off-by: Joonas Kylmälä <joonas.kylmala(a)iki.fi> --- drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 82 ++++++++++++++++++++------- 1 file changed, 60 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c index dbced6501204..aa75934f5bed 100644 --- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c +++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c @@ -10,8 +10,12 @@ * Eunchul Kim <chulspro.kim(a)samsung.com> * Tomasz Figa <t.figa(a)samsung.com> * Andrzej Hajda <a.hajda(a)samsung.com> + * + * Derived from panel-samsung-s6e63m0.c: + * Copyright (C) 2019 Paweł Chmiel <pawel.mikolaj.chmiel(a)gmail.com> */ +#include <linux/backlight.h> #include <linux/delay.h> #include <linux/gpio/consumer.h> #include <linux/module.h> @@ -85,6 +89,8 @@ #define AID_2 (0x6) #define AID_3 (0x7) +#define MAX_BRIGHTNESS (GAMMA_LEVEL_NUM - 1) + typedef u8 s6e8aa0_gamma_table[GAMMA_TABLE_LEN]; struct s6e8aa0_variant { @@ -95,6 +101,7 @@ struct s6e8aa0_variant { struct s6e8aa0 { struct device *dev; struct drm_panel panel; + struct backlight_device *bl_dev; struct regulator_bulk_data supplies[2]; struct gpio_desc *reset_gpio; @@ -110,7 +117,6 @@ struct s6e8aa0 { u8 version; u8 id; const struct s6e8aa0_variant *variant; - int brightness; /* This field is tested by functions directly accessing DSI bus before * transfer, transfer is skipped if it is set. In case of transfer @@ -321,9 +327,10 @@ static void s6e8aa0_etc_elvss_control(struct s6e8aa0 *ctx) static void s6e8aa0_elvss_nvm_set_v142(struct s6e8aa0 *ctx) { + struct backlight_device *bd = ctx->bl_dev; u8 br; - switch (ctx->brightness) { + switch (bd->props.brightness) { case 0 ... 6: /* 30cd ~ 100cd */ br = 0xdf; break; @@ -762,24 +769,6 @@ static const struct s6e8aa0_variant s6e8aa0_variants[] = { } }; -static void s6e8aa0_brightness_set(struct s6e8aa0 *ctx) -{ - const u8 *gamma; - - if (ctx->error) - return; - - gamma = ctx->variant->gamma_tables[ctx->brightness]; - - if (ctx->version >= 142) - s6e8aa0_elvss_nvm_set(ctx); - - s6e8aa0_dcs_write(ctx, gamma, GAMMA_TABLE_LEN); - - /* update gamma table. */ - s6e8aa0_dcs_write_seq_static(ctx, 0xf7, 0x03); -} - static void s6e8aa0_panel_init(struct s6e8aa0 *ctx) { s6e8aa0_apply_level_1_key(ctx); @@ -791,7 +780,7 @@ static void s6e8aa0_panel_init(struct s6e8aa0 *ctx) s6e8aa0_panel_cond_set(ctx); s6e8aa0_display_condition_set(ctx); - s6e8aa0_brightness_set(ctx); + backlight_enable(ctx->bl_dev); s6e8aa0_etc_source_control(ctx); s6e8aa0_etc_pentile_control(ctx); s6e8aa0_elvss_nvm_set(ctx); @@ -974,6 +963,53 @@ static int s6e8aa0_parse_dt(struct s6e8aa0 *ctx) return 0; } +static int s6e8aa0_set_brightness(struct backlight_device *bd) +{ + struct s6e8aa0 *ctx = bl_get_data(bd); + const u8 *gamma; + + if (ctx->error) + return; + + gamma = ctx->variant->gamma_tables[bd->props.brightness]; + + if (ctx->version >= 142) + s6e8aa0_elvss_nvm_set(ctx); + + s6e8aa0_dcs_write(ctx, gamma, GAMMA_TABLE_LEN); + + /* update gamma table. */ + s6e8aa0_dcs_write_seq_static(ctx, 0xf7, 0x03); + + return s6e8aa0_clear_error(ctx); +} + +static const struct backlight_ops s6e8aa0_backlight_ops = { + .update_status = s6e8aa0_set_brightness, +}; + +static int s6e8aa0_backlight_register(struct s6e8aa0 *ctx) +{ + struct backlight_properties props = { + .type = BACKLIGHT_RAW, + .brightness = MAX_BRIGHTNESS, + .max_brightness = MAX_BRIGHTNESS + }; + struct device *dev = ctx->dev; + int ret = 0; + + ctx->bl_dev = devm_backlight_device_register(dev, "panel", dev, ctx, + &s6e8aa0_backlight_ops, + &props); + if (IS_ERR(ctx->bl_dev)) { + ret = PTR_ERR(ctx->bl_dev); + DRM_DEV_ERROR(dev, "error registering backlight device (%d)\n", + ret); + } + + return ret; +} + static int s6e8aa0_probe(struct mipi_dsi_device *dsi) { struct device *dev = &dsi->dev; @@ -1015,7 +1051,9 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi) return PTR_ERR(ctx->reset_gpio); } - ctx->brightness = GAMMA_LEVEL_NUM - 1; + ret = s6e8aa0_backlight_register(ctx); + if (ret < 0) + return ret; drm_panel_init(&ctx->panel, dev, &s6e8aa0_drm_funcs, DRM_MODE_CONNECTOR_DSI); -- 2.11.0

4 5

← Newer
1
...
9
10
11
12
13
14
15
...
68
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2020