kernel oops loading i915 after "x86/asm: Pin sensitive CR4 bits" (873d50d58)
Hello, When I try to build and run the latest mainline kernel, it Oops loading i915 module: BUG: unable to handle page fault for address: 9edc1598 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 1a20c067 P4D 1a20c067 PUD 1a20d063 PMD 800019e000e1 Oops: 0003 [#1] SMP PTI The complete log is attached. Bisection tells "x86/asm: Pin sensitive CR4 bits" (873d50d58) is the first "bad" commit. I can revert it and also "x86/asm: Pin sensitive CR0 bits" (8dbec27a2) to make the kernel "seems to" work. I'm not a kernel expert so I can't tell if there is a bug in Kees' patch, or his patch exploits a bug in i915 or module loader. My CPU is an i3-3217u. If a kdump is helpful I'll try to gather it. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University Jul 10 12:58:52 xry111-laptop kernel: BUG: unable to handle page fault for address: 9edc1598 Jul 10 12:58:52 xry111-laptop kernel: #PF: supervisor write access in kernel mode Jul 10 12:58:52 xry111-laptop kernel: #PF: error_code(0x0003) - permissions violation Jul 10 12:58:52 xry111-laptop kernel: PGD 1a20c067 P4D 1a20c067 PUD 1a20d063 PMD 800019e000e1 Jul 10 12:58:52 xry111-laptop kernel: Oops: 0003 [#1] SMP PTI Jul 10 12:58:52 xry111-laptop kernel: CPU: 2 PID: 151 Comm: systemd-udevd Not tainted 5.2.0+ #54 Jul 10 12:58:52 xry111-laptop kernel: Hardware name: LENOVO 20175/INVALID, BIOS 66CN54WW 01/21/2013 Jul 10 12:58:52 xry111-laptop kernel: RIP: 0010:static_key_set_mod.isra.0+0x10/0x30 Jul 10 12:58:52 xry111-laptop kernel: Code: 48 8b 37 83 e6 03 48 09 c6 48 89 37 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f0 a8 03 75 0d 48 8b 37 83 e6 03 48 09 c6 <48> 89 37 c3 0f 0b 48 8b 37 83 e6 03 48 09 c6 48 89 37 c3 66 66 2e Jul 10 12:58:52 xry111-laptop kernel: RSP: :a606c032bc98 EFLAGS: 00010286 Jul 10 12:58:52 xry111-laptop kernel: RAX: 9981ddce30a0 RBX: 9edc1590 RCX: Jul 10 12:58:52 xry111-laptop kernel: RDX: 0020 RSI: 9981ddce30a0 RDI: 9edc1598 Jul 10 12:58:52 xry111-laptop kernel: RBP: c06f4000 R08: 9981e6003980 R09: 9981ddce30a0 Jul 10 12:58:52 xry111-laptop kernel: R10: R11: 00028b56 R12: c06f8880 Jul 10 12:58:52 xry111-laptop kernel: R13: 9981ddce3080 R14: c06f4008 R15: c06f6dc0 Jul 10 12:58:52 xry111-laptop kernel: FS: 7f992dd9a680() GS:9981e708() knlGS: Jul 10 12:58:52 xry111-laptop kernel: CS: 0010 DS: ES: CR0: 80050033 Jul 10 12:58:52 xry111-laptop kernel: CR2: 9edc1598 CR3: 0002233aa001 CR4: 001606e0 Jul 10 12:58:52 xry111-laptop kernel: Call Trace: Jul 10 12:58:52 xry111-laptop kernel: jump_label_module_notify+0x1e7/0x2b0 Jul 10 12:58:52 xry111-laptop kernel: notifier_call_chain+0x44/0x70 Jul 10 12:58:52 xry111-laptop kernel: blocking_notifier_call_chain+0x43/0x60 Jul 10 12:58:52 xry111-laptop kernel: load_module+0x1bcb/0x2490 Jul 10 12:58:52 xry111-laptop kernel: ? vfs_read+0x11f/0x150 Jul 10 12:58:52 xry111-laptop kernel: ? __do_sys_finit_module+0xbf/0xe0 Jul 10 12:58:52 xry111-laptop kernel: __do_sys_finit_module+0xbf/0xe0 Jul 10 12:58:52 xry111-laptop kernel: do_syscall_64+0x43/0x110 Jul 10 12:58:52 xry111-laptop kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jul 10 12:58:52 xry111-laptop kernel: RIP: 0033:0x7f992e2eeaf9 Jul 10 12:58:52 xry111-laptop kernel: Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 67 73 0d 00 f7 d8 64 89 01 48 Jul 10 12:58:52 xry111-laptop kernel: RSP: 002b:7ffca220d288 EFLAGS: 0246 ORIG_RAX: 0139 Jul 10 12:58:52 xry111-laptop kernel: RAX: ffda RBX: 009b8da0 RCX: 7f992e2eeaf9 Jul 10 12:58:52 xry111-laptop kernel: RDX: RSI: 7f992e464885 RDI: 0010 Jul 10 12:58:52 xry111-laptop kernel: RBP: 0002 R08: R09: 009c45c0 Jul 10 12:58:52 xry111-laptop kernel: R10: 0010 R11: 0246 R12: 7f992e464885 Jul 10 12:58:52 xry111-laptop kernel: R13: R14: 009acc50 R15: 009b8da0 Jul 10 12:58:52 xry111-laptop kernel: Modules linked in: kvm_intel(+) kvm irqbypass hid_sensor_hub crc32_pclmul mfd_core i2c_i801 snd_hda_intel i915(+) intel_gtt snd_hda_codec i2c_algo_bit snd_hwdep snd_hda_core drm_kms_helper snd_pcm syscopyarea sysfillrect sysimgblt fb_sys_fops drm hid_multitouch ideapad_laptop sparse_keymap hid_generic wmi efivarfs Jul 10 12:58:52 xry111-laptop kernel: CR2: 9edc1598 Jul 10 12:58:52 xry111-laptop kernel: ---[ end trace dbeb7e66daa9bdca ]--- Jul 10 12:58:52 xry111-laptop kernel: RIP: 0010:static_key_set_mod.isra.0+0x10/0x30 Jul 10 12:58:52 xry111-laptop kernel: Code: 48 8b 37 83 e6 03 48 09 c6 48 89 37
[PATCH 03/12] drm: aspeed_gfx: Fix misuse of GENMASK macro
Arguments are supposed to be ordered high then low. Signed-off-by: Joe Perches --- drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx.h b/drivers/gpu/drm/aspeed/aspeed_gfx.h index a10358bb61ec..095ea03e5833 100644 --- a/drivers/gpu/drm/aspeed/aspeed_gfx.h +++ b/drivers/gpu/drm/aspeed/aspeed_gfx.h @@ -74,7 +74,7 @@ int aspeed_gfx_create_output(struct drm_device *drm); /* CTRL2 */ #define CRT_CTRL_DAC_ENBIT(0) #define CRT_CTRL_VBLANK_LINE(x)(((x) << 20) & CRT_CTRL_VBLANK_LINE_MASK) -#define CRT_CTRL_VBLANK_LINE_MASK GENMASK(20, 31) +#define CRT_CTRL_VBLANK_LINE_MASK GENMASK(31, 20) /* CRT_HORIZ0 */ #define CRT_H_TOTAL(x) (x) -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] treewide: Fix GENMASK misuses
These GENMASK uses are inverted argument order and the actual masks produced are incorrect. Fix them. Add checkpatch tests to help avoid more misuses too. Joe Perches (12): checkpatch: Add GENMASK tests clocksource/drivers/npcm: Fix misuse of GENMASK macro drm: aspeed_gfx: Fix misuse of GENMASK macro iio: adc: max9611: Fix misuse of GENMASK macro irqchip/gic-v3-its: Fix misuse of GENMASK macro mmc: meson-mx-sdio: Fix misuse of GENMASK macro net: ethernet: mediatek: Fix misuses of GENMASK macro net: stmmac: Fix misuses of GENMASK macro rtw88: Fix misuse of GENMASK macro phy: amlogic: G12A: Fix misuse of GENMASK macro staging: media: cedrus: Fix misuse of GENMASK macro ASoC: wcd9335: Fix misuse of GENMASK macro drivers/clocksource/timer-npcm7xx.c | 2 +- drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 +- drivers/iio/adc/max9611.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 2 +- drivers/mmc/host/meson-mx-sdio.c | 2 +- drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +- drivers/net/ethernet/mediatek/mtk_sgmii.c | 2 +- drivers/net/ethernet/stmicro/stmmac/descs.h | 2 +- drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 4 ++-- drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +- drivers/phy/amlogic/phy-meson-g12a-usb2.c | 2 +- drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- scripts/checkpatch.pl | 15 +++ sound/soc/codecs/wcd-clsh-v2.c| 2 +- 14 files changed, 29 insertions(+), 14 deletions(-) -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] ASoC: rockchip: rockchip-max98090: Add node for HDMI
On Wed, Jul 10, 2019 at 4:01 AM Rob Herring wrote:
>
> On Mon, Jun 03, 2019 at 12:32:49PM +0800, Cheng-Yi Chiang wrote:
> > Let user specify HDMI node so machine driver can use it to let codec
> > driver register callback on correct hdmi-notifier.
> >
> > Signed-off-by: Cheng-Yi Chiang
> > ---
> > Documentation/devicetree/bindings/sound/rockchip-max98090.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> > b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> > index a805aa99ad75..dae57c14864e 100644
> > --- a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> > +++ b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> > @@ -7,6 +7,7 @@ Required properties:
> >connected to the CODEC
> > - rockchip,audio-codec: The phandle of the MAX98090 audio codec
> > - rockchip,headset-codec: The phandle of Ext chip for jack detection
> > +- rockchip,hdmi: The phandle of HDMI node for HDMI jack detection
> >
> > Example:
> >
> > @@ -16,4 +17,5 @@ sound {
> > rockchip,i2s-controller = <>;
> > rockchip,audio-codec = <>;
> > rockchip,headset-codec = <>;
> > + rockchip,hdmi= <>;
>
> space^
>
> With that,
>
> Acked-by: Rob Herring
>
Hi Rob,
Thank you for the review.
But I have changed the approach in v2 so there is no need for machine
driver to expose this property.
Thanks!
> > };
> > --
> > 2.22.0.rc1.257.g3120a18244-goog
> >
Re: [PATCH v2] gpu/drm_memory: fix a few warnings
> On Jul 8, 2019, at 1:57 PM, Thomas Gleixner wrote: > > On Mon, 8 Jul 2019, Qian Cai wrote: >> On Mon, 2019-07-08 at 15:21 -0400, Ilia Mirkin wrote: -/** +// SPDX-License-Identifier: MIT +/* * \file drm_memory.c * Memory management wrappers for DRM * @@ -12,25 +13,6 @@ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. * All Rights Reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR >>> >>> This talks about VA Linux Systems and/or its suppliers, while the MIT >>> licence talks about authors or copyright holders. > > That's looks lika a valid substitution and does not change the meaning of > the license, AFAICT. As of the 3.6 release of the SPDX License List, we will have added markup to denote that the name in the disclaimer can be changed and still considered a match. This is a common scenario in other licenses (like the BSD family), but I don’t think we’d come across it until the work on the kernel and adding SPDX identifiers. So, yes, MIT would be the correct SPDX identifier here as of 3.6 (which will be posted in a few days). For reference, the SPDX License List matching guidelines can be found here: https://spdx.org/spdx-license-list/matching-guidelines - see Guideline 2.1.3 specifically. Replaceable text is marked up in the master files that comprise the SPDX License List according the the XML schema and then displayed in color coded text on the website pages (see, for example, BSD-3-Clause - https://spdx.org/licenses/BSD-3-Clause.html Of course, if anyone finds any other license text that deserves this kind of accommodation, you can always make a PR here: https://github.com/spdx/license-list-XML :) thanks, Jilayne SPDX legal team co-lead
Re: [PATCH v7 06/18] kbuild: enable building KUnit
On Tue, Jul 9, 2019 at 3:34 PM Brendan Higgins wrote: > > KUnit is a new unit testing framework for the kernel and when used is > built into the kernel as a part of it. Add KUnit to the root Kconfig and > Makefile to allow it to be actually built. > > Signed-off-by: Brendan Higgins > Cc: Masahiro Yamada > Cc: Michal Marek > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Logan Gunthorpe > --- > Kconfig | 2 ++ > Makefile | 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Kconfig b/Kconfig > index 48a80beab6853..10428501edb78 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -30,3 +30,5 @@ source "crypto/Kconfig" > source "lib/Kconfig" > > source "lib/Kconfig.debug" > + > +source "kunit/Kconfig" > diff --git a/Makefile b/Makefile > index 3e4868a6498b2..60cf4f0813e0d 100644 > --- a/Makefile > +++ b/Makefile > @@ -991,7 +991,7 @@ endif > PHONY += prepare0 > > ifeq ($(KBUILD_EXTMOD),) > -core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ > +core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ kunit/ > > vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ > $(core-y) $(core-m) $(drivers-y) $(drivers-m) \ > -- > 2.22.0.410.gd8fdbe21b5-goog This is so trivial, and do not need to get ack from me. Just a nit. When CONFIG_KUNIT is disable, is there any point in descending into kunit/ ? core-$(CONFIG_KUNIT) += kunit/ ... might be useful to skip kunit/ entirely. If you look at the top-level Makefile, some entries are doing this: init-y := init/ drivers-y := drivers/ sound/ drivers-$(CONFIG_SAMPLES) += samples/ drivers-$(CONFIG_KERNEL_HEADER_TEST) += include/ net-y := net/ libs-y := lib/ core-y := usr/ -- Best Regards Masahiro Yamada
[pull] amdgpu, amdkfd drm-next-5.3
Hi Dave, Daniel, Fixes for 5.3. Mostly fixes for Navi10 and a few other odds and ends. Also contains a patch to ease the merge with hmm. Trivial merge fix when the trees are merged: diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -783,7 +783,7 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages) 0 : range->flags[HMM_PFN_WRITE]; range->pfn_flags_mask = 0; range->pfns = pfns; - hmm_range_register(range, mm, start, + hmm_range_register(range, mirror, start, start + ttm->num_pages * PAGE_SIZE, PAGE_SHIFT); The following changes since commit 440e80ce02cde7b810e4eb555768c2d77e7a27c8: drm/amd/display: fix a couple of spelling mistakes (2019-06-27 11:22:57 -0500) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.3-2019-07-09 for you to fetch changes up to 7f963d9f69bf28d639013630da30d7a4c95edd5d: drm/amdgpu/navi10: add uclk activity sensor (2019-07-09 17:43:36 -0500) drm-next-5.3-2019-07-09: amdgpu: - GPU reset for navi10 - Powerplay fixes for navi10 - GFX fixes for navi10 - Prepare for hmm_range_register API change - XGMI fixes - clang warning fixes - Fixes for various kconfig scenarios - Misc fixes and cleanups amdkfd: - Add workaround for soft hangs with oversubscribed runlists - Remove duplicated pcie atomics request Alex Deucher (8): drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZE drm/amdgpu/gfx10: use reset default for PA_SC_FIFO_SIZE drm/amdgpu/display: fix interrupt client id for navi drm/amdgpu: properly guard DC support in navi code drm/amdgpu/psp11: simplify the ucode register logic drm/amdgpu: add missing documentation on new module parameters drm/amdgpu: properly guard the generic discovery code drm/amdgpu/navi10: add uclk activity sensor Arnd Bergmann (4): amdgpu: make pmu support optional drm/amd/display: dcn20: include linux/delay.h drm/amd/powerplay: vega20: fix uninitialized variable use drm/amd/display: avoid 64-bit division Evan Quan (2): drm/amdgpu: fix MGPU fan boost enablement for XGMI reset drm/amd/powerplay: use hardware fan control if no powerplay fan table Felix Kuehling (5): drm/amdkfd: Print a warning when the runlist becomes oversubscribed drm/amdgpu: Use FENCE_OWNER_KFD in process_sync_pds_resv drm/amdgpu: Fix tracking of invalid userptrs drm/amdkfd: Add chained_runlist_idle_disable flag to pm4_mes_runlist drm/amdkfd: Disable idle optimization for chained runlist Flora Cui (1): drm/amdgpu: fix scheduler timeout calc Fuqian Huang (1): drm/amdgpu: Use kmemdup rather than duplicating its implementation Jack Xiao (5): drm/amdgpu: add field indicating if has PCIE atomics support drm/amdgpu: enable PCIE atomics ops support drm/amdkfd: remove duplicated PCIE atomics request drm/amdkfd: remove an unused variable drm/amd/powerplay: increase waiting time for smu response Kevin Wang (3): drm/amd/powerplay: add baco smu reset function for smu11 drm/amdgpu: add mode1 (psp) reset for navi asic drm/amd/powerplay: add temperature sensor support for navi10 Lyude Paul (1): drm/amdgpu: Don't skip display settings in hwmgr_resume() Marek Olšák (3): drm/amdgpu: fix transform feedback GDS hang on gfx10 (v2) drm/amdgpu: handle AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID on gfx10 drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback Nathan Chancellor (4): drm/amdgpu/mes10.1: Fix header guard drm/amd/powerplay: Use memset to initialize metrics structs drm/amd/powerplay: Zero initialize freq in smu_v11_0_get_current_clk_freq drm/amd/powerplay: Zero initialize current_rpm in vega20_get_fan_speed_percent Philip Yang (1): drm/amdgpu: Prepare for hmm_range_register API change (v2) Yrjan Skrimstad (1): drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking tiancyin (1): drm/amd/powerplay: update smu11_driver_if_navi10.h xinhui pan (1): drm/amdgpu: Disable ras features on all IPs before gpu reset drivers/gpu/drm/amd/amdgpu/Makefile| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 38 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 26 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h| 3 +-
Re: [PATCH v7 08/18] objtool: add kunit_try_catch_throw to the noreturn list
On Mon, Jul 08, 2019 at 11:30:13PM -0700, Brendan Higgins wrote: > Fix the following warning seen on GCC 7.3: > kunit/test-test.o: warning: objtool: kunit_test_unsuccessful_try() falls > through to next function kunit_test_catch() > > kunit_try_catch_throw is a function added in the following patch in this > series; it allows KUnit, a unit testing framework for the kernel, to > bail out of a broken test. As a consequence, it is a new __noreturn > function that objtool thinks is broken (as seen above). So fix this > warning by adding kunit_try_catch_throw to objtool's noreturn list. > > Reported-by: kbuild test robot > Signed-off-by: Brendan Higgins > Link: https://www.spinics.net/lists/linux-kbuild/msg21708.html > Cc: Josh Poimboeuf > Cc: Peter Zijlstra > --- > tools/objtool/check.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 172f991957269..98db5fe85c797 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -134,6 +134,7 @@ static int __dead_end_function(struct objtool_file *file, > struct symbol *func, > "usercopy_abort", > "machine_real_restart", > "rewind_stack_do_exit", > + "kunit_try_catch_throw", > }; > > if (func->bind == STB_WEAK) > -- > 2.22.0.410.gd8fdbe21b5-goog > Acked-by: Josh Poimboeuf -- Josh
[PATCH v7 2/4] drm/panel: set display info in panel attach
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function. These values
are stored from probe in the drm_panel struct.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 28
include/drm/drm_panel.h | 14 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 169bab54d52d..ca01095470a9 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
*/
int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
{
+ struct drm_display_info *info;
+
if (panel->connector)
return -EBUSY;
panel->connector = connector;
panel->drm = connector->dev;
+ info = >display_info;
+ info->width_mm = panel->width_mm;
+ info->height_mm = panel->height_mm;
+ info->bpc = panel->bpc;
+ info->panel_orientation = panel->orientation;
+ info->bus_flags = panel->bus_flags;
+ if (panel->bus_formats)
+ drm_display_info_set_bus_formats(>display_info,
+panel->bus_formats,
+panel->num_bus_formats);
return 0;
}
@@ -128,6 +140,22 @@ EXPORT_SYMBOL(drm_panel_attach);
*/
int drm_panel_detach(struct drm_panel *panel)
{
+ struct drm_display_info *info;
+
+ if (!panel->connector)
+ goto out;
+
+ info = >connector->display_info;
+ info->width_mm = 0;
+ info->height_mm = 0;
+ info->bpc = 0;
+ info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ info->bus_flags = 0;
+ kfree(info->bus_formats);
+ info->bus_formats = NULL;
+ info->num_bus_formats = 0;
+
+out:
panel->connector = NULL;
panel->drm = NULL;
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index fc7da55f41d9..a6a881b987dd 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -39,6 +39,8 @@ enum drm_panel_orientation;
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
+ * @detach: detach panel->connector (clear internal state, etc.)
+ * @attach: attach panel->connector (update internal state, etc.)
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
@@ -95,6 +97,18 @@ struct drm_panel {
const struct drm_panel_funcs *funcs;
+ /*
+* panel information to be set in the connector when the panel is
+* attached.
+*/
+ unsigned int width_mm;
+ unsigned int height_mm;
+ unsigned int bpc;
+ int orientation;
+ const u32 *bus_formats;
+ unsigned int num_bus_formats;
+ u32 bus_flags;
+
struct list_head list;
};
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v7 3/4] drm/connector: Split out orientation quirk detection
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connector.c | 45 ++---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
include/drm/drm_connector.h | 2 ++
4 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3f2cf7eae9c..52777d647494 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1892,31 +1892,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
* drm_connector_init_panel_orientation_property -
* initialize the connecters panel_orientation property
* @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
*
* This function should only be called for built-in panels, after setting
* connector->display_info.panel_orientation first (if known).
*
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * This function will check if the panel_orientation is not
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
+ * orientation" property to the connector.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_init_panel_orientation_property(
- struct drm_connector *connector, int width, int height)
+ struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_display_info *info = >display_info;
struct drm_property *prop;
- int orientation_quirk;
-
- orientation_quirk = drm_get_panel_orientation_quirk(width, height);
- if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
- info->panel_orientation = orientation_quirk;
if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
@@ -1939,6 +1931,35 @@ int drm_connector_init_panel_orientation_property(
}
EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+/**
+ * drm_connector_init_panel_orientation_property_quirk -
+ * initialize the connecters panel_orientation property with a quirk
+ * override
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property_quirk(
+ struct drm_connector *connector, int width, int height)
+{
+ int orientation_quirk;
+
+ orientation_quirk = drm_get_panel_orientation_quirk(width, height);
+ if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+ connector->display_info.panel_orientation = orientation_quirk;
+
+ return drm_connector_init_panel_orientation_property(connector);
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property_quirk);
+
int drm_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0bdb7ecc5a81..975196c86e50 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7063,8 +7063,8 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
intel_panel_setup_backlight(connector, pipe);
if (fixed_mode)
- drm_connector_init_panel_orientation_property(
- connector, fixed_mode->hdisplay, fixed_mode->vdisplay);
+ drm_connector_init_panel_orientation_property_quirk(connector,
+ fixed_mode->hdisplay, fixed_mode->vdisplay);
return true;
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index e272d826210a..dd7fa806f95c 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1662,7
[PATCH v7 1/4] drm/panel: Add helper for reading DT rotation
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 43 +
include/drm/drm_panel.h | 9
2 files changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index dbd5b873e8f2..169bab54d52d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -172,6 +172,49 @@ struct drm_panel *of_drm_find_panel(const struct
device_node *np)
return ERR_PTR(-EPROBE_DEFER);
}
EXPORT_SYMBOL(of_drm_find_panel);
+
+/**
+ * of_drm_get_panel_orientation - look up the orientation of the panel through
+ * the "rotation" binding from a device tree node
+ * @np: device tree node of the panel
+ * @orientation: orientation enum to be filled in
+ *
+ * Looks up the rotation of a panel in the device tree. The orientation of the
+ * panel is expressed as a property name "rotation" in the device tree. The
+ * rotation in the device tree is counter clockwise.
+ *
+ * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or the
+ * rotation property doesn't exist. -EERROR otherwise.
+ */
+int of_drm_get_panel_orientation(const struct device_node *np,
+enum drm_panel_orientation *orientation)
+{
+ int rotation, ret;
+
+ ret = of_property_read_u32(np, "rotation", );
+ if (ret == -EINVAL) {
+ /* Don't return an error if there's no rotation property. */
+ *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ return 0;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ if (rotation == 0)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+ else if (rotation == 90)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+ else if (rotation == 180)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+ else if (rotation == 270)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_drm_get_panel_orientation);
#endif
MODULE_AUTHOR("Thierry Reding ");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 8c738c0e6e9f..fc7da55f41d9 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -33,6 +33,8 @@ struct drm_device;
struct drm_panel;
struct display_timing;
+enum drm_panel_orientation;
+
/**
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
@@ -197,11 +199,18 @@ int drm_panel_detach(struct drm_panel *panel);
#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
struct drm_panel *of_drm_find_panel(const struct device_node *np);
+int of_drm_get_panel_orientation(const struct device_node *np,
+enum drm_panel_orientation *orientation);
#else
static inline struct drm_panel *of_drm_find_panel(const struct device_node *np)
{
return ERR_PTR(-ENODEV);
}
+static inline int of_drm_get_panel_orientation(const struct device_node *np,
+ enum drm_panel_orientation *orientation)
+{
+ return -ENODEV;
+}
#endif
#endif
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v7 0/4] Panel rotation patches
This adds the plumbing for reading panel rotation from the devicetree and sets up adding a panel property for the panel orientation on Mediatek SoCs when a rotation is present. v7 changes: -forgot to add static inline v6 changes: -added enum declaration to drm_panel.h header v5 changes: -rebased v4 changes: -fixed some changes made to the i915 driver -clarified comments on of orientation helper v3 changes: -changed from attach/detach callbacks to directly setting fixed panel values in drm_panel_attach -removed update to Documentation -added separate function for quirked panel orientation property init v2 changes: fixed build errors in i915 Derek Basehore (4): drm/panel: Add helper for reading DT rotation drm/panel: set display info in panel attach drm/connector: Split out orientation quirk detection drm/mtk: add panel orientation property drivers/gpu/drm/drm_connector.c| 45 ++- drivers/gpu/drm/drm_panel.c| 70 ++ drivers/gpu/drm/i915/intel_dp.c| 4 +- drivers/gpu/drm/i915/vlv_dsi.c | 5 +-- drivers/gpu/drm/mediatek/mtk_dsi.c | 8 include/drm/drm_connector.h| 2 + include/drm/drm_panel.h| 21 + 7 files changed, 138 insertions(+), 17 deletions(-) -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v7 4/4] drm/mtk: add panel orientation property
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b91c4616644a..2920458ae2fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -790,10 +790,18 @@ static int mtk_dsi_create_connector(struct drm_device
*drm, struct mtk_dsi *dsi)
DRM_ERROR("Failed to attach panel to drm\n");
goto err_connector_cleanup;
}
+
+ ret = drm_connector_init_panel_orientation_property(>conn);
+ if (ret) {
+ DRM_ERROR("Failed to init panel orientation\n");
+ goto err_panel_detach;
+ }
}
return 0;
+err_panel_detach:
+ drm_panel_detach(dsi->panel);
err_connector_cleanup:
drm_connector_cleanup(>conn);
return ret;
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH V3] drm/vkms: Add support for vkms work without vblank
Currently, vkms only work with enabled VBlank. This patch adds another
operation model that allows vkms to work without VBlank support. In this
scenario, vblank signaling is faked by calling drm_send_vblank_event()
in vkms_crtc_atomic_flush(); this approach works due to the
drm_vblank_get() == 0 checking.
Changes since V2:
- Rebase
Changes since V1:
Daniel Vetter:
- Change module parameter name from disablevblank to virtual_hw
- Improve parameter description
- Improve commit message
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
drivers/gpu/drm/vkms/vkms_drv.c | 13 +++--
drivers/gpu/drm/vkms/vkms_drv.h | 2 ++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 49a8ec2cb1c1..a0c75b8c4335 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -207,12 +207,22 @@ static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+
+ if (vkms_out->disable_vblank)
+ return;
+
drm_crtc_vblank_on(crtc);
}
static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+
+ if (vkms_out->disable_vblank)
+ return;
+
drm_crtc_vblank_off(crtc);
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 152d7de24a76..542a002ef9d5 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -34,6 +34,11 @@ bool enable_writeback;
module_param_named(enable_writeback, enable_writeback, bool, 0444);
MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector");
+bool virtual_hw;
+module_param_named(virtual_hw, virtual_hw, bool, 0444);
+MODULE_PARM_DESC(virtual_hw,
+"Enable virtual hardware mode (disables vblanks and
immediately completes flips)");
+
static const struct file_operations vkms_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -154,9 +159,13 @@ static int __init vkms_init(void)
if (ret)
goto out_unregister;
- vkms_device->drm.irq_enabled = true;
+ vkms_device->output.disable_vblank = virtual_hw;
+ vkms_device->drm.irq_enabled = !virtual_hw;
+
+ if (virtual_hw)
+ DRM_INFO("Virtual hardware mode enabled");
- ret = drm_vblank_init(_device->drm, 1);
+ ret = (virtual_hw) ? 0 : drm_vblank_init(_device->drm, 1);
if (ret) {
DRM_ERROR("Failed to vblank\n");
goto out_fini;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 9ff2cd4ebf81..256e5e65c947 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -21,6 +21,7 @@
extern bool enable_cursor;
extern bool enable_writeback;
+extern bool virtual_hw;
struct vkms_composer {
struct drm_framebuffer fb;
@@ -69,6 +70,7 @@ struct vkms_output {
struct drm_connector connector;
struct drm_writeback_connector wb_connector;
struct hrtimer vblank_hrtimer;
+ bool disable_vblank;
ktime_t period_ns;
struct drm_pending_vblank_event *event;
/* ordered wq for composer_work */
--
2.21.0
signature.asc
Description: PGP signature
[PATCH 2/2] drm/vkms: Use alpha channel for blending cursor with primary
Currently, the blend function overwriting the cursor value into the
primary plane. This patch utilizes the alpha value for a fully
transparent blend of the cursor (vaddr_src) with primary (vaddr_dst)
instead of overwriting it in blend().
Cc: Haneen Mohammed
Cc: Mamta Shukla
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_composer.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index fb106964d8bf..bb758a5131a4 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -26,6 +26,17 @@ static void set_pixel(int x, int y, u8 *buffer,
*dst = value;
}
+static u32 apply_alpha(u32 src, u32 dst)
+{
+ u8 alpha;
+ u32 k;
+
+ alpha = src >> 24;
+ alpha = (alpha + 1) >> 8;
+ k = (alpha << 24) - alpha;
+ return (k & src) | (~k & dst);
+}
+
/**
* compute_crc - Compute CRC value on output frame
*
@@ -89,15 +100,19 @@ static void blend(void *vaddr_dst, void *vaddr_src,
int y_limit = y_src + h_dst;
int x_limit = x_src + w_dst;
- u32 pixel_src;
+ u32 pixel_src, pixel_dst, new_pixel;
for (y = y_src, i_dst = y_dst; y < y_limit; ++y) {
for (x = x_src, j_dst = x_dst; x < x_limit; ++x) {
pixel_src = get_pixel_from_buffer(x, y,
vaddr_src,
src_composer);
- set_pixel(j_dst, i_dst, vaddr_dst, dest_composer,
- pixel_src);
+ pixel_dst = get_pixel_from_buffer(j_dst, i_dst,
+ vaddr_dst,
+ dst_composer);
+ new_pixel = apply_alpha(pixel_src, pixel_dst);
+ set_pixel(j_dst, i_dst, vaddr_dst, dst_composer,
+ new_pixel);
j_dst++;
}
i_dst++;
--
2.21.0
signature.asc
Description: PGP signature
[PATCH 1/2] drm/vkms: Rework blend function
For combining the cursor into the primary plane, vkms invokes a function
named blend which iterates in both buffers and ends up by copying the
cursor into the primary buffer. This patch, rework part of the blend
function to prepare it for using the alpha channel for blending.
Cc: Haneen Mohammed
Cc: Mamta Shukla
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_composer.c | 39 +---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 2317803e7320..fb106964d8bf 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -15,6 +15,17 @@ static u32 get_pixel_from_buffer(int x, int y, const u8
*buffer,
return *(u32 *)[src_offset];
}
+static void set_pixel(int x, int y, u8 *buffer,
+ const struct vkms_composer *composer, const u32 value)
+{
+ int offset = composer->offset + (y * composer->pitch)
+ + (x * composer->cpp);
+ u32 *dst;
+
+ dst = (u32 *)[offset];
+ *dst = value;
+}
+
/**
* compute_crc - Compute CRC value on output frame
*
@@ -50,7 +61,7 @@ static uint32_t compute_crc(const u8 *vaddr,
* blend - belnd value at vaddr_src with value at vaddr_dst
* @vaddr_dst: destination address
* @vaddr_src: source address
- * @dest_composer: destination framebuffer's metadata
+ * @dst_composer: destination framebuffer's metadata
* @src_composer: source framebuffer's metadata
*
* Blend value at vaddr_src with value at vaddr_dst.
@@ -62,11 +73,10 @@ static uint32_t compute_crc(const u8 *vaddr,
* instead of overwriting it.
*/
static void blend(void *vaddr_dst, void *vaddr_src,
- struct vkms_composer *dest_composer,
+ struct vkms_composer *dst_composer,
struct vkms_composer *src_composer)
{
- int i, j, j_dst, i_dst;
- int offset_src, offset_dst;
+ int y, x, j_dst, i_dst;
int x_src = src_composer->src.x1 >> 16;
int y_src = src_composer->src.y1 >> 16;
@@ -79,17 +89,16 @@ static void blend(void *vaddr_dst, void *vaddr_src,
int y_limit = y_src + h_dst;
int x_limit = x_src + w_dst;
- for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
- for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
- offset_dst = dest_composer->offset
-+ (i_dst * dest_composer->pitch)
-+ (j_dst++ * dest_composer->cpp);
- offset_src = src_composer->offset
-+ (i * src_composer->pitch)
-+ (j * src_composer->cpp);
-
- memcpy(vaddr_dst + offset_dst,
- vaddr_src + offset_src, sizeof(u32));
+ u32 pixel_src;
+
+ for (y = y_src, i_dst = y_dst; y < y_limit; ++y) {
+ for (x = x_src, j_dst = x_dst; x < x_limit; ++x) {
+ pixel_src = get_pixel_from_buffer(x, y,
+ vaddr_src,
+ src_composer);
+ set_pixel(j_dst, i_dst, vaddr_dst, dest_composer,
+ pixel_src);
+ j_dst++;
}
i_dst++;
}
--
2.21.0
signature.asc
Description: PGP signature
[PATCH 0/2] drm/vkms: Use alpha value for blending
The first patch of this series reworks part of the blend function to improve the readability and also for preparing it for using alpha value. The second patch updates the blend function for applying alpha value for a fully transparent blend. After applying this patchset, pipe-a-cursor-alpha-transparent in kms_cursor_crc start to pass. This patchset depends on: https://patchwork.freedesktop.org/series/61738/ Rodrigo Siqueira (2): drm/vkms: Rework blend function drm/vkms: Use alpha channel for blending cursor with primary drivers/gpu/drm/vkms/vkms_composer.c | 54 1 file changed, 39 insertions(+), 15 deletions(-) -- 2.21.0 signature.asc Description: PGP signature
[Bug 202799] amd/dc: right monitor sometimes never comes back up on dual-display setup after locking session
https://bugzilla.kernel.org/show_bug.cgi?id=202799 --- Comment #10 from Clément Guérin (li...@protonmail.com) --- This is still a problem on Linux 5.2. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/4] drm/panel: Add helper for reading DT rotation
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 43 +
include/drm/drm_panel.h | 9
2 files changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index dbd5b873e8f2..169bab54d52d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -172,6 +172,49 @@ struct drm_panel *of_drm_find_panel(const struct
device_node *np)
return ERR_PTR(-EPROBE_DEFER);
}
EXPORT_SYMBOL(of_drm_find_panel);
+
+/**
+ * of_drm_get_panel_orientation - look up the orientation of the panel through
+ * the "rotation" binding from a device tree node
+ * @np: device tree node of the panel
+ * @orientation: orientation enum to be filled in
+ *
+ * Looks up the rotation of a panel in the device tree. The orientation of the
+ * panel is expressed as a property name "rotation" in the device tree. The
+ * rotation in the device tree is counter clockwise.
+ *
+ * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or the
+ * rotation property doesn't exist. -EERROR otherwise.
+ */
+int of_drm_get_panel_orientation(const struct device_node *np,
+enum drm_panel_orientation *orientation)
+{
+ int rotation, ret;
+
+ ret = of_property_read_u32(np, "rotation", );
+ if (ret == -EINVAL) {
+ /* Don't return an error if there's no rotation property. */
+ *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ return 0;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ if (rotation == 0)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+ else if (rotation == 90)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+ else if (rotation == 180)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+ else if (rotation == 270)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_drm_get_panel_orientation);
#endif
MODULE_AUTHOR("Thierry Reding ");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 8c738c0e6e9f..a18c59f136ab 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -33,6 +33,8 @@ struct drm_device;
struct drm_panel;
struct display_timing;
+enum drm_panel_orientation;
+
/**
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
@@ -197,11 +199,18 @@ int drm_panel_detach(struct drm_panel *panel);
#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
struct drm_panel *of_drm_find_panel(const struct device_node *np);
+int of_drm_get_panel_orientation(const struct device_node *np,
+enum drm_panel_orientation *orientation);
#else
static inline struct drm_panel *of_drm_find_panel(const struct device_node *np)
{
return ERR_PTR(-ENODEV);
}
+int of_drm_get_panel_orientation(const struct device_node *np,
+enum drm_panel_orientation *orientation)
+{
+ return -ENODEV;
+}
#endif
#endif
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v6 3/4] drm/connector: Split out orientation quirk detection
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connector.c | 45 ++---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
include/drm/drm_connector.h | 2 ++
4 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3f2cf7eae9c..52777d647494 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1892,31 +1892,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
* drm_connector_init_panel_orientation_property -
* initialize the connecters panel_orientation property
* @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
*
* This function should only be called for built-in panels, after setting
* connector->display_info.panel_orientation first (if known).
*
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * This function will check if the panel_orientation is not
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
+ * orientation" property to the connector.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_init_panel_orientation_property(
- struct drm_connector *connector, int width, int height)
+ struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_display_info *info = >display_info;
struct drm_property *prop;
- int orientation_quirk;
-
- orientation_quirk = drm_get_panel_orientation_quirk(width, height);
- if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
- info->panel_orientation = orientation_quirk;
if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
@@ -1939,6 +1931,35 @@ int drm_connector_init_panel_orientation_property(
}
EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+/**
+ * drm_connector_init_panel_orientation_property_quirk -
+ * initialize the connecters panel_orientation property with a quirk
+ * override
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property_quirk(
+ struct drm_connector *connector, int width, int height)
+{
+ int orientation_quirk;
+
+ orientation_quirk = drm_get_panel_orientation_quirk(width, height);
+ if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+ connector->display_info.panel_orientation = orientation_quirk;
+
+ return drm_connector_init_panel_orientation_property(connector);
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property_quirk);
+
int drm_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8f7188d71d08..45b637419085 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7068,8 +7068,8 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
intel_panel_setup_backlight(connector, pipe);
if (fixed_mode)
- drm_connector_init_panel_orientation_property(
- connector, fixed_mode->hdisplay, fixed_mode->vdisplay);
+ drm_connector_init_panel_orientation_property_quirk(connector,
+ fixed_mode->hdisplay, fixed_mode->vdisplay);
return true;
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index e272d826210a..dd7fa806f95c 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1662,7
[PATCH v6 2/4] drm/panel: set display info in panel attach
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function. These values
are stored from probe in the drm_panel struct.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 28
include/drm/drm_panel.h | 14 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 169bab54d52d..ca01095470a9 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
*/
int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
{
+ struct drm_display_info *info;
+
if (panel->connector)
return -EBUSY;
panel->connector = connector;
panel->drm = connector->dev;
+ info = >display_info;
+ info->width_mm = panel->width_mm;
+ info->height_mm = panel->height_mm;
+ info->bpc = panel->bpc;
+ info->panel_orientation = panel->orientation;
+ info->bus_flags = panel->bus_flags;
+ if (panel->bus_formats)
+ drm_display_info_set_bus_formats(>display_info,
+panel->bus_formats,
+panel->num_bus_formats);
return 0;
}
@@ -128,6 +140,22 @@ EXPORT_SYMBOL(drm_panel_attach);
*/
int drm_panel_detach(struct drm_panel *panel)
{
+ struct drm_display_info *info;
+
+ if (!panel->connector)
+ goto out;
+
+ info = >connector->display_info;
+ info->width_mm = 0;
+ info->height_mm = 0;
+ info->bpc = 0;
+ info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ info->bus_flags = 0;
+ kfree(info->bus_formats);
+ info->bus_formats = NULL;
+ info->num_bus_formats = 0;
+
+out:
panel->connector = NULL;
panel->drm = NULL;
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index a18c59f136ab..1760c11e0298 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -39,6 +39,8 @@ enum drm_panel_orientation;
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
+ * @detach: detach panel->connector (clear internal state, etc.)
+ * @attach: attach panel->connector (update internal state, etc.)
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
@@ -95,6 +97,18 @@ struct drm_panel {
const struct drm_panel_funcs *funcs;
+ /*
+* panel information to be set in the connector when the panel is
+* attached.
+*/
+ unsigned int width_mm;
+ unsigned int height_mm;
+ unsigned int bpc;
+ int orientation;
+ const u32 *bus_formats;
+ unsigned int num_bus_formats;
+ u32 bus_flags;
+
struct list_head list;
};
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v6 4/4] drm/mtk: add panel orientation property
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b91c4616644a..2920458ae2fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -790,10 +790,18 @@ static int mtk_dsi_create_connector(struct drm_device
*drm, struct mtk_dsi *dsi)
DRM_ERROR("Failed to attach panel to drm\n");
goto err_connector_cleanup;
}
+
+ ret = drm_connector_init_panel_orientation_property(>conn);
+ if (ret) {
+ DRM_ERROR("Failed to init panel orientation\n");
+ goto err_panel_detach;
+ }
}
return 0;
+err_panel_detach:
+ drm_panel_detach(dsi->panel);
err_connector_cleanup:
drm_connector_cleanup(>conn);
return ret;
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v6 0/4] Panel rotation patches
This adds the plumbing for reading panel rotation from the devicetree and sets up adding a panel property for the panel orientation on Mediatek SoCs when a rotation is present. v6 changes: -added enum declaration to drm_panel.h header v5 changes: -rebased v4 changes: -fixed some changes made to the i915 driver -clarified comments on of orientation helper v3 changes: -changed from attach/detach callbacks to directly setting fixed panel values in drm_panel_attach -removed update to Documentation -added separate function for quirked panel orientation property init v2 changes: fixed build errors in i915 Derek Basehore (4): drm/panel: Add helper for reading DT rotation drm/panel: set display info in panel attach drm/connector: Split out orientation quirk detection drm/mtk: add panel orientation property drivers/gpu/drm/drm_connector.c| 45 ++- drivers/gpu/drm/drm_panel.c| 70 ++ drivers/gpu/drm/i915/intel_dp.c| 4 +- drivers/gpu/drm/i915/vlv_dsi.c | 5 +-- drivers/gpu/drm/mediatek/mtk_dsi.c | 8 include/drm/drm_connector.h| 2 + include/drm/drm_panel.h| 21 + 7 files changed, 138 insertions(+), 17 deletions(-) -- 2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH v2 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
On Fri, 21 Jun 2019 18:13:44 -0300, Ezequiel Garcia wrote: > Add the register specifier description for an > optional gamma LUT address. > > Signed-off-by: Ezequiel Garcia > --- > Changes from v1: > * Drop reg-names, suggested by Doug. > --- > .../devicetree/bindings/display/rockchip/rockchip-vop.txt | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #85 from dwagner --- (In reply to Wilko Bartels from comment #84) > nevermind. it crashed on 60hz as well (once) yesterday It sure does. This bug is now about two years old, during which amdgpu has never been stable, got worse, and every contemporary kernel, whether "official" ones or ones compiled from git heads of development trees has this very problem, which I can reproduce within minutes. I've given up hoping for a fix. I'll buy an Intel Xe GPU as soon as it hits the shelves. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/tegra: Fix gpiod_get_from_of_node() regression
09.07.2019 19:27, Jon Hunter пишет:
>
> On 05/07/2019 16:11, Dmitry Osipenko wrote:
>> That function now returns ERR_PTR instead of NULL if "hpd-gpio" is not
>> present in device-tree. The offending patch missed to adapt the Tegra's
>> DRM driver for the API change.
>>
>> Fixes: 025bf37725f1 ("gpio: Fix return value mismatch of function
>> gpiod_get_from_of_node()")
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/tegra/output.c | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
>> index 274cb955e2e1..471d33809cd4 100644
>> --- a/drivers/gpu/drm/tegra/output.c
>> +++ b/drivers/gpu/drm/tegra/output.c
>> @@ -126,8 +126,12 @@ int tegra_output_probe(struct tegra_output *output)
>> "nvidia,hpd-gpio", 0,
>> GPIOD_IN,
>> "HDMI hotplug detect");
>> -if (IS_ERR(output->hpd_gpio))
>> -return PTR_ERR(output->hpd_gpio);
>> +if (IS_ERR(output->hpd_gpio)) {
>> +if (PTR_ERR(output->hpd_gpio) == -ENOENT)
>> +output->hpd_gpio = NULL;
>> +else
>> +return PTR_ERR(output->hpd_gpio);
>> +}
>>
>> if (output->hpd_gpio) {
>> err = gpiod_to_irq(output->hpd_gpio);
>>
>
> Acked-by: Jon Hunter
Thanks!
Re: [PATCH v8 1/6] drm: Add Content protection type property
On 2019-07-09 at 16:26:31 +0300, Pekka Paalanen wrote:
> On Mon, 8 Jul 2019 14:42:29 +0530
> Ramalingam C wrote:
>
> > On 2019-07-08 at 12:59:59 +0300, Pekka Paalanen wrote:
> > > On Mon, 8 Jul 2019 12:52:17 +0300
> > > Pekka Paalanen wrote:
> > >
> > > > On Fri, 5 Jul 2019 06:16:37 +0530
> > > > Ramalingam C wrote:
> > > >
> > > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > > This property is used for mentioning the protected content's type
> > > > > from userspace to kernel HDCP authentication.
> > > > >
> > > > > Type of the stream is decided by the protected content providers.
> > > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > > >
> > > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > > enable, kernel will honour it only if HDCP2.2 authentication is
> > > > > through
> > > > > for type 1. Else HDCP enable will be failed.
> > > > >
> > > > > Need ACK for this new conenctor property from userspace consumer.
> > > > >
> > > > > v2:
> > > > > cp_content_type is replaced with content_protection_type [daniel]
> > > > > check at atomic_set_property is removed [Maarten]
> > > > > v3:
> > > > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > > > v4:
> > > > > property is created for the first requested connector and then
> > > > > reused.
> > > > > [Danvet]
> > > > > v5:
> > > > > kernel doc nits addressed [Daniel]
> > > > > Rebased as part of patch reordering.
> > > > > v6:
> > > > > Kernel docs are modified [pekka]
> > > > >
> > > > > Signed-off-by: Ramalingam C
> > > > > Reviewed-by: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > > > > drivers/gpu/drm/drm_connector.c | 22 ++
> > > > > drivers/gpu/drm/drm_hdcp.c| 36
> > > > > ++-
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > > > > include/drm/drm_connector.h | 7 +
> > > > > include/drm/drm_hdcp.h| 2 +-
> > > > > include/drm/drm_mode_config.h | 6
> > > > > include/uapi/drm/drm_mode.h | 4 +++
> > > > > 8 files changed, 82 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > index abe38bdf85ae..19ae119f1a5d 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > > @@ -747,6 +747,8 @@ static int
> > > > > drm_atomic_connector_set_property(struct drm_connector *connector,
> > > > > return -EINVAL;
> > > > > }
> > > > > state->content_protection = val;
> > > > > + } else if (property == config->hdcp_content_type_property) {
> > > > > + state->hdcp_content_type = val;
> > > > > } else if (property == connector->colorspace_property) {
> > > > > state->colorspace = val;
> > > > > } else if (property == config->writeback_fb_id_property) {
> > > > > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct
> > > > > drm_connector *connector,
> > > > > state->hdr_output_metadata->base.id : 0;
> > > > > } else if (property == config->content_protection_property) {
> > > > > *val = state->content_protection;
> > > > > + } else if (property == config->hdcp_content_type_property) {
> > > > > + *val = state->hdcp_content_type;
> > > > > } else if (property == config->writeback_fb_id_property) {
> > > > > /* Writeback framebuffer is one-shot, write and forget
> > > > > */
> > > > > *val = 0;
> > > > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > > > b/drivers/gpu/drm/drm_connector.c
> > > > > index 068d4b05f1be..17aef88c03a6 100644
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -951,6 +951,28 @@ static const struct drm_prop_enum_list
> > > > > hdmi_colorspaces[] = {
> > > > > * the value transitions from ENABLED to DESIRED. This signifies
> > > > > the link
> > > > > * is no longer protected and userspace should take appropriate
> > > > > action
> > > > > * (whatever that might be).
> > > > > + * HDCP Content Type:
> > > > > + * This property is used by the userspace to configure the kernel
> > > > > with
> > > > > + * to be displayed stream's content type. Content Type of a stream
> > > > > is
> > > > > + * decided by the owner of the stream, as "HDCP Type0" or "HDCP
> > > > > Type1".
> > > > > + *
> > > > > + * The value of the property can be one the below:
> > > > > + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> > > > > + * HDCP Type0 streams can be transmitted on a link which is
> > >
Re: [PATCH v9 1/6] drm: Add Content protection type property
On 2019-07-09 at 17:31:10 +0300, Pekka Paalanen wrote:
> On Mon, 8 Jul 2019 16:51:11 +0530
> Ramalingam C wrote:
>
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentication.
> >
> > Type of the stream is decided by the protected content providers.
> > Type 0 content can be rendered on any HDCP protected display wires.
> > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> >
> > So when a userspace sets this property to Type 1 and starts the HDCP
> > enable, kernel will honour it only if HDCP2.2 authentication is through
> > for type 1. Else HDCP enable will be failed.
> >
> > Need ACK for this new conenctor property from userspace consumer.
> >
> > v2:
> > cp_content_type is replaced with content_protection_type [daniel]
> > check at atomic_set_property is removed [Maarten]
> > v3:
> > %s/content_protection_type/hdcp_content_type [Pekka]
> > v4:
> > property is created for the first requested connector and then reused.
> > [Danvet]
> > v5:
> > kernel doc nits addressed [Daniel]
> > Rebased as part of patch reordering.
> > v6:
> > Kernel docs are modified [pekka]
> > v7:
> > More details in Kernel docs. [pekka]
> >
> > Signed-off-by: Ramalingam C
> > Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > drivers/gpu/drm/drm_connector.c | 39 +++
> > drivers/gpu/drm/drm_hdcp.c| 36 -
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > include/drm/drm_connector.h | 7
> > include/drm/drm_hdcp.h| 2 +-
> > include/drm/drm_mode_config.h | 6
> > include/uapi/drm/drm_mode.h | 4 +++
> > 8 files changed, 99 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index abe38bdf85ae..19ae119f1a5d 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > + } else if (property == config->hdcp_content_type_property) {
> > + state->hdcp_content_type = val;
> > } else if (property == connector->colorspace_property) {
> > state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
> > *connector,
> > state->hdr_output_metadata->base.id : 0;
> > } else if (property == config->content_protection_property) {
> > *val = state->content_protection;
> > + } else if (property == config->hdcp_content_type_property) {
> > + *val = state->hdcp_content_type;
> > } else if (property == config->writeback_fb_id_property) {
> > /* Writeback framebuffer is one-shot, write and forget */
> > *val = 0;
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 068d4b05f1be..732f6645643d 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -952,6 +952,45 @@ static const struct drm_prop_enum_list
> > hdmi_colorspaces[] = {
> > * is no longer protected and userspace should take appropriate action
> > * (whatever that might be).
> > *
> > + * HDCP Content Type:
> > + * This Enum property is used by the userspace to declare the content type
> > + * of the display stream, to kernel. Here display stream stands for any
> > + * display content that userspace intended to render with HDCP encryption.
>
> Hi,
>
> I'd suggest s/render with/display through/.
>
> As a gfx dev, rendering is something quite different to me.
Ok.
>
> > + *
> > + * Content Type of a stream is decided by the owner of the stream, as
> > + * "HDCP Type0" or "HDCP Type1".
> > + *
> > + * The value of the property can be one the below:
>
> *one of the below
Sure.
>
> > + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> > + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> > + *
> > + * When kernel starts the HDCP authentication upon the "DESIRED" state of
> > + * the "Content Protection", it refers the "HDCP Content Type" property
> > + * state. And perform the HDCP authentication with the display sink for
> > + * the content type mentioned by "HDCP Content Type".
>
> How about:
>
> When kernel starts the HDCP authentication (see "Content Protection"
> for details), it uses the content type in "HDCP Content Type"
> for performing the HDCP authentication with the display sink.
less confusing :) Thanks.
>
> > + *
> > + * Stream classified as HDCP Type0 can be
Re: [PATCH] drm/amd/display: avoid 64-bit division
On Tue, Jul 9, 2019 at 6:40 PM Deucher, Alexander wrote: > > I'll just apply Arnd's patch. If the display team wants to adjust it later > to clarify the > operation, they should go ahead as a follow up patch. Thanks! > From: Abramov, Slava > Sent: Tuesday, July 9, 2019 12:31 PM > > Thanks for bisecting this issue. > > > > I wonder whether you are going to commit your patch or planning to update > > it and it's > > still in your work queue. We have one of our 32-bit builds failing because > > of this > > issue, so that I would like either to fix it or wait to your fix if it has > > chances to go > > upstream today. I was going to update the patch, but had not gotten to that yet. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/33] drm: drop use of drmp.h in drm-misc
Hi all. On Sun, Jun 30, 2019 at 08:18:49AM +0200, Sam Ravnborg wrote: > This patch set removes a far share of the remaining uses of drmP.h. > Common for all patches are that the respective files are maintained > in drm-misc. > All patches are independent except [PATCH 32] drm/ast, > [PATCH 31] drm/bochs and [PATCH 33] drm/hisilicon. > They need the fix to drm_vram_mm_helper.h [PATCH 30]. > > Patches have all been build tested with various configs and various > architectures. > There are likely introduced a few build issues that randconfig > build will reveal, but for all configs I have used the build was OK. > > This patchset does not conclude the quest to kill all uses > of drmP.h, but it is a major step towards the goal. > > Please review/ack. > I plan to apply the patches to drm-misc, but feel free > to do it yourself. On holiday this week, will process patches next week. Plan to apply reviewed patches to drm-misc-next and hope to have almost all of it ready for 5.3. Final removal of drmP.h will be after 5.3 due to dependencies with other trees. This is how I see it outlined now, plans may change as reality strikes. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Enable MST Aux devices (v2)
Hi Lyude, sorry - just realized I forgot to CC you on this series! Let me know if I should resend them. Adding some additional reviewers as well. Thanks, Leo On 2019-07-04 3:05 p.m., sunpeng...@amd.com wrote: > From: Leo Li > > Hi all, > > Here's the second revision of patches to enable mst aux devices. > > v2 fixes an aux device unregistration issue during driver unload. See > patch 2/10 for details. Consequently, drivers supporting mst are > modified to use the new mst connector late register and early unregister > helpers. > > Thanks, > Leo > > Leo Li (9): > drm/dp: Use non-cyclic idr > drm/sysfs: Add mstpath attribute to connector devices > drm/nouveau: Use connector kdev as aux device parent > drm/bridge/analogix-anx78xx: Use connector kdev as aux device parent > drm/amd/display: Use connector kdev as aux device parent > drm/i915: Implement MST Aux device registration > drm/nouveau/kms/nv50: Implement MST Aux device registration > drm/radeon: Implement MST Aux device registration > drm/amd/display: Implement MST Aux device registration > > Ville Syrjälä (1): > drm/dp_mst: Enable registration of AUX devices for MST ports > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 26 +++- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 22 +-- > drivers/gpu/drm/drm_dp_aux_dev.c | 19 ++- > drivers/gpu/drm/drm_dp_mst_topology.c | 137 -- > drivers/gpu/drm/drm_sysfs.c | 23 +++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 +++- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 20 +++ > drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +- > drivers/gpu/drm/radeon/radeon_dp_mst.c| 22 +++ > include/drm/drm_dp_helper.h | 4 + > include/drm/drm_dp_mst_helper.h | 11 ++ > 11 files changed, 285 insertions(+), 30 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation
Add an entry for the stable backlight sysfs ABI to the MAINTAINERS file. Signed-off-by: Matthias Kaehlcke Acked-by: Daniel Thompson --- Changes in v3: - none Changes in v2: - added Daniel's 'Acked-by' tag --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..d51e74340870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2857,6 +2857,7 @@ F:drivers/video/backlight/ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight +F: Documentation/ABI/stable/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
Backlight brightness curves can have different shapes. The two main
types are linear and non-linear curves. The human eye doesn't
perceive linearly increasing/decreasing brightness as linear (see
also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED
linearly to human eye"), hence many backlights use non-linear (often
logarithmic) brightness curves. The type of curve currently is opaque
to userspace, so userspace often uses more or less reliable heuristics
(like the number of brightness levels) to decide whether to treat a
backlight device as linear or non-linear.
Export the type of the brightness curve via the new sysfs attribute
'scale'. The value of the attribute can be 'linear', 'non-linear' or
'unknown'. For devices that don't provide information about the scale
of their brightness curve the value of the 'scale' attribute is 'unknown'.
Signed-off-by: Matthias Kaehlcke
---
Feel free to suggest improvements in the documentation :)
Changes in v3:
- removed composite strings, only keep 'linear', 'non-linear' and
'unknown'
- updated sysfs attribute documentation
- updated commit message
Changes in v2:
- changed order of brightness scale enums, explicitly make 'unknown' zero
- minor update of commit message
- deleted excess blank line after 'backlight_scale_types'
- s/curves/curve/ in sysfs doc
---
.../ABI/testing/sysfs-class-backlight | 26 +++
MAINTAINERS | 1 +
drivers/video/backlight/backlight.c | 19 ++
include/linux/backlight.h | 8 ++
4 files changed, 54 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-backlight
diff --git a/Documentation/ABI/testing/sysfs-class-backlight
b/Documentation/ABI/testing/sysfs-class-backlight
new file mode 100644
index ..3ab175a3f5cb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight
@@ -0,0 +1,26 @@
+What: /sys/class/backlight//scale
+Date: July 2019
+KernelVersion: 5.4
+Contact: Daniel Thompson
+Description:
+ Description of the scale of the brightness curve.
+
+ The human eye senses brightness approximately logarithmically,
+ hence linear changes in brightness are perceived as being
+ non-linear. To achieve a linear perception of brightness changes
+ controls like sliders need to apply a logarithmic mapping for
+ backlights with a linear brightness curve.
+
+ Possible values of the attribute are:
+
+ unknown
+ The scale of the brightness curve is unknown.
+
+ linear
+ The brightness changes linearly with each step. Brightness
+ controls should apply a logarithmic mapping for a linear
+ perception.
+
+ non-linear
+ The brightness changes non-linearly with each step. Brightness
+ controls should use a linear mapping for a linear perception.
diff --git a/MAINTAINERS b/MAINTAINERS
index d51e74340870..c46812510ba5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2858,6 +2858,7 @@ F:include/linux/backlight.h
F: include/linux/pwm_backlight.h
F: Documentation/devicetree/bindings/leds/backlight
F: Documentation/ABI/stable/sysfs-class-backlight
+F: Documentation/ABI/testing/sysfs-class-backlight
BATMAN ADVANCED
M: Marek Lindner
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 1ef8b6fd62ac..277abc76c83a 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -32,6 +32,12 @@ static const char *const backlight_types[] = {
[BACKLIGHT_FIRMWARE] = "firmware",
};
+static const char *const backlight_scale_types[] = {
+ [BACKLIGHT_SCALE_UNKNOWN] = "unknown",
+ [BACKLIGHT_SCALE_LINEAR]= "linear",
+ [BACKLIGHT_SCALE_NON_LINEAR]= "non-linear",
+};
+
#if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
@@ -246,6 +252,18 @@ static ssize_t actual_brightness_show(struct device *dev,
}
static DEVICE_ATTR_RO(actual_brightness);
+static ssize_t scale_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct backlight_device *bd = to_backlight_device(dev);
+
+ if (WARN_ON(bd->props.scale > BACKLIGHT_SCALE_NON_LINEAR))
+ return sprintf(buf, "unknown\n");
+
+ return sprintf(buf, "%s\n", backlight_scale_types[bd->props.scale]);
+}
+static DEVICE_ATTR_RO(scale);
+
static struct class *backlight_class;
#ifdef CONFIG_PM_SLEEP
@@ -292,6 +310,7 @@ static struct attribute *bl_device_attrs[] = {
_attr_brightness.attr,
_attr_actual_brightness.attr,
[PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type to non-linear. This makes the scale type
available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke
Tested-by: Enric Balletbo i Serra
Acked-by: Daniel Thompson
---
Changes in v3:
- mark scale as non-linear instead of using the CIE1931 type which
has been removed
- updated commit message
Changes in v2:
- added Enric's 'Tested-by' tag
- added Daniel's 'Acked-by' tag
---
drivers/video/backlight/pwm_bl.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..7c6dfc4a601d 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -553,6 +553,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ memset(, 0, sizeof(struct backlight_properties));
+
if (data->levels) {
/*
* For the DT case, only when brightness levels is defined
@@ -591,6 +593,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->levels = data->levels;
}
+
+ props.scale = BACKLIGHT_SCALE_NON_LINEAR;
} else {
/*
* That only happens for the non-DT case, where platform data
@@ -601,7 +605,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
- memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
bl = backlight_device_register(dev_name(>dev), >dev, pb,
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT
Check if a brightness curve specified in the device tree is linear or
not and set the corresponding property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
To determine if a curve is linear it is compared to a interpolated linear
curve between min and max brightness. The curve is considered linear if
no value deviates more than +/-5% of ${brightness_range} from their
interpolated value.
Signed-off-by: Matthias Kaehlcke
Acked-by: Daniel Thompson
---
Changes in v3:
- none
Changes in v2:
- use 128 (power of two) instead of 100 as factor for the slope
- add comment about max quantization error
- added Daniel's 'Acked-by' tag
---
drivers/video/backlight/pwm_bl.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 7c6dfc4a601d..fef98beb8b7e 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -404,6 +404,31 @@ int pwm_backlight_brightness_default(struct device *dev,
}
#endif
+static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data)
+{
+ unsigned int nlevels = data->max_brightness + 1;
+ unsigned int min_val = data->levels[0];
+ unsigned int max_val = data->levels[nlevels - 1];
+ /*
+* Multiplying by 128 means that even in pathological cases such
+* as (max_val - min_val) == nlevels the error at max_val is less
+* than 1%.
+*/
+ unsigned int slope = (128 * (max_val - min_val)) / nlevels;
+ unsigned int margin = (max_val - min_val) / 20; /* 5% */
+ int i;
+
+ for (i = 1; i < nlevels; i++) {
+ unsigned int linear_value = min_val + ((i * slope) / 128);
+ unsigned int delta = abs(linear_value - data->levels[i]);
+
+ if (delta > margin)
+ return false;
+ }
+
+ return true;
+}
+
static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
{
struct device_node *node = pb->dev->of_node;
@@ -567,6 +592,11 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->levels = data->levels;
}
+
+ if (pwm_backlight_is_linear(data))
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+ else
+ props.scale = BACKLIGHT_SCALE_NON_LINEAR;
} else if (!data->max_brightness) {
/*
* If no brightness levels are provided and max_brightness is
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 0/4] backlight: Expose brightness curve type through sysfs
Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve is currently opaque to userspace, so userspace often relies on more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via a new sysfs attribute. Matthias Kaehlcke (4): MAINTAINERS: Add entry for stable backlight sysfs ABI documentation backlight: Expose brightness curve type through sysfs backlight: pwm_bl: Set scale type for CIE 1931 curves backlight: pwm_bl: Set scale type for brightness curves specified in the DT .../ABI/testing/sysfs-class-backlight | 26 ++ MAINTAINERS | 2 ++ drivers/video/backlight/backlight.c | 19 ++ drivers/video/backlight/pwm_bl.c | 35 ++- include/linux/backlight.h | 8 + 5 files changed, 89 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight -- 2.22.0.410.gd8fdbe21b5-goog
[Bug 109524] "Invalid glsl version in shading_language_version()" when trying to run directX games using wine
https://bugs.freedesktop.org/show_bug.cgi?id=109524 --- Comment #12 from BabylonAS --- On Debian Testing I still have Mesa 18.3.6; so do I have to build Mesa from source code in order to get the patch? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/amd/display: Use proper enum conversion functions
On Thu, Jul 4, 2019 at 7:52 AM Nathan Chancellor
wrote:
>
> clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8:
> warning: implicit conversion from enumeration type 'enum smu_clk_type'
> to different enumeration type 'enum amd_pp_clock_type'
> [-Wenum-conversion]
> dc_to_smu_clock_type(clk_type),
> ^~~
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14:
> warning: implicit conversion from enumeration type 'enum
> amd_pp_clock_type' to different enumeration type 'enum smu_clk_type'
> [-Wenum-conversion]
> dc_to_pp_clock_type(clk_type),
> ^~
>
> There are functions to properly convert between all of these types, use
> them so there are no longer any warnings.
I had a different solution for this one as well. The difference is that your
patch keeps the types and assumes that the functions do the right thing
(i.e. the warning was correct), while my version assumes that the code
works correctly, but the types are wrong (a false positive warning).
One of the two patches is correct, the other one is broken, but I have
no idea which one.
Arnd
From 61316b80c852d103bb61e1ce9904002414600125 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 8 Jul 2019 17:44:05 +0200
Subject: [PATCH] drm/amd/powerplay: fix one more incorrect enum conversion
Similar to a previous patch, this one converts the type from a
function argument of a different enum type:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8:
error: implicit conversion from enumeration type 'enum smu_clk_type'
to different enumeration type 'enum amd_pp_clock_type'
[-Werror,-Wenum-conversion]
dc_to_smu_clock_type(clk_type),
^~~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:868:77: note:
expanded from macro 'smu_get_clock_by_type'
((smu)->funcs->get_clock_by_type ?
(smu)->funcs->get_clock_by_type((smu), (type), (clocks)) : 0)
~
^~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14:
error: implicit conversion from enumeration type 'enum
amd_pp_clock_type' to different enumeration type 'enum smu_clk_type'
[-Werror,-Wenum-conversion]
dc_to_pp_clock_type(clk_type),
^~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:872:111:
note: expanded from macro 'smu_get_clock_by_type_with_latency'
Add another type cast.
Fixes: e5e4e22391c2 ("drm/amd/powerplay: add interface to get clock by
type with latency for display (v2)")
Signed-off-by: Arnd Bergmann
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index eac09bfe3be2..88e3f8456b1c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -333,7 +333,7 @@ bool dm_pp_get_clock_levels_by_type(
}
} else if (adev->smu.funcs && adev->smu.funcs->get_clock_by_type) {
if (smu_get_clock_by_type(>smu,
- dc_to_smu_clock_type(clk_type),
+ (enum
amd_pp_clock_type)dc_to_smu_clock_type(clk_type),
_clks)) {
get_default_clock_levels(clk_type, dc_clks);
return true;
@@ -418,7 +418,7 @@ bool dm_pp_get_clock_levels_by_type_with_latency(
return false;
} else if (adev->smu.ppt_funcs &&
adev->smu.ppt_funcs->get_clock_by_type_with_latency) {
if (smu_get_clock_by_type_with_latency(>smu,
-
dc_to_pp_clock_type(clk_type),
+ (enum
smu_clk_type)dc_to_pp_clock_type(clk_type),
_clks))
return false;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #41 from Sylvain BERTRAND --- Guys, I am getting freezes on tahiti xt/fx9590 recently... But I am not logging a bug yet because I think the reason is summer heat. Try to game with an opened computer case with a big fan blowing into it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
Guys, I am getting freezes on tahiti xt/fx9590 recently... But I am not logging a bug yet because I think the reason is summer heat. Try to game with an opened computer case with a big fan blowing into it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] fbdev changes for v5.3
The pull request you sent on Tue, 9 Jul 2019 15:10:33 +0200: > https://github.com/bzolnier/linux.git tags/fbdev-v5.3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2d41ef5432b76ae90dc0db93026f1d981f874ec4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 16/18] MAINTAINERS: add entry for KUnit the unit testing framework
On Tue, Jul 9, 2019 at 7:53 AM shuah wrote: > > On 7/9/19 12:30 AM, Brendan Higgins wrote: > > Add myself as maintainer of KUnit, the Linux kernel's unit testing > > framework. > > > > Signed-off-by: Brendan Higgins > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Logan Gunthorpe > > --- > > MAINTAINERS | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 677ef41cb012c..48d04d180a988 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8599,6 +8599,17 @@ S: Maintained > > F: tools/testing/selftests/ > > F: Documentation/dev-tools/kselftest* > > > > +KERNEL UNIT TESTING FRAMEWORK (KUnit) > > +M: Brendan Higgins > > +L: linux-kselft...@vger.kernel.org > > +L: kunit-...@googlegroups.com > > +W: https://google.github.io/kunit-docs/third_party/kernel/docs/ > > +S: Maintained > > +F: Documentation/dev-tools/kunit/ > > +F: include/kunit/ > > +F: kunit/ > > +F: tools/testing/kunit/ > > + > > KERNEL USERMODE HELPER > > M: Luis Chamberlain > > L: linux-ker...@vger.kernel.org > > > > Thanks Brendan. > > I am good with this. I can take KUnit patches through kselftest > with your Ack. My acknowledgement? Sure! I thought we already agreed to that. Also, do we need an ack from Masahiro or Michal for the Kbuild patch [PATCH v7 06/18]? And an ack from Josh or Peter for the objtool patch [PATCH v7 08/18]? Greg and Logan gave me a Reviewed-by for the Kbuild patch, so maybe that's fine, but I don't have any reviews or acks for the objtool patch. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 01/22] docs: Documentation/*.txt: rename all ReST files to *.rst
On Tue, Jun 18, 2019 at 06:05:25PM -0300, Mauro Carvalho Chehab wrote:
> Those files are actually at ReST format. Ok, currently, they
> don't belong to any place yet at the organized book series,
> but we don't want patches to break them as ReST files. So,
> rename them and add a :orphan: in order to shut up warning
> messages like those:
>
> ...
> Documentation/svga.rst: WARNING: document isn't included in any toctree
> Documentation/switchtec.rst: WARNING: document isn't included in any
> toctree
> ...
>
> Later patches will move them to a better place and remove the
> :orphan: markup.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> I had to remove the long list of maintainers got by
> getpatch.pl, as it was too long. I opted to keep only the
> mailing lists.
>
> Documentation/ABI/removed/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-devices-node | 2 +-
> Documentation/ABI/testing/procfs-diskstats| 2 +-
> Documentation/ABI/testing/sysfs-block | 2 +-
> .../ABI/testing/sysfs-class-switchtec | 2 +-
> .../ABI/testing/sysfs-devices-system-cpu | 4 +-
> .../{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst} | 2 +
> Documentation/{DMA-API.txt => DMA-API.rst}| 8 ++-
> .../{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst} | 4 +-
> ...{DMA-attributes.txt => DMA-attributes.rst} | 2 +
> Documentation/{IPMI.txt => IPMI.rst} | 2 +
> .../{IRQ-affinity.txt => IRQ-affinity.rst}| 2 +
> .../{IRQ-domain.txt => IRQ-domain.rst}| 2 +
> Documentation/{IRQ.txt => IRQ.rst}| 2 +
> .../{Intel-IOMMU.txt => Intel-IOMMU.rst} | 2 +
> Documentation/PCI/pci.rst | 8 +--
> Documentation/{SAK.txt => SAK.rst}| 3 +-
> Documentation/{SM501.txt => SM501.rst}| 2 +
> Documentation/admin-guide/hw-vuln/l1tf.rst| 2 +-
> .../admin-guide/kernel-parameters.txt | 4 +-
> .../{atomic_bitops.txt => atomic_bitops.rst} | 3 +-
> Documentation/block/biodoc.txt| 2 +-
> .../{bt8xxgpio.txt => bt8xxgpio.rst} | 3 +-
> Documentation/{btmrvl.txt => btmrvl.rst} | 2 +
> ...-mapping.txt => bus-virt-phys-mapping.rst} | 54 +-
> ...g-warn-once.txt => clearing-warn-once.rst} | 2 +
> Documentation/{cpu-load.txt => cpu-load.rst} | 2 +
> .../{cputopology.txt => cputopology.rst} | 2 +
> Documentation/{crc32.txt => crc32.rst}| 2 +
> Documentation/{dcdbas.txt => dcdbas.rst} | 2 +
> ...ging-modules.txt => debugging-modules.rst} | 2 +
> ...hci1394.txt => debugging-via-ohci1394.rst} | 2 +
> Documentation/{dell_rbu.txt => dell_rbu.rst} | 3 +-
> Documentation/device-mapper/statistics.rst| 4 +-
> .../devicetree/bindings/phy/phy-bindings.txt | 2 +-
Acked-by: Rob Herring
> Documentation/{digsig.txt => digsig.rst} | 2 +
> Documentation/driver-api/usb/dma.rst | 6 +-
> Documentation/driver-model/device.rst | 2 +-
> Documentation/{efi-stub.txt => efi-stub.rst} | 2 +
> Documentation/{eisa.txt => eisa.rst} | 2 +
> Documentation/fb/vesafb.rst | 2 +-
> Documentation/filesystems/sysfs.txt | 2 +-
> ...ex-requeue-pi.txt => futex-requeue-pi.rst} | 2 +
> .../{gcc-plugins.txt => gcc-plugins.rst} | 2 +
> Documentation/gpu/drm-mm.rst | 2 +-
> Documentation/{highuid.txt => highuid.rst}| 4 +-
> .../{hw_random.txt => hw_random.rst} | 2 +
> .../{hwspinlock.txt => hwspinlock.rst}| 2 +
> Documentation/ia64/irq-redir.rst | 2 +-
> .../{intel_txt.txt => intel_txt.rst} | 2 +
> .../{io-mapping.txt => io-mapping.rst}| 2 +
> .../{io_ordering.txt => io_ordering.rst} | 2 +
> Documentation/{iostats.txt => iostats.rst}| 2 +
> ...flags-tracing.txt => irqflags-tracing.rst} | 3 +-
> Documentation/{isa.txt => isa.rst}| 2 +
> Documentation/{isapnp.txt => isapnp.rst} | 2 +
> ...hreads.txt => kernel-per-CPU-kthreads.rst} | 4 +-
> Documentation/{kobject.txt => kobject.rst}| 6 +-
> Documentation/{kprobes.txt => kprobes.rst}| 3 +-
> Documentation/{kref.txt => kref.rst} | 2 +
> Documentation/laptops/thinkpad-acpi.rst | 6 +-
> Documentation/{ldm.txt => ldm.rst}| 5 +-
> Documentation/locking/rt-mutex.rst| 2 +-
> ...kup-watchdogs.txt => lockup-watchdogs.rst} | 2 +
> Documentation/{lsm.txt => lsm.rst}| 2 +
> Documentation/{lzo.txt => lzo.rst}| 2 +
> Documentation/{mailbox.txt => mailbox.rst}| 2 +
> Documentation/memory-barriers.txt | 6 +-
> ...hameleon-bus.txt => men-chameleon-bus.rst} | 2 +
> Documentation/networking/scaling.rst | 4 +-
> .../{nommu-mmap.txt => nommu-mmap.rst}| 2 +
> Documentation/{ntb.txt => ntb.rst}| 2 +
> Documentation/{numastat.txt =>
Re: [PATCH 5/6] dt-bindings: display: ssd1307fb: Add initialization properties
On Tue, 18 Jun 2019 10:41:10 +0300, Marko Kohtala wrote: > Document new bindings for adapting ssd1307fb driver to new displays. > > Signed-off-by: Marko Kohtala > --- > .../devicetree/bindings/display/ssd1307fb.txt | 10 ++ > 1 file changed, 10 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: avoid 64-bit division
I'll just apply Arnd's patch. If the display team wants to adjust it later to
clarify the operation, they should go ahead as a follow up patch.
Thanks,
Alex
From: Abramov, Slava
Sent: Tuesday, July 9, 2019 12:31 PM
To: Arnd Bergmann; Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander;
Koenig, Christian; Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: Re: [PATCH] drm/amd/display: avoid 64-bit division
Hi Arnd!
Thanks for bisecting this issue.
I wonder whether you are going to commit your patch or planning to update it
and it's still in your work queue. We have one of our 32-bit builds failing
because of this issue, so that I would like either to fix it or wait to your
fix if it has chances to go upstream today.
Sincerely,
Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: avoid 64-bit division
Hi Arnd!
Thanks for bisecting this issue.
I wonder whether you are going to commit your patch or planning to update it
and it's still in your work queue. We have one of our 32-bit builds failing
because of this issue, so that I would like either to fix it or wait to your
fix if it has chances to go upstream today.
Sincerely,
Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/tegra: Fix gpiod_get_from_of_node() regression
On 05/07/2019 16:11, Dmitry Osipenko wrote:
> That function now returns ERR_PTR instead of NULL if "hpd-gpio" is not
> present in device-tree. The offending patch missed to adapt the Tegra's
> DRM driver for the API change.
>
> Fixes: 025bf37725f1 ("gpio: Fix return value mismatch of function
> gpiod_get_from_of_node()")
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/output.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index 274cb955e2e1..471d33809cd4 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -126,8 +126,12 @@ int tegra_output_probe(struct tegra_output *output)
> "nvidia,hpd-gpio", 0,
> GPIOD_IN,
> "HDMI hotplug detect");
> - if (IS_ERR(output->hpd_gpio))
> - return PTR_ERR(output->hpd_gpio);
> + if (IS_ERR(output->hpd_gpio)) {
> + if (PTR_ERR(output->hpd_gpio) == -ENOENT)
> + output->hpd_gpio = NULL;
> + else
> + return PTR_ERR(output->hpd_gpio);
> + }
>
> if (output->hpd_gpio) {
> err = gpiod_to_irq(output->hpd_gpio);
>
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
Re: [PATCH] drm/atmel-hlcdc: set layer REP bit to enable replication logic
On 09/07/2019 at 17:35, Joshua Henderson wrote:
> This bit enables replication logic to expand an RGB color less than 24
> bits, to 24 bits, which is used internally for all formats. Otherwise,
> the least significant bits are always set to zero and the color may not
> be what is expected.
>
> Signed-off-by: Joshua Henderson
Acked-by: Nicolas Ferre
Here is patchwork entry:
https://patchwork.kernel.org/patch/11037167/
Thanks, best regards,
Nicolas
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index eb7c4cf..6f6cf61 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -389,7 +389,7 @@ atmel_hlcdc_plane_update_general_settings(struct
> atmel_hlcdc_plane *plane,
> atmel_hlcdc_layer_write_cfg(>layer, ATMEL_HLCDC_LAYER_DMA_CFG,
> cfg);
>
> - cfg = ATMEL_HLCDC_LAYER_DMA;
> + cfg = ATMEL_HLCDC_LAYER_DMA | ATMEL_HLCDC_LAYER_REP;
>
> if (plane->base.type != DRM_PLANE_TYPE_PRIMARY) {
> cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
>
--
Nicolas Ferre
Re: [PATCH v2 17/28] drivers: Introduce bus_find_device_by_of_node() helper
On Fri, 14 Jun 2019 18:54:12 +0100, Suzuki K Poulose wrote: > Add a wrapper to bus_find_device() to search for a device > by the of_node pointer, reusing the generic match function. > Also convert the existing users to make use of the new helper. > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: dri-devel@lists.freedesktop.org > Cc: David Airlie > Cc: Daniel Vetter > Cc: devicet...@vger.kernel.org > Cc: Florian Fainelli > Cc: Frank Rowand > Cc: Heiko Stuebner > Cc: Liam Girdwood > Cc: linux-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: Mathieu Poirier > Cc: Rob Herring > Cc: Srinivas Kandagatla > Cc: Takashi Iwai > Cc: Wolfram Sang > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Suzuki K Poulose > --- > drivers/gpu/drm/drm_mipi_dsi.c | 7 +-- > drivers/hwtracing/coresight/of_coresight.c | 11 ++- > drivers/i2c/i2c-core-of.c | 7 +-- > drivers/nvmem/core.c | 7 +-- > drivers/of/of_mdio.c | 8 +--- > drivers/of/platform.c | 7 +-- > drivers/spi/spi.c | 9 ++--- > include/linux/device.h | 12 > sound/soc/rockchip/rk3399_gru_sound.c | 9 ++--- > 9 files changed, 23 insertions(+), 54 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v2 7/9] dt-bindings: sun6i-dsi: Add R40 DPHY compatible (w/ A31 fallback)
On Fri, 14 Jun 2019 22:13:22 +0530, Jagan Teki wrote: > The MIPI DSI PHY controller on Allwinner R40 is similar > on the one on A31. > > Add R40 compatible and append A31 compatible as fallback. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atmel-hlcdc: set layer REP bit to enable replication logic
This bit enables replication logic to expand an RGB color less than 24
bits, to 24 bits, which is used internally for all formats. Otherwise,
the least significant bits are always set to zero and the color may not
be what is expected.
Signed-off-by: Joshua Henderson
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index eb7c4cf..6f6cf61 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -389,7 +389,7 @@ atmel_hlcdc_plane_update_general_settings(struct
atmel_hlcdc_plane *plane,
atmel_hlcdc_layer_write_cfg(>layer, ATMEL_HLCDC_LAYER_DMA_CFG,
cfg);
- cfg = ATMEL_HLCDC_LAYER_DMA;
+ cfg = ATMEL_HLCDC_LAYER_DMA | ATMEL_HLCDC_LAYER_REP;
if (plane->base.type != DRM_PLANE_TYPE_PRIMARY) {
cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
--
2.7.4
[PATCH v3] gpu/drm_memory: fix a few warnings
The opening comment mark "/**" is reserved for kernel-doc comments, so it will generate a warning with "make W=1". drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file drm_memory.c Also, silence a checkpatch warning by adding a license identfiter where it indicates the MIT license further down in the source file. WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 Fix it by adding the MIT SPDX identifier without touching the boilerplate language. Suggested-by: Thomas Gleixner Signed-off-by: Qian Cai --- v3: Keep the boilerplate language. v2: Remove the redundant description of the license. drivers/gpu/drm/drm_memory.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c index 132fef8ff1b6..683042c8ee2c 100644 --- a/drivers/gpu/drm/drm_memory.c +++ b/drivers/gpu/drm/drm_memory.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: MIT +/* * \file drm_memory.c * Memory management wrappers for DRM * -- 1.8.3.1
Re: [PATCH v1 12/33] drm/vkms: drop use of drmP.h
On Sun, Jun 30, 2019 at 3:19 AM Sam Ravnborg wrote:
>
> Drop use of the deprecated drmP.h header.
> Replace it with the necessary includes in the individual .c files.
> The header files was self-contained, and extra includes were not added
> there.
>
> Signed-off-by: Sam Ravnborg
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: David Airlie
Hi Sam,
Thanks for you patch, it LGTM.
Reviewed-by: Rodrigo Siqueira
> ---
> The list of cc: was too large to add all recipients to the cover letter.
> Please find cover letter here:
> https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
> Search for "drm: drop use of drmp.h in drm-misc"
>
> Sam
>
> drivers/gpu/drm/vkms/vkms_crc.c | 5 -
> drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
> drivers/gpu/drm/vkms/vkms_drv.c | 11 +--
> drivers/gpu/drm/vkms/vkms_drv.h | 4 ++--
> drivers/gpu/drm/vkms/vkms_gem.c | 1 +
> drivers/gpu/drm/vkms/vkms_plane.c | 6 --
> 6 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 30b048b67a32..2037e5669fcf 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -1,10 +1,13 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -#include "vkms_drv.h"
> #include
> +
> #include
> #include
> #include
> +#include
> +
> +#include "vkms_drv.h"
>
> /**
> * compute_crc - Compute CRC value on output frame
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 7e2a081f3764..8e9cc35c16d3 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -1,9 +1,11 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -#include "vkms_drv.h"
> #include
> #include
> #include
> +#include
> +
> +#include "vkms_drv.h"
>
> static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> {
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cc53ef88a331..0a236160b235 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -10,12 +10,19 @@
> */
>
> #include
> -#include
> +#include
> +
> #include
> #include
> -#include
> +#include
> #include
> +#include
> +#include
> +#include
> +#include
> #include
> +#include
> +
> #include "vkms_drv.h"
>
> #define DRIVER_NAME"vkms"
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 12b4db7ac641..0a4ba8b57e11 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -3,11 +3,11 @@
> #ifndef _VKMS_DRV_H_
> #define _VKMS_DRV_H_
>
> -#include
> +#include
> +
> #include
> #include
> #include
> -#include
>
> #define XRES_MIN20
> #define YRES_MIN20
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index 69048e73377d..6489bfe0a149 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> #include
> +#include
>
> #include "vkms_drv.h"
>
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 0fceb6258422..3a610b4060c1 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -1,10 +1,12 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> -#include "vkms_drv.h"
> -#include
> #include
> #include
> +#include
> #include
> +#include
> +
> +#include "vkms_drv.h"
>
> static const u32 vkms_formats[] = {
> DRM_FORMAT_XRGB,
> --
> 2.20.1
>
--
Rodrigo Siqueira
https://siqueira.tech
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 16/18] MAINTAINERS: add entry for KUnit the unit testing framework
On 7/9/19 12:30 AM, Brendan Higgins wrote: Add myself as maintainer of KUnit, the Linux kernel's unit testing framework. Signed-off-by: Brendan Higgins Reviewed-by: Greg Kroah-Hartman Reviewed-by: Logan Gunthorpe --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 677ef41cb012c..48d04d180a988 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8599,6 +8599,17 @@ S: Maintained F:tools/testing/selftests/ F:Documentation/dev-tools/kselftest* +KERNEL UNIT TESTING FRAMEWORK (KUnit) +M: Brendan Higgins +L: linux-kselft...@vger.kernel.org +L: kunit-...@googlegroups.com +W: https://google.github.io/kunit-docs/third_party/kernel/docs/ +S: Maintained +F: Documentation/dev-tools/kunit/ +F: include/kunit/ +F: kunit/ +F: tools/testing/kunit/ + KERNEL USERMODE HELPER M:Luis Chamberlain L:linux-ker...@vger.kernel.org Thanks Brendan. I am good with this. I can take KUnit patches through kselftest with your Ack. thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/modes: Skip invalid cmdline mode
The named mode could be invalid and then cmdline parser misses to validate
mode's dimensions, happily adding 0x0 mode as a valid mode. One case where
this happens is NVIDIA Tegra devices that are using downstream bootloader
which adds "video=tegrafb" to the kernel's cmdline and thus upstream Tegra
DRM driver fails to probe because of the invalid mode.
Fixes: 3aeeb13d8996 ("drm/modes: Support modes names on the command line")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client_modeset.c | 3 ++-
drivers/gpu/drm/drm_modes.c | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index e95fceac8f8b..56d36779d213 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -180,7 +180,8 @@ drm_connector_pick_cmdline_mode(struct drm_connector
*connector)
create_mode:
mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode);
- list_add(>head, >modes);
+ if (mode)
+ list_add(>head, >modes);
return mode;
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 910561d4f071..74a5739df506 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -158,6 +158,9 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device
*dev, int hdisplay,
int interlace;
u64 tmp;
+ if (!hdisplay || !vdisplay)
+ return NULL;
+
/* allocate the drm_display_mode structure. If failure, we will
* return directly
*/
@@ -392,6 +395,9 @@ drm_gtf_mode_complex(struct drm_device *dev, int hdisplay,
int vdisplay,
int hsync, hfront_porch, vodd_front_porch_lines;
unsigned int tmp1, tmp2;
+ if (!hdisplay || !vdisplay)
+ return NULL;
+
drm_mode = drm_mode_create(dev);
if (!drm_mode)
return NULL;
--
2.22.0
Re: [PATCH v2 6/9] dt-bindings: sun6i-dsi: Add R40 MIPI-DSI compatible (w/ A64 fallback)
On Fri, 14 Jun 2019 22:13:21 +0530, Jagan Teki wrote: > The MIPI DSI controller on Allwinner R40 is similar on > the one on A64 like doesn't associate any DSI_SCLK gating. > > So, add R40 compatible and append A64 compatible as fallback. > > Signed-off-by: Jagan Teki > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH v2 1/9] dt-bindings: display: Add TCON LCD compatible for R40
On Fri, 14 Jun 2019 22:13:16 +0530, Jagan Teki wrote: > Like TCON TV0, TV1 allwinner R40 has TCON LCD0, LCD1 which > are managed via TCON TOP. > > Add tcon lcd compatible R40, the same compatible can handle > TCON LCD0, LCD1. > > Signed-off-by: Jagan Teki > Acked-by: Chen-Yu Tsai > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/6] drm/hdcp: update content protection property with uevent
On Mon, 8 Jul 2019 16:51:14 +0530
Ramalingam C wrote:
> drm function is defined and exported to update a connector's
> content protection property state and to generate a uevent along
> with it.
>
> Need ACK for the uevent from userspace consumer.
>
> v2:
> Update only when state is different from old one.
> v3:
> KDoc is added [Daniel]
> v4:
> KDoc is extended bit more [pekka]
> v5:
> Uevent usage is documented at kdoc of "Content Protection" also
> [pekka]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_connector.c | 17 +
> drivers/gpu/drm/drm_hdcp.c | 34 +
> include/drm/drm_hdcp.h | 2 ++
> 3 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 732f6645643d..6de906ef10b3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -947,10 +947,19 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> * - If the state is DESIRED, kernel should attempt to re-authenticate the
> * link whenever possible. This includes across disable/enable, dpms,
> * hotplug, downstream device changes, link status failures, etc..
> - * - Userspace is responsible for polling the property to determine when
> - * the value transitions from ENABLED to DESIRED. This signifies the link
> - * is no longer protected and userspace should take appropriate action
> - * (whatever that might be).
> + * - Kernel sends uevent with the connector id and property id through
> + * @drm_hdcp_update_content_protection, upon below kernel triggered
> + * scenarios:
> + * DESIRED -> ENABLED (authentication success)
> + * ENABLED -> DESIRED (termination of authentication)
> + * - Please note no uevents for userspace triggered property state changes,
> + * which can't fail such as
> + * DESIRED/ENABLED -> UNDESIRED
> + * UNDESIRED -> DESIRED
> + * - Userspace is responsible for polling the property or listen to uevents
> + * to determine when the value transitions from ENABLED to DESIRED.
> + * This signifies the link is no longer protected and userspace should
> + * take appropriate action (whatever that might be).
Yes!
This doc is exactly what I hoped to see. Good job.
This is also exactly how
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 deals
with this in userspace. That MR still has some open issues, but I think
nothing related to the uevent.
Thanks,
pq
> *
> * HDCP Content Type:
> * This Enum property is used by the userspace to declare the content type
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index ce235fd1c844..77433ee3d652 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -374,6 +374,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
> *
> * The content protection will be set to
> _connector_state.content_protection
> *
> + * When kernel triggered content protection state change like
> DESIRED->ENABLED
> + * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to
> update
> + * the content protection state of a connector.
> + *
> * Returns:
> * Zero on success, negative errno on failure.
> */
> @@ -414,3 +418,33 @@ int drm_connector_attach_content_protection_property(
> return 0;
> }
> EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
> +
> +/**
> + * drm_hdcp_update_content_protection - Updates the content protection state
> + * of a connector
> + *
> + * @connector: drm_connector on which content protection state needs an
> update
> + * @val: New state of the content protection property
> + *
> + * This function can be used by display drivers, to update the kernel
> triggered
> + * content protection state changes of a drm_connector such as
> DESIRED->ENABLED
> + * and ENABLED->DESIRED. No uevent for DESIRED->UNDESIRED or
> ENABLED->UNDESIRED,
> + * as userspace is triggering such state change and kernel performs it
> without
> + * fail.This function update the new state of the property into the
> connector's
> + * state and generate an uevent to notify the userspace.
> + */
> +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> + u64 val)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_connector_state *state = connector->state;
> +
> + WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> + if (state->content_protection == val)
> + return;
> +
> + state->content_protection = val;
> + drm_sysfs_connector_status_event(connector,
> + dev->mode_config.content_protection_property);
> +}
> +EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> diff --git
Re: [PATCH 07/60] drm/bridge: simple-bridge: Add support for the TI OP362
On 07.07.2019 20:18, Laurent Pinchart wrote:
> The TI OP362 is an analog video amplifier controlled through a GPIO. Add
> support for it to the simple-bridge driver.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index a7edf3c39627..7495b9bef865 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -296,6 +296,11 @@ static const struct of_device_id simple_bridge_match[] =
> {
> .timings = _bridge_timings,
> .type = DRM_MODE_CONNECTOR_VGA,
> },
> + }, {
> + .compatible = "ti,opa362",
> + .data = &(const struct simple_bridge_info) {
> + .type = DRM_MODE_CONNECTOR_Composite,
> + },
> }, {
> .compatible = "ti,ths8135",
> .data = &(const struct simple_bridge_info) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/60] drm/bridge: simple-bridge: Add support for enable GPIO
On 07.07.2019 20:18, Laurent Pinchart wrote:
> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
>
> Signed-off-by: Laurent Pinchart
Hmm, simple becomes less simple. I guess we will end-up with sth similar
to panel-simple. And then we can merge both :)
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index bff240cf283d..a7edf3c39627 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -6,6 +6,7 @@
> * Maxime Ripard
> */
>
> +#include
> #include
> #include
> #include
> @@ -29,6 +30,7 @@ struct simple_bridge {
>
> struct i2c_adapter *ddc;
> struct regulator*vdd;
> + struct gpio_desc*enable;
> };
>
> static inline struct simple_bridge *
> @@ -135,19 +137,23 @@ static int simple_bridge_attach(struct drm_bridge
> *bridge)
> static void simple_bridge_enable(struct drm_bridge *bridge)
> {
> struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> - int ret = 0;
> + int ret;
>
> - if (sbridge->vdd)
> + if (sbridge->vdd) {
> ret = regulator_enable(sbridge->vdd);
> + if (ret)
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + }
>
> - if (ret)
> - DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + gpiod_set_value_cansleep(sbridge->enable, 1);
> }
>
> static void simple_bridge_disable(struct drm_bridge *bridge)
> {
> struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
>
> + gpiod_set_value_cansleep(sbridge->enable, 0);
> +
> if (sbridge->vdd)
> regulator_disable(sbridge->vdd);
> }
> @@ -200,6 +206,14 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
> dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
> }
>
> + sbridge->enable = devm_gpiod_get_optional(>dev, "enable",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(sbridge->enable)) {
> + if (PTR_ERR(sbridge->enable) != -EPROBE_DEFER)
> + dev_err(>dev, "Unable to retrieve enable GPIO\n");
> + return PTR_ERR(sbridge->enable);
> + }
> +
> sbridge->ddc = simple_bridge_retrieve_ddc(>dev);
> if (IS_ERR(sbridge->ddc)) {
> if (PTR_ERR(sbridge->ddc) == -ENODEV) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm: Add Content protection type property
On Mon, 8 Jul 2019 16:51:11 +0530
Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
>
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
>
> Need ACK for this new conenctor property from userspace consumer.
>
> v2:
> cp_content_type is replaced with content_protection_type [daniel]
> check at atomic_set_property is removed [Maarten]
> v3:
> %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
> property is created for the first requested connector and then reused.
> [Danvet]
> v5:
> kernel doc nits addressed [Daniel]
> Rebased as part of patch reordering.
> v6:
> Kernel docs are modified [pekka]
> v7:
> More details in Kernel docs. [pekka]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 39 +++
> drivers/gpu/drm/drm_hdcp.c| 36 -
> drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> include/drm/drm_connector.h | 7
> include/drm/drm_hdcp.h| 2 +-
> include/drm/drm_mode_config.h | 6
> include/uapi/drm/drm_mode.h | 4 +++
> 8 files changed, 99 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index abe38bdf85ae..19ae119f1a5d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == config->hdcp_content_type_property) {
> + state->hdcp_content_type = val;
> } else if (property == connector->colorspace_property) {
> state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> state->hdr_output_metadata->base.id : 0;
> } else if (property == config->content_protection_property) {
> *val = state->content_protection;
> + } else if (property == config->hdcp_content_type_property) {
> + *val = state->hdcp_content_type;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 068d4b05f1be..732f6645643d 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -952,6 +952,45 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> * is no longer protected and userspace should take appropriate action
> * (whatever that might be).
> *
> + * HDCP Content Type:
> + * This Enum property is used by the userspace to declare the content type
> + * of the display stream, to kernel. Here display stream stands for any
> + * display content that userspace intended to render with HDCP encryption.
Hi,
I'd suggest s/render with/display through/.
As a gfx dev, rendering is something quite different to me.
> + *
> + * Content Type of a stream is decided by the owner of the stream, as
> + * "HDCP Type0" or "HDCP Type1".
> + *
> + * The value of the property can be one the below:
*one of the below
> + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> + *
> + * When kernel starts the HDCP authentication upon the "DESIRED" state of
> + * the "Content Protection", it refers the "HDCP Content Type" property
> + * state. And perform the HDCP authentication with the display sink for
> + * the content type mentioned by "HDCP Content Type".
How about:
When kernel starts the HDCP authentication (see "Content Protection"
for details), it uses the content type in "HDCP Content Type"
for performing the HDCP authentication with the display sink.
> + *
> + * Stream classified as HDCP Type0 can be transmitted on a link which is
> + * encrypted with HDCP 1.4 or higher versions of HDCP(i.e HDCP2.2
> + * and more).
This is where I get confused, see my earlier email from today on the
previous revision of this patch series. Is it necessary to talk
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #40 from Wilko Bartels --- Since i experience the same issue since june (didnt game much) i want to share my system info. I am on Ryzen 2600X, Vega 56 Pulse, Strix B450. Using Arch 5.1. Tested every Windowmanager i know , tested also 60Hz and 144Hz. The crashes are totally random. I only play Dota 2. Last friday i played like 6 games in a row without a single issue. The day after i crashed like 7 times per game. Always have to press reset on my PC. Is it know that hits issue related to a kernel or mesa update? I mean it wasnt always like this no? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote: > > > 于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard 写到: > >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > >> > > Maybe instead of edp-connector one would introduce integrator's > >specific > >> > > connector, for example with compatible > >"olimex,teres-edp-connector" > >> > > which should follow edp abstract connector rules? This will be at > >least > >> > > consistent with below presentation[1] - eDP requirements depends > >on > >> > > integrator. Then if olimex has standard way of dealing with > >panels > >> > > present in olimex/teres platforms the driver would then create > >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I > >guess. > >> > > Anyway it still looks fishy for me :), maybe because I am not > >> > > familiarized with details of these platforms. > >> > > >> > That makes sense yes > >> > >> Actually, it makes no sense at all. Current implementation for > >anx6345 > >> driver works fine as is with any panel specified assuming panel > >delays > >> are long enough for connected panel. It just doesn't use panel > >timings > >> from the driver. Creating a platform driver for connector itself > >looks > >> redundant since it can't be reused, it doesn't describe actual > >> hardware and it's just defeats purpose of DT by introducing > >> board-specific code. > > > >I'm not sure where you got the idea that the purpose of DT is to not > >have any board-specific code. > > > >It's perfectly fine to have some, that's even why there's a compatible > >assigned to each and every board. > > > >What the DT is about is allowing us to have a generic behaviour that > >we can detect: we can have a given behaviour for a given board, and a > >separate one for another one, and this will be evaluated at runtime. > > > >This is *exactly* what this is about: we can have a compatible that > >sets a given, more specific, behaviour (olimex,teres-edp-connector) > >while saying that this is compatible with the generic behaviour > >(edp-connector). That way, any OS will know what quirk to apply if > >needed, and if not that it can use the generic behaviour. > > > >And we could create a generic driver, for the generic behaviour if > >needed. > > > >> There's another issue: if we introduce edp-connector we'll have to > >> specify power up delays somewhere (in dts? or in platform driver?), > >so > >> edp-connector doesn't really solve the issue of multiple panels with > >> same motherboard. > > > >And that's what that compatible is about :) > > Maybe we can introduce a connector w/o any driver just like hdmi-connector? Ironically, a driver for it has been sent yesterday :) But yeah, we can definitely do that too. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/60] drm/bridge: simple-bridge: Add support for non-VGA bridges
On 07.07.2019 20:18, Laurent Pinchart wrote:
> Create a new simple_bridge_info structure that stores information about
> the bridge model, and store the bridge timings in there, along with the
> connector type. Use that new structure for of_device_id data. This
> enables support for non-VGA bridges.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 41 ++
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index da5479bd5878..bff240cf283d 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -16,10 +16,17 @@
> #include
> #include
>
> +struct simple_bridge_info {
> + const struct drm_bridge_timings *timings;
> + unsigned int type;
> +};
> +
> struct simple_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
>
> + const struct simple_bridge_info *info;
> +
> struct i2c_adapter *ddc;
> struct regulator*vdd;
> };
> @@ -113,7 +120,7 @@ static int simple_bridge_attach(struct drm_bridge *bridge)
>_bridge_con_helper_funcs);
> ret = drm_connector_init(bridge->dev, >connector,
>_bridge_con_funcs,
> - DRM_MODE_CONNECTOR_VGA);
> + sbridge->info->type);
> if (ret) {
> DRM_ERROR("Failed to initialize connector\n");
> return ret;
> @@ -182,6 +189,8 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, sbridge);
>
> + sbridge->info = of_device_get_match_data(>dev);
> +
> sbridge->vdd = devm_regulator_get_optional(>dev, "vdd");
> if (IS_ERR(sbridge->vdd)) {
> int ret = PTR_ERR(sbridge->vdd);
> @@ -204,7 +213,7 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
>
> sbridge->bridge.funcs = _bridge_bridge_funcs;
> sbridge->bridge.of_node = pdev->dev.of_node;
> - sbridge->bridge.timings = of_device_get_match_data(>dev);
> + sbridge->bridge.timings = sbridge->info->timings;
>
> drm_bridge_add(>bridge);
>
> @@ -264,19 +273,27 @@ static const struct drm_bridge_timings
> ti_ths8135_bridge_timings = {
> static const struct of_device_id simple_bridge_match[] = {
> {
> .compatible = "dumb-vga-dac",
> - .data = NULL,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "adi,adv7123",
> - .data = _bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = _bridge_timings,
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "ti,ths8135",
> - .data = _ths8135_bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = _ths8135_bridge_timings,
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "ti,ths8134",
> - .data = _ths8134_bridge_timings,
> + .data = &(const struct simple_bridge_info) {
> + .timings = _ths8134_bridge_timings,
> + .type = DRM_MODE_CONNECTOR_VGA,
> + },
> },
> {},
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/komeda: remove set but not used variable 'old'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/arm/display/komeda/komeda_plane.c:
In function komeda_plane_atomic_duplicate_state:
drivers/gpu/drm/arm/display/komeda/komeda_plane.c:161:35:
warning: variable old set but not used [-Wunused-but-set-variable
It is not used since commit 990dee3aa456 ("drm/komeda:
Computing image enhancer internally")
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index c095af1..c1381ac 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -158,8 +158,6 @@ static void komeda_plane_reset(struct drm_plane *plane)
static struct drm_plane_state *
komeda_plane_atomic_duplicate_state(struct drm_plane *plane)
{
- struct komeda_plane_state *new, *old;
-
if (WARN_ON(!plane->state))
return NULL;
@@ -169,8 +167,6 @@ komeda_plane_atomic_duplicate_state(struct drm_plane *plane)
__drm_atomic_helper_plane_duplicate_state(plane, >base);
- old = to_kplane_st(plane->state);
-
return >base;
}
--
2.7.4
Re: [PATCH] drm/vkms: prime import support
Hi Oleg,
First of all, thank you for your patch and for working in this issue.
A few comments inline.
On Thu, Jul 4, 2019 at 5:54 AM Oleg Vasilev wrote:
>
> Bring dmabuf sharing through implementing prime_import_sg_table callback.
> This will help to validate userspace conformance in prime configurations
> without using any actual hardware (e.g. in the cloud).
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Signed-off-by: Oleg Vasilev
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 6 +
> drivers/gpu/drm/vkms/vkms_drv.h | 9 +++
> drivers/gpu/drm/vkms/vkms_gem.c | 46 +
> 3 files changed, 61 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cc53ef88a331..b71c16d9ca09 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -10,6 +10,7 @@
> */
>
> #include
> +#include
Maybe I missed something, but I think you don't need to add this
include here since you already included it on vkms_gem.
> #include
> #include
> #include
> @@ -96,6 +97,8 @@ static struct drm_driver vkms_driver = {
> .gem_vm_ops = _gem_vm_ops,
> .gem_free_object_unlocked = vkms_gem_free_object,
> .get_vblank_timestamp = vkms_get_vblank_timestamp,
> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> @@ -147,6 +150,9 @@ static int __init vkms_init(void)
>
> ret = drm_dev_init(_device->drm, _driver,
>_device->platform->dev);
> +
> + dma_coerce_mask_and_coherent(vkms_device->drm.dev,
> +DMA_BIT_MASK(64));
How about capture the return value from dma_coerce_mask_and_coherent()
and warn the user if something wrong happened? Something like:
ret = dma_coerce_mask_and_coherent(..);
if (ret)
DRM_WARN("Failed to set dma mask");
Additionally, I would like to suggest you move this code above
drm_dev_init() since there's a return validation of ret in the below
if.
> if (ret)
> goto out_unregister;
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 12b4db7ac641..fb15101c8f3e 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -126,6 +126,9 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
> *dev,
>u32 *handle,
>u64 size);
>
> +struct vkms_gem_object *vkms_gem_create_private(struct drm_device *dev,
> + u64 size);
> +
> vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
>
> int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
> @@ -137,6 +140,12 @@ int vkms_gem_vmap(struct drm_gem_object *obj);
>
> void vkms_gem_vunmap(struct drm_gem_object *obj);
>
> +/* Prime */
> +struct drm_gem_object *
> +vkms_prime_import_sg_table(struct drm_device *dev,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sg);
> +
> /* CRC Support */
> const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
> size_t *count);
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index 69048e73377d..a1b837460f63 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -1,5 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> +#include
> #include
>
> #include "vkms_drv.h"
> @@ -117,6 +118,25 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
> *dev,
> return >gem;
> }
>
> +struct vkms_gem_object *vkms_gem_create_private(struct drm_device *dev,
> + u64 size)
> +{
I did not fully get the idea behind this function in this patch, and
it looks like this function is never invoked. Am I right or I missed
something?
> + struct vkms_gem_object *obj;
> +
> + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> +
> + if (!obj)
> + return ERR_PTR(-ENOMEM);
> +
> + size = roundup(size, PAGE_SIZE);
> +
> + drm_gem_private_object_init(dev, >gem, size);
Please, correct if I'm wrong, I'm trying to understand where this
function should be placed and when it is invoked. If I correctly
understood, you want to use this function for creating a separate gem
object to be used as a private area to be shared with another device,
am I right? If I am right, I'm wondering if we could reuse or update
some of the functions available in the vkms_gem. If I am wrong, I'm
wondering if we may have synchronization problems for handling
multiples mutex for accessing pages. Could you help me here?
> +
> + mutex_init(>pages_lock);
> +
>
Re: [PATCH 04/60] drm/bridge: dumb-vga-dac: Rename driver to simple-bridge
On 07.07.2019 20:18, Laurent Pinchart wrote:
> The dumb-vga-dac driver can support simple DRM bridges without being
> limited to VGA DACs. Rename it to simple-bridge.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> arch/arm/configs/davinci_all_defconfig | 2 +-
> arch/arm/configs/integrator_defconfig| 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/shmobile_defconfig | 2 +-
> arch/arm/configs/sunxi_defconfig | 2 +-
> arch/arm/configs/versatile_defconfig | 2 +-
> drivers/gpu/drm/bridge/Kconfig | 16
> drivers/gpu/drm/bridge/Makefile | 2 +-
> .../bridge/{dumb-vga-dac.c => simple-bridge.c} | 2 +-
> 9 files changed, 16 insertions(+), 16 deletions(-)
> rename drivers/gpu/drm/bridge/{dumb-vga-dac.c => simple-bridge.c} (99%)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig
> b/arch/arm/configs/davinci_all_defconfig
> index 4a8cad4d3707..f422d34a4e4e 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -154,7 +154,7 @@ CONFIG_VIDEO_TVP514X=m
> CONFIG_VIDEO_ADV7343=m
> CONFIG_DRM=m
> CONFIG_DRM_TILCDC=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_TINYDRM=m
> CONFIG_TINYDRM_ST7586=m
> CONFIG_FB=y
> diff --git a/arch/arm/configs/integrator_defconfig
> b/arch/arm/configs/integrator_defconfig
> index 747550c7af2f..4d265a689655 100644
> --- a/arch/arm/configs/integrator_defconfig
> +++ b/arch/arm/configs/integrator_defconfig
> @@ -55,7 +55,7 @@ CONFIG_SMC91X=y
> # CONFIG_KEYBOARD_ATKBD is not set
> # CONFIG_SERIO_SERPORT is not set
> CONFIG_DRM=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_PL111=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_MATROX=y
> diff --git a/arch/arm/configs/multi_v7_defconfig
> b/arch/arm/configs/multi_v7_defconfig
> index 6b748f214eae..634e029a5736 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -643,11 +643,11 @@ CONFIG_DRM_PANEL_ORISETECH_OTM8009A=m
> CONFIG_DRM_PANEL_RAYDIUM_RM68200=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> CONFIG_DRM_NXP_PTN3460=m
> CONFIG_DRM_PARADE_PS8622=m
> CONFIG_DRM_SII902X=m
> CONFIG_DRM_SII9234=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_TOSHIBA_TC358764=m
> CONFIG_DRM_I2C_ADV7511=m
> CONFIG_DRM_I2C_ADV7511_AUDIO=y
> diff --git a/arch/arm/configs/shmobile_defconfig
> b/arch/arm/configs/shmobile_defconfig
> index eb02ba9ec6e6..771074e399fb 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -125,8 +125,8 @@ CONFIG_VIDEO_ADV7604=y
> CONFIG_VIDEO_ML86V7667=y
> CONFIG_DRM=y
> CONFIG_DRM_RCAR_DU=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> CONFIG_DRM_SII902X=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_I2C_ADV7511=y
> CONFIG_DRM_I2C_ADV7511_AUDIO=y
> CONFIG_FB_SH_MOBILE_LCDC=y
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index df433abfcb02..19cccae84a19 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -99,7 +99,7 @@ CONFIG_RC_DEVICES=y
> CONFIG_IR_SUNXI=y
> CONFIG_DRM=y
> CONFIG_DRM_SUN4I=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_FB_SIMPLE=y
> CONFIG_SOUND=y
> CONFIG_SND=y
> diff --git a/arch/arm/configs/versatile_defconfig
> b/arch/arm/configs/versatile_defconfig
> index 5282324c7cef..afc44c99e7f9 100644
> --- a/arch/arm/configs/versatile_defconfig
> +++ b/arch/arm/configs/versatile_defconfig
> @@ -59,7 +59,7 @@ CONFIG_GPIO_PL061=y
> CONFIG_DRM=y
> CONFIG_DRM_PANEL_ARM_VERSATILE=y
> CONFIG_DRM_PANEL_SIMPLE=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_PL111=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index ee777469293a..a78392e2dbb9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -37,14 +37,6 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> -config DRM_DUMB_VGA_DAC
> - tristate "Dumb VGA DAC Bridge support"
> - depends on OF
> - select DRM_KMS_HELPER
> - help
> - Support for non-programmable RGB to VGA DAC bridges, such as ADI
> - ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> -
> config DRM_LVDS_ENCODER
> tristate "Transparent parallel to LVDS encoder support"
> depends on OF
> @@ -108,6 +100,14 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>
> +config DRM_SIMPLE_BRIDGE
> + tristate "Simple DRM bridge
Re: [PATCH 03/60] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge
On 07.07.2019 20:07, Laurent Pinchart wrote:
> The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
> DACs that don't require configuration. Other non-VGA bridges fall in a
> similar category, and would benefit from a common driver. Prepare for
> this by renaming the internal symbols from dumb-vga-dac to
> simple-bridge.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 149 +-
> 1 file changed, 75 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index d32885b906ae..d46e461ae039 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -16,7 +16,7 @@
> #include
> #include
>
> -struct dumb_vga {
> +struct simple_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
>
> @@ -24,28 +24,28 @@ struct dumb_vga {
> struct regulator*vdd;
> };
>
> -static inline struct dumb_vga *
> -drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +static inline struct simple_bridge *
> +drm_bridge_to_simple_bridge(struct drm_bridge *bridge)
> {
> - return container_of(bridge, struct dumb_vga, bridge);
> + return container_of(bridge, struct simple_bridge, bridge);
> }
>
> -static inline struct dumb_vga *
> -drm_connector_to_dumb_vga(struct drm_connector *connector)
> +static inline struct simple_bridge *
> +drm_connector_to_simple_bridge(struct drm_connector *connector)
> {
> - return container_of(connector, struct dumb_vga, connector);
> + return container_of(connector, struct simple_bridge, connector);
> }
>
> -static int dumb_vga_get_modes(struct drm_connector *connector)
> +static int simple_bridge_get_modes(struct drm_connector *connector)
> {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge =
> drm_connector_to_simple_bridge(connector);
> struct edid *edid;
> int ret;
>
> - if (IS_ERR(vga->ddc))
> + if (IS_ERR(sbridge->ddc))
> goto fallback;
>
> - edid = drm_get_edid(connector, vga->ddc);
> + edid = drm_get_edid(connector, sbridge->ddc);
> if (!edid) {
> DRM_INFO("EDID readout failed, falling back to standard
> modes\n");
> goto fallback;
> @@ -69,14 +69,14 @@ static int dumb_vga_get_modes(struct drm_connector
> *connector)
> return ret;
> }
>
> -static const struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> - .get_modes = dumb_vga_get_modes,
> +static const struct drm_connector_helper_funcs
> simple_bridge_con_helper_funcs = {
> + .get_modes = simple_bridge_get_modes,
> };
>
> static enum drm_connector_status
> -dumb_vga_connector_detect(struct drm_connector *connector, bool force)
> +simple_bridge_connector_detect(struct drm_connector *connector, bool force)
> {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge =
> drm_connector_to_simple_bridge(connector);
>
> /*
>* Even if we have an I2C bus, we can't assume that the cable
> @@ -84,14 +84,14 @@ dumb_vga_connector_detect(struct drm_connector
> *connector, bool force)
>* wire the DDC pins, or the I2C bus might not be working at
>* all.
>*/
> - if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> + if (!IS_ERR(sbridge->ddc) && drm_probe_ddc(sbridge->ddc))
> return connector_status_connected;
>
> return connector_status_unknown;
> }
>
> -static const struct drm_connector_funcs dumb_vga_con_funcs = {
> - .detect = dumb_vga_connector_detect,
> +static const struct drm_connector_funcs simple_bridge_con_funcs = {
> + .detect = simple_bridge_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy= drm_connector_cleanup,
> .reset = drm_atomic_helper_connector_reset,
> @@ -99,9 +99,9 @@ static const struct drm_connector_funcs dumb_vga_con_funcs
> = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static int dumb_vga_attach(struct drm_bridge *bridge)
> +static int simple_bridge_attach(struct drm_bridge *bridge)
> {
> - struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> int ret;
>
> if (!bridge->encoder) {
> @@ -109,48 +109,49 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
> return -ENODEV;
> }
>
> - drm_connector_helper_add(>connector,
> - _vga_con_helper_funcs);
> - ret = drm_connector_init(bridge->dev, >connector,
> - _vga_con_funcs,
Re: [PATCH v5 05/12] drm/modes: Rewrite the command line parser
On 09/07/2019 14:26, Jon Hunter wrote: > > On 09/07/2019 13:52, Dmitry Osipenko wrote: >> 09.07.2019 15:45, Maxime Ripard пишет: >>> Hi, >>> >>> On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote: 17.06.2019 17:51, Maxime Ripard пишет: > From: Maxime Ripard > > Rewrite the command line parser in order to get away from the state > machine > parsing the video mode lines. > > Hopefully, this will allow to extend it more easily to support named modes > and / or properties set directly on the command line. > > Reviewed-by: Noralf Trønnes > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/drm_modes.c | 325 +++-- > 1 file changed, 210 insertions(+), 115 deletions(-) I have a Tegra device that uses a stock android bootloader which passes "video=tegrafb" in the kernels cmdline. That wasn't a problem before this patch, but now Tegra DRM driver fails to probe because the mode is 0x0:0 and hence framebuffer allocation fails. Is it a legit regression that should be fixed in upstream? >>> >>> Thierry indeed reported that issue, but the discussion pretty much >>> stalled since then. > > Yes Thierry is currently out and hence has not responded. I had been > planning to look at this this week and responded. > >> Sorry, this doesn't answer my question. Where it was reported? > > Same thread [0]. Correction, it was on patch 6/12 and not this one. Jon -- nvpublic ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/12] drm/modes: Rewrite the command line parser
On 09/07/2019 13:52, Dmitry Osipenko wrote: > 09.07.2019 15:45, Maxime Ripard пишет: >> Hi, >> >> On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote: >>> 17.06.2019 17:51, Maxime Ripard пишет: From: Maxime Ripard Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_modes.c | 325 +++-- 1 file changed, 210 insertions(+), 115 deletions(-) >>> >>> I have a Tegra device that uses a stock android bootloader which >>> passes "video=tegrafb" in the kernels cmdline. That wasn't a problem >>> before this patch, but now Tegra DRM driver fails to probe because >>> the mode is 0x0:0 and hence framebuffer allocation fails. Is it a >>> legit regression that should be fixed in upstream? >> >> Thierry indeed reported that issue, but the discussion pretty much >> stalled since then. Yes Thierry is currently out and hence has not responded. I had been planning to look at this this week and responded. > Sorry, this doesn't answer my question. Where it was reported? Same thread [0]. Dmitry, are you able to respond to Maxime's response to Thierry? Cheers Jon [0] https://patchwork.kernel.org/patch/10999393/ -- nvpublic ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/6] drm: Add Content protection type property
On Mon, 8 Jul 2019 14:42:29 +0530
Ramalingam C wrote:
> On 2019-07-08 at 12:59:59 +0300, Pekka Paalanen wrote:
> > On Mon, 8 Jul 2019 12:52:17 +0300
> > Pekka Paalanen wrote:
> >
> > > On Fri, 5 Jul 2019 06:16:37 +0530
> > > Ramalingam C wrote:
> > >
> > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > This property is used for mentioning the protected content's type
> > > > from userspace to kernel HDCP authentication.
> > > >
> > > > Type of the stream is decided by the protected content providers.
> > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > >
> > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > enable, kernel will honour it only if HDCP2.2 authentication is through
> > > > for type 1. Else HDCP enable will be failed.
> > > >
> > > > Need ACK for this new conenctor property from userspace consumer.
> > > >
> > > > v2:
> > > > cp_content_type is replaced with content_protection_type [daniel]
> > > > check at atomic_set_property is removed [Maarten]
> > > > v3:
> > > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > > v4:
> > > > property is created for the first requested connector and then reused.
> > > > [Danvet]
> > > > v5:
> > > > kernel doc nits addressed [Daniel]
> > > > Rebased as part of patch reordering.
> > > > v6:
> > > > Kernel docs are modified [pekka]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > Reviewed-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > > > drivers/gpu/drm/drm_connector.c | 22 ++
> > > > drivers/gpu/drm/drm_hdcp.c| 36 ++-
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > > > include/drm/drm_connector.h | 7 +
> > > > include/drm/drm_hdcp.h| 2 +-
> > > > include/drm/drm_mode_config.h | 6
> > > > include/uapi/drm/drm_mode.h | 4 +++
> > > > 8 files changed, 82 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > index abe38bdf85ae..19ae119f1a5d 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> > > > drm_connector *connector,
> > > > return -EINVAL;
> > > > }
> > > > state->content_protection = val;
> > > > + } else if (property == config->hdcp_content_type_property) {
> > > > + state->hdcp_content_type = val;
> > > > } else if (property == connector->colorspace_property) {
> > > > state->colorspace = val;
> > > > } else if (property == config->writeback_fb_id_property) {
> > > > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct
> > > > drm_connector *connector,
> > > > state->hdr_output_metadata->base.id : 0;
> > > > } else if (property == config->content_protection_property) {
> > > > *val = state->content_protection;
> > > > + } else if (property == config->hdcp_content_type_property) {
> > > > + *val = state->hdcp_content_type;
> > > > } else if (property == config->writeback_fb_id_property) {
> > > > /* Writeback framebuffer is one-shot, write and forget
> > > > */
> > > > *val = 0;
> > > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > > b/drivers/gpu/drm/drm_connector.c
> > > > index 068d4b05f1be..17aef88c03a6 100644
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -951,6 +951,28 @@ static const struct drm_prop_enum_list
> > > > hdmi_colorspaces[] = {
> > > > * the value transitions from ENABLED to DESIRED. This signifies
> > > > the link
> > > > * is no longer protected and userspace should take appropriate
> > > > action
> > > > * (whatever that might be).
> > > > + * HDCP Content Type:
> > > > + * This property is used by the userspace to configure the kernel
> > > > with
> > > > + * to be displayed stream's content type. Content Type of a stream
> > > > is
> > > > + * decided by the owner of the stream, as "HDCP Type0" or "HDCP
> > > > Type1".
> > > > + *
> > > > + * The value of the property can be one the below:
> > > > + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> > > > + * HDCP Type0 streams can be transmitted on a link which is
> > > > + * encrypted with HDCP 1.4 or higher versions of HDCP(i.e
> > > > HDCP2.2
> > > > + * and more).
> > > > + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> > > > + * HDCP Type1 streams
Re: [PATCH 02/60] video: hdmi: Change return type of hdmi_avi_infoframe_init() to void
On 07.07.2019 20:07, Laurent Pinchart wrote: > The hdmi_avi_infoframe_init() never needs to return an error, change its > return type to void. > > Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/60] drm/edid: Add flag to drm_display_info to identify HDMI sinks
On 07.07.2019 20:07, Laurent Pinchart wrote:
> The drm_display_info structure contains many fields related to HDMI
> sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
> shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
> populate it according to section 8.3.3 ("DVI/HDMI Device
> Discrimination") of the HDMI v1.3 specification.
>
> Signed-off-by: Laurent Pinchart
It looks like it can replace drm_detect_hdmi_monitor usage in most cases.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> include/drm/drm_connector.h | 5 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 82a4ceed3fcf..d2e7a5334c3f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4559,6 +4559,8 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
> *connector, const u8 *db)
> struct drm_display_info *info = >display_info;
> u8 len = cea_db_payload_len(db);
>
> + info->is_hdmi = true;
> +
> if (len >= 6)
> info->dvi_dual = db[6] & 1;
> if (len >= 7)
> @@ -4627,6 +4629,7 @@ drm_reset_display_info(struct drm_connector *connector)
> info->cea_rev = 0;
> info->max_tmds_clock = 0;
> info->dvi_dual = false;
> + info->is_hdmi = false;
> info->has_hdmi_infoframe = false;
> info->rgb_quant_range_selectable = false;
> memset(>hdmi, 0, sizeof(info->hdmi));
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ca745d9feaf5..e80ca0d149e5 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -426,6 +426,11 @@ struct drm_display_info {
>*/
> bool dvi_dual;
>
> + /**
> + * @is_hdmi: True if the sink is an HDMI device.
> + */
> + bool is_hdmi;
> +
> /**
>* @has_hdmi_infoframe: Does the sink support the HDMI infoframe?
>*/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #21 from ITwrx --- @juan sure, but i'll probably wait long enough for arch to package the new version. Thanks for letting me know. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] fbdev changes for v5.3
Hi Linus,
Please pull fbdev changes for v5.3. They are:
- removal of fbdev notifier usage for fbcon
- COMPILE_TEST support for more fb drivers
- removal of no longer needed fbdev mxsfb driver
- minor fixes/cleanups for other fb drivers
Please see the signed tag description for details.
Test merge revealed a small merge conflict with SPDX changes, the
resolution is trivial (drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
should be deleted).
Also there is a conflict with media tree (pull request for media
tree has been posted a bit earlier today by Mauro), a fix for it
has been carried in linux-next tree by Stephen:
diff --cc drivers/media/pci/ivtv/ivtvfb.c
index 800b3654cac5,299ff032f528..
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@@ -1251,16 -1246,7 +1251,12 @@@ static int ivtvfb_callback_cleanup(stru
struct osd_info *oi = itv->osd_info;
if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
+ itv->streams[IVTV_DEC_STREAM_TYPE_YUV].vdev.device_caps &=
+ ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
+ itv->streams[IVTV_DEC_STREAM_TYPE_MPG].vdev.device_caps &=
+ ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
+ itv->v4l2_cap &= ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
- if (unregister_framebuffer(>osd_info->ivtvfb_info)) {
- IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
- itv->instance);
- return 0;
- }
+ unregister_framebuffer(>osd_info->ivtvfb_info);
IVTVFB_INFO("Unregister framebuffer %d\n", itv->instance);
itv->ivtvfb_restore = NULL;
ivtvfb_blank(FB_BLANK_VSYNC_SUSPEND, >ivtvfb_info);
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the git repository at:
https://github.com/bzolnier/linux.git tags/fbdev-v5.3
for you to fetch changes up to 732146a3f1dc78ebb0d3c4b1f4dc6ea33cc2c58f:
video: fbdev: imxfb: fix a typo in imxfb_probe() (2019-07-05 17:42:13 +0200)
fbdev changes for v5.3:
- remove fbdev notifier usage for fbcon (as prep work to clean up the fbcon
locking), add locking checks in vt/console code and make assorted cleanups
in fbdev and backlight code (Daniel Vetter)
- add COMPILE_TEST support to atmel_lcdfb, da8xx-fb, gbefb, imxfb, pvr2fb and
pxa168fb drivers (me)
- fix DMA API abuse in au1200fb and jz4740_fb drivers (Christoph Hellwig)
- add check for new BGRT status field rotation bits in efifb driver (Hans de
Goede)
- mark expected switch fall-throughs in s3c-fb driver (Gustavo A. R. Silva)
- remove fbdev mxsfb driver in favour of the drm version (Fabio Estevam)
- remove broken rfbi code from omap2fb driver (me)
- misc fixes (Arnd Bergmann, Shobhit Kukreti, Wei Yongjun, me)
- misc cleanups (Gustavo A. R. Silva, Colin Ian King, me)
Arnd Bergmann (1):
video: fbdev: pvr2fb: fix link error for pvr2fb_pci_exit
Bartlomiej Zolnierkiewicz (21):
Merge tag 'v5.2-rc1' of https://git.kernel.org/.../torvalds/linux into
fbdev-for-next
video: fbdev: atafb: remove superfluous function prototypes
video: fbdev: atmel_lcdfb: add COMPILE_TEST support
video: fbdev: imxfb: add COMPILE_TEST support
video: fbdev: pxa168fb: add COMPILE_TEST support
video: fbdev: gbefb: add COMPILE_TEST support
video: fbdev: da8xx-fb: add COMPILE_TEST support
video: fbdev: cyber2000fb: remove superfluous CONFIG_PCI ifdef
video: fbdev: pvr2fb: remove function prototypes
video: fbdev: pvr2fb: add COMPILE_TEST support
Merge tag 'topic/remove-fbcon-notifiers-2019-06-14-1' of
git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next
Merge branch 'topic/remove-fbcon-notifiers' of
git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next
video: fbdev: pvr2fb: fix build warning when compiling as module
video: fbdev: imxfb: fix sparse warnings about using incorrect types
video: fbdev: s3c-fb: add COMPILE_TEST support
video: fbdev: omap2: remove rfbi
Merge tag 'topic/remove-fbcon-notifiers-2019-06-26' of
git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next
video: fbdev: s3c-fb: return -ENOMEM on framebuffer_alloc() failure
video: fbdev: intelfb: return -ENOMEM on framebuffer_alloc() failure
video: fbdev: don't print error message on framebuffer_alloc() failure
video: fbdev: s3c-fb: fix sparse warnings about using incorrect types
Christoph Hellwig (2):
au1200fb: fix DMA API abuse
jz4740_fb: fix DMA API abuse
Colin Ian King (1):
video: fbdev: atmel_lcdfb:
Re: [PATCH v2 03/19] arm64: renesas: Update 'vsps' property
Hi Jacopo,
On 08/07/2019 04:11, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:30PM +0200, Jacopo Mondi wrote:
>> Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
>> match what's in in the documentation example.
>>
>> Signed-off-by: Jacopo Mondi
>
> Reviewed-by: Laurent Pinchart
+1 from me too. This certainly improves readability/clarity IMO.
Reviewed-by: Kieran Bingham
>
>> ---
>> arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 +-
>> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> index 3f86db199dbf..e643f9d3c102 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
>> @@ -1807,7 +1807,7 @@
>> clocks = < CPG_MOD 724>,
>> < CPG_MOD 723>;
>> clock-names = "du.0", "du.1";
>> -vsps = < 0 0>;
>> +vsps = < 0>, < 0>;
>> status = "disabled";
>>
>> ports {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> index 097538cc4b1f..432f4036a8a8 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -3098,7 +3098,7 @@
>> < CPG_MOD 722>,
>> < CPG_MOD 721>;
>> clock-names = "du.0", "du.1", "du.2", "du.3";
>> -vsps = < 0 0 0 1>;
>> +vsps = < 0>, < 0>, < 0>, < 1>;
>> status = "disabled";
>>
>> ports {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> index 2554b1742dbf..b701aeb4f438 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> @@ -2456,7 +2456,7 @@
>> clock-names = "du.0", "du.1", "du.3";
>> status = "disabled";
>>
>> -vsps = < 0 0 1>;
>> +vsps = < 0>, < 0>, < 1>;
>>
>> ports {
>> #address-cells = <1>;
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> index 56cb566ffa09..79db5441b7e7 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>> @@ -1764,7 +1764,7 @@
>> clocks = < CPG_MOD 724>,
>> < CPG_MOD 723>;
>> clock-names = "du.0", "du.1";
>> -vsps = < 0 0>;
>> +vsps = < 0>, < 0>;
>> status = "disabled";
>>
>> ports {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> index 5bf3af246e14..49a11b4f55bd 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> @@ -1001,7 +1001,7 @@
>> clocks = < CPG_MOD 724>,
>> < CPG_MOD 723>;
>> clock-names = "du.0", "du.1";
>> -vsps = < 0 0>;
>> +vsps = < 0>, < 0>;
>> status = "disabled";
>>
>> ports {
>
Re: [PATCH] drm/amdgpu: Fix build without CONFIG_HMM_MIRROR
On Tue, Jul 9, 2019 at 8:55 AM YueHaibing wrote:
>
> If CONFIG_HMM_MIRROR is not set, building may fails:
>
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu.h:72:0,
> from drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:40:
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h:69:20: error: field mirror has
> incomplete type
> struct hmm_mirror mirror;
>
> Fixes: 7590f6d211ec ("drm/amdgpu: Prepare for hmm_range_register API change")
> Signed-off-by: YueHaibing
I already applied a similar patch from Arnd.
Thanks,
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> index 281fd9f..b14f175 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
> @@ -65,8 +65,10 @@ struct amdgpu_mn {
> struct rw_semaphore lock;
> struct rb_root_cached objects;
>
> +#if defined(CONFIG_HMM_MIRROR)
> /* HMM mirror */
> struct hmm_mirror mirror;
> +#endif
> };
>
> #if defined(CONFIG_HMM_MIRROR)
> --
> 2.7.4
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] v4l: Add definitions for missing 16-bit RGB4444 formats
Hi Laurent,
On 3/28/19 8:07 AM, Laurent Pinchart wrote:
> The V4L2 API is missing the 16-bit RGB formats for the RGBA, RGBX,
> ABGR, XBGR, BGRA and BGRX component orders. Add them, using the same
> 4CCs as DRM.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../media/uapi/v4l/pixfmt-packed-rgb.rst | 138 ++
> include/uapi/linux/videodev2.h| 6 +
> 2 files changed, 144 insertions(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4e5222726719..df9fa78a6ab7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -514,6 +514,12 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_RGB444 v4l2_fourcc('R', '4', '4', '4') /* 16
> */
> #define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_RGBA444 v4l2_fourcc('R', 'A', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_RGBX444 v4l2_fourcc('R', 'X', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_ABGR444 v4l2_fourcc('A', 'B', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16
> */
> +#define V4L2_PIX_FMT_BGRA444 v4l2_fourcc('B', 'A', '1', '2') /* 16
> */
Hmm, 'BA12' clashes with V4L2_PIX_FMT_SGRBG12 which has the same fourcc.
That fourcc makes no sense for V4L2_PIX_FMT_SGRBG12 and I suspect it was
a mistake, but it's been in use since 2014.
I think V4L2_PIX_FMT_BGRA444 should get a different fourcc and be backported to
5.2.
Can you address this issue?
Regards,
Hans
> +#define V4L2_PIX_FMT_BGRX444 v4l2_fourcc('B', 'X', '1', '2') /* 16
> */
> #define V4L2_PIX_FMT_RGB555 v4l2_fourcc('R', 'G', 'B', 'O') /* 16
> RGB-5-5-5 */
> #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
> ARGB-1-5-5-5 */
> #define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16
> XRGB-1-5-5-5 */
>
Re: [PATCH v5 05/12] drm/modes: Rewrite the command line parser
Hi, On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote: > 17.06.2019 17:51, Maxime Ripard пишет: > > From: Maxime Ripard > > > > Rewrite the command line parser in order to get away from the state machine > > parsing the video mode lines. > > > > Hopefully, this will allow to extend it more easily to support named modes > > and / or properties set directly on the command line. > > > > Reviewed-by: Noralf Trønnes > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/drm_modes.c | 325 +++-- > > 1 file changed, 210 insertions(+), 115 deletions(-) > > I have a Tegra device that uses a stock android bootloader which > passes "video=tegrafb" in the kernels cmdline. That wasn't a problem > before this patch, but now Tegra DRM driver fails to probe because > the mode is 0x0:0 and hence framebuffer allocation fails. Is it a > legit regression that should be fixed in upstream? Thierry indeed reported that issue, but the discussion pretty much stalled since then. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event
On Mon, Jul 8, 2019 at 1:03 PM Cheng-yi Chiang wrote: > > On Fri, Jul 5, 2019 at 8:12 PM Mark Brown wrote: > > > > On Fri, Jul 05, 2019 at 03:08:37PM +0800, Tzung-Bi Shih wrote: > > > On Fri, Jul 5, 2019 at 12:26 PM Cheng-Yi Chiang > > > wrote: > > > > > > +typedef void (*hdmi_codec_plugged_cb)(struct platform_device *dev, > > > > + bool plugged); > > > > + > > > > > The callback prototype is "weird" by struct platform_device. Is it > > > possible to having snd_soc_component instead of platform_device? > > > > Or if it's got to be a device why not just a generic device so > > we're not tied to a particular bus here? > > My intention was to invoke the call in dw-hdmi.c like this: > > hdmi->plugged_cb(hdmi->audio, >result == connector_status_connected); > > Here hdmi->audio is a platform_device. > I think dw-hdmi can not get snd_soc_component easily. > I can use a generic device here so the ops is more general. > The calling will be like > hdmi->plugged_cb(>audio->dev, >result == connector_status_connected); > I will update this in v2. > Thanks! I have thought about this a bit more. And I think the more proper interface is to pass in a generic struct device* for codec. This way, the user of hdmi-codec driver on the DRM side is not limited to the relation chain of audio platform device -> codec platform device, which is just a special case in dw-hdmi driver. As long as DRM side can get hdmi-codec device pointer through drv_data, it can use this callback. Hope this makes the interface more generic.
Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event
On Tue, Jul 9, 2019 at 7:47 PM Cezary Rojewski
wrote:
>
> On 2019-07-05 06:26, Cheng-Yi Chiang wrote:
> > +static void hdmi_codec_jack_report(struct hdmi_codec_priv *hcp,
> > +unsigned int jack_status)
> > +{
> > + if (!hcp->jack)
> > + return;
> > +
> > + if (jack_status != hcp->jack_status) {
> > + snd_soc_jack_report(hcp->jack, jack_status, SND_JACK_LINEOUT);
> > + hcp->jack_status = jack_status;
> > + }
> > +}
>
> Single "if" statement instead? The first "if" does not even cover all
> cases - if the secondary check fails, you'll "return;" too.
>
ACK.
I will fix in v2.
> > +/**
> > + * hdmi_codec_set_jack_detect - register HDMI plugged callback
> > + * @component: the hdmi-codec instance
> > + * @jack: ASoC jack to report (dis)connection events on
> > + */
> > +int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
> > +struct snd_soc_jack *jack)
> > +{
> > + struct hdmi_codec_priv *hcp =
> > snd_soc_component_get_drvdata(component);
> > + int ret;
> > +
> > + if (hcp->hcd.ops->hook_plugged_cb) {
> > + hcp->jack = jack;
> > + ret = hcp->hcd.ops->hook_plugged_cb(component->dev->parent,
> > + hcp->hcd.data,
> > + plugged_cb);
> > + if (ret) {
> > + hcp->jack = NULL;
> > + return ret;
> > + }
> > + return 0;
> > + }
> > + return -EOPNOTSUPP;
> > +}
> > +EXPORT_SYMBOL_GPL(hdmi_codec_set_jack_detect);
>
> int ret = -EOPNOTSUPP;
> (...)
>
> return ret;
>
> In consequence, you can reduce the number of "return(s)" and also remove
> the redundant parenthesis for the if-statement used to set jack to NULL.
>
> Czarek
ACK
will fix in v2.
Thanks a lot for the review!
Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event
On 2019-07-05 06:26, Cheng-Yi Chiang wrote:
+static void hdmi_codec_jack_report(struct hdmi_codec_priv *hcp,
+ unsigned int jack_status)
+{
+ if (!hcp->jack)
+ return;
+
+ if (jack_status != hcp->jack_status) {
+ snd_soc_jack_report(hcp->jack, jack_status, SND_JACK_LINEOUT);
+ hcp->jack_status = jack_status;
+ }
+}
Single "if" statement instead? The first "if" does not even cover all
cases - if the secondary check fails, you'll "return;" too.
+/**
+ * hdmi_codec_set_jack_detect - register HDMI plugged callback
+ * @component: the hdmi-codec instance
+ * @jack: ASoC jack to report (dis)connection events on
+ */
+int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
+ struct snd_soc_jack *jack)
+{
+ struct hdmi_codec_priv *hcp = snd_soc_component_get_drvdata(component);
+ int ret;
+
+ if (hcp->hcd.ops->hook_plugged_cb) {
+ hcp->jack = jack;
+ ret = hcp->hcd.ops->hook_plugged_cb(component->dev->parent,
+ hcp->hcd.data,
+ plugged_cb);
+ if (ret) {
+ hcp->jack = NULL;
+ return ret;
+ }
+ return 0;
+ }
+ return -EOPNOTSUPP;
+}
+EXPORT_SYMBOL_GPL(hdmi_codec_set_jack_detect);
int ret = -EOPNOTSUPP;
(...)
return ret;
In consequence, you can reduce the number of "return(s)" and also remove
the redundant parenthesis for the if-statement used to set jack to NULL.
Czarek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 4/5] drm/vkms: Compute CRC without change input data
On Tue, 2019-06-25 at 22:38 -0300, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the input
> framebuffer, which is not a problem since this function receives a
> copy
> of the original buffer. However, if we want to use this function in a
> context without a buffer copy, it will change the initial value. This
> patch makes compute_crc() calculate the CRC value without modifying
> the
> input framebuffer.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 31 +-
> --
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 51a270514219..8126aa0f968f 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -6,33 +6,40 @@
> #include
> #include
>
> +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> + const struct vkms_composer *composer)
> +{
> + int src_offset = composer->offset + (y * composer->pitch)
> + + (x * composer->cpp);
> +
> + return *(u32 *)[src_offset];
> +}
> +
> /**
> * compute_crc - Compute CRC value on output frame
> *
> - * @vaddr_out: address to final framebuffer
> + * @vaddr: address to final framebuffer
> * @composer: framebuffer's metadata
> *
> * returns CRC value computed using crc32 on the visible portion of
> * the final framebuffer at vaddr_out
> */
> -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer
> *composer)
> +static uint32_t compute_crc(const u8 *vaddr,
> + const struct vkms_composer *composer)
> {
> - int i, j, src_offset;
> + int x, y;
> int x_src = composer->src.x1 >> 16;
> int y_src = composer->src.y1 >> 16;
> int h_src = drm_rect_height(>src) >> 16;
> int w_src = drm_rect_width(>src) >> 16;
> - u32 crc = 0;
> + u32 crc = 0, pixel = 0;
>
> - for (i = y_src; i < y_src + h_src; ++i) {
> - for (j = x_src; j < x_src + w_src; ++j) {
> - src_offset = composer->offset
> - + (i * composer->pitch)
> - + (j * composer->cpp);
> + for (y = y_src; y < y_src + h_src; ++y) {
> + for (x = x_src; x < x_src + w_src; ++x) {
> /* XRGB format ignores Alpha channel */
> - memset(vaddr_out + src_offset + 24, 0, 8);
Hi Rodgrigo,
Do I understand correctly, that previous version with memset was
actually zeroing out the whole fb, except first 24 bytes? On the first
iteration bytes 24..32 would be zeroed, on the second 25..33, etc.
Should we add more CRC tests to IGT, so we can catch such mistakes? For
example, compute CRC, than augment random pixel and assert that CRC
changed.
Oleg
> - crc = crc32_le(crc, vaddr_out + src_offset,
> -sizeof(u32));
> + pixel = get_pixel_from_buffer(x, y, vaddr,
> composer);
> + bitmap_clear((void *), 0, 8);
> + crc = crc32_le(crc, (void *),
> sizeof(u32));
> }
> }
>
smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/client: remove the exporting of drm_client_close
Den 04.07.2019 16.07, skrev Emil Velikov: > On Thu, 4 Jul 2019 at 08:27, Denis Efremov wrote: >> >> The function drm_client_close is declared as static and marked as >> EXPORT_SYMBOL. It's a bit confusing for an internal function to be >> exported. The area of visibility for such function is its .c file >> and all other modules. Other *.c files of the same module can't use it, >> despite all other modules can. Relying on the fact that this is the >> internal function and it's not a crucial part of the API, the patch >> removes the EXPORT_SYMBOL marking of drm_client_close. >> >> Signed-off-by: Denis Efremov > > Nice one: > Reviewed-by: Emil Velikov Thanks, applied. Noralf.
[Bug 110944] [Bisected] Blender 2.8 crashes when closing certain windows
https://bugs.freedesktop.org/show_bug.cgi?id=110944 Juan A. Suarez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Juan A. Suarez --- The patch has been released also with Mesa 19.1.2. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #20 from Juan A. Suarez --- The fix has landed in 19.1.2 release. Can you try it again? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le
https://bugs.freedesktop.org/show_bug.cgi?id=110702 Juan A. Suarez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Juan A. Suarez --- And the fix is also included in Mesa 19.1.2 release. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] backlight: rave-sp: don't touch initial state and register with correct device
On Mon, Jul 08, 2019 at 02:41:29PM +0200, Lucas Stach wrote: > This way the backlight can be referenced through its device node and > enabling/disabling can be managed through the panel driver. > > Signed-off-by: Lucas Stach Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/rave-sp-backlight.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/backlight/rave-sp-backlight.c > b/drivers/video/backlight/rave-sp-backlight.c > index 462f14a1b19d..05b5f003a3d1 100644 > --- a/drivers/video/backlight/rave-sp-backlight.c > +++ b/drivers/video/backlight/rave-sp-backlight.c > @@ -48,14 +48,20 @@ static int rave_sp_backlight_probe(struct platform_device > *pdev) > struct device *dev = >dev; > struct backlight_device *bd; > > - bd = devm_backlight_device_register(dev, pdev->name, dev->parent, > + bd = devm_backlight_device_register(dev, pdev->name, dev, > dev_get_drvdata(dev->parent), > _sp_backlight_ops, > _sp_backlight_props); > if (IS_ERR(bd)) > return PTR_ERR(bd); > > - backlight_update_status(bd); > + /* > + * If there is a phandle pointing to the device node we can > + * assume that another device will manage the status changes. > + * If not we make sure the backlight is in a consistent state. > + */ > + if (!dev->of_node->phandle) > + backlight_update_status(bd); > > return 0; > } > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] backlight: add led-backlight driver
On Mon, Jul 08, 2019 at 12:27:00PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jean-Jacques Hiblot
> ---
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/led_bl.c | 235 +++
> 3 files changed, 243 insertions(+)
> create mode 100644 drivers/video/backlight/led_bl.c
> diff --git a/drivers/video/backlight/led_bl.c
> b/drivers/video/backlight/led_bl.c
> new file mode 100644
> index ..7644277cfdbb
> --- /dev/null
> +++ b/drivers/video/backlight/led_bl.c
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2015-2019 Texas Instruments Incorporated -
> http://www.ti.com/
> + * Author: Tomi Valkeinen
> + *
> + * Based on pwm_bl.c
> + */
> +
> +#include
> +#include
Header should no longer be needed.
> +static int led_bl_probe(struct platform_device *pdev)
> +{
> + struct backlight_properties props;
> + struct led_bl_data *priv;
> + int ret;
> + int i;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->dev = >dev;
> +
> + ret = led_bl_parse_dt(>dev, priv);
> + if (ret < 0) {
> + dev_err(>dev, "failed to parse DT data\n");
> + return ret;
> + }
> + priv->leds = devm_kzalloc(>dev,
> + sizeof(struct led_classdev *) * priv->nb_leds,
> + GFP_KERNEL);
> + if (!priv->leds)
> + return -ENOMEM;
> +
> + for (i = 0; i < priv->nb_leds; i++) {
> + priv->leds[i] = devm_led_get(>dev, i);
> + if (IS_ERR(priv->leds[i]))
> + return PTR_ERR(priv->leds[i]);
> + }
> +
> + memset(, 0, sizeof(struct backlight_properties));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = priv->max_brightness;
> + priv->bl_dev = backlight_device_register(dev_name(>dev),
> + >dev, priv, _bl_ops, );
> + if (IS_ERR(priv->bl_dev)) {
> + dev_err(>dev, "failed to register backlight\n");
> + ret = PTR_ERR(priv->bl_dev);
> + goto err;
goto is pointless for a pure-devm function.
> + }
> +
> + priv->bl_dev->props.brightness = priv->default_brightness;
> + backlight_update_status(priv->bl_dev);
This will light up the backlight during backlight probe.
Can you take a look at pwm_backlight_initial_power_state() and decide
how much of it applies to an LED based backlight (the phandle stuff
certainly does).
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard 写到: >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: >> > > Maybe instead of edp-connector one would introduce integrator's >specific >> > > connector, for example with compatible >"olimex,teres-edp-connector" >> > > which should follow edp abstract connector rules? This will be at >least >> > > consistent with below presentation[1] - eDP requirements depends >on >> > > integrator. Then if olimex has standard way of dealing with >panels >> > > present in olimex/teres platforms the driver would then create >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I >guess. >> > > Anyway it still looks fishy for me :), maybe because I am not >> > > familiarized with details of these platforms. >> > >> > That makes sense yes >> >> Actually, it makes no sense at all. Current implementation for >anx6345 >> driver works fine as is with any panel specified assuming panel >delays >> are long enough for connected panel. It just doesn't use panel >timings >> from the driver. Creating a platform driver for connector itself >looks >> redundant since it can't be reused, it doesn't describe actual >> hardware and it's just defeats purpose of DT by introducing >> board-specific code. > >I'm not sure where you got the idea that the purpose of DT is to not >have any board-specific code. > >It's perfectly fine to have some, that's even why there's a compatible >assigned to each and every board. > >What the DT is about is allowing us to have a generic behaviour that >we can detect: we can have a given behaviour for a given board, and a >separate one for another one, and this will be evaluated at runtime. > >This is *exactly* what this is about: we can have a compatible that >sets a given, more specific, behaviour (olimex,teres-edp-connector) >while saying that this is compatible with the generic behaviour >(edp-connector). That way, any OS will know what quirk to apply if >needed, and if not that it can use the generic behaviour. > >And we could create a generic driver, for the generic behaviour if >needed. > >> There's another issue: if we introduce edp-connector we'll have to >> specify power up delays somewhere (in dts? or in platform driver?), >so >> edp-connector doesn't really solve the issue of multiple panels with >> same motherboard. > >And that's what that compatible is about :) Maybe we can introduce a connector w/o any driver just like hdmi-connector? > >> I'd say DT overlays should be preferred solution here, not another >> connector binding. > >Overlays are a way to apply a device tree dynamically. It's orthogonal >to the binding. > >Maxime > >-- >Maxime Ripard, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com -- 使用 K-9 Mail 发送自我的Android设备。
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > Maybe instead of edp-connector one would introduce integrator's specific > > > connector, for example with compatible "olimex,teres-edp-connector" > > > which should follow edp abstract connector rules? This will be at least > > > consistent with below presentation[1] - eDP requirements depends on > > > integrator. Then if olimex has standard way of dealing with panels > > > present in olimex/teres platforms the driver would then create > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > Anyway it still looks fishy for me :), maybe because I am not > > > familiarized with details of these platforms. > > > > That makes sense yes > > Actually, it makes no sense at all. Current implementation for anx6345 > driver works fine as is with any panel specified assuming panel delays > are long enough for connected panel. It just doesn't use panel timings > from the driver. Creating a platform driver for connector itself looks > redundant since it can't be reused, it doesn't describe actual > hardware and it's just defeats purpose of DT by introducing > board-specific code. I'm not sure where you got the idea that the purpose of DT is to not have any board-specific code. It's perfectly fine to have some, that's even why there's a compatible assigned to each and every board. What the DT is about is allowing us to have a generic behaviour that we can detect: we can have a given behaviour for a given board, and a separate one for another one, and this will be evaluated at runtime. This is *exactly* what this is about: we can have a compatible that sets a given, more specific, behaviour (olimex,teres-edp-connector) while saying that this is compatible with the generic behaviour (edp-connector). That way, any OS will know what quirk to apply if needed, and if not that it can use the generic behaviour. And we could create a generic driver, for the generic behaviour if needed. > There's another issue: if we introduce edp-connector we'll have to > specify power up delays somewhere (in dts? or in platform driver?), so > edp-connector doesn't really solve the issue of multiple panels with > same motherboard. And that's what that compatible is about :) > I'd say DT overlays should be preferred solution here, not another > connector binding. Overlays are a way to apply a device tree dynamically. It's orthogonal to the binding. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH 4/5] drm/komeda: Remove layer_split property
On Fri, Jul 05, 2019 at 02:10:05PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> Again this probably needs multiple pieces to solve this properly:
>
> - Instead of expecting userspace to compute this (and duplicating
> modeset code), the kernel driver should compute when it's necessary
> to enable layer_split mode to make a configuration possible. I.e. in
> komeda_plane_atomic_check() first try komeda_build_layer_data_flow()
> and if that fails, try komeda_build_layer_split_data_flow(), and set
> dflow.en_split accordingly. Assuming I understand somewhat correctly
> what this does.
>
> - If this is needed for validation then you want a debugfs file to
> force this one way or the other, or alternatively use
> ->atomic_print_state to dump such hidden driver-private state.
> Depends upon how you do your validation ofc.
>
> Fixes: a407a6509393 ("drm/komeda: Add layer split support")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 -
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 61 ---
> 2 files changed, 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index fb2adc233760..0c006576a25c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -33,9 +33,6 @@ struct komeda_plane {
>* Layers with same capabilities.
>*/
> struct komeda_layer *layer;
> -
> - /** @prop_layer_split: for on/off layer_split */
> - struct drm_property *prop_layer_split;
> };
>
> /**
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index 23db38650a46..5bb8553cc117 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -188,40 +188,6 @@ komeda_plane_atomic_destroy_state(struct drm_plane
> *plane,
> kfree(to_kplane_st(state));
> }
>
> -static int
> -komeda_plane_atomic_get_property(struct drm_plane *plane,
> - const struct drm_plane_state *state,
> - struct drm_property *property,
> - uint64_t *val)
> -{
> - struct komeda_plane *kplane = to_kplane(plane);
> - struct komeda_plane_state *st = to_kplane_st(state);
> -
> - if (property == kplane->prop_layer_split)
> - *val = st->layer_split;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int
> -komeda_plane_atomic_set_property(struct drm_plane *plane,
> - struct drm_plane_state *state,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - struct komeda_plane *kplane = to_kplane(plane);
> - struct komeda_plane_state *st = to_kplane_st(state);
> -
> - if (property == kplane->prop_layer_split)
> - st->layer_split = !!val;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> static bool
> komeda_plane_format_mod_supported(struct drm_plane *plane,
> u32 format, u64 modifier)
> @@ -241,32 +207,9 @@ static const struct drm_plane_funcs komeda_plane_funcs =
> {
> .reset = komeda_plane_reset,
> .atomic_duplicate_state = komeda_plane_atomic_duplicate_state,
> .atomic_destroy_state = komeda_plane_atomic_destroy_state,
> - .atomic_get_property= komeda_plane_atomic_get_property,
> - .atomic_set_property= komeda_plane_atomic_set_property,
> .format_mod_supported = komeda_plane_format_mod_supported,
> };
>
> -static int
> -komeda_plane_create_layer_properties(struct komeda_plane *kplane,
> - struct komeda_layer *layer)
> -{
> - struct drm_device *drm = kplane->base.dev;
> - struct drm_plane *plane = >base;
> - struct drm_property *prop = NULL;
> -
> - /* property: layer split */
> - if (layer->right) {
> - prop = drm_property_create_bool(drm, DRM_MODE_PROP_ATOMIC,
> - "layer_split");
> - if (!prop)
> - return -ENOMEM;
> - kplane->prop_layer_split = prop;
> - drm_object_attach_property(>base, prop, 0);
> - }
> -
Re: [PATCH 3/5] drm/komeda: remove img_enhancement property
On Fri, Jul 05, 2019 at 02:10:04PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> Again this probably needs multiple pieces to solve this properly:
>
> - Instead of expecting userspace to compute this (and duplicating
> modeset code), the kernel driver should compute when it's possible
> to enable this better up/downscale mode (assuming I understood
> Liviu correctly on what this does) automatically.
>
> - If this is needed for validation then you want a debugfs file to
> force this one way or the other, or alternatively use
> ->atomic_print_state to dump such hidden driver-private state.
> Depends upon how you do your validation ofc.
>
> Fixes: 42b6f118f6d1 ("drm/komeda: Add image enhancement support")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 --
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 19 ++-
> 2 files changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index c545cb963d40..fb2adc233760 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -34,8 +34,6 @@ struct komeda_plane {
>*/
> struct komeda_layer *layer;
>
> - /** @prop_img_enhancement: for on/off image enhancement */
> - struct drm_property *prop_img_enhancement;
> /** @prop_layer_split: for on/off layer_split */
> struct drm_property *prop_layer_split;
> };
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index 04b122f28fb6..23db38650a46 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -197,9 +197,7 @@ komeda_plane_atomic_get_property(struct drm_plane *plane,
> struct komeda_plane *kplane = to_kplane(plane);
> struct komeda_plane_state *st = to_kplane_st(state);
>
> - if (property == kplane->prop_img_enhancement)
> - *val = st->img_enhancement;
> - else if (property == kplane->prop_layer_split)
> + if (property == kplane->prop_layer_split)
> *val = st->layer_split;
> else
> return -EINVAL;
> @@ -216,9 +214,7 @@ komeda_plane_atomic_set_property(struct drm_plane *plane,
> struct komeda_plane *kplane = to_kplane(plane);
> struct komeda_plane_state *st = to_kplane_st(state);
>
> - if (property == kplane->prop_img_enhancement)
> - st->img_enhancement = !!val;
> - else if (property == kplane->prop_layer_split)
> + if (property == kplane->prop_layer_split)
> st->layer_split = !!val;
> else
> return -EINVAL;
> @@ -258,17 +254,6 @@ komeda_plane_create_layer_properties(struct komeda_plane
> *kplane,
> struct drm_plane *plane = >base;
> struct drm_property *prop = NULL;
>
> - /* property: layer image_enhancement */
> - if (layer->base.supported_outputs & KOMEDA_PIPELINE_SCALERS) {
> - prop = drm_property_create_bool(drm, DRM_MODE_PROP_ATOMIC,
> - "img_enhancement");
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(>base, prop, 0);
> - kplane->prop_img_enhancement = prop;
> - }
> -
> /* property: layer split */
> if (layer->right) {
> prop = drm_property_create_bool(drm, DRM_MODE_PROP_ATOMIC,
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/komeda: Remove clock ratio property
On Fri, Jul 05, 2019 at 02:10:02PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> >From the discussion with Liviu the solution for these here needs
> multiple pieces:
>
> - For being able to reliably read the memory clock we need a DT
> property, plus maybe DT override snippets to fix it if it's wrong.
>
> - For exposing plane limitations to userspace there's TEST_ONLY. There
> is a bit a gap in telling userspace better that scaling doesn't work
> due to limits (atm a good strategy is to retry again without scaling
> when adding a plane didn't work the first time around). But that
> needs a more generic solution, not exposing something extremely
> komeda specific.
>
> - If this is needed by validation tools, you can still expose it in
> debugfs. We have an entire nice infrastructure for debug printing of
> kms objects already, see the various atomic_print_state callbacks
> and infrastructure around them.
>
> Fixes: 1f7f9ab7900e ("drm/komeda: Add engine clock requirement check for the
> downscaling")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 39 ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 --
> 2 files changed, 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 3f222f464eb2..e852dc27f1b8 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -454,24 +454,6 @@ static void komeda_crtc_vblank_disable(struct drm_crtc
> *crtc)
> mdev->funcs->on_off_vblank(mdev, kcrtc->master->id, false);
> }
>
> -static int
> -komeda_crtc_atomic_get_property(struct drm_crtc *crtc,
> - const struct drm_crtc_state *state,
> - struct drm_property *property, uint64_t *val)
> -{
> - struct komeda_crtc *kcrtc = to_kcrtc(crtc);
> - struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(state);
> -
> - if (property == kcrtc->clock_ratio_property) {
> - *val = kcrtc_st->clock_ratio;
> - } else {
> - DRM_DEBUG_DRIVER("Unknown property %s\n", property->name);
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> static const struct drm_crtc_funcs komeda_crtc_funcs = {
> .gamma_set = drm_atomic_helper_legacy_gamma_set,
> .destroy= drm_crtc_cleanup,
> @@ -482,7 +464,6 @@ static const struct drm_crtc_funcs komeda_crtc_funcs = {
> .atomic_destroy_state = komeda_crtc_atomic_destroy_state,
> .enable_vblank = komeda_crtc_vblank_enable,
> .disable_vblank = komeda_crtc_vblank_disable,
> - .atomic_get_property= komeda_crtc_atomic_get_property,
> };
>
> int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> @@ -518,22 +499,6 @@ int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> return 0;
> }
>
> -static int komeda_crtc_create_clock_ratio_property(struct komeda_crtc *kcrtc)
> -{
> - struct drm_crtc *crtc = >base;
> - struct drm_property *prop;
> -
> - prop = drm_property_create_range(crtc->dev, DRM_MODE_PROP_ATOMIC,
> - "CLOCK_RATIO", 0, U64_MAX);
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(>base, prop, 0);
> - kcrtc->clock_ratio_property = prop;
> -
> - return 0;
> -}
> -
> static int komeda_crtc_create_slave_planes_property(struct komeda_crtc
> *kcrtc)
> {
> struct drm_crtc *crtc = >base;
> @@ -590,10 +555,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> - err = komeda_crtc_create_clock_ratio_property(kcrtc);
> - if (err)
> - return err;
> -
> err = komeda_crtc_create_slave_planes_property(kcrtc);
> if (err)
> return err;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 219fa3f0c336..2775f34bf4ab 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -95,9 +95,6 @@ struct komeda_crtc {
> /** @disable_done: this flip_done is for tracing the disable */
> struct completion *disable_done;
>
> - /** @clock_ratio_property: property for ratio of (aclk <<
Re: [PATCH 2/5] drm/komeda: remove slave_planes property
On Fri, Jul 05, 2019 at 02:10:03PM +0200, Daniel Vetter wrote:
> Properties are uapi like anything else, with all the usual rules
> regarding review, testcases, open source userspace ... Furthermore
> driver-private kms properties are highly discouraged, over the past
> few years we've realized we need to make a serious effort at better
> standardizing this stuff.
>
> Again this probably needs multiple pieces to solve this properly:
>
> - To make plane configuration less surprising to userspace you
> propably need to virtualize planes, and reorder which logical plane
> you map to which physical one dynamically. Instead of exposing a
> komeda-specific limitation to userspace and expecting them to dtrt.
> I think msm and rcar-du do that already (and others), if you need
> people to chat with or example code.
>
> - If this is needed for validation, again ->atomic_print_state and the
> infrastructure around that is your friend.
>
> Fixes: 3b9dfa4ef28c ("drm/komeda: Add slave pipeline support")
> Cc: Lowry Li (Arm Technology China)
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Brian Starkey
> Signed-off-by: Daniel Vetter
Hi Daniel:
Thank you for the patch!
Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 24 ---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 ---
> 2 files changed, 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index e852dc27f1b8..f4400788ab94 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -499,26 +499,6 @@ int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> return 0;
> }
>
> -static int komeda_crtc_create_slave_planes_property(struct komeda_crtc
> *kcrtc)
> -{
> - struct drm_crtc *crtc = >base;
> - struct drm_property *prop;
> -
> - if (kcrtc->slave_planes == 0)
> - return 0;
> -
> - prop = drm_property_create_range(crtc->dev, DRM_MODE_PROP_IMMUTABLE,
> - "slave_planes", 0, U32_MAX);
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(>base, prop, kcrtc->slave_planes);
> -
> - kcrtc->slave_planes_property = prop;
> -
> - return 0;
> -}
> -
> static struct drm_plane *
> get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> {
> @@ -555,10 +535,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> - err = komeda_crtc_create_slave_planes_property(kcrtc);
> - if (err)
> - return err;
> -
> return err;
> }
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 2775f34bf4ab..c545cb963d40 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -94,9 +94,6 @@ struct komeda_crtc {
>
> /** @disable_done: this flip_done is for tracing the disable */
> struct completion *disable_done;
> -
> - /** @slave_planes_property: property for slaves of the planes */
> - struct drm_property *slave_planes_property;
> };
>
> /**
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/komeda: Enable new product D32 support
D32 is simple version of D71, the difference is:
- Only has one pipeline
- Drop the periph block and merge it to GCU
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_product.h | 3 +-
.../arm/display/komeda/d71/d71_component.c| 2 +-
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 43 ---
.../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 ++
.../gpu/drm/arm/display/komeda/komeda_drv.c | 1 +
5 files changed, 44 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h
b/drivers/gpu/drm/arm/display/include/malidp_product.h
index 1053b11352eb..16a8a2c22c42 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_product.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
@@ -18,7 +18,8 @@
#define MALIDP_CORE_ID_STATUS(__core_id) (((__u32)(__core_id)) & 0xFF)
/* Mali-display product IDs */
-#define MALIDP_D71_PRODUCT_ID 0x0071
+#define MALIDP_D71_PRODUCT_ID 0x0071
+#define MALIDP_D32_PRODUCT_ID 0x0032
union komeda_config_id {
struct {
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index a68954bb594a..593f8b7e9bb6 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -1178,7 +1178,7 @@ static int d71_timing_ctrlr_init(struct d71_dev *d71,
ctrlr = to_ctrlr(c);
- ctrlr->supports_dual_link = true;
+ ctrlr->supports_dual_link = d71->supports_dual_link;
ctrlr->supports_vrr = true;
set_range(>vfp_range, 0, 0x3FF);
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index e383a781c9e9..8f7c44a0b916 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -371,23 +371,33 @@ static int d71_enum_resources(struct komeda_dev *mdev)
goto err_cleanup;
}
- /* probe PERIPH */
+ /* Only the legacy HW has the periph block, the newer merges the periph
+* into GCU
+*/
value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
- if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
- DRM_ERROR("access blk periph but got blk: %d.\n",
- BLOCK_INFO_BLK_TYPE(value));
- err = -EINVAL;
- goto err_cleanup;
+ if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH)
+ d71->periph_addr = NULL;
+
+ if (d71->periph_addr) {
+ /* probe PERIPHERAL in legacy HW */
+ value = malidp_read32(d71->periph_addr,
PERIPH_CONFIGURATION_ID);
+
+ d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 :
2048;
+ d71->max_vsize = 4096;
+ d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 :
1;
+ d71->supports_dual_link = !!(value & PERIPH_SPLIT_EN);
+ d71->integrates_tbu = !!(value & PERIPH_TBU_EN);
+ } else {
+ value = malidp_read32(d71->gcu_addr, GCU_CONFIGURATION_ID0);
+ d71->max_line_size = GCU_MAX_LINE_SIZE(value);
+ d71->max_vsize = GCU_MAX_NUM_LINES(value);
+
+ value = malidp_read32(d71->gcu_addr, GCU_CONFIGURATION_ID1);
+ d71->num_rich_layers= GCU_NUM_RICH_LAYERS(value);
+ d71->supports_dual_link = GCU_DISPLAY_SPLIT_EN(value);
+ d71->integrates_tbu = GCU_DISPLAY_TBU_EN(value);
}
- value = malidp_read32(d71->periph_addr, PERIPH_CONFIGURATION_ID);
-
- d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 : 2048;
- d71->max_vsize = 4096;
- d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 : 1;
- d71->supports_dual_link = value & PERIPH_SPLIT_EN ? true : false;
- d71->integrates_tbu = value & PERIPH_TBU_EN ? true : false;
-
for (i = 0; i < d71->num_pipelines; i++) {
pipe = komeda_pipeline_add(mdev, sizeof(struct d71_pipeline),
_pipeline_funcs);
@@ -399,7 +409,7 @@ static int d71_enum_resources(struct komeda_dev *mdev)
}
/* loop the register blks and probe */
- i = 2; /* exclude GCU and PERIPH */
+ i = 1; /* exclude GCU */
offset = D71_BLOCK_SIZE; /* skip GCU */
while (i < d71->num_blocks) {
blk_base = mdev->reg_base + (offset >> 2);
@@ -409,9 +419,9 @@ static int d71_enum_resources(struct komeda_dev *mdev)
err = d71_probe_block(d71, , blk_base);
if (err)
goto err_cleanup;
- i++;
}
+ i++;
offset += D71_BLOCK_SIZE;
}
@@ -587,6 +597,7 @@
[PATCH 1/2] drm/komeda: Update the chip identify
1. Drop komeda-CORE product id comparison and put it into the d71_identify
2. Update pipeline node DT-binding:
*. Skip the needless pipeline DT node.
*. Return fail if the essential pipeline DT node was missing.
With these changes, for one family chips no need to change the DT.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 27 ++--
.../gpu/drm/arm/display/komeda/komeda_dev.c | 62 ++-
.../gpu/drm/arm/display/komeda/komeda_dev.h | 14 +
.../gpu/drm/arm/display/komeda/komeda_drv.c | 9 +--
4 files changed, 60 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 7e7c9e935eaf..e383a781c9e9 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -578,10 +578,27 @@ static const struct komeda_dev_funcs d71_chip_funcs = {
const struct komeda_dev_funcs *
d71_identify(u32 __iomem *reg_base, struct komeda_chip_info *chip)
{
- chip->arch_id = malidp_read32(reg_base, GLB_ARCH_ID);
- chip->core_id = malidp_read32(reg_base, GLB_CORE_ID);
- chip->core_info = malidp_read32(reg_base, GLB_CORE_INFO);
- chip->bus_width = D71_BUS_WIDTH_16_BYTES;
+ const struct komeda_dev_funcs *funcs;
+ u32 product_id;
- return _chip_funcs;
+ chip->core_id = malidp_read32(reg_base, GLB_CORE_ID);
+
+ product_id = MALIDP_CORE_ID_PRODUCT_ID(chip->core_id);
+
+ switch (product_id) {
+ case MALIDP_D71_PRODUCT_ID:
+ funcs = _chip_funcs;
+ break;
+ default:
+ funcs = NULL;
+ DRM_ERROR("Unsupported product: 0x%x\n", product_id);
+ }
+
+ if (funcs) {
+ chip->arch_id = malidp_read32(reg_base, GLB_ARCH_ID);
+ chip->core_info = malidp_read32(reg_base, GLB_CORE_INFO);
+ chip->bus_width = D71_BUS_WIDTH_16_BYTES;
+ }
+
+ return funcs;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 2aee735a683f..dd4a0ba1c37d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -125,23 +125,16 @@ static int to_color_format(const char *str)
return format;
}
-static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node
*np)
+static int komeda_parse_pipe_dt(struct komeda_pipeline *pipe)
{
- struct komeda_pipeline *pipe;
+ struct device_node *np = pipe->of_node;
struct clk *clk;
- u32 pipe_id;
- int ret = 0, color_format;
+ u32 color_format;
const char *str;
- ret = of_property_read_u32(np, "reg", _id);
- if (ret != 0 || pipe_id >= mdev->n_pipelines)
- return -EINVAL;
-
- pipe = mdev->pipelines[pipe_id];
-
clk = of_clk_get_by_name(np, "pxclk");
if (IS_ERR(clk)) {
- DRM_ERROR("get pxclk for pipeline %d failed!\n", pipe_id);
+ DRM_ERROR("get pxclk for pipeline %d failed!\n", pipe->id);
return PTR_ERR(clk);
}
pipe->pxlclk = clk;
@@ -163,7 +156,6 @@ static int komeda_parse_pipe_dt(struct komeda_dev *mdev,
struct device_node *np)
of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
- pipe->of_node = np;
return 0;
}
@@ -172,7 +164,9 @@ static int komeda_parse_dt(struct device *dev, struct
komeda_dev *mdev)
{
struct platform_device *pdev = to_platform_device(dev);
struct device_node *child, *np = dev->of_node;
- int ret;
+ struct komeda_pipeline *pipe;
+ u32 pipe_id = U32_MAX;
+ int ret = -1;
mdev->irq = platform_get_irq(pdev, 0);
if (mdev->irq < 0) {
@@ -181,32 +175,46 @@ static int komeda_parse_dt(struct device *dev, struct
komeda_dev *mdev)
}
for_each_available_child_of_node(np, child) {
- if (of_node_cmp(child->name, "pipeline") == 0) {
- ret = komeda_parse_pipe_dt(mdev, child);
- if (ret) {
- DRM_ERROR("parse pipeline dt error!\n");
+ if (of_node_name_eq(child, "pipeline")) {
+ ret = of_property_read_u32(child, "reg", _id);
+ if (pipe_id >= mdev->n_pipelines) {
+ DRM_WARN("Skip the redandunt DT node:
pipeline-%u.\n",
+pipe_id);
of_node_put(child);
- break;
+ continue;
}
+ mdev->pipelines[pipe_id]->of_node = child;
+ }
+ }
+
+ for (pipe_id = 0;
[PATCH 0/2] drm/komeda: Add new product "D32" support
This series enables new product "D32" support James Qian Wang (Arm Technology China) (2): drm/komeda: Update the chip identify drm/komeda: Enable new product D32 support .../drm/arm/display/include/malidp_product.h | 3 +- .../arm/display/komeda/d71/d71_component.c| 2 +- .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 70 +-- .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 .../gpu/drm/arm/display/komeda/komeda_dev.c | 62 .../gpu/drm/arm/display/komeda/komeda_dev.h | 14 +--- .../gpu/drm/arm/display/komeda/komeda_drv.c | 10 +-- 7 files changed, 104 insertions(+), 70 deletions(-) -- 2.20.1
Re: [PATCH v2 03/14] drm/sti: Remove pointless casts
Le lun. 8 juil. 2019 à 18:21, Ville Syrjala a écrit : > > From: Ville Syrjälä > > There's no point in the cast for accessing the base class. Just > take the address of the struct instead. Applied on drm-misc-next, Thanks, Benjamin > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Acked-by: Benjamin Gaignard > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index e1b3c8cb7287..42f4c264a783 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -669,7 +669,7 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *)encoder; > + drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 0; > @@ -722,7 +722,7 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *) encoder; > + drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 0; > @@ -771,7 +771,7 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *) encoder; > + drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 1; > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/14] drm/sti: Try to fix up the tvout possible clones
Le lun. 8 juil. 2019 à 18:21, Ville Syrjala a écrit : > > From: Ville Syrjälä > > The current possible_clones setup doesn't look sensible. I'm assuming > the 0 and 1 are supposed to refer to the indexes of the hdmi and hda > encoders? So it kinda looks like we want hda+hdmi cloning, but then > dvo also claims to be cloneable with hdmi, but hdmi won't recipricate. > > Benjamin tells me all encoders should be cloneable with each other, > so let's fix up the masks to indicate that. > Applied on drm-misc-next, Thanks, Benjamin > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Acked-by: Benjamin Gaignard > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/sti/sti_tvout.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index 42f4c264a783..aba79c172512 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -672,7 +672,6 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS, > @@ -725,7 +724,6 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); > @@ -774,7 +772,6 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 1; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_TMDS, > NULL); > @@ -790,6 +787,13 @@ static void sti_tvout_create_encoders(struct drm_device > *dev, > tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); > tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); > tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); > + > + tvout->hdmi->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->hda->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->dvo->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > } > > static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
