dri-devel April 2020

dri-devel@lists.freedesktop.org

353 participants
944 discussions

[PATCH v5 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors
by Sean Paul 07 Apr '20

07 Apr '20

From: Sean Paul <seanpaul(a)chromium.org> Hello friends, Another version of HDCP over MST rebased on -tip (pls stop refactoring stuff!). I've also added a couple of fixes to fix bugs found when I did some testing I on a non-CrOS laptop. PTAL, Sean Sean Paul (16): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 117 +++ drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h | 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 624 +-------------- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 712 ++++++++++++++++++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + drivers/gpu/drm/i915/display/intel_hdcp.c | 217 ++++-- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +- include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h | 3 + 16 files changed, 1155 insertions(+), 695 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS

4 20

Re: upstream boot error: KASAN: slab-out-of-bounds Write in virtio_gpu_object_create
by Dmitry Vyukov 07 Apr '20

07 Apr '20

On Mon, Apr 6, 2020 at 8:46 AM syzbot <syzbot+d3a7951ed361037407db(a)syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit: ffc1c20c Merge tag 'for-5.7/dm-changes' of git://git.kerne.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1690471fe00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=d6a1e2f9a9986236 > dashboard link: https://syzkaller.appspot.com/bug?extid=d3a7951ed361037407db > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+d3a7951ed361037407db(a)syzkaller.appspotmail.com +drivers/gpu/drm/virtio/virtgpu_object.c maintainers Now we have both mainline and linux-next boot broken (linux-next is broken for the past 40 days). No testing of new code happens. > NET: Registered protocol family 38 > async_tx: api initialized (async) > Key type asymmetric registered > Asymmetric key parser 'x509' registered > Asymmetric key parser 'pkcs8' registered > Key type pkcs7_test registered > Asymmetric key parser 'tpm_parser' registered > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243) > io scheduler mq-deadline registered > io scheduler kyber registered > io scheduler bfq registered > hgafb: HGA card not detected. > hgafb: probe of hgafb.0 failed with error -22 > usbcore: registered new interface driver udlfb > uvesafb: failed to execute /sbin/v86d > uvesafb: make sure that the v86d helper is installed and executable > uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) > uvesafb: vbe_init() failed with -22 > uvesafb: probe of uvesafb.0 failed with error -22 > vga16fb: mapped to 0x00000000ab381a8e > Console: switching to colour frame buffer device 80x30 > fb0: VGA16 VGA frame buffer device > input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 > ACPI: Power Button [PWRF] > ioatdma: Intel(R) QuickData Technology Driver 5.00 > PCI Interrupt Link [GSIF] enabled at IRQ 21 > PCI Interrupt Link [GSIH] enabled at IRQ 23 > N_HDLC line discipline registered with maxframe=4096 > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > Cyclades driver 2.6 > Initializing Nozomi driver 2.1d > RocketPort device driver module, version 2.09, 12-June-2003 > No rocketport ports found; unloading driver > Non-volatile memory driver v1.3 > Linux agpgart interface v0.103 > [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0 > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1 > usbcore: registered new interface driver udl > [drm] pci: virtio-vga detected at 0000:00:01.0 > fb0: switching to virtiodrmfb from VGA16 VGA > Console: switching to colour VGA+ 80x25 > virtio-pci 0000:00:01.0: vgaarb: deactivate vga console > Console: switching to colour dummy device 80x25 > [drm] features: -virgl +edid > [drm] number of scanouts: 1 > [drm] number of cap sets: 0 > [drm] Initialized virtio_gpu 0.1.0 0 for virtio0 on minor 2 > ================================================================== > BUG: KASAN: slab-out-of-bounds in virtio_gpu_object_shmem_init drivers/gpu/drm/virtio/virtgpu_object.c:151 [inline] > BUG: KASAN: slab-out-of-bounds in virtio_gpu_object_create+0x9f3/0xaa0 drivers/gpu/drm/virtio/virtgpu_object.c:230 > Write of size 8 at addr ffff888027f7a388 by task swapper/0/1 > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-syzkaller #0 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x188/0x20d lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd3/0x315 mm/kasan/report.c:374 > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:506 > kasan_report+0xe/0x20 mm/kasan/common.c:641 > virtio_gpu_object_shmem_init drivers/gpu/drm/virtio/virtgpu_object.c:151 [inline] > virtio_gpu_object_create+0x9f3/0xaa0 drivers/gpu/drm/virtio/virtgpu_object.c:230 > virtio_gpu_gem_create+0xaa/0x1d0 drivers/gpu/drm/virtio/virtgpu_gem.c:42 > virtio_gpu_mode_dumb_create+0x21e/0x360 drivers/gpu/drm/virtio/virtgpu_gem.c:82 > drm_mode_create_dumb+0x27c/0x300 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_client_buffer_create drivers/gpu/drm/drm_client.c:267 [inline] > drm_client_framebuffer_create+0x1b7/0x770 drivers/gpu/drm/drm_client.c:412 > drm_fb_helper_generic_probe+0x1e4/0x810 drivers/gpu/drm/drm_fb_helper.c:2039 > drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1588 [inline] > __drm_fb_helper_initial_config_and_unlock+0xb56/0x11e0 drivers/gpu/drm/drm_fb_helper.c:1746 > drm_fb_helper_initial_config drivers/gpu/drm/drm_fb_helper.c:1841 [inline] > drm_fb_helper_initial_config drivers/gpu/drm/drm_fb_helper.c:1833 [inline] > drm_fbdev_client_hotplug+0x30f/0x580 drivers/gpu/drm/drm_fb_helper.c:2133 > drm_fbdev_generic_setup drivers/gpu/drm/drm_fb_helper.c:2212 [inline] > drm_fbdev_generic_setup+0x18b/0x295 drivers/gpu/drm/drm_fb_helper.c:2185 > virtio_gpu_probe+0x28f/0x2de drivers/gpu/drm/virtio/virtgpu_drv.c:127 > virtio_dev_probe+0x463/0x710 drivers/virtio/virtio.c:248 > really_probe+0x281/0x6d0 drivers/base/dd.c:527 > driver_probe_device+0x104/0x210 drivers/base/dd.c:701 > device_driver_attach+0x108/0x140 drivers/base/dd.c:975 > __driver_attach+0xda/0x240 drivers/base/dd.c:1052 > bus_for_each_dev+0x14b/0x1d0 drivers/base/bus.c:305 > bus_add_driver+0x4a2/0x5a0 drivers/base/bus.c:622 > driver_register+0x1c4/0x330 drivers/base/driver.c:171 > do_one_initcall+0x10a/0x7d0 init/main.c:1152 > do_initcall_level init/main.c:1225 [inline] > do_initcalls init/main.c:1241 [inline] > do_basic_setup init/main.c:1261 [inline] > kernel_init_freeable+0x501/0x5ae init/main.c:1445 > kernel_init+0xd/0x1bb init/main.c:1352 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > > Allocated by task 1: > save_stack+0x1b/0x80 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > __kasan_kmalloc mm/kasan/common.c:515 [inline] > __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:488 > kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551 > kmalloc include/linux/slab.h:555 [inline] > kzalloc include/linux/slab.h:669 [inline] > virtio_gpu_create_object+0x3c/0xe0 drivers/gpu/drm/virtio/virtgpu_object.c:128 > drm_gem_shmem_create+0x83/0x330 drivers/gpu/drm/drm_gem_shmem_helper.c:58 > virtio_gpu_object_create+0xa5/0xaa0 drivers/gpu/drm/virtio/virtgpu_object.c:199 > virtio_gpu_gem_create+0xaa/0x1d0 drivers/gpu/drm/virtio/virtgpu_gem.c:42 > virtio_gpu_mode_dumb_create+0x21e/0x360 drivers/gpu/drm/virtio/virtgpu_gem.c:82 > drm_mode_create_dumb+0x27c/0x300 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_client_buffer_create drivers/gpu/drm/drm_client.c:267 [inline] > drm_client_framebuffer_create+0x1b7/0x770 drivers/gpu/drm/drm_client.c:412 > drm_fb_helper_generic_probe+0x1e4/0x810 drivers/gpu/drm/drm_fb_helper.c:2039 > drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1588 [inline] > __drm_fb_helper_initial_config_and_unlock+0xb56/0x11e0 drivers/gpu/drm/drm_fb_helper.c:1746 > drm_fb_helper_initial_config drivers/gpu/drm/drm_fb_helper.c:1841 [inline] > drm_fb_helper_initial_config drivers/gpu/drm/drm_fb_helper.c:1833 [inline] > drm_fbdev_client_hotplug+0x30f/0x580 drivers/gpu/drm/drm_fb_helper.c:2133 > drm_fbdev_generic_setup drivers/gpu/drm/drm_fb_helper.c:2212 [inline] > drm_fbdev_generic_setup+0x18b/0x295 drivers/gpu/drm/drm_fb_helper.c:2185 > virtio_gpu_probe+0x28f/0x2de drivers/gpu/drm/virtio/virtgpu_drv.c:127 > virtio_dev_probe+0x463/0x710 drivers/virtio/virtio.c:248 > really_probe+0x281/0x6d0 drivers/base/dd.c:527 > driver_probe_device+0x104/0x210 drivers/base/dd.c:701 > device_driver_attach+0x108/0x140 drivers/base/dd.c:975 > __driver_attach+0xda/0x240 drivers/base/dd.c:1052 > bus_for_each_dev+0x14b/0x1d0 drivers/base/bus.c:305 > bus_add_driver+0x4a2/0x5a0 drivers/base/bus.c:622 > driver_register+0x1c4/0x330 drivers/base/driver.c:171 > do_one_initcall+0x10a/0x7d0 init/main.c:1152 > do_initcall_level init/main.c:1225 [inline] > do_initcalls init/main.c:1241 [inline] > do_basic_setup init/main.c:1261 [inline] > kernel_init_freeable+0x501/0x5ae init/main.c:1445 > kernel_init+0xd/0x1bb init/main.c:1352 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > > Freed by task 0: > (stack is not available) > > The buggy address belongs to the object at ffff888027f7a000 > which belongs to the cache kmalloc-1k of size 1024 > The buggy address is located 904 bytes inside of > 1024-byte region [ffff888027f7a000, ffff888027f7a400) > The buggy address belongs to the page: > page:ffffea00009fde80 refcount:1 mapcount:0 mapping:ffff88802c800c40 index:0x0 > flags: 0xfffe0000000200(slab) > raw: 00fffe0000000200 ffffea0000a49408 ffff88802c801850 ffff88802c800c40 > raw: 0000000000000000 ffff888027f7a000 0000000100000002 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff888027f7a280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff888027f7a300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >ffff888027f7a380: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ^ > ffff888027f7a400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff888027f7a480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ================================================================== > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller(a)googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe(a)googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000091056b05a2999f….

3 4

[PATCH v5 0/5] Add support for devices in the Energy Model
by Lukasz Luba 07 Apr '20

07 Apr '20

Hi all, This patch set introduces support for devices in the Energy Model (EM) framework. It will unify the power model for thermal subsystem and make it simpler. The 1st patch refactors EM framework and adds support for devices. The 2nd patch changes dev_pm_opp_of_register_em() in OPP/OF which now should take as an argument struct device pointer. It touches a few trees (OMAP, NXP, Mediatek) updating their CPUfreq drivers to the new interface. Patch 4/5 changes thermal devfreq cooling removing old code for calculating local power table. It simplifies the code and uses EM for requested power calculation. Last patch 5/5 adds EM to Panfrost driver. The patch set is based on linux-next tag next-20200317. I have decided to add a pending patch developed by Matthias [5]. It introduces PM QoS limits in devfreq cooling, to not break the build test. When it lands into thermal/linux-next and then in linux-next, I'll drop it from this series. Changes: v5: - devfreq cooling: rebased on top of pending patch introducing PM QoS limits - devfreq cooling: added Matthias's patch to make this series build check pass - devfreq cooling: removed OPP disable code and switched to PM QoS - devfreq cooling: since thermal code always used a pointer to devfreq_dev_status, switched to work on a local copy and avoid potential race when either busy_time or total_time could change in the background - devfreq cooling: added _normalize_load() and handle all scenarios when busy_time and total_time could have odd values (even raw counters) - Energy Model patch 2/4: removed prints from cpufreq drivers and added print inside dev_pm_opp_of_register_em() - update patch 2/4 description to better reflect upcoming changes - collected ACK from Quentin for patch 1/4 and Reviewed-by from Steven for 4/4 v4 [4]: - devfreq cooling: added two new registration functions, which will take care of registering EM for the device and simplify drivers code (suggested by Robin and Rob) - Energy Model: changed unregistering code, added kref to track usage, added code freeing tables, added helper function - added return value to function dev_pm_opp_of_register_em() and updated CPUFreq drivers code, added debug prints in case of failure - updated comments in devfreq cooling removing statement that only simple_ondemand devfreq governor is supported to work with power extentions - fixed spelling in the documentation (reported by Randy) v3 [3]: - added back the cpumask 'cpus' in the em_perf_domain due potential cache misses - removed _is_cpu_em() since there is no need for it - changed function name from em_pd_energy() to em_cpu_energy(), which is optimized for usage from the scheduler making some assumptions and not validating arguments to speed-up, there is a comment stressing that it should be used only for CPUs em_perf_domain - changed em_get_pd() to em_pd_get() which is now aligned with em_cpu_get() naming - Energy Model: add code which checks if the EM is already registered for the devfreq device - extended comment in em_cpu_get() describing the need for this function - fixed build warning reported on x86 by kbuild test robot in devfreq_cooling.c - updated documentation in the energy-model.rst - changed print messages from 'energy_model' to 'EM' - changed dev_warn to dev_dbg, should calm down test scripts in case the platform has OPPs less efficient in the OPP table (some of them are there for cooling reasons, we shouldn't warn in this case, debug info is enough) v2 [2]: - changed EM API em_register_perf_domain() adding cpumask_t pointer as last argument (which was discussed with Dietmar and Quentin) - removed dependency on PM_OPP, thanks to the cpumask_t argument - removed enum em_type and em->type dependent code - em_get_pd() can handle CPU device as well as devfreq device - updated EM documentation - in devfreq cooling added code which prevents from race condition with devfreq governors which are trying to use OPPs while thermal is in the middle of disabling them. - in devfreq cooling added code which updates state of the devfreq device to avoid working on stale data when governor has not updated it for a long time - in devfreq cooling added backward compatibility frequency table for drivers which did not provide EM - added Steven's Reviewed-by to trace code in thermal - added another CPUFreq driver which needs to be updated to the new API The v1 can be found here [1]. Regards, Lukasz Luba [1] https://lkml.org/lkml/2020/1/16/619 [2] https://lkml.org/lkml/2020/2/6/377 [3] https://lkml.org/lkml/2020/2/21/1910 [4] https://lkml.org/lkml/2020/3/9/471 [5] https://patchwork.kernel.org/patch/11435217/ Lukasz Luba (4): PM / EM: add devices to Energy Model OPP: refactor dev_pm_opp_of_register_em() and update related drivers thermal: devfreq_cooling: Refactor code and switch to use Energy Model drm/panfrost: Register devfreq cooling and attempt to add Energy Model Matthias Kaehlcke (1): thermal: devfreq_cooling: Use PM QoS to set frequency limits Documentation/power/energy-model.rst | 133 ++--- Documentation/scheduler/sched-energy.rst | 2 +- drivers/cpufreq/cpufreq-dt.c | 2 +- drivers/cpufreq/imx6q-cpufreq.c | 2 +- drivers/cpufreq/mediatek-cpufreq.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- drivers/cpufreq/scmi-cpufreq.c | 13 +- drivers/cpufreq/scpi-cpufreq.c | 2 +- drivers/cpufreq/vexpress-spc-cpufreq.c | 2 +- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +- drivers/opp/of.c | 76 +-- drivers/thermal/cpufreq_cooling.c | 12 +- drivers/thermal/devfreq_cooling.c | 536 ++++++++++---------- include/linux/devfreq_cooling.h | 39 +- include/linux/energy_model.h | 111 ++-- include/linux/pm_opp.h | 15 +- include/trace/events/thermal.h | 19 +- kernel/power/energy_model.c | 465 +++++++++++++---- kernel/sched/fair.c | 2 +- kernel/sched/topology.c | 4 +- 21 files changed, 901 insertions(+), 542 deletions(-) -- 2.17.1

4 22

[RESEND 1/2] drm: bridge: adv7511: Enable SPDIF DAI
by Bogdan Togorean 07 Apr '20

07 Apr '20

ADV7511 support I2S or SPDIF as audio input interfaces. This commit enable support for SPDIF. Signed-off-by: Bogdan Togorean <bogdan.togorean(a)analog.com> Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> --- drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c index a428185be2c1..1e9b128d229b 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c @@ -119,6 +119,9 @@ int adv7511_hdmi_hw_params(struct device *dev, void *data, audio_source = ADV7511_AUDIO_SOURCE_I2S; i2s_format = ADV7511_I2S_FORMAT_LEFT_J; break; + case HDMI_SPDIF: + audio_source = ADV7511_AUDIO_SOURCE_SPDIF; + break; default: return -EINVAL; } @@ -175,11 +178,21 @@ static int audio_startup(struct device *dev, void *data) /* use Audio infoframe updated info */ regmap_update_bits(adv7511->regmap, ADV7511_REG_GC(1), BIT(5), 0); + /* enable SPDIF receiver */ + if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF) + regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG, + BIT(7), BIT(7)); + return 0; } static void audio_shutdown(struct device *dev, void *data) { + struct adv7511 *adv7511 = dev_get_drvdata(dev); + + if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF) + regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG, + BIT(7), 0); } static int adv7511_hdmi_i2s_get_dai_id(struct snd_soc_component *component, @@ -213,6 +226,7 @@ static const struct hdmi_codec_pdata codec_data = { .ops = &adv7511_codec_ops, .max_i2s_channels = 2, .i2s = 1, + .spdif = 1, }; int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511) -- 2.17.1

1 1

[RESEND] drm: bridge: adv7511: Fix low refresh rate register for ADV7533/5
by Bogdan Togorean 07 Apr '20

07 Apr '20

For ADV7533 and ADV7535 low refresh rate is selected using bits [3:2] of 0x4a main register. So depending on ADV model write 0xfb or 0x4a register. Fixes: 9c8af882bf12: ("drm: Add adv7511 encoder driver") Signed-off-by: Bogdan Togorean <bogdan.togorean(a)analog.com> --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 87b58c1acff4..2a8fd2b27f0d 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -756,8 +756,13 @@ static void adv7511_mode_set(struct adv7511 *adv7511, else low_refresh_rate = ADV7511_LOW_REFRESH_RATE_NONE; - regmap_update_bits(adv7511->regmap, 0xfb, - 0x6, low_refresh_rate << 1); + if (adv7511->type == ADV7511) + regmap_update_bits(adv7511->regmap, 0xfb, + 0x6, low_refresh_rate << 1); + else + regmap_update_bits(adv7511->regmap, 0x4a, + 0xc, low_refresh_rate << 2); + regmap_update_bits(adv7511->regmap, 0x17, 0x60, (vsync_polarity << 6) | (hsync_polarity << 5)); -- 2.17.1

1 0

[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 1/2] drm/ttm: clean up ttm_trace_dma_map/ttm_trace_dma_unmap
by Huang Rui 07 Apr '20

07 Apr '20

ttm_trace_dma_map/ttm_trace_dma_unmap is never used anymore. Move the pr_fmt prefix into this header. Signed-off-by: Huang Rui <ray.huang(a)amd.com> --- include/drm/ttm/ttm_debug.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/ttm/ttm_debug.h b/include/drm/ttm/ttm_debug.h index b5e460f..bd7cf37 100644 --- a/include/drm/ttm/ttm_debug.h +++ b/include/drm/ttm/ttm_debug.h @@ -27,5 +27,5 @@ /* * Authors: Tom St Denis <tom.stdenis(a)amd.com> */ -extern void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt); -extern void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt); + +#define pr_fmt(fmt) "[TTM] " fmt -- 2.7.4

2 3

[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

Aliases for DRI connectors?
by Matt Hoosier 07 Apr '20

07 Apr '20

I'm searching for some sort of scheme that will let my DRI master query the set of available connectors and select the one carrying a prearranged designation. The problem I'm trying to solve is to allow deploying one standardized userspace component across a fleet of devices that have varying numbers of displays, with the use cases not always driven on the same connector topologically. I had a look around the properties available on my system's DRI connectors, and nothing immediate jumped out at me. Is there a standard connector property that (assuming I can find the right place in DeviceTree or similar to) that would be a good fit for this? -Matt

4 6

[PATCH] drm: plane: Verify that no or all planes have a zpos property
by Laurent Pinchart 07 Apr '20

07 Apr '20

The zpos property is used by userspace to sort the order of planes. While the property is not mandatory for drivers to implement, mixing planes with and without zpos confuses userspace, and shall not be allowed. Clarify this in the documentation and warn at runtime if the drivers mixes planes with and without zpos properties. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> --- drivers/gpu/drm/drm_blend.c | 10 ++++++---- drivers/gpu/drm/drm_plane.c | 9 +++++++++ 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 88eedee018d3..f1dcad96f341 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -135,7 +135,9 @@ * are underneath planes with higher Z position values. Two planes with the * same Z position value have undefined ordering. Note that the Z position * value can also be immutable, to inform userspace about the hard-coded - * stacking of planes, see drm_plane_create_zpos_immutable_property(). + * stacking of planes, see drm_plane_create_zpos_immutable_property(). If + * any plane has a zpos property (either mutable or immutable), then all + * planes shall have a zpos property. * * pixel blend mode: * Pixel blend mode is set up with drm_plane_create_blend_mode_property(). @@ -344,10 +346,10 @@ EXPORT_SYMBOL(drm_rotation_simplify); * should be set to 0 and max to maximal number of planes for given crtc - 1. * * If zpos of some planes cannot be changed (like fixed background or - * cursor/topmost planes), driver should adjust min/max values and assign those - * planes immutable zpos property with lower or higher values (for more + * cursor/topmost planes), drivers shall adjust the min/max values and assign + * those planes immutable zpos properties with lower or higher values (for more * information, see drm_plane_create_zpos_immutable_property() function). In such - * case driver should also assign proper initial zpos values for all planes in + * case drivers shall also assign proper initial zpos values for all planes in * its plane_reset() callback, so the planes will be always sorted properly. * * See also drm_atomic_normalize_zpos(). diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index d6ad60ab0d38..efb9c16ddc21 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -289,6 +289,8 @@ EXPORT_SYMBOL(drm_universal_plane_init); int drm_plane_register_all(struct drm_device *dev) { + unsigned int num_planes = 0; + unsigned int num_zpos = 0; struct drm_plane *plane; int ret = 0; @@ -297,8 +299,15 @@ int drm_plane_register_all(struct drm_device *dev) ret = plane->funcs->late_register(plane); if (ret) return ret; + + if (plane->zpos_property) + num_zpos++; + num_planes++; } + drm_WARN(dev, num_planes != num_zpos, + "Mixing planes with and without zpos property is invalid\n"); + return 0; } -- Regards, Laurent Pinchart

4 3

← Newer
1
...
84
85
86
87
88
89
90
...
95
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2020