Re: [PATCH 1/6] drm/i915: export the stolen region as a resource
+ Ville to comment if the removed code loses some meaningful comments or not. I already went through the code doing consolidations, about a year ago, so I may be blind to it. On Wed, 2017-11-22 at 21:19 +, Matthew Auld wrote: > We duplicate the stolen discovery code in early-quirks and in i915, > however if we just export the region as a resource from early-quirks we > can nuke the duplication. > > Suggested-by: Joonas Lahtinen > Suggested-by: Chris Wilson > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Paulo Zanoni > Cc: Ingo Molnar > Cc: H. Peter Anvin > Cc: dri-devel@lists.freedesktop.org > Cc: x...@kernel.org > @@ -548,6 +551,9 @@ intel_graphics_stolen(int num, int slot, int func, > printk(KERN_INFO "Reserving Intel graphics memory at %pa-%pa\n", > &base, &end); > > + intel_graphics_stolen_res.start = base; > + intel_graphics_stolen_res.end = end; You can take advantage of the newly establisted resource by using %pR in the printk. I sent a patch to convert the function signatures to resource_size_t for a less painful future. Maybe squash just the early quirks/header change portion of this patch to that patch, then we can iterate on the i915 changes on a reminder of the series on top of that. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)
https://bugs.freedesktop.org/show_bug.cgi?id=103370 --- Comment #41 from Robert Liu --- So far, setting max_sclk to 6 and max_mclk to 8, the system passed a 24hours burn-in test (vblank_mode=0 DRI_PRIME=1 glmark2 --run-forever). Another issue found is when removing the adapter, the system goes to suspend. After I wake it up, it continues running the benchmark. -- 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: 4.9.62: intermittent flicker after upgrade from 4.9.61
On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote: > Rainer Fiebig wrote: > > Maarten Lankhorst wrote: > >> Op 20-11-17 om 09:51 schreef Rainer Fiebig: > >>> Jani Nikula wrote: > On Sun, 19 Nov 2017, Greg KH wrote: > > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote: > >> Greg KH wrote: > >>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote: > Greg KH wrote: > > On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote: > >> Greg KH wrote: > >>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote: > Hi! > > Hopefully the right addressee. > > Encountered two bad backports which cause screen-flicker. > dmesg shows: > > ... > [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO > underrun > [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO > underrun > [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO > underrun > [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO > underrun > ... > > CPU: Intel Core i3 (Clarkdale/Ironlake) > > The backports are: > > - diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 49de476..277a802 100644 > - diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index a19ec06..3ce9ba3 100644 > > After reversing them the flicker is gone, no more messages in > dmesg. All > else OK so far. > >>> So which commit was the one that caused the problem? I will be > >>> glad to > >>> revert it. > >>> > >>> thanks, > >>> > >>> greg k-h > >>> > >>> > >> I started by reverting the more complex one first ("index > >> 49de476..277a802100644"). But the kernel wouldn't compile then. > > What git commit id is that? I don't see those ids in the 4.9-stable > > tree. > > > >> So I also reverted "index a19ec06..3ce9ba3 100644". After that the > >> kernel compiled just fine and the problems were gone (still are). > > Same here, what git commit id was this? > > > > thanks, > > > > greg k-h > > > OK, no mistake. IIRC, I took the patches (and the IDs) from the > changelog for patch-4.9.62. I've attached both, so you can check > yourself. > > I've also applied a freshly downloaded patch-4.9.62 to a freshly > expanded 4.9 and re-compiled. The flicker is there. I haven't yet > reverted the two patches but I'm confident that after having done so > the > flicker will be gone. If not I'll let you know. > > As a good news: 4.14 is *not* affected. So to me it seems those two > patches are part of sort of a package and can not be backported > alone. > > So long! > Rainer Fiebig > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 49de476..277a802 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -27,6 +27,7 @@ > > #include > #include > +#include > #include "i915_drv.h" > #include "intel_drv.h" > #include "../../../platform/x86/intel_ips.h" > @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct > drm_i915_private *dev_priv, > const struct intel_crtc *intel_crtc, > int level, > struct intel_crtc_state *cstate, > - struct intel_plane_state *pristate, > - struct intel_plane_state *sprstate, > - struct intel_plane_state *curstate, > + const struct intel_plane_state > *pristate, > + const struct intel_plane_state > *sprstate, > + const struct intel_plane_state > *curstate, > struct intel_wm_level *result) > { > uint16_t pri_latency = dev_priv->wm.pri_latency[level]; > @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct > intel_crtc_state *cstate) > struct intel_pipe_wm *pipe_w
[git pull] drm for 4.15 part 2 (updated)
Hi Linus, This is an incremental pull on top of yesterdays, it contains all of that, Summary from first pull: This is just some bits and pieces for the second half of the merge window, 1. Remove the MSM dt-bindings file Rob managed to push in the previous pull. 2. Add a property/edid quirk to denote HMD devices, I had these hanging around for a few weeks and Keith had done some work on them, they are fairly self contained and small, and only affect people using HTC Vive VR headsets so far. 3. amdgpu, tegra, tilcdc, fsl fixes 4. some imx-drm cleanups I missed, these seemed pretty small, and no reason to hold off. Extras: TTM regression fix for running on bochs vga (Fedora reported) Some i915 fixes headed for stable One vc4 fix One EDID fix One new uapi fix. Dave. The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014: Merge tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2017-11-14 14:12:43 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.15-part2-fixes for you to fetch changes up to c209101fc1c91a318422733a3721ff6a9ff7899f: Merge tag 'drm-misc-fixes-2017-11-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24 11:33:29 +1000) previous part 2 tag + ttm regression fix, i915,vc4,core,uapi fixes Alex Deucher (2): Revert "drm/radeon: dont switch vt on suspend" drm/amdgpu: don't skip attributes when powerplay is enabled Chris Wilson (2): drm/i915: Clear breadcrumb node when cancelling signaling drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM Christian König (2): drm/amdgpu: make AMDGPU_VA_RESERVED_SIZE 64bit drm/amdgpu: set f_mapping on exported DMA-bufs Cihangir Akturk (1): drm/imx: switch to drm_*_get(), drm_*_put() helpers Colin Ian King (2): drm/amd/powerplay: fix copy-n-paste error on vddci_buf index drm/i915/gvt: ensure -ve return value is handled correctly Dave Airlie (13): Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'drm-fsl-dcu-fixes-for-v4.15' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next Merge tag 'drm/tegra/for-4.15-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux into drm-next Merge tag 'imx-drm-next-2017-10-18' of git://git.pengutronix.de/git/pza/linux into drm-next Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'tilcdc-4.15-fixes' of https://github.com/jsarha/linux into drm-next drm: add connector info/property for non-desktop displays [v2] drm/fb: add support for not enabling fbcon on non-desktop displays [v2] drm/edid: quirk HTC vive headset as non-desktop. [v2] drm/ttm: don't attempt to use hugepages if dma32 requested (v2) Merge tag 'drm-misc-next-fixes-2017-11-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'drm-intel-next-fixes-2017-11-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Merge tag 'drm-misc-fixes-2017-11-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Emily Deng (1): drm/amdgpu: Fix null pointer issue in amdgpu_cs_wait_any_fence Eric Huang (1): drm/amd/powerplay: fix unfreeze level smc message for smu7 Fabio Estevam (1): gpu: ipu-v3: ipu-dc: Remove unused 'di' variable Hans de Goede (2): drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 drm/i915: Re-register PMIC bus access notifier on runtime resume Jyri Sarha (1): drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding support Ken Wang (2): drm/amdgpu: Remove check which is not valid for certain VBIOS drm/amdgpu: Add common golden settings for GFX9 Laurent Pinchart (1): drm/fsl-dcu: Don't set connector DPMS property Lucas Stach (1): drm/imx: parallel-display: use correct connector enum Maarten Lankhorst (1): drm/vblank: Pass crtc_id to page_flip_ioctl. Marco Franchi (1): dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage Monk Liu (2): drm/amdgpu:fix memleak in takedown drm/amdgpu:fix memleak Nicolai Hähnle (1): drm/amdgpu/gfx9: implement wave VGPR reading Rex Zhu (2): drm/amd/pp: fix dpm randomly failed on Vega10 drm/amd/pp: fix typecast error in powerplay. Rob Clark (1): dt-bindings: remove file that was added accidentally Roger He (2): drm/amd/amdgpu: if visible VRAM allocation fail, fall back to invisible try again drm/amd/amdgpu: fix over-bound accessing in amdgpu_cs_wait_any_fence Stefan Agner (2): drm/fsl-dcu: avoid disabling pixel clock twice on suspend drm/fsl-dcu: enable IRQ before dr
[Bug 103874] The Witcher 3: flickering regression with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=103874 Bug ID: 103874 Summary: The Witcher 3: flickering regression with radeonsi Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: shtetl...@gmail.com QA Contact: dri-devel@lists.freedesktop.org With latest Mesa master, The Witcher 3 in Wine started performing worse and it also introduced noticeable flickering (once in a few seconds). I was able to narrow down this flickering to these commits by Marek: adab7f16ffd3ea4c52e8d07f40ca6ae4868c3706 2017-11-06 radeonsi: don't map big VRAM buffers for the first upload directly 4b0dc098b2561c07c59f7dab2813640a25789bf1 2017-11-06 gallium/u_threaded: don't map big VRAM buffers for the first upload directly a5d3999c31e2460f690b561b41170bb7bc24fc65 2017-11-06 gallium/u_threaded: clean up tc_improve_map_buffer_flags and prevent reentry One commit before them this flickering doesn't occur: OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0 / 4.13.0-1-amd64, LLVM 5.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel (git-60a9705e00) And with them, it does: OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0 / 4.13.0-1-amd64, LLVM 5.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel (git-adab7f16ff) I'm running The Witcher3 with mesa_glthread and csmt enabled (both). You can use latest Wine staging to test 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: [PATCH 8/8] drm/msm/gpu: Add devfreq support for the GPU
Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on next-20171122] [cannot apply to v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jordan-Crouse/msm-gpu-devfreq-support/20171124-022911 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm tree with Linus' tree
Hi all, FIXME: Add owner of second tree to To: Add author(s)/SOB of conflicting commits. Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c between commits: 0290c4ca2536 ("of: overlay: rename identifiers to more reflect what they do") 24789c5ce5a3 ("of: overlay: detect cases where device tree may become corrupt") f948d6d8b792 ("of: overlay: avoid race condition between applying multiple overlays") from Linus' tree and commit: 739acd85ffdb ("drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding support") from the drm tree. I fixed it up (the latter removed the file, so I did that) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: add missing MODULE_FIRMWARE declarations
On Thu, Nov 23, 2017 at 2:49 PM, Nicolas Dechesne wrote: > * some a5xx files were missing > * fixup for an existing typo > > Signed-off-by: Nicolas Dechesne Thanks Reviewed-by: Rob Clark > --- > drivers/gpu/drm/msm/adreno/adreno_device.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c > b/drivers/gpu/drm/msm/adreno/adreno_device.c > index 3c1d23b9ddc3..ef4baa919135 100644 > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c > @@ -96,8 +96,13 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw"); > MODULE_FIRMWARE("qcom/a330_pfp.fw"); > MODULE_FIRMWARE("qcom/a420_pm4.fw"); > MODULE_FIRMWARE("qcom/a420_pfp.fw"); > -MODULE_FIRMWARE("qcom/a530_fm4.fw"); > +MODULE_FIRMWARE("qcom/a530_pm4.fw"); > MODULE_FIRMWARE("qcom/a530_pfp.fw"); > +MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2"); > +MODULE_FIRMWARE("qcom/a530_zap.mdt"); > +MODULE_FIRMWARE("qcom/a530_zap.b00"); > +MODULE_FIRMWARE("qcom/a530_zap.b01"); > +MODULE_FIRMWARE("qcom/a530_zap.b02"); > > static inline bool _rev_match(uint8_t entry, uint8_t id) > { > -- > 2.15.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/ttm: add page order in page pool
Hi Roger, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20171122] [cannot apply to v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-add-page-order-in-page-pool/20171124-032341 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/gpu//drm/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init': >> drivers/gpu//drm/ttm/ttm_page_alloc.c:979:18: error: call to >> '__compiletime_assert_979' declared with attribute error: BUILD_BUG failed drivers/gpu//drm/ttm/ttm_page_alloc.c:983:20: error: call to '__compiletime_assert_983' declared with attribute error: BUILD_BUG failed vim +/__compiletime_assert_979 +979 drivers/gpu//drm/ttm/ttm_page_alloc.c 956 957 int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) 958 { 959 int ret; 960 961 WARN_ON(_manager); 962 963 pr_info("Initializing pool allocator\n"); 964 965 _manager = kzalloc(sizeof(*_manager), GFP_KERNEL); 966 967 ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0); 968 969 ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0); 970 971 ttm_page_pool_init_locked(&_manager->wc_pool_dma32, 972GFP_USER | GFP_DMA32, "wc dma", 0); 973 974 ttm_page_pool_init_locked(&_manager->uc_pool_dma32, 975GFP_USER | GFP_DMA32, "uc dma", 0); 976 977 ttm_page_pool_init_locked(&_manager->wc_pool_huge, 978GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP), > 979"wc huge", HPAGE_PMD_ORDER); 980 981 ttm_page_pool_init_locked(&_manager->uc_pool_huge, 982GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP) 983, "uc huge", HPAGE_PMD_ORDER); 984 985 _manager->options.max_size = max_pages; 986 _manager->options.small = SMALL_ALLOCATION; 987 _manager->options.alloc_size = NUM_PAGES_TO_ALLOC; 988 989 ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type, 990 &glob->kobj, "pool"); 991 if (unlikely(ret != 0)) { 992 kobject_put(&_manager->kobj); 993 _manager = NULL; 994 return ret; 995 } 996 997 ttm_pool_mm_shrink_init(_manager); 998 999 return 0; 1000 } 1001 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/msm/gpu: Add devfreq support for the GPU
Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on next-20171122] [cannot apply to v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jordan-Crouse/msm-gpu-devfreq-support/20171124-022911 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-multi_v7_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/gpu/drm/msm/msm_gpu.o: In function `msm_devfreq_get_dev_status': >> msm_gpu.c:(.text+0x558): undefined reference to `__aeabi_uldivmod' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/ttm: add page order in page pool
Hi Roger, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20171122] [cannot apply to v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-add-page-order-in-page-pool/20171124-035121 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: i386-randconfig-x008-201747 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): >> drivers/gpu/drm/ttm/ttm_page_alloc.c:963:0: warning: "HPAGE_PMD_ORDER" >> redefined #define HPAGE_PMD_ORDER 9 In file included from include/linux/mm.h:451:0, from include/linux/highmem.h:7, from drivers/gpu/drm/ttm/ttm_page_alloc.c:38: include/linux/huge_mm.h:78:0: note: this is the location of the previous definition #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) In file included from include/uapi/linux/stddef.h:1:0, from include/linux/stddef.h:4, from include/uapi/linux/posix_types.h:4, from include/uapi/linux/types.h:13, from include/linux/types.h:5, from include/linux/list.h:4, from drivers/gpu/drm/ttm/ttm_page_alloc.c:36: include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'strcpy' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:421:2: note: in expansion of macro 'if' if (p_size == (size_t)-1 && q_size == (size_t)-1) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'kmemdup' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:411:2: note: in expansion of macro 'if' if (p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'kmemdup' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:409:2: note: in expansion of macro 'if' if (__builtin_constant_p(size) && p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr_inv' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:400:2: note: in expansion of macro 'if' if (p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr_inv' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:398:2: note: in expansion of macro 'if' if (__builtin_constant_p(size) && p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:389:2: note: in expansion of macro 'if' if (p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memchr' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) ) ^~ include/linux/string.h:387:2: note: in expansion of macro 'if' if (__builtin_constant_p(size) && p_size < size) ^~ include/linux/compiler.h:162:4: warning: '__f' is static but declared in inline function 'memcmp' which is not static __f = { \ ^ include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if' #define if(cond, ...) __trace_if( (cond , ## __VA_
Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes
On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä wrote: > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote: >> We need to shift the values up, otherwise we'd end up with a negative >> shift. This works for up-to 16-bit components, which is fine for now. > > Shouldn't we actually replicate the high bits in the low bits? Not entirely sure what you're proposing... Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA which would then shift down as necessary (and even there, you could end up with off-by-1's maybe?). For e.g. 0xff, that should become 0x3ff but with my code will become 0x3fc. But for other values, it's less clear what to do with the low bits. I figured it didn't really matter. Do you have a concrete proposal? -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()
Hi Tobias, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20171122] [cannot apply to drm-exynos/exynos-drm/for-next v4.14 v4.14-rc8 v4.14-rc7 v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tobias-Jakobi/drm-exynos-mixer-avoid-Oops-in-vp_video_buffer/20171124-012413 config: arm-exynos_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/gpu/drm/exynos/exynos_mixer.c: In function 'vp_video_buffer': >> drivers/gpu/drm/exynos/exynos_mixer.c:518:16: error: 'res' undeclared (first >> use in this function) vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2); ^~~ drivers/gpu/drm/exynos/exynos_mixer.c:518:16: note: each undeclared identifier is reported only once for each function it appears in vim +/res +518 drivers/gpu/drm/exynos/exynos_mixer.c 463 464 static void vp_video_buffer(struct mixer_context *ctx, 465 struct exynos_drm_plane *plane) 466 { 467 struct exynos_drm_plane_state *state = 468 to_exynos_plane_state(plane->base.state); 469 struct drm_framebuffer *fb = state->base.fb; 470 unsigned int priority = state->base.normalized_zpos + 1; 471 unsigned long flags; 472 dma_addr_t luma_addr[2], chroma_addr[2]; 473 bool is_tiled, is_nv21; 474 u32 val; 475 476 is_nv21 = (fb->format->format == DRM_FORMAT_NV21); 477 is_tiled = (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE); 478 479 luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0); 480 chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1); 481 482 if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) { 483 if (is_tiled) { 484 luma_addr[1] = luma_addr[0] + 0x40; 485 chroma_addr[1] = chroma_addr[0] + 0x40; 486 } else { 487 luma_addr[1] = luma_addr[0] + fb->pitches[0]; 488 chroma_addr[1] = chroma_addr[0] + fb->pitches[1]; 489 } 490 } else { 491 luma_addr[1] = 0; 492 chroma_addr[1] = 0; 493 } 494 495 spin_lock_irqsave(&ctx->reg_slock, flags); 496 497 /* interlace or progressive scan mode */ 498 val = (test_bit(MXR_BIT_INTERLACE, &ctx->flags) ? ~0 : 0); 499 vp_reg_writemask(ctx, VP_MODE, val, VP_MODE_LINE_SKIP); 500 501 /* setup format */ 502 val = (is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12); 503 val |= (is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR); 504 vp_reg_writemask(ctx, VP_MODE, val, VP_MODE_FMT_MASK); 505 506 /* setting size of input image */ 507 vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) | 508 VP_IMG_VSIZE(fb->height)); 509 /* chroma plane for NV12/NV21 is half the height of the luma plane */ 510 vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) | 511 VP_IMG_VSIZE(fb->height / 2)); 512 513 vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w); 514 vp_reg_write(ctx, VP_SRC_H_POSITION, 515 VP_SRC_H_POSITION_VAL(state->src.x)); 516 517 if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) { > 518 vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2); 519 vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2); 520 } else { 521 vp_reg_write(res, VP_SRC_HEIGHT, state->src.h); 522 vp_reg_write(res, VP_SRC_V_POSITION, state->src.y); 523 } 524 525 vp_reg_write(res, VP_DST_WIDTH, state->crtc.w); 526 vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x); 527 vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h); 528 vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y); 529 530 vp_reg_write(ctx, VP_H_RATIO, state->h_ratio); 531 vp_reg_write(ctx, VP_V_RATIO, state->v_ratio); 532 533 vp_reg_write(ctx, VP_ENDIAN_MODE, VP_ENDIAN_MODE_LITTLE); 534 535 /* set buffer address to vp */ 536 vp_reg_write(ctx, VP_TOP_Y_PTR, luma_addr[0]); 537 vp_reg_write(ctx, VP_BOT_Y_PTR, luma_addr[1]); 538 vp_reg_write(ctx, VP
Re: [PATCH 1/4] drm/ttm: add page order in page pool
Hi Roger, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20171122] [cannot apply to v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Roger-He/drm-ttm-add-page-order-in-page-pool/20171124-032341 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: x86_64-randconfig-x007-201747 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): In file included from include/uapi/linux/stddef.h:1:0, from include/linux/stddef.h:4, from include/uapi/linux/posix_types.h:4, from include/uapi/linux/types.h:13, from include/linux/types.h:5, from include/linux/list.h:4, from drivers/gpu/drm/ttm/ttm_page_alloc.c:36: drivers/gpu/drm/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init': >> include/linux/compiler.h:576:38: error: call to '__compiletime_assert_979' >> declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/compiler.h:556:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~ include/linux/compiler.h:576:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ include/linux/build_bug.h:46:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ include/linux/build_bug.h:80:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") ^~~~ include/linux/huge_mm.h:248:28: note: in expansion of macro 'BUILD_BUG' #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) ^ include/linux/huge_mm.h:78:26: note: in expansion of macro 'HPAGE_PMD_SHIFT' #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) ^~~ >> drivers/gpu/drm/ttm/ttm_page_alloc.c:979:18: note: in expansion of macro >> 'HPAGE_PMD_ORDER' "wc huge", HPAGE_PMD_ORDER); ^~~ include/linux/compiler.h:576:38: error: call to '__compiletime_assert_983' declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/compiler.h:556:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~ include/linux/compiler.h:576:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ include/linux/build_bug.h:46:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ include/linux/build_bug.h:80:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") ^~~~ include/linux/huge_mm.h:248:28: note: in expansion of macro 'BUILD_BUG' #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) ^ include/linux/huge_mm.h:78:26: note: in expansion of macro 'HPAGE_PMD_SHIFT' #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) ^~~ drivers/gpu/drm/ttm/ttm_page_alloc.c:983:20: note: in expansion of macro 'HPAGE_PMD_ORDER' , "uc huge", HPAGE_PMD_ORDER); ^~~ -- In file included from include/uapi/linux/stddef.h:1:0, from include/linux/stddef.h:4, from include/uapi/linux/posix_types.h:4, from include/uapi/linux/types.h:13, from include/linux/types.h:5, from include/linux/list.h:4, from drivers/gpu//drm/ttm/ttm_page_alloc.c:36: drivers/gpu//drm/ttm/ttm_page_alloc.c: In function 'ttm_page_alloc_init': >> include/linux/compiler.h:576:38: error: call to '__compiletime_assert_979' >> declared with attribute error: BUILD_BUG failed _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/compiler.h:556:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~~~
[Bug 103850] "Quern" game crashes on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=103850 --- Comment #5 from yunt...@gmail.com --- (In reply to Michel Dänzer from comment #2) > Looks like there might be memory corruption, can you run one of these games > in valgrind and attach the output from valgrind? Valgrind output attached. Looks quite useless to me... Interestingly, Quern actually shows the main menu when run under valgrind. A duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=101675 then? -- 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
[PATCH] drm/msm: add missing MODULE_FIRMWARE declarations
* some a5xx files were missing * fixup for an existing typo Signed-off-by: Nicolas Dechesne --- drivers/gpu/drm/msm/adreno/adreno_device.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 3c1d23b9ddc3..ef4baa919135 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -96,8 +96,13 @@ MODULE_FIRMWARE("qcom/a330_pm4.fw"); MODULE_FIRMWARE("qcom/a330_pfp.fw"); MODULE_FIRMWARE("qcom/a420_pm4.fw"); MODULE_FIRMWARE("qcom/a420_pfp.fw"); -MODULE_FIRMWARE("qcom/a530_fm4.fw"); +MODULE_FIRMWARE("qcom/a530_pm4.fw"); MODULE_FIRMWARE("qcom/a530_pfp.fw"); +MODULE_FIRMWARE("qcom/a530v3_gpmu.fw2"); +MODULE_FIRMWARE("qcom/a530_zap.mdt"); +MODULE_FIRMWARE("qcom/a530_zap.b00"); +MODULE_FIRMWARE("qcom/a530_zap.b01"); +MODULE_FIRMWARE("qcom/a530_zap.b02"); static inline bool _rev_match(uint8_t entry, uint8_t id) { -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103850] "Quern" game crashes on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=103850 --- Comment #3 from yunt...@gmail.com --- Created attachment 135687 --> https://bugs.freedesktop.org/attachment.cgi?id=135687&action=edit Quern - valgrind output -- 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 103850] "Quern" game crashes on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=103850 --- Comment #4 from yunt...@gmail.com --- Created attachment 135688 --> https://bugs.freedesktop.org/attachment.cgi?id=135688&action=edit Unturned - valgrind output -- 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
[PULL] drm-misc-next-fixes
Hi Dave, drm-misc-next-fixes-2017-11-23: Fix crtc_id in page_flip event. One tiny uapi fix, cc: stable, for a small oversight. Shouldn't matter much since we added this for atomic, but yay for OCD and making igt happy :-) Cheers, Daniel The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014: Merge tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2017-11-14 14:12:43 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2017-11-23 for you to fetch changes up to b8a3365a30c463e9105969ab1bf8674b763e3408: drm/vblank: Pass crtc_id to page_flip_ioctl. (2017-11-23 13:04:19 +0100) Fix crtc_id in page_flip event. Maarten Lankhorst (1): drm/vblank: Pass crtc_id to page_flip_ioctl. drivers/gpu/drm/drm_plane.c | 1 + 1 file changed, 1 insertion(+) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103863] Screen doesn't light up with "amdgpu.dc=1"
https://bugs.freedesktop.org/show_bug.cgi?id=103863 Benjamin Bellec changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #4 from Benjamin Bellec --- I reinstalled Fedora 26 (instead of 27) on my computer, and reinstalled the kernel 4.15.0-0.rc0.git7.1.fc28.x86_64 on it, and I haven't the error anymore... Now I have a display and the HDMI audio on my second screen (TV in fact) is working. Also, my F27 computer was on a new Ryzen config, which I finally reverted to old Core i5 due to global instability. So I don't know where the problem was... -- 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
[radeon-alex:amd-mainline-dkms-4.13 2023/2065] ci_smc.c:(.text+0xa60): multiple definition of `ci_send_msg_to_smc'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.13 head: 59aa856b7672d465443305a3fd7a6956f9567ea6 commit: b3be11d6288525da016bec7d50a11476d6ff1089 [2023/2065] drm/amdgpu: Fix for amd_pm_funcs moved to struct amd_powerplay config: i386-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout b3be11d6288525da016bec7d50a11476d6ff1089 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.o: In function `ci_send_msg_to_smc': >> ci_smc.c:(.text+0xa60): multiple definition of `ci_send_msg_to_smc' drivers/gpu/drm/radeon/ci_smc.o:ci_smc.c:(.text+0x320): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes
On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote: > We need to shift the values up, otherwise we'd end up with a negative > shift. This works for up-to 16-bit components, which is fine for now. Shouldn't we actually replicate the high bits in the low bits? > > Signed-off-by: Ilia Mirkin > --- > tests/util/pattern.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/tests/util/pattern.c b/tests/util/pattern.c > index 41fb541b..2f9bb384 100644 > --- a/tests/util/pattern.c > +++ b/tests/util/pattern.c > @@ -64,11 +64,17 @@ struct color_yuv { > .u = MAKE_YUV_601_U(r, g, b), \ > .v = MAKE_YUV_601_V(r, g, b) } > > +static inline uint32_t shiftcolor(const struct util_color_component *comp, > + uint32_t value) > +{ > + return ((value << 8) >> (16 - comp->length)) << comp->offset; > +} > + > #define MAKE_RGBA(rgb, r, g, b, a) \ > - r) >> (8 - (rgb)->red.length)) << (rgb)->red.offset) | \ > - (((g) >> (8 - (rgb)->green.length)) << (rgb)->green.offset) | \ > - (((b) >> (8 - (rgb)->blue.length)) << (rgb)->blue.offset) | \ > - (((a) >> (8 - (rgb)->alpha.length)) << (rgb)->alpha.offset)) > + (shiftcolor(&(rgb)->red, (r)) | \ > + shiftcolor(&(rgb)->green, (g)) | \ > + shiftcolor(&(rgb)->blue, (b)) | \ > + shiftcolor(&(rgb)->alpha, (a))) > > #define MAKE_RGB24(rgb, r, g, b) \ > { .value = MAKE_RGBA(rgb, r, g, b, 0) } > -- > 2.13.6 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
From: Ville Syrjälä Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. Cc: Laurent Pinchart Cc: Daniel Vetter Suggested-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +-- drivers/gpu/drm/arm/malidp_planes.c | 7 +-- drivers/gpu/drm/armada/armada_overlay.c | 6 +- drivers/gpu/drm/drm_atomic_helper.c | 12 +++- drivers/gpu/drm/drm_plane_helper.c | 11 +++ drivers/gpu/drm/drm_simple_kms_helper.c | 6 -- drivers/gpu/drm/i915/intel_display.c| 12 drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +-- drivers/gpu/drm/meson/meson_plane.c | 7 +-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ drivers/gpu/drm/nouveau/nv50_display.c | 12 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +-- drivers/gpu/drm/tegra/dc.c | 7 +-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +-- drivers/gpu/drm/zte/zx_plane.c | 13 + include/drm/drm_atomic_helper.h | 1 - include/drm/drm_plane_helper.h | 1 - 18 files changed, 22 insertions(+), 122 deletions(-) diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index fa852fc1c9e6..93c503b754ba 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = { static int hdlcd_plane_atomic_check(struct drm_plane *plane, struct drm_plane_state *state) { - struct drm_rect clip = { 0 }; struct drm_crtc_state *crtc_state; u32 src_h = state->src_h >> 16; @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane, return -EINVAL; } - if (crtc_state->enable) - drm_mode_get_hv_timing(&crtc_state->mode, - &clip.x2, &clip.y2); - - return drm_atomic_helper_check_plane_state(state, crtc_state, &clip, + return drm_atomic_helper_check_plane_state(state, crtc_state, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, false, true); diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index 2f6d608d6eaf..e630c0218aaf 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane *mp, struct drm_crtc_state *crtc_state = drm_atomic_get_existing_crtc_state(state->state, state->crtc); struct malidp_crtc_state *mc; - struct drm_rect clip = { 0 }; u32 src_w, src_h; int ret; if (!crtc_state) return -EINVAL; - if (crtc_state->enable) - drm_mode_get_hv_timing(&crtc_state->mode, - &clip.x2, &clip.y2); - - ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, + ret = drm_atomic_helper_check_plane_state(state, crtc_state, 0, INT_MAX, true, true); if (ret) return ret; diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c index b411b608821a..564bd63a5f6a 100644 --- a/drivers/gpu/drm/armada/armada_overlay.c +++ b/drivers/gpu/drm/armada/armada_overlay.c @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc, .x2 = crtc_x + crtc_w, .y2 = crtc_y + crtc_h, }; - const struct drm_rect clip = { - .x2 = crtc->mode.hdisplay, - .y2 = crtc->mode.vdisplay, - }; uint32_t val, ctrl0; unsigned idx = 0; bool visible; @@ -124,7 +120,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc, crtc_x, crtc_y, crtc_w, crtc_h, src_x, src_y, src_w, src_h); - ret = drm_plane_helper_check_update(plane, crtc, fb, &src, &dest, &clip, + ret = drm_plane_helper_check_update(plane, crtc, fb, &src, &dest, DRM_MODE_ROTATE_0, 0, INT_MAX, true, false, &visible); if (ret) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 2f80377101a1..d25eaf6f62a9 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -699,7 +699,6 @@ EXPORT_S
[PATCH 12/15] drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Thierry Reding Cc: linux-te...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/tegra/dc.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index fc70351b9017..93b47e0e038b 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -477,7 +477,7 @@ static int tegra_plane_state_add(struct tegra_plane *plane, { struct drm_crtc_state *crtc_state; struct tegra_dc_state *tegra; - struct drm_rect clip; + struct drm_rect clip = {}; int err; /* Propagate errors from allocation or locking failures. */ @@ -485,10 +485,9 @@ static int tegra_plane_state_add(struct tegra_plane *plane, if (IS_ERR(crtc_state)) return PTR_ERR(crtc_state); - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->mode.hdisplay; - clip.y2 = crtc_state->mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); /* Check plane state for visibility and calculate clipping bounds */ err = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/15] drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Rob Clark Cc: Archit Taneja Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c index ee41423baeb7..09f758e7bb1b 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c @@ -286,7 +286,7 @@ static int mdp5_plane_atomic_check_with_state(struct drm_crtc_state *crtc_state, uint32_t max_width, max_height; bool out_of_bounds = false; uint32_t caps = 0; - struct drm_rect clip; + struct drm_rect clip = {}; int min_scale, max_scale; int ret; @@ -320,13 +320,13 @@ static int mdp5_plane_atomic_check_with_state(struct drm_crtc_state *crtc_state, return -ERANGE; } - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; min_scale = FRAC_16_16(1, 8); max_scale = FRAC_16_16(8, 1); + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, min_scale, max_scale, true, true); @@ -471,7 +471,7 @@ static int mdp5_plane_atomic_async_check(struct drm_plane *plane, { struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state); struct drm_crtc_state *crtc_state; - struct drm_rect clip; + struct drm_rect clip = {}; int min_scale, max_scale; int ret; @@ -499,13 +499,13 @@ static int mdp5_plane_atomic_async_check(struct drm_plane *plane, plane->state->fb != state->fb) return -EINVAL; - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; min_scale = FRAC_16_16(1, 8); max_scale = FRAC_16_16(8, 1); + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, min_scale, max_scale, true, true); -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/15] drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Shawn Guo Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/zte/zx_plane.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c index 68fd2e2dc78a..8e1f34274e24 100644 --- a/drivers/gpu/drm/zte/zx_plane.c +++ b/drivers/gpu/drm/zte/zx_plane.c @@ -55,7 +55,7 @@ static int zx_vl_plane_atomic_check(struct drm_plane *plane, struct drm_framebuffer *fb = plane_state->fb; struct drm_crtc *crtc = plane_state->crtc; struct drm_crtc_state *crtc_state; - struct drm_rect clip; + struct drm_rect clip = {}; int min_scale = FRAC_16_16(1, 8); int max_scale = FRAC_16_16(8, 1); @@ -75,10 +75,9 @@ static int zx_vl_plane_atomic_check(struct drm_plane *plane, if (!plane_state->crtc) return -EINVAL; - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); return drm_atomic_helper_check_plane_state(plane_state, crtc_state, &clip, min_scale, max_scale, @@ -292,7 +291,7 @@ static int zx_gl_plane_atomic_check(struct drm_plane *plane, struct drm_framebuffer *fb = plane_state->fb; struct drm_crtc *crtc = plane_state->crtc; struct drm_crtc_state *crtc_state; - struct drm_rect clip; + struct drm_rect clip = {}; if (!crtc || !fb) return 0; @@ -310,10 +309,9 @@ static int zx_gl_plane_atomic_check(struct drm_plane *plane, if (!plane_state->crtc) return -EINVAL; - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); return drm_atomic_helper_check_plane_state(plane_state, crtc_state, &clip, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/15] drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas Hellstrom Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index a2a93d7e2a04..25d96560180b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -449,10 +449,9 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane *plane, if (state->crtc) crtc_state = drm_atomic_get_new_crtc_state(state->state, state->crtc); - if (crtc_state && crtc_state->enable) { - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; - } + if (crtc_state && crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, DRM_PLANE_HELPER_NO_SCALING, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/15] drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Mark Yao Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index ba7505292b78..cd2c72389629 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -641,7 +641,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane, struct vop_win *vop_win = to_vop_win(plane); const struct vop_win_data *win = vop_win->data; int ret; - struct drm_rect clip; + struct drm_rect clip = {}; int min_scale = win->phy->scl ? FRAC_16_16(1, 8) : DRM_PLANE_HELPER_NO_SCALING; int max_scale = win->phy->scl ? FRAC_16_16(8, 1) : @@ -654,10 +654,9 @@ static int vop_plane_atomic_check(struct drm_plane *plane, if (WARN_ON(!crtc_state)) return -EINVAL; - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, min_scale, max_scale, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/15] drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/nouveau/nv50_display.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 65336948e807..7d8307ec442c 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -228,8 +228,6 @@ struct nv50_wndw_atom { struct drm_plane_state state; u8 interval; - struct drm_rect clip; - struct { u32 handle; u16 offset:12; @@ -840,10 +838,6 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw, int ret; NV_ATOMIC(drm, "%s acquire\n", wndw->plane.name); - asyw->clip.x1 = 0; - asyw->clip.y1 = 0; - asyw->clip.x2 = asyh->state.mode.hdisplay; - asyw->clip.y2 = asyh->state.mode.vdisplay; asyw->image.w = fb->base.width; asyw->image.h = fb->base.height; @@ -1141,10 +1135,15 @@ static int nv50_curs_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw, struct nv50_head_atom *asyh) { + struct drm_rect clip = {}; int ret; + if (asyh->state.enable) + drm_mode_get_hv_timing(&asyh->state.mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(&asyw->state, &asyh->state, - &asyw->clip, + &clip, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, true, true); @@ -1428,13 +1427,18 @@ nv50_base_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw, struct nv50_head_atom *asyh) { const struct drm_framebuffer *fb = asyw->state.fb; + struct drm_rect clip = {}; int ret; if (!fb->format->depth) return -EINVAL; + if (asyh->state.enable) + drm_mode_get_hv_timing(&asyh->state.mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(&asyw->state, &asyh->state, - &asyw->clip, + &clip, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, false, true); -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: CK Hu Cc: Philipp Zabel Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index 5ef898b93d8d..b5c6eec9a584 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -108,8 +108,9 @@ static int mtk_plane_atomic_check(struct drm_plane *plane, if (IS_ERR(crtc_state)) return PTR_ERR(crtc_state); - clip.x2 = crtc_state->mode.hdisplay; - clip.y2 = crtc_state->mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); return drm_atomic_helper_check_plane_state(state, crtc_state, &clip, DRM_PLANE_HELPER_NO_SCALING, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/15] drm/meson: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Neil Armstrong Cc: linux-amlo...@lists.infradead.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/meson/meson_plane.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_plane.c b/drivers/gpu/drm/meson/meson_plane.c index d0a6ac8390f3..3801bee1f9e6 100644 --- a/drivers/gpu/drm/meson/meson_plane.c +++ b/drivers/gpu/drm/meson/meson_plane.c @@ -58,8 +58,9 @@ static int meson_plane_atomic_check(struct drm_plane *plane, if (IS_ERR(crtc_state)) return PTR_ERR(crtc_state); - clip.x2 = crtc_state->mode.hdisplay; - clip.y2 = crtc_state->mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); return drm_atomic_helper_check_plane_state(state, crtc_state, &clip, DRM_PLANE_HELPER_NO_SCALING, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/15] drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes since pipe_src_w/h are already filled via drm_mode_get_hv_timing(). Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_atomic_plane.c | 8 drivers/gpu/drm/i915/intel_display.c | 14 -- drivers/gpu/drm/i915/intel_drv.h | 1 - drivers/gpu/drm/i915/intel_sprite.c | 8 ++-- 4 files changed, 18 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c index 8e6dc159f64d..c7984a80706e 100644 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c @@ -129,14 +129,6 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_ if (!intel_state->base.crtc && !old_plane_state->base.crtc) return 0; - /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */ - intel_state->clip.x1 = 0; - intel_state->clip.y1 = 0; - intel_state->clip.x2 = - crtc_state->base.enable ? crtc_state->pipe_src_w : 0; - intel_state->clip.y2 = - crtc_state->base.enable ? crtc_state->pipe_src_h : 0; - if (state->fb && drm_rotation_90_or_270(state->rotation)) { struct drm_format_name_buf format_name; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 959d21157328..4eeec590b722 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9267,13 +9267,18 @@ static int intel_check_cursor(struct intel_crtc_state *crtc_state, struct intel_plane_state *plane_state) { const struct drm_framebuffer *fb = plane_state->base.fb; + struct drm_rect clip = {}; int src_x, src_y; u32 offset; int ret; + if (crtc_state->base.enable) + drm_mode_get_hv_timing(&crtc_state->base.mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(&plane_state->base, &crtc_state->base, - &plane_state->clip, + &clip, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, true, true); @@ -12832,6 +12837,7 @@ intel_check_primary_plane(struct intel_plane *plane, int min_scale = DRM_PLANE_HELPER_NO_SCALING; int max_scale = DRM_PLANE_HELPER_NO_SCALING; bool can_position = false; + struct drm_rect clip = {}; int ret; if (INTEL_GEN(dev_priv) >= 9) { @@ -12843,9 +12849,13 @@ intel_check_primary_plane(struct intel_plane *plane, can_position = true; } + if (crtc_state->base.enable) + drm_mode_get_hv_timing(&crtc_state->base.mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(&state->base, &crtc_state->base, - &state->clip, + &clip, min_scale, max_scale, can_position, true); if (ret) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 635a96fcd788..06017de4a29c 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -403,7 +403,6 @@ struct intel_atomic_state { struct intel_plane_state { struct drm_plane_state base; - struct drm_rect clip; struct i915_vma *vma; struct { diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index dd485f59eb1d..cffa7a8b0f9c 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -864,7 +864,7 @@ intel_check_sprite_plane(struct intel_plane *plane, uint32_t src_x, src_y, src_w, src_h; struct drm_rect *src = &state->base.src; struct drm_rect *dst = &state->base.dst; - const struct drm_rect *clip = &state->clip; + struct drm_rect clip = {}; int hscale, vscale; int max_scale, min_scale; bool can_scale; @@ -922,7 +922,11 @@ intel_check_sprite_plane(struct intel_plane *plane, vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale); BUG_ON(vscale < 0); - state->base.visible = drm_rect_clip_scaled(src, dst, clip, hscale, vscale); +
[PATCH 06/15] drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Philipp Zabel Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/imx/ipuv3-plane.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index 5a67daedcf4d..c0662503571b 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -322,7 +322,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane, struct drm_framebuffer *old_fb = old_state->fb; unsigned long eba, ubo, vbo, old_ubo, old_vbo, alpha_eba; bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY); - struct drm_rect clip; + struct drm_rect clip = {}; int hsub, vsub; int ret; @@ -338,10 +338,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane, if (WARN_ON(!crtc_state)) return -EINVAL; - clip.x1 = 0; - clip.y1 = 0; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/15] drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/malidp_planes.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index 72a07950167e..2f6d608d6eaf 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -148,8 +148,10 @@ static int malidp_se_check_scaling(struct malidp_plane *mp, if (!crtc_state) return -EINVAL; - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); + ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, 0, INT_MAX, true, true); if (ret) -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/15] drm: More plane clipping polish
From: Ville Syrjälä This series first unifies all users of drm_atomic_helper_check_plane_state() to populate the clip rectangle with drm_mode_get_hv_timing(), and once everything is unified the clip rectangle handling is sucked into drm_atomic_helper_check_plane_state() away from driver code. Entire series available here: git://github.com/vsyrjala/linux.git atomic_plane_helper_clip Cc: Archit Taneja Cc: Ben Skeggs Cc: Brian Starkey Cc: CK Hu Cc: Daniel Vetter Cc: freedr...@lists.freedesktop.org Cc: Laurent Pinchart Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: Liviu Dudau Cc: Mali DP Maintainers Cc: Mark Yao Cc: Neil Armstrong Cc: Noralf Trønnes Cc: nouv...@lists.freedesktop.org Cc: Philipp Zabel Cc: Rob Clark Cc: Shawn Guo Cc: Sinclair Yeh Cc: Thierry Reding Cc: Thomas Hellstrom Cc: VMware Graphics Ville Syrjälä (15): drm/i915: Reject odd pipe source width with double wide/dual link drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/meson: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm: Don't pass clip to drm_atomic_helper_check_plane_state() drivers/gpu/drm/arm/hdlcd_crtc.c| 6 +- drivers/gpu/drm/arm/malidp_planes.c | 5 + drivers/gpu/drm/armada/armada_overlay.c | 2 +- drivers/gpu/drm/drm_atomic_helper.c | 12 +++- drivers/gpu/drm/drm_plane_helper.c | 11 +++ drivers/gpu/drm/drm_simple_kms_helper.c | 5 - drivers/gpu/drm/i915/intel_atomic_plane.c | 8 drivers/gpu/drm/i915/intel_display.c| 12 +++- drivers/gpu/drm/i915/intel_drv.h| 1 - drivers/gpu/drm/i915/intel_sprite.c | 8 ++-- drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 +- drivers/gpu/drm/meson/meson_plane.c | 6 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ drivers/gpu/drm/nouveau/nv50_display.c | 8 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +--- drivers/gpu/drm/tegra/dc.c | 8 +--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +--- drivers/gpu/drm/zte/zx_plane.c | 15 +-- include/drm/drm_atomic_helper.h | 1 - include/drm/drm_plane_helper.h | 1 - 21 files changed, 35 insertions(+), 117 deletions(-) -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/15] drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Noralf Trønnes Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_simple_kms_helper.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c index 9f3b1c94802b..9d3f6b70812c 100644 --- a/drivers/gpu/drm/drm_simple_kms_helper.c +++ b/drivers/gpu/drm/drm_simple_kms_helper.c @@ -100,8 +100,9 @@ static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane, if (!crtc_state->enable) return 0; /* nothing to check when disabling or disabled */ - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state, &clip, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/15] drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/hdlcd_crtc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index 63511a3bbf6c..fa852fc1c9e6 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -249,8 +249,9 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane, return -EINVAL; } - clip.x2 = crtc_state->adjusted_mode.hdisplay; - clip.y2 = crtc_state->adjusted_mode.vdisplay; + if (crtc_state->enable) + drm_mode_get_hv_timing(&crtc_state->mode, + &clip.x2, &clip.y2); return drm_atomic_helper_check_plane_state(state, crtc_state, &clip, DRM_PLANE_HELPER_NO_SCALING, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/15] drm/i915: Reject odd pipe source width with double wide/dual link
From: Ville Syrjälä In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay we must not adjust pipe_src_w to accommodate double wide/dual link. Instead just reject the mode outright. This will allows us to rely on crtc_state->mode for plane clipping. Cc: Laurent Pinchart Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d67c7c498b34..959d21157328 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6332,9 +6332,18 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc, * - LVDS dual channel mode * - Double wide pipe */ - if ((intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) && -intel_is_dual_link_lvds(dev)) || pipe_config->double_wide) - pipe_config->pipe_src_w &= ~1; + if (pipe_config->pipe_src_w & 1) { + if (pipe_config->double_wide) { + DRM_DEBUG_KMS("Odd pipe source width not supported with double wide pipe\n"); + return -EINVAL; + } + + if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) && + intel_is_dual_link_lvds(dev)) { + DRM_DEBUG_KMS("Odd pipe source width not supported with dual link LVDS\n"); + return -EINVAL; + } + } /* Cantiga+ cannot handle modes with a hsync front porch of 0. * WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw. -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes
We need to shift the values up, otherwise we'd end up with a negative shift. This works for up-to 16-bit components, which is fine for now. Signed-off-by: Ilia Mirkin --- tests/util/pattern.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/tests/util/pattern.c b/tests/util/pattern.c index 41fb541b..2f9bb384 100644 --- a/tests/util/pattern.c +++ b/tests/util/pattern.c @@ -64,11 +64,17 @@ struct color_yuv { .u = MAKE_YUV_601_U(r, g, b), \ .v = MAKE_YUV_601_V(r, g, b) } +static inline uint32_t shiftcolor(const struct util_color_component *comp, + uint32_t value) +{ + return ((value << 8) >> (16 - comp->length)) << comp->offset; +} + #define MAKE_RGBA(rgb, r, g, b, a) \ - r) >> (8 - (rgb)->red.length)) << (rgb)->red.offset) | \ -(((g) >> (8 - (rgb)->green.length)) << (rgb)->green.offset) | \ -(((b) >> (8 - (rgb)->blue.length)) << (rgb)->blue.offset) | \ -(((a) >> (8 - (rgb)->alpha.length)) << (rgb)->alpha.offset)) + (shiftcolor(&(rgb)->red, (r)) | \ +shiftcolor(&(rgb)->green, (g)) | \ +shiftcolor(&(rgb)->blue, (b)) | \ +shiftcolor(&(rgb)->alpha, (a))) #define MAKE_RGB24(rgb, r, g, b) \ { .value = MAKE_RGBA(rgb, r, g, b, 0) } -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-mainline-dkms-4.13 2016/2065] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:579:62: warning: 'tmp' may be used uninitialized in this function
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.13 head: 59aa856b7672d465443305a3fd7a6956f9567ea6 commit: 9c2014d08693830897cad6bbd359d905825d8a18 [2016/2065] drm/amd/powerplay: add CI asics support to smumgr config: i386-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout 9c2014d08693830897cad6bbd359d905825d8a18 # save the attached .config to linux build tree make ARCH=i386 Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c: In function 'ci_init_smc_table': >> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:579:62: warning: >> 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized] smu_data->power_tune_table.FuzzyFan_PwmSetDelta = CONVERT_FROM_HOST_TO_SMC_US(tmp); ~^~~ drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:571:11: note: 'tmp' was declared here uint16_t tmp; ^~~ vim +/tmp +579 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c 568 569 static int ci_populate_fuzzy_fan(struct pp_hwmgr *hwmgr, uint32_t fuse_table_offset) 570 { 571 uint16_t tmp; 572 struct ci_smumgr *smu_data = (struct ci_smumgr *)(hwmgr->smumgr->backend); 573 574 if ((hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity & (1 << 15)) 575 || 0 == hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity) 576 tmp = hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity 577 = hwmgr->thermal_controller.advanceFanControlParameters.usDefaultFanOutputSensitivity; 578 > 579 smu_data->power_tune_table.FuzzyFan_PwmSetDelta = > CONVERT_FROM_HOST_TO_SMC_US(tmp); 580 581 return 0; 582 } 583 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103863] Screen doesn't light up with "amdgpu.dc=1"
https://bugs.freedesktop.org/show_bug.cgi?id=103863 --- Comment #3 from Jordan L --- Hi Benjamin, Do you have a full dmesg log? Also, would you be able to try with a different cable? It looks like a link training failure. Thanks -- 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] drm/msm: update adreno firmware path in MODULE_FIRMWARE
On Thu, Nov 23, 2017 at 10:09 AM, Nicolas Dechesne wrote: > On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote: >> On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne >> wrote: >>> The preferred location for Adreno firmware files is now in qcom/ subfolder, >>> especially now that we are adding some of them in linux-firmware. >>> >>> Reported-by: Ben Hutchings >>> Signed-off-by: Nicolas Dechesne >> >> Thanks, I was wondering if we should perhaps list both old and new >> paths? I'm not sure, maybe we don't need to care about dracut or >> initrd generation for the legacy case (since mostly there you are >> using fastboot). > > I've been going back and forth on that too. and i decided to ignore > the legacy paths... alternatively we could use the legacy paths for > a3xx and the new path for a5xx since we have links for a3xx files... > but i thought it was too much noise.. > >> >> Also, I noticed we are missing a few a5xx fw files, but perhaps that >> should be fixed with a separate patch. > > as you want. I can include them if you prefer and resend. I think based on what Ben pointed out, let's not include legacy paths. But if you could send an additional patch to add the missing a5xx fw that would be appreciated BR, -R >> >> Either way, >> >> Reviewed-by: Rob Clark >> >>> --- >>> drivers/gpu/drm/msm/adreno/adreno_device.c | 16 >>> 1 file changed, 8 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c >>> b/drivers/gpu/drm/msm/adreno/adreno_device.c >>> index 05022ea2a007..3c1d23b9ddc3 100644 >>> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c >>> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c >>> @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = { >>> }, >>> }; >>> >>> -MODULE_FIRMWARE("a300_pm4.fw"); >>> -MODULE_FIRMWARE("a300_pfp.fw"); >>> -MODULE_FIRMWARE("a330_pm4.fw"); >>> -MODULE_FIRMWARE("a330_pfp.fw"); >>> -MODULE_FIRMWARE("a420_pm4.fw"); >>> -MODULE_FIRMWARE("a420_pfp.fw"); >>> -MODULE_FIRMWARE("a530_fm4.fw"); >>> -MODULE_FIRMWARE("a530_pfp.fw"); >>> +MODULE_FIRMWARE("qcom/a300_pm4.fw"); >>> +MODULE_FIRMWARE("qcom/a300_pfp.fw"); >>> +MODULE_FIRMWARE("qcom/a330_pm4.fw"); >>> +MODULE_FIRMWARE("qcom/a330_pfp.fw"); >>> +MODULE_FIRMWARE("qcom/a420_pm4.fw"); >>> +MODULE_FIRMWARE("qcom/a420_pfp.fw"); >>> +MODULE_FIRMWARE("qcom/a530_fm4.fw"); >>> +MODULE_FIRMWARE("qcom/a530_pfp.fw"); >>> >>> static inline bool _rev_match(uint8_t entry, uint8_t id) >>> { >>> -- >>> 2.15.0 >>> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE
On Thu, Nov 23, 2017 at 12:09 PM, Ben Hutchings wrote: > On Thu, 2017-11-23 at 16:09 +0100, Nicolas Dechesne wrote: >> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote: >> > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne >> > wrote: >> > > The preferred location for Adreno firmware files is now in qcom/ >> > > subfolder, >> > > especially now that we are adding some of them in linux-firmware. >> > > >> > > Reported-by: Ben Hutchings >> > > Signed-off-by: Nicolas Dechesne >> > >> > Thanks, I was wondering if we should perhaps list both old and new >> > paths? I'm not sure, maybe we don't need to care about dracut or >> > initrd generation for the legacy case (since mostly there you are >> > using fastboot). >> >> I've been going back and forth on that too. and i decided to ignore >> the legacy paths... alternatively we could use the legacy paths for >> a3xx and the new path for a5xx since we have links for a3xx files... >> but i thought it was too much noise.. >> >> > >> > Also, I noticed we are missing a few a5xx fw files, but perhaps that >> > should be fixed with a separate patch. >> >> as you want. I can include them if you prefer and resend. > > Whenever I've added MODULE_FIRMWARE information I've listed only the > first-choice firmware paths. > > initramfs-tools will warn when including a module if some of the listed > firmware is not available, so listing multiple paths for the same > firmware will likely mean it always warns about one of them. > Ok, that sounds like good reason to not to list legacy paths. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE
On Thu, 2017-11-23 at 16:09 +0100, Nicolas Dechesne wrote: > On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote: > > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne > > wrote: > > > The preferred location for Adreno firmware files is now in qcom/ > > > subfolder, > > > especially now that we are adding some of them in linux-firmware. > > > > > > Reported-by: Ben Hutchings > > > Signed-off-by: Nicolas Dechesne > > > > Thanks, I was wondering if we should perhaps list both old and new > > paths? I'm not sure, maybe we don't need to care about dracut or > > initrd generation for the legacy case (since mostly there you are > > using fastboot). > > I've been going back and forth on that too. and i decided to ignore > the legacy paths... alternatively we could use the legacy paths for > a3xx and the new path for a5xx since we have links for a3xx files... > but i thought it was too much noise.. > > > > > Also, I noticed we are missing a few a5xx fw files, but perhaps that > > should be fixed with a separate patch. > > as you want. I can include them if you prefer and resend. Whenever I've added MODULE_FIRMWARE information I've listed only the first-choice firmware paths. initramfs-tools will warn when including a module if some of the listed firmware is not available, so listing multiple paths for the same firmware will likely mean it always warns about one of them. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: adapt to new TTM interface
Hi, On 23-11-17 17:14, Christian König wrote: I missed this driver because it is in the staging area. Signed-off-by: Christian König Thank you, looks good to me. Can you please re-send this with Greh KH (the staging maintainer) added in the To: list and my: Reviewed-by: Hans de Goede Added? Regards, Hans --- drivers/staging/vboxvideo/vbox_ttm.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_ttm.c b/drivers/staging/vboxvideo/vbox_ttm.c index 4eb410a2a1a8..231c89e0699c 100644 --- a/drivers/staging/vboxvideo/vbox_ttm.c +++ b/drivers/staging/vboxvideo/vbox_ttm.c @@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev, { } -static int vbox_bo_move(struct ttm_buffer_object *bo, - bool evict, bool interruptible, - bool no_wait_gpu, struct ttm_mem_reg *new_mem) -{ - return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem); -} - static void vbox_ttm_backend_destroy(struct ttm_tt *tt) { ttm_tt_fini(tt); @@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = { .init_mem_type = vbox_bo_init_mem_type, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = vbox_bo_evict_flags, - .move = vbox_bo_move, .verify_access = vbox_bo_verify_access, .io_mem_reserve = &vbox_ttm_io_mem_reserve, .io_mem_free = &vbox_ttm_io_mem_free, @@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo) int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (bo->pin_count) { @@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false); + ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); if (ret) return ret; @@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) int vbox_bo_unpin(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false); + ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); if (ret) return ret; @@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) */ int vbox_bo_push_sysram(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false); + ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); if (ret) { DRM_ERROR("pushing to VRAM failed\n"); return ret; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: vboxvideo: adapt to new TTM interface
I missed this driver because it is in the staging area. Signed-off-by: Christian König --- drivers/staging/vboxvideo/vbox_ttm.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_ttm.c b/drivers/staging/vboxvideo/vbox_ttm.c index 4eb410a2a1a8..231c89e0699c 100644 --- a/drivers/staging/vboxvideo/vbox_ttm.c +++ b/drivers/staging/vboxvideo/vbox_ttm.c @@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev, { } -static int vbox_bo_move(struct ttm_buffer_object *bo, - bool evict, bool interruptible, - bool no_wait_gpu, struct ttm_mem_reg *new_mem) -{ - return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem); -} - static void vbox_ttm_backend_destroy(struct ttm_tt *tt) { ttm_tt_fini(tt); @@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = { .init_mem_type = vbox_bo_init_mem_type, .eviction_valuable = ttm_bo_eviction_valuable, .evict_flags = vbox_bo_evict_flags, - .move = vbox_bo_move, .verify_access = vbox_bo_verify_access, .io_mem_reserve = &vbox_ttm_io_mem_reserve, .io_mem_free = &vbox_ttm_io_mem_free, @@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo) int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (bo->pin_count) { @@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false); + ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); if (ret) return ret; @@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr) int vbox_bo_unpin(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false); + ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); if (ret) return ret; @@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo) */ int vbox_bo_push_sysram(struct vbox_bo *bo) { + struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (!bo->pin_count) { @@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; - ret = ttm_bo_validate(&bo->bo, &bo->placement, false, false); + ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); if (ret) { DRM_ERROR("pushing to VRAM failed\n"); return ret; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format
On Thu, Nov 23, 2017 at 04:56:56PM +0800, Tina Zhang wrote: > The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in > windows. The float format in each component is 1:5:10 MSb-sign:exponent: > fraction. > > This patch is to introduce the format to drm, so that the windows guest's > framebuffer in this kind of format can be recognized and used by linux > host. > > v14: > - add some details about the float pixel format. (Daniel) > - add F suffix to the defined name. (Daniel) > > v12: > - send to dri-devel at lists.freedesktop.org. (Ville) > > v9: > - separated from framebuffer decoder patch. (Zhenyu) (Xiaoguang) > > Signed-off-by: Tina Zhang > Cc: Ville Syrjälä > Cc: Dave Airlie > Cc: Daniel Vetter > --- > include/uapi/drm/drm_fourcc.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 3ad838d..391d2e6 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -113,6 +113,10 @@ extern "C" { > > #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /* > [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */ > > +/* 64 bpp RGB 16:16:16:16 Floating Point */ As before this is still extremely vague. Stating that each component is a IEEE-754 half-precision float (binary16) should cover it. Well, assuming that it really is one. > +#define DRM_FORMAT_XRGB161616F fourcc_code('X', 'R', '3', 'F') /* [63:0] > x:R:G:B 16:16:16:16 little endian */ > +#define DRM_FORMAT_XBGR161616F fourcc_code('X', 'B', '3', 'F') /* [63:0] > x:B:G:R 16:16:16:16 little endian */ Missing one 16 from that name to be consistent with the non-float stuff. Also maybe it should be (... '4', 'F')? '3' would seem to imply a 48 bit pixel. And of course it's still missing the actual implemntation for any driver. > + > /* > * 2 plane RGB + A > * index 0 = RGB plane, same format as the corresponding non _A8 format has > -- > 2.7.4 -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE
On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote: > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne > wrote: >> The preferred location for Adreno firmware files is now in qcom/ subfolder, >> especially now that we are adding some of them in linux-firmware. >> >> Reported-by: Ben Hutchings >> Signed-off-by: Nicolas Dechesne > > Thanks, I was wondering if we should perhaps list both old and new > paths? I'm not sure, maybe we don't need to care about dracut or > initrd generation for the legacy case (since mostly there you are > using fastboot). I've been going back and forth on that too. and i decided to ignore the legacy paths... alternatively we could use the legacy paths for a3xx and the new path for a5xx since we have links for a3xx files... but i thought it was too much noise.. > > Also, I noticed we are missing a few a5xx fw files, but perhaps that > should be fixed with a separate patch. as you want. I can include them if you prefer and resend. > > Either way, > > Reviewed-by: Rob Clark > >> --- >> drivers/gpu/drm/msm/adreno/adreno_device.c | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c >> b/drivers/gpu/drm/msm/adreno/adreno_device.c >> index 05022ea2a007..3c1d23b9ddc3 100644 >> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c >> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c >> @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = { >> }, >> }; >> >> -MODULE_FIRMWARE("a300_pm4.fw"); >> -MODULE_FIRMWARE("a300_pfp.fw"); >> -MODULE_FIRMWARE("a330_pm4.fw"); >> -MODULE_FIRMWARE("a330_pfp.fw"); >> -MODULE_FIRMWARE("a420_pm4.fw"); >> -MODULE_FIRMWARE("a420_pfp.fw"); >> -MODULE_FIRMWARE("a530_fm4.fw"); >> -MODULE_FIRMWARE("a530_pfp.fw"); >> +MODULE_FIRMWARE("qcom/a300_pm4.fw"); >> +MODULE_FIRMWARE("qcom/a300_pfp.fw"); >> +MODULE_FIRMWARE("qcom/a330_pm4.fw"); >> +MODULE_FIRMWARE("qcom/a330_pfp.fw"); >> +MODULE_FIRMWARE("qcom/a420_pm4.fw"); >> +MODULE_FIRMWARE("qcom/a420_pfp.fw"); >> +MODULE_FIRMWARE("qcom/a530_fm4.fw"); >> +MODULE_FIRMWARE("qcom/a530_pfp.fw"); >> >> static inline bool _rev_match(uint8_t entry, uint8_t id) >> { >> -- >> 2.15.0 >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
Hi Jan, On Thu, Nov 23, 2017 at 10:55 AM, Jan Tuerk wrote: > The Emerging Display Technology ETM0700G0BDH6 is exactly > the same display as the ETM0700G0DH6, exept the pixelclock > polarity. Therefore re-use the ETM0700G0DH6 modes. It is > used by default on emtrion Avari based development kits. > > Signed-off-by: Jan Tuerk Please run ./scripts/checkpatch.pl on your patch. Currently it gives: total: 18 errors, 13 warnings, 39 lines checked Please fix and resend. Also, you could try git send-email in the next time. Regards, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE
On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne wrote: > The preferred location for Adreno firmware files is now in qcom/ subfolder, > especially now that we are adding some of them in linux-firmware. > > Reported-by: Ben Hutchings > Signed-off-by: Nicolas Dechesne Thanks, I was wondering if we should perhaps list both old and new paths? I'm not sure, maybe we don't need to care about dracut or initrd generation for the legacy case (since mostly there you are using fastboot). Also, I noticed we are missing a few a5xx fw files, but perhaps that should be fixed with a separate patch. Either way, Reviewed-by: Rob Clark > --- > drivers/gpu/drm/msm/adreno/adreno_device.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c > b/drivers/gpu/drm/msm/adreno/adreno_device.c > index 05022ea2a007..3c1d23b9ddc3 100644 > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c > @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = { > }, > }; > > -MODULE_FIRMWARE("a300_pm4.fw"); > -MODULE_FIRMWARE("a300_pfp.fw"); > -MODULE_FIRMWARE("a330_pm4.fw"); > -MODULE_FIRMWARE("a330_pfp.fw"); > -MODULE_FIRMWARE("a420_pm4.fw"); > -MODULE_FIRMWARE("a420_pfp.fw"); > -MODULE_FIRMWARE("a530_fm4.fw"); > -MODULE_FIRMWARE("a530_pfp.fw"); > +MODULE_FIRMWARE("qcom/a300_pm4.fw"); > +MODULE_FIRMWARE("qcom/a300_pfp.fw"); > +MODULE_FIRMWARE("qcom/a330_pm4.fw"); > +MODULE_FIRMWARE("qcom/a330_pfp.fw"); > +MODULE_FIRMWARE("qcom/a420_pm4.fw"); > +MODULE_FIRMWARE("qcom/a420_pfp.fw"); > +MODULE_FIRMWARE("qcom/a530_fm4.fw"); > +MODULE_FIRMWARE("qcom/a530_pfp.fw"); > > static inline bool _rev_match(uint8_t entry, uint8_t id) > { > -- > 2.15.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos: mixer: avoid Oops in vp_video_buffer()
If an interlaced video mode is selected, a IOMMU pagefault is triggered by vp_video_buffer(). Fix the most apparent bugs: - pitch value for chroma plane - divide by two of height and vpos This is more like a band-aid at this point. The VP plane is still corrupted, but at least there are no more pagefaults. Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index dc5d79465f9b..a18426379e57 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx, chroma_addr[1] = chroma_addr[0] + 0x40; } else { luma_addr[1] = luma_addr[0] + fb->pitches[0]; - chroma_addr[1] = chroma_addr[0] + fb->pitches[0]; + chroma_addr[1] = chroma_addr[0] + fb->pitches[1]; } } else { luma_addr[1] = 0; @@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx, vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) | VP_IMG_VSIZE(fb->height)); /* chroma plane for NV12/NV21 is half the height of the luma plane */ - vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) | + vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) | VP_IMG_VSIZE(fb->height / 2)); vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w); - vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h); vp_reg_write(ctx, VP_SRC_H_POSITION, VP_SRC_H_POSITION_VAL(state->src.x)); - vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y); - vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w); - vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x); if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) { - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2); - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2); + vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h / 2); + vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y / 2); } else { - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h); - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y); + vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h); + vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y); } + vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w); + vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x); + vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h); + vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y); + vp_reg_write(ctx, VP_H_RATIO, state->h_ratio); vp_reg_write(ctx, VP_V_RATIO, state->v_ratio); -- 2.13.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()
Please disregard this one, need to rebase. v2 in a minute... - Tobias Tobias Jakobi wrote: > If an interlaced video mode is selected, a IOMMU pagefault is > triggered by vp_video_buffer(). > > Fix the most apparent bugs: > - pitch value for chroma plane > - divide by two of height and vpos > > This is more like a band-aid at this point. The VP plane is > still corrupted, but at least there are no more pagefaults. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++-- > 1 file changed, 11 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index dc5d79465f9b..c382f99e0f5b 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx, > chroma_addr[1] = chroma_addr[0] + 0x40; > } else { > luma_addr[1] = luma_addr[0] + fb->pitches[0]; > - chroma_addr[1] = chroma_addr[0] + fb->pitches[0]; > + chroma_addr[1] = chroma_addr[0] + fb->pitches[1]; > } > } else { > luma_addr[1] = 0; > @@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx, > vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) | > VP_IMG_VSIZE(fb->height)); > /* chroma plane for NV12/NV21 is half the height of the luma plane */ > - vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) | > + vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) | > VP_IMG_VSIZE(fb->height / 2)); > > vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w); > - vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h); > vp_reg_write(ctx, VP_SRC_H_POSITION, > VP_SRC_H_POSITION_VAL(state->src.x)); > - vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y); > > - vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w); > - vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x); > if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) { > - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2); > - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2); > + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2); > + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2); > } else { > - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h); > - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y); > + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h); > + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y); > } > > + vp_reg_write(res, VP_DST_WIDTH, state->crtc.w); > + vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x); > + vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h); > + vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y); > + > vp_reg_write(ctx, VP_H_RATIO, state->h_ratio); > vp_reg_write(ctx, VP_V_RATIO, state->v_ratio); > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()
If an interlaced video mode is selected, a IOMMU pagefault is triggered by vp_video_buffer(). Fix the most apparent bugs: - pitch value for chroma plane - divide by two of height and vpos This is more like a band-aid at this point. The VP plane is still corrupted, but at least there are no more pagefaults. Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index dc5d79465f9b..c382f99e0f5b 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx, chroma_addr[1] = chroma_addr[0] + 0x40; } else { luma_addr[1] = luma_addr[0] + fb->pitches[0]; - chroma_addr[1] = chroma_addr[0] + fb->pitches[0]; + chroma_addr[1] = chroma_addr[0] + fb->pitches[1]; } } else { luma_addr[1] = 0; @@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx, vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) | VP_IMG_VSIZE(fb->height)); /* chroma plane for NV12/NV21 is half the height of the luma plane */ - vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) | + vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) | VP_IMG_VSIZE(fb->height / 2)); vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w); - vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h); vp_reg_write(ctx, VP_SRC_H_POSITION, VP_SRC_H_POSITION_VAL(state->src.x)); - vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y); - vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w); - vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x); if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) { - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2); - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2); + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2); + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2); } else { - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h); - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y); + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h); + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y); } + vp_reg_write(res, VP_DST_WIDTH, state->crtc.w); + vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x); + vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h); + vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y); + vp_reg_write(ctx, VP_H_RATIO, state->h_ratio); vp_reg_write(ctx, VP_V_RATIO, state->v_ratio); -- 2.13.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly
This was implemented correctly only on the atomic ioctl before, but it should really be working on all 3 ioctl's involved, so ensure we always set crtc_id correctly with a testcase. Signed-off-by: Maarten Lankhorst --- tests/kms_vblank.c | 60 ++ 1 file changed, 56 insertions(+), 4 deletions(-) diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c index 47fd10fb9078..004f0e6104ee 100644 --- a/tests/kms_vblank.c +++ b/tests/kms_vblank.c @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void (*testfunc)(data_t *, int, int)) igt_display_t *display = &data->display; igt_output_t *output; enum pipe p; - unsigned int valid_tests = 0; for_each_pipe_with_valid_output(display, p, output) { igt_hang_t hang; @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void (*testfunc)(data_t *, int, int)) /* cleanup what prepare_crtc() has done */ cleanup_crtc(data, fd, output); - valid_tests++; } +} + +static void crtc_id_subtest(data_t *data, int fd) +{ + igt_display_t *display = &data->display; + igt_output_t *output; + enum pipe p; + + for_each_pipe_with_valid_output(display, p, output) { + struct drm_event_vblank buf; + const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p); + unsigned crtc_id, expected_crtc_id; + uint64_t val; + union drm_wait_vblank vbl; + + crtc_id = display->pipes[p].crtc_id; + if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, &val) == 0) + expected_crtc_id = crtc_id; + else + expected_crtc_id = 0; + + data->pipe = p; + prepare_crtc(data, fd, output); + + memset(&vbl, 0, sizeof(vbl)); + vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT; + vbl.request.type |= pipe_id_flag; + vbl.request.sequence = 1; + igt_assert_eq(wait_vblank(fd, &vbl), 0); + + igt_assert_eq(read(fd, &buf, sizeof(buf)), sizeof(buf)); + igt_assert_eq(buf.crtc_id, expected_crtc_id); + + do_or_die(drmModePageFlip(fd, crtc_id, + data->primary_fb.fb_id, + DRM_MODE_PAGE_FLIP_EVENT, NULL)); + + igt_assert_eq(read(fd, &buf, sizeof(buf)), sizeof(buf)); + igt_assert_eq(buf.crtc_id, expected_crtc_id); + + if (display->is_atomic) { + igt_plane_t *primary = igt_output_get_plane(output, 0); + + igt_plane_set_fb(primary, &data->primary_fb); + igt_display_commit_atomic(display, DRM_MODE_PAGE_FLIP_EVENT, NULL); - igt_require_f(valid_tests, - "no valid crtc/connector combinations found\n"); + igt_assert_eq(read(fd, &buf, sizeof(buf)), sizeof(buf)); + igt_assert_eq(buf.crtc_id, expected_crtc_id); + } + + cleanup_crtc(data, fd, output); + return; + } } static void accuracy(data_t *data, int fd, int nchildren) @@ -307,8 +355,12 @@ igt_main fd = drm_open_driver(DRIVER_ANY); kmstest_set_vt_graphics_mode(); igt_display_init(&data.display, fd); + igt_display_require_output(&data.display); } + igt_subtest("crtc-id") + crtc_id_subtest(&data, fd); + for (f = funcs; f->name; f++) { for (m = modes; m->name; m++) { if (m->flags & ~f->valid) -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
Inki Dae wrote: > > > 2017년 11월 22일 22:14에 Marek Szyprowski 이(가) 쓴 글: >> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver >> are contiguous, because of the underlying dma_alloc_attrs() function >> provides only such buffers. In such case it makes no sense to keep >> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid >> failures for buffer contiguity checks in the subsequent operations on GEM >> objects. >> >> Signed-off-by: Marek Szyprowski >> CC: sta...@vger.kernel.org # v4.4+ >> --- >> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu >> support for exynos drm framework"), but this patch applies cleanly >> only to v4.4+ kernel releases due changes in the surrounding code. >> >> Changelog: >> v2: >> - added warning message when buffer flags are updadated (requested by Inki) >> >> v1: https://patchwork.kernel.org/patch/10034919/ >> - initial version >> --- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 + >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c >> b/drivers/gpu/drm/exynos/exynos_drm_gem.c >> index 077de014d610..4400efe3974a 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c >> @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct >> drm_device *dev, >> if (IS_ERR(exynos_gem)) >> return exynos_gem; >> >> +if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) { >> +/* >> + * when no IOMMU is available, all allocated buffers are >> + * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag >> + */ >> +flags &= ~EXYNOS_BO_NONCONTIG; >> +DRM_WARN("Non-contiguous allocation is not supported without >> IOMMU, falling back to contiguous buffer\n"); > > WARNING: line over 80 characters That warning is bogus. Message strings are not supposed to be split. > I wil change above a warning like below if you are ok, > DRM_WARN("Changed to CONTIG buffer due to no IOMMU support.\n"); I think Marek's message is more descriptive. - Tobias > > > Thanks, > Inki Dae > >> +} >> + >> /* set memory type and cache attribute from user side. */ >> exynos_gem->flags = flags; >> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer
I'm juggling too many things, and drm-misc maintenance is one that I keep dropping on the floor. Admit reality and remove myself as maintainer. This still leaves us with a nice team of three who are actually doing the drm-misc work, while I focus on drm-intel. Cc: Daniel Vetter Cc: Gustavo Padovan Cc: Sean Paul Cc: Dave Airlie Signed-off-by: Jani Nikula --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9a9d3fdc55ef..fb8820458a7f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4490,7 +4490,6 @@ F:include/linux/vga* DRM DRIVERS AND MISC GPU PATCHES M: Daniel Vetter -M: Jani Nikula M: Gustavo Padovan M: Sean Paul W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drivers/video/hdmi: allow for larger-than-needed vendor IF
On 11/21/17 16:27, Ville Syrjälä wrote: > On Mon, Nov 20, 2017 at 04:02:14PM +0100, Hans Verkuil wrote: >> On 11/20/2017 03:51 PM, Ville Syrjälä wrote: >>> On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote: From: Hans Verkuil Some devices (Windows Intel driver!) send a Vendor InfoFrame that uses a payload length of 0x1b instead of the length of 5 or 6 that the unpack code expects. The InfoFrame is padded with 0 by the source. >>> >>> So it doesn't put any 3D_Metadata stuff in there? We don't see to >>> have code to parse/generate any of that. >> >> I can't remember if it puts any 3D stuff in there. Let me know if you >> want me to check this later this week. > > Would be nice to know. > > I guess we should really add code to parse/generate that stuff too, > otherwise we're going to be lying when we unpack an infoframe with that > stuff present. > Hmm, I can't reproduce this anymore. We did observe it but I can't remember with which hardware or graphics driver version. Testing with a Windows 10 Intel laptop with recent drivers just showed either an empty vendor InfoFrame with a 1080p EDID or a vendor InfoFrame that sets the HDMI VIC to 1 for a 4kp30 EDID. The length is 5 in both cases. Testing with a different laptop gave a vendor InfoFrame with HDMI VIC 1 and a length of 6. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: remove redundant self assignment of 'height'
From: Colin Ian King The assignment of height to itself is redundant and can be removed. Detected with Coccinelle. Signed-off-by: Colin Ian King --- drivers/video/fbdev/vga16fb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c index 5f0690c8fc93..2c6a576ed84c 100644 --- a/drivers/video/fbdev/vga16fb.c +++ b/drivers/video/fbdev/vga16fb.c @@ -1055,7 +1055,6 @@ static void vga16fb_copyarea(struct fb_info *info, const struct fb_copyarea *are case FB_TYPE_VGA_PLANES: if (info->fix.type_aux == FB_AUX_VGA_PLANES_VGA4) { width = width/8; - height = height; line_ofs = info->fix.line_length - width; setmode(1); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Fix ifnullfree.cocci warnings
Hello Vasyl, On 22 November 2017 at 20:52, Vasyl Gomonovych wrote: > NULL check before some freeing functions is not needed. > drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing > debugfs_remove_recursive > Generated by: scripts/coccinelle/free/ifnullfree.cocci Thank you for your patch; applied to drm-misc-next. > > Signed-off-by: Vasyl Gomonovych > --- > drivers/dma-buf/dma-buf.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 4a038dcf5361..048827b06c03 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1179,8 +1179,7 @@ static int dma_buf_init_debugfs(void) > > static void dma_buf_uninit_debugfs(void) > { > - if (dma_buf_debugfs_dir) > - debugfs_remove_recursive(dma_buf_debugfs_dir); > + debugfs_remove_recursive(dma_buf_debugfs_dir); > } > #else > static inline int dma_buf_init_debugfs(void) > -- > 1.9.1 > -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vblank: Pass crtc_id to page_flip_ioctl.
We added crtc_id to the atomic ioctl, but forgot to add it for vblank and page flip events. Commit bd386e518056 ("drm: Reorganize drm_pending_event to support future event types [v2]") added it to the vblank event, but page flip event was still missing. Correct this and add a test for making sure we always set crtc_id correctly. Fixes: bd386e518056 ("drm: Reorganize drm_pending_event to support future event types [v2]") Fixes: 5db06a8a98f5 ("drm: Pass CRTC ID in userspace vblank events") Cc: Daniel Stone Cc: Daniel Vetter Cc: Gustavo Padovan Cc: Sean Paul Cc: dri-devel@lists.freedesktop.org Cc: # v4.12+ Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 19404e34cd59..37a93cdffb4a 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -1030,6 +1030,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, e->event.base.type = DRM_EVENT_FLIP_COMPLETE; e->event.base.length = sizeof(e->event); e->event.vbl.user_data = page_flip->user_data; + e->event.vbl.crtc_id = crtc->base.id; ret = drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base); if (ret) { kfree(e); -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: update adreno firmware path in MODULE_FIRMWARE
The preferred location for Adreno firmware files is now in qcom/ subfolder, especially now that we are adding some of them in linux-firmware. Reported-by: Ben Hutchings Signed-off-by: Nicolas Dechesne --- drivers/gpu/drm/msm/adreno/adreno_device.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 05022ea2a007..3c1d23b9ddc3 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -90,14 +90,14 @@ static const struct adreno_info gpulist[] = { }, }; -MODULE_FIRMWARE("a300_pm4.fw"); -MODULE_FIRMWARE("a300_pfp.fw"); -MODULE_FIRMWARE("a330_pm4.fw"); -MODULE_FIRMWARE("a330_pfp.fw"); -MODULE_FIRMWARE("a420_pm4.fw"); -MODULE_FIRMWARE("a420_pfp.fw"); -MODULE_FIRMWARE("a530_fm4.fw"); -MODULE_FIRMWARE("a530_pfp.fw"); +MODULE_FIRMWARE("qcom/a300_pm4.fw"); +MODULE_FIRMWARE("qcom/a300_pfp.fw"); +MODULE_FIRMWARE("qcom/a330_pm4.fw"); +MODULE_FIRMWARE("qcom/a330_pfp.fw"); +MODULE_FIRMWARE("qcom/a420_pm4.fw"); +MODULE_FIRMWARE("qcom/a420_pfp.fw"); +MODULE_FIRMWARE("qcom/a530_fm4.fw"); +MODULE_FIRMWARE("qcom/a530_pfp.fw"); static inline bool _rev_match(uint8_t entry, uint8_t id) { -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff
Hi Ville, On Monday, 20 November 2017 21:36:46 EET Ville Syrjälä wrote: > On Mon, Nov 20, 2017 at 09:32:56AM -0800, Sinclair Yeh wrote: > > On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote: > >> On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote: > >>> On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote: > >>> > Sorry this took so long. > >>> > >>> No worries. > >>> > The vmwgfx part: Reviewed-by: Sinclair Yeh > > I've done some testing and the vmwgfx part looks good. Has Daniel > already taken these or should I put them in my next request? > >>> > >>> You can take them, or I can push them to drm-misc-next. Whatever > >>> works best for you. > >>> > >>> And I'll want to revisit this topic soonish and move the clip > >>> handling into the helper as discussed with Daniel. But that can > >>> wait a bit until we get this round merged somewhere. > >> > >> Because we're still in the merge window I think it's probably best if we > >> push the entire series in through drm-misc. Tree-coordination in the > >> merge window is always a bit a pain. > > > > Ok, so I'll leave this series to you then. > > All right. Series pushed to drm-misc-next. Thanks for the reviews. And I now realize my review comments aren't very useful (apart possibly the one about adding a comment to the drm_plane_helper_check_update() function, feel free to submit a patch for that if you think it's useful) as the series has been merged already :-/ I should really start reading mails in the reverse chronological order. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/vmwgfx: Use drm_plane_helper_check_state()
Hi Ville, Thank you for the patch. On Wednesday, 1 November 2017 20:29:17 EET Ville Syrjala wrote: > From: Ville Syrjälä > > Atomic drivers have no reason to use drm_plane_helper_check_update() > instead of drm_plane_helper_check_state(). So let's switch over. > > Cc: VMware Graphics > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Signed-off-by: Ville Syrjälä Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +++-- > 1 file changed, 3 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index a4b56699679a..515b67783a41 > 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > @@ -442,29 +442,18 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane > *plane, struct drm_plane_state *state) > { > struct drm_framebuffer *new_fb = state->fb; > - bool visible; > - > - struct drm_rect src = { > - .x1 = state->src_x, > - .y1 = state->src_y, > - .x2 = state->src_x + state->src_w, > - .y2 = state->src_y + state->src_h, > - }; > - struct drm_rect dest = { > + struct drm_rect clip = { > .x1 = state->crtc_x, > .y1 = state->crtc_y, > .x2 = state->crtc_x + state->crtc_w, > .y2 = state->crtc_y + state->crtc_h, > }; > - struct drm_rect clip = dest; > int ret; > > - ret = drm_plane_helper_check_update(plane, state->crtc, new_fb, > - &src, &dest, &clip, > - DRM_MODE_ROTATE_0, > + ret = drm_plane_helper_check_state(state, &clip, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > - false, true, &visible); > + false, true); > > > if (!ret && new_fb) { -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/vmwgfx: Remove bogus crtc coords vs fb size check
Hi Ville, Thank you for the patch. On Wednesday, 1 November 2017 20:29:16 EET Ville Syrjala wrote: > From: Ville Syrjälä > > Throw away the bugs crtc coords vs. fb size check. Crtc coords don't > define the viewport inside the fb, that's a job for the src coords, > which have been checked by the core already. > > Cc: VMware Graphics > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Signed-off-by: Ville Syrjälä Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 0545740b3724..a4b56699679a > 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > @@ -476,12 +476,6 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane > *plane, > > vcs = vmw_connector_state_to_vcs(du->connector.state); > > - if ((dest.x2 > new_fb->width || > - dest.y2 > new_fb->height)) { > - DRM_ERROR("CRTC area outside of framebuffer\n"); > - return -EINVAL; > - } > - > /* Only one active implicit framebuffer at a time. */ > mutex_lock(&dev_priv->global_kms_state_mutex); > if (vcs->is_implicit && dev_priv->implicit_fb && -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c
Hi Ville, Thank you for the patch. On Wednesday, 1 November 2017 20:29:20 EET Ville Syrjala wrote: > From: Ville Syrjälä > > drm_plane_helper_check_update() isn't a transitional helper, so let's > rename it to drm_atomic_helper_check_plane_state() and move it into > drm_atomic_helper.c. > > Cc: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä I would move this patch before 4/5 to make it easier to revert 4/5 (for the reason explaining as a reply to that patch). Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/arm/hdlcd_crtc.c| 8 +-- > drivers/gpu/drm/arm/malidp_planes.c | 4 +- > drivers/gpu/drm/drm_atomic_helper.c | 95 + > drivers/gpu/drm/drm_plane_helper.c | 103 +--- > drivers/gpu/drm/drm_simple_kms_helper.c | 9 +-- > drivers/gpu/drm/i915/intel_display.c| 22 +++--- > drivers/gpu/drm/imx/ipuv3-plane.c | 8 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 8 +-- > drivers/gpu/drm/meson/meson_plane.c | 8 +-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 5 +- > drivers/gpu/drm/nouveau/nv50_display.c | 20 +++--- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +- > drivers/gpu/drm/tegra/dc.c | 4 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +-- > drivers/gpu/drm/zte/zx_plane.c | 15 ++-- > include/drm/drm_atomic_helper.h | 7 ++ > include/drm/drm_plane_helper.h | 6 -- > 17 files changed, 170 insertions(+), 166 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c index 14721723fa8a..63511a3bbf6c 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -252,10 +252,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane > *plane, clip.x2 = crtc_state->adjusted_mode.hdisplay; > clip.y2 = crtc_state->adjusted_mode.vdisplay; > > - return drm_plane_helper_check_state(state, crtc_state, &clip, > - DRM_PLANE_HELPER_NO_SCALING, > - DRM_PLANE_HELPER_NO_SCALING, > - false, true); > + return drm_atomic_helper_check_plane_state(state, crtc_state, &clip, > +DRM_PLANE_HELPER_NO_SCALING, > +DRM_PLANE_HELPER_NO_SCALING, > +false, true); > } > > static void hdlcd_plane_atomic_update(struct drm_plane *plane, > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c index 492d99dd55d4..72a07950167e > 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -150,8 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane > *mp, > > clip.x2 = crtc_state->adjusted_mode.hdisplay; > clip.y2 = crtc_state->adjusted_mode.vdisplay; > - ret = drm_plane_helper_check_state(state, crtc_state, &clip, > -0, INT_MAX, true, true); > + ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip, > + 0, INT_MAX, true, true); > if (ret) > return ret; > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c index 71d712f1b56a..7595ad8ad2f3 > 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -696,6 +696,101 @@ drm_atomic_helper_check_modeset(struct drm_device > *dev, EXPORT_SYMBOL(drm_atomic_helper_check_modeset); > > /** > + * drm_atomic_helper_check_plane_state() - Check plane state for validity > + * @plane_state: plane state to check > + * @crtc_state: crtc state to check > + * @clip: integer clipping coordinates > + * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point > + * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point > + * @can_position: is it legal to position the plane such that it > + *doesn't cover the entire crtc? This will generally > + *only be false for primary planes. > + * @can_update_disabled: can the plane be updated while the crtc > + * is disabled? > + * > + * Checks that a desired plane update is valid, and updates various > + * bits of derived state (clipped coordinates etc.). Drivers that provide > + * their own plane handling rather than helper-provided implementations may > + * still wish to call this function to avoid duplication of error checking > + * code. > + * > + * RETURNS: > + * Zero if update appears valid, error code on failure > + */ > +int drm_atomic_helper_check_plane_state(struct drm_plane_state > *plane_state, + const struct > drm_crtc_state *crtc_state,
Re: [PATCH 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()
Hi Ville, Thank you for the patch. On Wednesday, 1 November 2017 20:29:19 EET Ville Syrjala wrote: > From: Ville Syrjälä > > drm_plane_helper_check_state() is supposed to do things the atomic way, > so it should not be inspecting crtc->enabled. Rather we should be > looking at crtc_state->enable. > > We have a slight complication due to drm_plane_helper_check_update() > reusing drm_plane_helper_check_state() for non-atomic drivers. Thus > we'll have to pass the crtc_state in manally and construct a fake > crtc_state in drm_plane_helper_check_update(). The only user of drm_plane_helper_check_update() apart from vmwgfx which you converted in patch 2/5 is the armada driver. It would be nice to convert it to atomic modesetting and drop this function :-) At the very least, I'd add a comment to drm_plane_helper_check_update() that this change should be reverted when the function is dropped, otherwise we'll carry the CRTC state argument for a long time without realizing it's not needed anymore. Apart from that, Reviewed-by: Laurent Pinchart > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/arm/hdlcd_crtc.c| 2 +- > drivers/gpu/drm/arm/malidp_planes.c | 3 +- > drivers/gpu/drm/drm_plane_helper.c | 52 ++ > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/i915/intel_display.c| 2 ++ > drivers/gpu/drm/imx/ipuv3-plane.c | 2 +- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 2 +- > drivers/gpu/drm/meson/meson_plane.c | 2 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 +-- > drivers/gpu/drm/nouveau/nv50_display.c | 6 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +- > drivers/gpu/drm/tegra/dc.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- > drivers/gpu/drm/zte/zx_plane.c | 4 +-- > include/drm/drm_plane_helper.h | 3 +- > 15 files changed, 53 insertions(+), 39 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c index 72b22b805412..14721723fa8a 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -252,7 +252,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane > *plane, clip.x2 = crtc_state->adjusted_mode.hdisplay; > clip.y2 = crtc_state->adjusted_mode.vdisplay; > > - return drm_plane_helper_check_state(state, &clip, > + return drm_plane_helper_check_state(state, crtc_state, &clip, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > false, true); > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c index 94e7e3fa3408..492d99dd55d4 > 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -150,7 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane > *mp, > > clip.x2 = crtc_state->adjusted_mode.hdisplay; > clip.y2 = crtc_state->adjusted_mode.vdisplay; > - ret = drm_plane_helper_check_state(state, &clip, 0, INT_MAX, true, > true); > + ret = drm_plane_helper_check_state(state, crtc_state, &clip, > +0, INT_MAX, true, true); > if (ret) > return ret; > > diff --git a/drivers/gpu/drm/drm_plane_helper.c > b/drivers/gpu/drm/drm_plane_helper.c index 759ed93f4ba8..adb8d94484f2 > 100644 > --- a/drivers/gpu/drm/drm_plane_helper.c > +++ b/drivers/gpu/drm/drm_plane_helper.c > @@ -101,7 +101,8 @@ static int get_connectors_for_crtc(struct drm_crtc > *crtc, > > /** > * drm_plane_helper_check_state() - Check plane state for validity > - * @state: plane state to check > + * @plane_state: plane state to check > + * @crtc_state: crtc state to check > * @clip: integer clipping coordinates > * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point > * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point > @@ -120,35 +121,38 @@ static int get_connectors_for_crtc(struct drm_crtc > *crtc, * RETURNS: > * Zero if update appears valid, error code on failure > */ > -int drm_plane_helper_check_state(struct drm_plane_state *state, > +int drm_plane_helper_check_state(struct drm_plane_state *plane_state, > + const struct drm_crtc_state *crtc_state, >const struct drm_rect *clip, >int min_scale, >int max_scale, >bool can_position, >bool can_update_disabled) > { > - struct drm_crtc *crtc = state->crtc; > - struct drm_framebuffer *fb = state->fb; > - struct drm_rect *src = &state->src; > - struct drm_rect *dst = &state->dst; > - unsigned int rotation = state->rotation; > + str
Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping
Hi Ville, On Monday, 6 November 2017 20:04:38 EET Ville Syrjälä wrote: > On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote: > > On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote: > >> On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote: > >>> From: Ville Syrjälä > >>> > >>> Try to fix the code to actually clip the plane to the crtc bounds > >>> instead of the user provided crtc coordinates (which would be a no-op > >>> since those are exactly the coordinates before clipping). > >>> > >>> Cc: VMware Graphics > >>> Cc: Sinclair Yeh > >>> Cc: Thomas Hellstrom > >>> Signed-off-by: Ville Syrjälä > >> > >> I kinda wonder whether we shouldn't push this down into the helper ... I think that would be nice. > > Would require quite going through all drivers making sure they are > > happy with using the adjusted_mode.crtc_ timings. I think most drivers > > use the other adjusted_mode timings currently, and some even use the > > user mode timings (which could be an actual bug). > > Let me take that back. What we want is to clip to the user mode > timings. Stereo 3D needs the special treatment from > drm_mode_get_hv_timing(). I'm getting confused by all these > different timings we have all over the place. > > I think for i915 all we would need is to change the double wide/dual > link adjustent for pipe_src_w to simply reject odd widths instead. > That would guarantee that the user mode timings match the pipe_src_w/h > 100%. > > For the other driver we'd need to figure out why they're using > adjusted_mode timings for clipping. I guess that's just a mistake, > which I repeated here with vmwgfx after getting confused by looking > at the other drivers. I suppose it's a mix of cargo-cult and the fact that adjusted_mode hints that it contains the timings that should be applied to the hardware. That's why I use it in rcar-du. Are drivers allowed to adjust the hdisplay and vdisplay values though ? I thought unsupported values there had to be rejected with an error at atomic check time, not adjusted. > I guess I just volunteered myself to do this. Just needs plenty of > acks from driver maintainers I suppose. I'll review and test the rcar-du patch :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103863] Screen doesn't light up with "amdgpu.dc=1"
https://bugs.freedesktop.org/show_bug.cgi?id=103863 Michel Dänzer changed: What|Removed |Added Component|Driver/AMDgpu |DRM/AMDgpu QA Contact|xorg-t...@lists.x.org | Version|git |unspecified Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org CC||harry.wentl...@amd.com, ||jordan.laz...@amd.com Product|xorg|DRI -- 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
[PULL] drm-intel-next-fixes
Hi Dave, some early fixes for v4.15 and stable. BR, Jani. The following changes since commit e8c49fa96838101435b9e4884d49b30da7a4e0c6: drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU (2017-11-09 16:18:37 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2017-11-23 for you to fetch changes up to 3572f04c69ed4369da5d3c65d84fb18774aa60b6: drm/i915: Fix init_clock_gating for resume (2017-11-21 11:40:12 +0200) drm/i915 fixes for v4.15 Chris Wilson (2): drm/i915: Clear breadcrumb node when cancelling signaling drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM Colin Ian King (1): drm/i915/gvt: ensure -ve return value is handled correctly Hans de Goede (2): drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 drm/i915: Re-register PMIC bus access notifier on runtime resume Ville Syrjälä (1): drm/i915: Fix init_clock_gating for resume drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +- drivers/gpu/drm/i915/i915_drv.c | 3 +++ drivers/gpu/drm/i915/i915_gem_userptr.c | 6 -- drivers/gpu/drm/i915/intel_breadcrumbs.c | 1 + drivers/gpu/drm/i915/intel_uncore.c | 13 + drivers/gpu/drm/i915/intel_uncore.h | 1 + 6 files changed, 23 insertions(+), 3 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
On Tue, 2017-11-21 at 23:31 +0100, Vasyl Gomonovych wrote: > Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). > > drivers/gpu/drm/mediatek/mtk_drm_gem.c:223:9-16: WARNING: ERR_CAST can be > used with mtk_gem > Generated by: scripts/coccinelle/api/err_cast.cocci > > Signed-off-by: Vasyl Gomonovych > --- > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c > b/drivers/gpu/drm/mediatek/mtk_drm_gem.c > index f595ac816b55..5766b42fc174 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c > @@ -220,7 +220,7 @@ struct drm_gem_object > *mtk_gem_prime_import_sg_table(struct drm_device *dev, > mtk_gem = mtk_drm_gem_init(dev, attach->dmabuf->size); > > if (IS_ERR(mtk_gem)) > - return ERR_PTR(PTR_ERR(mtk_gem)); > + return ERR_CAST(mtk_gem)); > > expected = sg_dma_address(sg->sgl); > for_each_sg(sg->sgl, s, sg->nents, i) { Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/mediatek: Add mfd support for mt8173
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > Use the MFD device for SoC mt8173. Probing via devicetree > is no longer needed for any SoC, so delete it. > > Signed-off-by: Matthias Brugger Apart from the mmsys_private issue noted in previous patches, Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] mfd: mtk-mmsys: Add mt8173 nodes
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > Add devices for the mt8173 SoC. > > Signed-off-by: Matthias Brugger Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > With the mtk-mmsys MFD device in place, we switch the probing for > mt2701 from device-tree to mfd. > > Signed-off-by: Matthias Brugger > --- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 +--- > 1 file changed, 25 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index dd249cf5121e..5a263aa3ab6e 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -392,9 +393,10 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = > { > > static int mtk_drm_probe(struct platform_device *pdev) > { > + struct mmsys_dev *mmsys_private; > struct device *dev = &pdev->dev; > struct mtk_drm_private *private; > - struct device_node *node; > + struct device_node *node, *parent_node; > struct component_match *match = NULL; > int ret; > int i; > @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device *pdev) > INIT_WORK(&private->commit.work, mtk_atomic_work); > private->data = of_device_get_match_data(dev); > > - private->config_regs = syscon_node_to_regmap(dev->of_node); > - if (IS_ERR(private->config_regs)) > - return PTR_ERR(private->config_regs); > + /* Check if called from mfd */ > + if (!dev->of_node) { > + mmsys_private = dev_get_drvdata(pdev->dev.parent); > + private->data = (struct mtk_mmsys_driver_data *) > + platform_get_device_id(pdev)->driver_data; > + private->config_regs = > + syscon_node_to_regmap(mmsys_private->of_node); > + parent_node = mmsys_private->of_node->parent; I think this could be just: mmsys_node = pdev->dev.parent->of_node; private->data = (struct mtk_mmsys_driver_data *)> + platform_get_device_id(pdev)->driver_data; private->config_regs = syscon_node_to_regmap(mmsys_node); parent_node = mmsys_node->parent; regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] mfd: mtk-mmsys: Add mmsys driver
Hi Matthias, On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > The MMSYS subsystem includes clocks and drm components. > This patch adds a MFD device to probe both drivers from the same > device tree compatible. > > Signed-off-by: Matthias Brugger > --- > drivers/mfd/Kconfig | 9 + > drivers/mfd/Makefile | 2 ++ > drivers/mfd/mtk-mmsys.c | 91 > +++ > include/linux/mfd/mmsys.h | 18 ++ > 4 files changed, 120 insertions(+) > create mode 100644 drivers/mfd/mtk-mmsys.c > create mode 100644 include/linux/mfd/mmsys.h > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index fc5e4fef89d2..3250ce5d205a 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -368,6 +368,15 @@ config MFD_MC13XXX_I2C > help > Select this if your MC13xxx is connected via an I2C bus. > > +config MFD_MEDIATEK_MMSYS > + tristate "Mediatek MMSYS interface" > + select MDF_CORE > + select REGMAP_MMIO > + help > + Select this if you have a MMSYS subsystem in your SoC. The > + MMSYS subsystem has at least a clock driver part and some > + DRM components. > + > config MFD_MXS_LRADC > tristate "Freescale i.MX23/i.MX28 LRADC" > depends on ARCH_MXS || COMPILE_TEST > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 8703ff17998e..d4fc99df784c 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -100,6 +100,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o > obj-$(CONFIG_MFD_MC13XXX_SPI)+= mc13xxx-spi.o > obj-$(CONFIG_MFD_MC13XXX_I2C)+= mc13xxx-i2c.o > > +obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o > + > obj-$(CONFIG_MFD_CORE) += mfd-core.o > > obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o > diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c > new file mode 100644 > index ..102b491aa28f > --- /dev/null > +++ b/drivers/mfd/mtk-mmsys.c > @@ -0,0 +1,91 @@ > +/* > + * mtk-mmsys.c -- Mediatek MMSYS multi-function driver > + * > + * Copyright (c) 2017 Matthias Brugger > + * > + * Author: Matthias Brugger > + * > + * For licencing details see kernel-base/COPYING > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +enum { > + MMSYS_MT2701 = 1, > +}; > + > +static const struct mfd_cell mmsys_mt2701_devs[] = { > + { .name = "clk-mt2701-mm", }, > + { .name = "drm-mt2701-mm", }, > +}; > + > +static int mmsys_probe(struct platform_device *pdev) > +{ > + struct mmsys_dev *private; > + const struct mfd_cell *mmsys_cells; > + int nr_cells; > + long id; > + int ret; > + > + id = (long) of_device_get_match_data(&pdev->dev); > + if (!id) { > + dev_err(&pdev->dev, "of_device_get match_data() failed\n"); > + return -EINVAL; > + } > + > + switch (id) { > + case MMSYS_MT2701: > + mmsys_cells = mmsys_mt2701_devs; > + nr_cells = ARRAY_SIZE(mmsys_mt2701_devs); > + break; > + default: > + return -ENODEV; > + } > + > + private = devm_kzalloc(&pdev->dev, sizeof(*private), GFP_KERNEL); > + if (!private) > + return -ENOMEM; > + > + private->dev = &pdev->dev; > + dev_set_drvdata(private->dev, private); > + > + private->of_node = pdev->dev.of_node; This seems superfluous to me. The of_node can be obtained from the device, and the device itself is already needed to get to the drvdata. Instead of mmsys_private = drv_get_drvdata(pdev->dev.parent); mmsys_dev = mmsys_private.dev; mmsys_of_node = mmsys_private.of_node; couldn't the mfd children just do mmsys_dev = pdev->dev.parent; mmsys_of_node = pdev->dev.parent->of_node; ? > + > + ret = devm_mfd_add_devices(private->dev, 0, mmsys_cells, nr_cells, > + NULL, 0, NULL); > + if (ret) { > + dev_err(&pdev->dev, "failed to add MFD devices %d\n", ret); > + return ret; > + } > + > + return 0; > +}; > + > +static const struct of_device_id of_match_mmsys[] = { > + { .compatible = "mediatek,mt2701-mmsys", > + .data = (void *) MMSYS_MT2701, > + }, > + { /* sentinel */ }, > +}; > + > +static struct platform_driver mmsys_drv = { > + .probe = mmsys_probe, > + .driver = { > + .name = "mediatek-mmysys", > + .of_match_table = of_match_ptr(of_match_mmsys), > + }, > +}; > + > +builtin_platform_driver(mmsys_drv); > + > +MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver"); > +MODULE_LICENSE("GPL"); > diff --git a/include/linux/mfd/mmsys.h b/include/linux/mfd/mmsys.h > new file mode 100644 > index ..274b9ee03ada > --- /dev/null > +++ b/include/linux/mfd/mmsys.h > @@ -0,0 +1,18 @@ > +/* Header of MMSYS MFD core driver for Mediatek platforms > +
Re: [PATCH 2/8] mfd: mtk-mmsys: Add mmsys driver
Hi, Matthias: On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > The MMSYS subsystem includes clocks and drm components. > This patch adds a MFD device to probe both drivers from the same > device tree compatible. > > Signed-off-by: Matthias Brugger > --- > drivers/mfd/Kconfig | 9 + > drivers/mfd/Makefile | 2 ++ > drivers/mfd/mtk-mmsys.c | 91 > +++ > include/linux/mfd/mmsys.h | 18 ++ > 4 files changed, 120 insertions(+) > create mode 100644 drivers/mfd/mtk-mmsys.c > create mode 100644 include/linux/mfd/mmsys.h > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index fc5e4fef89d2..3250ce5d205a 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -368,6 +368,15 @@ config MFD_MC13XXX_I2C > help > Select this if your MC13xxx is connected via an I2C bus. > > +config MFD_MEDIATEK_MMSYS > + tristate "Mediatek MMSYS interface" > + select MDF_CORE > + select REGMAP_MMIO > + help > + Select this if you have a MMSYS subsystem in your SoC. The > + MMSYS subsystem has at least a clock driver part and some > + DRM components. > + > config MFD_MXS_LRADC > tristate "Freescale i.MX23/i.MX28 LRADC" > depends on ARCH_MXS || COMPILE_TEST > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 8703ff17998e..d4fc99df784c 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -100,6 +100,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o > obj-$(CONFIG_MFD_MC13XXX_SPI)+= mc13xxx-spi.o > obj-$(CONFIG_MFD_MC13XXX_I2C)+= mc13xxx-i2c.o > > +obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o > + > obj-$(CONFIG_MFD_CORE) += mfd-core.o > > obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o > diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c > new file mode 100644 > index ..102b491aa28f > --- /dev/null > +++ b/drivers/mfd/mtk-mmsys.c > @@ -0,0 +1,91 @@ > +/* > + * mtk-mmsys.c -- Mediatek MMSYS multi-function driver > + * > + * Copyright (c) 2017 Matthias Brugger > + * > + * Author: Matthias Brugger > + * > + * For licencing details see kernel-base/COPYING > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +enum { > + MMSYS_MT2701 = 1, > +}; > + > +static const struct mfd_cell mmsys_mt2701_devs[] = { > + { .name = "clk-mt2701-mm", }, > + { .name = "drm-mt2701-mm", }, > +}; > + > +static int mmsys_probe(struct platform_device *pdev) > +{ > + struct mmsys_dev *private; > + const struct mfd_cell *mmsys_cells; > + int nr_cells; > + long id; > + int ret; > + > + id = (long) of_device_get_match_data(&pdev->dev); > + if (!id) { > + dev_err(&pdev->dev, "of_device_get match_data() failed\n"); > + return -EINVAL; > + } > + > + switch (id) { > + case MMSYS_MT2701: > + mmsys_cells = mmsys_mt2701_devs; > + nr_cells = ARRAY_SIZE(mmsys_mt2701_devs); > + break; > + default: > + return -ENODEV; > + } > + > + private = devm_kzalloc(&pdev->dev, sizeof(*private), GFP_KERNEL); > + if (!private) > + return -ENOMEM; > + > + private->dev = &pdev->dev; > + dev_set_drvdata(private->dev, private); > + > + private->of_node = pdev->dev.of_node; > + > + ret = devm_mfd_add_devices(private->dev, 0, mmsys_cells, nr_cells, > + NULL, 0, NULL); > + if (ret) { > + dev_err(&pdev->dev, "failed to add MFD devices %d\n", ret); > + return ret; > + } > + > + return 0; > +}; > + > +static const struct of_device_id of_match_mmsys[] = { > + { .compatible = "mediatek,mt2701-mmsys", Because this driver replace the original "mediatek,mt2701-mmsys" driver, could you modify the binding document of "mediatek,mt2701-mmsys" [1]? [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt Regards, CK > + .data = (void *) MMSYS_MT2701, > + }, > + { /* sentinel */ }, > +}; > + > +static struct platform_driver mmsys_drv = { > + .probe = mmsys_probe, > + .driver = { > + .name = "mediatek-mmysys", > + .of_match_table = of_match_ptr(of_match_mmsys), > + }, > +}; > + > +builtin_platform_driver(mmsys_drv); > + > +MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver"); > +MODULE_LICENSE("GPL"); > diff --git a/include/linux/mfd/mmsys.h b/include/linux/mfd/mmsys.h > new file mode 100644 > index ..274b9ee03ada > --- /dev/null > +++ b/include/linux/mfd/mmsys.h > @@ -0,0 +1,18 @@ > +/* Header of MMSYS MFD core driver for Mediatek platforms > + * > + * Copyright (c) 2017 Matthias Brugger > + * > + * This program is free software; you can redistribute it and/or modify it > under > + * the terms of the GNU Gen
[PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format
The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in windows. The float format in each component is 1:5:10 MSb-sign:exponent: fraction. This patch is to introduce the format to drm, so that the windows guest's framebuffer in this kind of format can be recognized and used by linux host. v14: - add some details about the float pixel format. (Daniel) - add F suffix to the defined name. (Daniel) v12: - send to dri-devel at lists.freedesktop.org. (Ville) v9: - separated from framebuffer decoder patch. (Zhenyu) (Xiaoguang) Signed-off-by: Tina Zhang Cc: Ville Syrjälä Cc: Dave Airlie Cc: Daniel Vetter --- include/uapi/drm/drm_fourcc.h | 4 1 file changed, 4 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 3ad838d..391d2e6 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -113,6 +113,10 @@ extern "C" { #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */ +/* 64 bpp RGB 16:16:16:16 Floating Point */ +#define DRM_FORMAT_XRGB161616F fourcc_code('X', 'R', '3', 'F') /* [63:0] x:R:G:B 16:16:16:16 little endian */ +#define DRM_FORMAT_XBGR161616F fourcc_code('X', 'B', '3', 'F') /* [63:0] x:B:G:R 16:16:16:16 little endian */ + /* * 2 plane RGB + A * index 0 = RGB plane, same format as the corresponding non _A8 format has -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103850] "Quern" game crashes on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=103850 --- Comment #2 from Michel Dänzer --- Looks like there might be memory corruption, can you run one of these games in valgrind and attach the output from valgrind? -- 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
[PATCH] drm: Introduce RGB 64-bit 16:16:16:16 float format
This patch is from "[PATCH v19 0/6] drm/i915/gvt: Dma-buf support for GVT-g": https://lists.freedesktop.org/archives/intel-gvt-dev/2017-November/002508.html The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in windows. The float format in each component is 1:5:10 MSb-sign:exponent: fraction. This patch is to introduce the format to drm, so that the windows guest's framebuffer in this kind of format can be recognized and used by linux host. Tina Zhang (1): drm: Introduce RGB 64-bit 16:16:16:16 float format include/uapi/drm/drm_fourcc.h | 4 1 file changed, 4 insertions(+) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'
https://bugs.freedesktop.org/show_bug.cgi?id=100745 --- Comment #9 from Michel Dänzer --- (In reply to Benjamin Bellec from comment #8) > I hit the same problem today after enabling amdgpu.dc=1 > The screen doesn't light up at all if I boot the kernel with amdgpu.dc=1 AFAICT this report is about the non-DC code, please file your own report about the issue with DC. -- 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 1/8] drm/mediatek: Use regmap for register access
Hi Matthias, On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > The mmsys memory space is shared between the drm and the > clk driver. Use regmap to access it. > > Signed-off-by: Matthias Brugger > --- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++-- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 30 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 ++-- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 - > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- > 5 files changed, 26 insertions(+), 27 deletions(-) [...] > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > index 8130f3dab661..1227d6db07da 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > @@ -185,16 +185,16 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id > cur, > return value; > } > > -static void mtk_ddp_sout_sel(void __iomem *config_regs, > +static void mtk_ddp_sout_sel(struct regmap *config_regs, >enum mtk_ddp_comp_id cur, >enum mtk_ddp_comp_id next) > { > if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) > - writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1, > -config_regs + DISP_REG_CONFIG_OUT_SEL); > + regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL, > + BLS_TO_DSI_RDMA1_TO_DPI1); > } > > -void mtk_ddp_add_comp_to_path(void __iomem *config_regs, > +void mtk_ddp_add_comp_to_path(struct regmap *config_regs, > enum mtk_ddp_comp_id cur, > enum mtk_ddp_comp_id next) > { > @@ -202,20 +202,22 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs, > > value = mtk_ddp_mout_en(cur, next, &addr); > if (value) { > - reg = readl_relaxed(config_regs + addr) | value; > - writel_relaxed(reg, config_regs + addr); > + regmap_read(config_regs, addr, ®); > + reg |= value; > + regmap_write(config_regs, addr, reg); You can use regmap_update_bits(config_regs, addr, value, value); here and drop the local variable reg. > } > > mtk_ddp_sout_sel(config_regs, cur, next); > > value = mtk_ddp_sel_in(cur, next, &addr); > if (value) { > - reg = readl_relaxed(config_regs + addr) | value; > - writel_relaxed(reg, config_regs + addr); > + regmap_read(config_regs, addr, ®); > + reg |= value; > + regmap_write(config_regs, addr, reg); regmap_update_bits(config_regs, addr, value, value); > } > } > > -void mtk_ddp_remove_comp_from_path(void __iomem *config_regs, > +void mtk_ddp_remove_comp_from_path(struct regmap *config_regs, > enum mtk_ddp_comp_id cur, > enum mtk_ddp_comp_id next) > { > @@ -223,14 +225,16 @@ void mtk_ddp_remove_comp_from_path(void __iomem > *config_regs, > > value = mtk_ddp_mout_en(cur, next, &addr); > if (value) { > - reg = readl_relaxed(config_regs + addr) & ~value; > - writel_relaxed(reg, config_regs + addr); > + regmap_read(config_regs, addr, ®); > + reg &= ~value; > + regmap_write(config_regs, addr, reg); regmap_update_bits(config_regs, addr, value, 0); > } > > value = mtk_ddp_sel_in(cur, next, &addr); > if (value) { > - reg = readl_relaxed(config_regs + addr) & ~value; > - writel_relaxed(reg, config_regs + addr); > + regmap_read(config_regs, addr, ®); > + reg &= ~value; > + regmap_write(config_regs, addr, reg); regmap_update_bits(config_regs, addr, value, 0); Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'
https://bugs.freedesktop.org/show_bug.cgi?id=100745 Michel Dänzer changed: What|Removed |Added Attachment #130957|text/x-log |text/plain mime type|| -- 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 6/8] drm/mediatek: Add mfd support for mt8173
Hi, Matthias: On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > Use the MFD device for SoC mt8173. Probing via devicetree > is no longer needed for any SoC, so delete it. > > Signed-off-by: Matthias Brugger Acked-by: CK Hu > --- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +++- > 1 file changed, 7 insertions(+), 21 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index 5a263aa3ab6e..1eb02acf229a 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -409,20 +409,12 @@ static int mtk_drm_probe(struct platform_device *pdev) > INIT_WORK(&private->commit.work, mtk_atomic_work); > private->data = of_device_get_match_data(dev); > > - /* Check if called from mfd */ > - if (!dev->of_node) { > - mmsys_private = dev_get_drvdata(pdev->dev.parent); > - private->data = (struct mtk_mmsys_driver_data *) > - platform_get_device_id(pdev)->driver_data; > - private->config_regs = > - syscon_node_to_regmap(mmsys_private->of_node); > - parent_node = mmsys_private->of_node->parent; > - } else { > - private->config_regs = syscon_node_to_regmap(dev->of_node); > - if (IS_ERR(private->config_regs)) > - return PTR_ERR(private->config_regs); > - parent_node = dev->of_node->parent; > - } > + mmsys_private = dev_get_drvdata(pdev->dev.parent); > + private->data = (struct mtk_mmsys_driver_data *) > + platform_get_device_id(pdev)->driver_data; > + private->config_regs = > + syscon_node_to_regmap(mmsys_private->of_node); > + parent_node = mmsys_private->of_node->parent; > > /* Iterate over sibling DISP function blocks */ > for_each_child_of_node(parent_node, node) { > @@ -565,14 +557,9 @@ static int mtk_drm_sys_resume(struct device *dev) > static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend, >mtk_drm_sys_resume); > > -static const struct of_device_id mtk_drm_of_ids[] = { > - { .compatible = "mediatek,mt8173-mmsys", > - .data = &mt8173_mmsys_driver_data}, > - { } > -}; > - > static const struct platform_device_id mtk_drm_ids[] = { > { "drm-mt2701-mm", (kernel_ulong_t)&mt2701_mmsys_driver_data }, > + { "drm-mt8173-mm", (kernel_ulong_t)&mt8173_mmsys_driver_data }, > { /* sentinel */ }, > }; > MODULE_DEVICE_TABLE(platform, mtk_drm_ids); > @@ -582,7 +569,6 @@ static struct platform_driver mtk_drm_platform_driver = { > .remove = mtk_drm_remove, > .driver = { > .name = "mediatek-drm", > - .of_match_table = mtk_drm_of_ids, > .pm = &mtk_drm_pm_ops, > }, > .id_table = mtk_drm_ids, ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.
Hi, Matthias: On Thu, 2017-11-23 at 09:30 +0100, Matthias Brugger wrote: > > On 11/23/2017 06:48 AM, CK Hu wrote: > > Hi, Matthias: > > > > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote: > >> With the mtk-mmsys MFD device in place, we switch the probing for > >> mt2701 from device-tree to mfd. > >> > >> Signed-off-by: Matthias Brugger > >> --- > >> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 > >> +--- > >> 1 file changed, 25 insertions(+), 7 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > >> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > >> index dd249cf5121e..5a263aa3ab6e 100644 > >> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > >> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > >> @@ -21,6 +21,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -392,9 +393,10 @@ static const struct of_device_id > >> mtk_ddp_comp_dt_ids[] = { > >> > >> static int mtk_drm_probe(struct platform_device *pdev) > >> { > >> + struct mmsys_dev *mmsys_private; > >>struct device *dev = &pdev->dev; > >>struct mtk_drm_private *private; > >> - struct device_node *node; > >> + struct device_node *node, *parent_node; > >>struct component_match *match = NULL; > >>int ret; > >>int i; > >> @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device > >> *pdev) > >>INIT_WORK(&private->commit.work, mtk_atomic_work); > >>private->data = of_device_get_match_data(dev); > >> > >> - private->config_regs = syscon_node_to_regmap(dev->of_node); > >> - if (IS_ERR(private->config_regs)) > >> - return PTR_ERR(private->config_regs); > >> + /* Check if called from mfd */ > >> + if (!dev->of_node) { > >> + mmsys_private = dev_get_drvdata(pdev->dev.parent); > > > > Why do you directly access parent's driver data? You just need the > > device node of mmsys, maybe you could refer to [1]. > > > > [1] > > https://elixir.free-electrons.com/linux/latest/source/drivers/reset/reset-berlin.c#L78 > > > > The difference is, that the driver you mentioned gets probed via device tree > matching, while we get invoked here through the id_table. So there is no > device > node (the if actually checkes for pdev->dev.of_node to identify exactly this > case). > > Regards, > Matthias Yes, you are right. So Acked-by: CK Hu Regards, CK > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 09/29] drm/i915: deprecate pci_get_bus_and_slot()
On 11/22/2017 5:49 PM, Sinan Kaya wrote: > static int i915_get_bridge_dev(struct drm_i915_private *dev_priv) > { > - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)); > + u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus); I'll convert domain type to int on the next version across the series. I tried to convert most of the drivers to use pci_domain_nr() per feedback from Greg KH. I'll hold onto posting a new version until I gather feedback with the approach I have taken. I just did a build test with the series. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Fix ifnullfree.cocci warnings
NULL check before some freeing functions is not needed. drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing debugfs_remove_recursive Generated by: scripts/coccinelle/free/ifnullfree.cocci Signed-off-by: Vasyl Gomonovych --- drivers/dma-buf/dma-buf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 4a038dcf5361..048827b06c03 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1179,8 +1179,7 @@ static int dma_buf_init_debugfs(void) static void dma_buf_uninit_debugfs(void) { - if (dma_buf_debugfs_dir) - debugfs_remove_recursive(dma_buf_debugfs_dir); + debugfs_remove_recursive(dma_buf_debugfs_dir); } #else static inline int dma_buf_init_debugfs(void) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.
Hi Boris, > Boris Brezillon hat am 22. November 2017 > um 18:51 geschrieben: > > > Hi Stefan, > > On Wed, 22 Nov 2017 17:43:35 +0100 (CET) > Stefan Wahren wrote: > ... > > Looks like I didn't test this code with CONFIG_REFCOUNT_FULL enabled :-/. > > Anyway, can you try to apply the following diff and let me know if it > fixes the problem? yes, this fixes the problem. > > Thanks, > > Boris > > --->8--- > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c > index 4ae45d7dac42..2decc8e2c79f 100644 > --- a/drivers/gpu/drm/vc4/vc4_bo.c > +++ b/drivers/gpu/drm/vc4/vc4_bo.c > @@ -637,7 +637,8 @@ int vc4_bo_inc_usecnt(struct vc4_bo *bo) > mutex_lock(&bo->madv_lock); > switch (bo->madv) { > case VC4_MADV_WILLNEED: > - refcount_inc(&bo->usecnt); > + if (!refcount_inc_not_zero(&bo->usecnt)) > + refcount_set(&bo->usecnt, 1); > ret = 0; > break; > case VC4_MADV_DONTNEED: > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
On 11/22/2017 05:09 AM, Christian König wrote: > Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >> On 11/21/2017 08:34 AM, Christian König wrote: >>> Hi Boris, >>> >>> attached are two patches. >>> >>> The first one is a trivial fix for the infinite loop issue, it now >>> correctly aborts the fixup when it can't find address space for the >>> root window. >>> >>> The second is a workaround for your board. It simply checks if there >>> is exactly one Processor Function to apply this fix on. >>> >>> Both are based on linus current master branch. Please test if they fix >>> your issue. >> >> Yes, they do fix it but that's because the feature is disabled. >> >> Do you know what the actual problem was (on Xen)? > > I still haven't understood what you actually did with Xen. > > When you used PCI pass through with those devices then you have made a > major configuration error. > > When the problem happened on dom0 then the explanation is most likely > that some PCI device ended up in the configured space, but the routing > was only setup correctly on one CPU socket. The problem is that dom0 can be (and was in my case() booted with less than full physical memory and so the "rest" of the host memory is not necessarily reflected in iomem. Your patch then tried to configure that memory for MMIO and the system hang. And so my guess is that this patch will break dom0 on a single-socket system as well. -boris > > Regards, > Christian. > >> >> Thanks. >> -boris >> >>> Thanks for the help, >>> Christian. >>> >>> Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky: On 11/20/2017 11:07 AM, Christian König wrote: > Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >> (and then it breaks differently as a Xen guest --- we hung on the >> last >> pci_read_config_dword(), I haven't looked at this at all yet) > Hui? How does this fix applies to a Xen guest in the first place? > > Please provide the output of "lspci -nn" and explain further what is > your config with Xen. > > This is dom0. -bash-4.1# lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge only dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02) 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device [1002:5a23] 00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx1 port B) [1002:5a1e] 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] [1002:4391] 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] 00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398] 00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397] 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398] 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396] 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 3d) 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d] 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] 00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller [1002:4399] 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1600] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1601] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1602] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1603] 00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1604] 00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1605] 00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1600] 00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1601] 00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1602] 00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1603] 00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1604] 00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1605] 01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA G200eW WPCM450 [102b:0532] (rev 0a) 02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01) 02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01) -bash-4.1#
[BUG] drm: vc4: refcount_t: increment on 0; use-after-free.
Hi Boris, if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with sufficient CMA memory (32 MB), i'll get this warning during boot: [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4]) [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4]) [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [7.750841] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [7.757620] [drm] Driver supports precise vblank timestamp query. [7.811775] [ cut here ] [7.811780] refcount_t: increment on 0; use-after-free. [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 refcount_inc+0x44/0x50 [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma crc32_ce i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6 [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 4.14.0-next-20171122 #1 [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [7.811958] task: 800036b91c00 task.stack: 0d6f [7.811967] pstate: 2005 (nzCv daif -PAN -UAO) [7.811974] pc : refcount_inc+0x44/0x50 [7.811981] lr : refcount_inc+0x44/0x50 [7.811984] sp : 0d6f3300 [7.811988] x29: 0d6f3300 x28: [7.811996] x27: 0003 x26: 800037107800 [7.812004] x25: 0001 x24: 800035afdc00 [7.812012] x23: x22: 800035dfa600 [7.812020] x21: 800035afd9b0 x20: 800035afd9a4 [7.812027] x19: x18: [7.812034] x17: 0001 x16: 0019 [7.812042] x15: 0001 x14: fff0 [7.812049] x13: 090ae840 x12: 08fa2d50 [7.812057] x11: 08fa2000 x10: 090ad000 [7.812064] x9 : x8 : 090b5c2f [7.812072] x7 : x6 : 0015ee00 [7.812079] x5 : x4 : [7.812087] x3 : x2 : 800030047000 [7.812094] x1 : 800036b91c00 x0 : 002b [7.812102] Call trace: [7.812109] refcount_inc+0x44/0x50 [7.812226] vc4_bo_inc_usecnt+0x84/0x88 [vc4] [7.812310] vc4_prepare_fb+0x40/0xf0 [vc4] [7.812460] drm_atomic_helper_prepare_planes+0x54/0xf0 [drm_kms_helper] [7.812543] vc4_atomic_commit+0x88/0x130 [vc4] [7.812868] drm_atomic_commit+0x48/0x68 [drm] [7.813002] restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper] [7.813113] restore_fbdev_mode+0x28/0x160 [drm_kms_helper] [7.813223] drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 [drm_kms_helper] [7.813331] drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper] [7.813346] fbcon_init+0x4e8/0x538 [7.813357] visual_init+0xb4/0x108 [7.813366] do_bind_con_driver+0x1b8/0x3a0 [7.813373] do_take_over_console+0x150/0x1d0 [7.813380] do_fbcon_takeover+0x6c/0xf0 [7.813387] fbcon_event_notify+0x8fc/0x928 [7.813399] notifier_call_chain+0x50/0x90 [7.813406] __blocking_notifier_call_chain+0x4c/0x90 [7.813413] blocking_notifier_call_chain+0x14/0x20 [7.813420] fb_notifier_call_chain+0x1c/0x28 [7.813426] register_framebuffer+0x1d0/0x2d8 [7.813533] __drm_fb_helper_initial_config_and_unlock+0x1e8/0x350 [drm_kms_helper] [7.813639] drm_fb_helper_initial_config+0x40/0x58 [drm_kms_helper] [7.813747] drm_fbdev_cma_init_with_funcs+0x88/0x158 [drm_kms_helper] [7.813855] drm_fbdev_cma_init+0x14/0x28 [drm_kms_helper] [7.813943] vc4_kms_load+0xa4/0xf0 [vc4] [7.814026] vc4_drm_bind+0x100/0x168 [vc4] [7.814038] try_to_bring_up_master+0x144/0x1a8 [7.814044] component_master_add_with_match+0x9c/0xe0 [7.814128] vc4_platform_drm_probe+0xb4/0xf0 [vc4] [7.814137] platform_drv_probe+0x58/0xc0 [7.814146] driver_probe_device+0x224/0x308 [7.814153] __driver_attach+0xac/0xb0 [7.814161] bus_for_each_dev+0x64/0xa0 [7.814169] driver_attach+0x20/0x28 [7.814177] bus_add_driver+0x108/0x228 [7.814184] driver_register+0x60/0xf8 [7.814190] __platform_driver_register+0x40/0x48 [7.814274] vc4_drm_register+0x38/0x1000 [vc4] [7.814283] do_one_initcall+0x38/0x120 [7.814295] do_init_module+0x58/0x1b8 [7.814304] load_module+0x1fa8/0x2280 [7.814311] SyS_finit_module+0xc0/0xd0 [7.814318] __sys_trace_return+0x0/0x4 [7.814325] ---[ end trace 3348554eb91e19a1 ]--- __
[PATCH V2 09/29] drm/i915: deprecate pci_get_bus_and_slot()
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Extract the domain number from drm_device and pass it into pci_get_domain_bus_and_slot() function. Signed-off-by: Sinan Kaya --- drivers/gpu/drm/i915/i915_drv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 9f45cfe..fea2b5e 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void *data, static int i915_get_bridge_dev(struct drm_i915_private *dev_priv) { - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)); + u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus); + + dev_priv->bridge_dev = + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0)); if (!dev_priv->bridge_dev) { DRM_ERROR("bridge device not found\n"); return -1; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 10/29] drm/nouveau: deprecate pci_get_bus_and_slot()
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot() and extract the domain number from 1. struct pci_dev 2. struct pci_dev through drm_device->pdev 3. struct pci_dev through fb->subdev->drm_device->pdev Signed-off-by: Sinan Kaya --- drivers/gpu/drm/nouveau/dispnv04/arb.c | 4 +++- drivers/gpu/drm/nouveau/dispnv04/hw.c| 10 +++--- drivers/gpu/drm/nouveau/nouveau_drm.c| 3 ++- drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c | 10 +- 4 files changed, 21 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c b/drivers/gpu/drm/nouveau/dispnv04/arb.c index 90075b6..e7455f7 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/arb.c +++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c @@ -213,8 +213,10 @@ struct nv_sim_state { if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ || (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) { uint32_t type; + u32 domain = pci_domain_nr(dev->pdev->bus); - pci_read_config_dword(pci_get_bus_and_slot(0, 1), 0x7c, &type); + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1), + 0x7c, &type); sim_data.memory_type = (type >> 12) & 1; sim_data.memory_width = 64; diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c b/drivers/gpu/drm/nouveau/dispnv04/hw.c index b985990..8806b1b 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/hw.c +++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c @@ -216,12 +216,15 @@ { struct nvkm_pll_vals pllvals; int ret; + u32 domain; + + domain = pci_domain_nr(dev->pdev->bus); if (plltype == PLL_MEMORY && (dev->pdev->device & 0x0ff0) == CHIPSET_NFORCE) { uint32_t mpllP; - - pci_read_config_dword(pci_get_bus_and_slot(0, 3), 0x6c, &mpllP); + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 3), + 0x6c, &mpllP); mpllP = (mpllP >> 8) & 0xf; if (!mpllP) mpllP = 4; @@ -232,7 +235,8 @@ (dev->pdev->device & 0xff0) == CHIPSET_NFORCE2) { uint32_t clock; - pci_read_config_dword(pci_get_bus_and_slot(0, 5), 0x4c, &clock); + pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 5), + 0x4c, &clock); return clock / 1000; } diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 595630d..0b6c639 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -406,7 +406,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev, } /* subfunction one is a hdmi audio device? */ - drm->hdmi_device = pci_get_bus_and_slot((unsigned int)pdev->bus->number, + drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus), + (unsigned int)pdev->bus->number, PCI_DEVFN(PCI_SLOT(pdev->devfn), 1)); if (!drm->hdmi_device) { diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c index 3c6a871..273a632 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv1a.c @@ -28,8 +28,16 @@ { struct pci_dev *bridge; u32 mem, mib; + u32 domain = 0; + struct pci_dev *pdev = NULL; - bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 1)); + if (dev_is_pci(fb->subdev.device->dev)) + pdev = to_pci_dev(fb->subdev.device->dev); + + if (pdev) + domain = pci_domain_nr(pdev->bus); + + bridge = pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 1)); if (!bridge) { nvkm_error(&fb->subdev, "no bridge device\n"); return -ENODEV; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
On 11/22/2017 11:54 AM, Christian König wrote: > Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >> On 11/22/2017 05:09 AM, Christian König wrote: >>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: On 11/21/2017 08:34 AM, Christian König wrote: > Hi Boris, > > attached are two patches. > > The first one is a trivial fix for the infinite loop issue, it now > correctly aborts the fixup when it can't find address space for the > root window. > > The second is a workaround for your board. It simply checks if there > is exactly one Processor Function to apply this fix on. > > Both are based on linus current master branch. Please test if they > fix > your issue. Yes, they do fix it but that's because the feature is disabled. Do you know what the actual problem was (on Xen)? >>> I still haven't understood what you actually did with Xen. >>> >>> When you used PCI pass through with those devices then you have made a >>> major configuration error. >>> >>> When the problem happened on dom0 then the explanation is most likely >>> that some PCI device ended up in the configured space, but the routing >>> was only setup correctly on one CPU socket. >> The problem is that dom0 can be (and was in my case() booted with less >> than full physical memory and so the "rest" of the host memory is not >> necessarily reflected in iomem. Your patch then tried to configure that >> memory for MMIO and the system hang. >> >> And so my guess is that this patch will break dom0 on a single-socket >> system as well. > > Oh, thanks! > > I've thought about that possibility before, but wasn't able to find a > system which actually does that. > > May I ask why the rest of the memory isn't reported to the OS? That memory doesn't belong to the OS (dom0), it is owned by the hypervisor. > > Sounds like I can't trust Linux resource management and probably need > to read the DRAM config to figure things out after all. My question is whether what you are trying to do should ever be done for a guest at all (any guest, not necessarily Xen). -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Avoid enum conversion warning
Fixes the following enum conversion warning: drivers/gpu/drm/i915/intel_ddi.c:1481:30: error: implicit conversion from enumeration type 'enum port' to different enumeration type 'enum intel_dpll_id' [-Werror,-Wenum-conversion] enum intel_dpll_id pll_id = port; ~~ ^~~~ Signed-off-by: Nick Desaulniers --- drivers/gpu/drm/i915/intel_ddi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 933c18fd4258..f9de45316901 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1478,7 +1478,7 @@ static void bxt_ddi_clock_get(struct intel_encoder *encoder, { struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); enum port port = intel_ddi_get_encoder_port(encoder); - enum intel_dpll_id pll_id = port; + uint32_t pll_id = port; pipe_config->port_clock = bxt_calc_pll_link(dev_priv, pll_id); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)
On Tue, Nov 21, 2017 at 05:55:29PM +, Emil Velikov wrote: >On 21 November 2017 at 15:07, wrote: >> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote: >>> - Document the autoselect process >>>Information about about What, Why, and [ideally] How - analogous to >>>the normal stable nominations. >>>Insert reference to the process in the patch notification email. >> >> I agree with this one, and it'll definitely happen. The story behind >> this is that this is all based on Julia Lawall's work which is well >> documented in a published paper here: >> >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__soarsmu.github.io_papers_icse12-2Dpatch.pdf&d=DwIBaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=fv1wuXCQm6WYyxCaomxaGGxNXY-K4gUrTY4VOx24NXw&s=9BjAjAQOia0gDJdPjQJYuyj3vYKPJ3RXNRQaA-Y7eug&e= >> >> I have modified inputs and process, but it essentially is very similar >> to what's described in that paper. >> >> While I have no problem with sharing what I have so far, this is >> still very much work in progress, and things keep constantly changing >> based on comments I receive from reviewers and Greg, so I want to >> reach a more stable point before trying to explain things and change >> my mind the day after :) >> >> If anyone is really interested in seeing the guts of this mess I >> currently have I can push it to github, but bear in mind that in it's >> current state it's very custom to the configuration I have, and is >> a borderline unreadable mix of bash scripts and LUA. >> >> Ideally it'll all get cleaned up and pushed anyways once I feel >> comfortable with the quality of the process. >> >At first I would focus on What and Why. Getting that information out >and publicising it via that blogs, G+, meetings, etc. is essential. >Reference to the current [WIP or not] heuristics is nice but can >follow-up in due time. A placeholder must be available though. I ended up getting a few more requests to dig into this, and I'm always happy to get more eyes on it, so I'll clean it up slightly and push whatever code I have to github and let anyone who wants see how it works and improve it. Should be done shortly after the upcoming holiday :) >>> - Make the autoselect nominations _more_ distinct than the normal stable >>> ones. >>>Maintainers will want to put more cognitive effort into the patches. >> >> So this came up before, and the participants of that thread agreed >> that adding "AUTOSEL" in the patch prefix is sufficient. What else >> would you suggest adding? >> >Being consistent [with existing stable nominations style] is good, but >first focus* should be on making it noticeable and distinct. >In other words - do _not_ be consistent. > >Flipping the order AUTOSEL PATCH, using WARN, NOTE or just dropping >PATCH should help. >People tend to read PATC. /xx: ... last words of commit message. > >Additionally, different template + a big note/warning in the email >body is a good idea. Say: >WARNING: This patch is nominated via the autosel procedure as defined at $ref. > >HTH >Emil > >* Regardless if autosel patches default to "ACK to merge" or not. I really didn't want to mess with the usual patch tagging ("[PATCH*") since I'm afraid it'll interfere with people's mail rules (it would, at least, in my case) and may cause people to miss this mail. -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] 4.15 vmgfx boot warning
The 4.15 vmwgfx driver shows a warning during boot (32 bit x86) It is caused by a mismatch between the result of vmw_enable_vblank() and what the drm_atomic_helper expects: /... ret = drm_crtc_vblank_get(crtc); WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n"); /... Signed-off by: Woody Suwalski --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 2017-11-22 15:29:46.511674079 -0500 +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 2017-11-22 15:30:35.344559592 -0500 @@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de */ int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe) { - return -ENOSYS; + return -EINVAL; } /** ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/i915: export the stolen region as a resource
* Joonas Lahtinen wrote: > + Dave as a heads-up > > On Thu, 2017-11-23 at 07:17 +0100, Ingo Molnar wrote: > > * Matthew Auld wrote: > > > > > We duplicate the stolen discovery code in early-quirks and in i915, > > > however if we just export the region as a resource from early-quirks we > > > can nuke the duplication. > > > > > > Suggested-by: Joonas Lahtinen > > > Suggested-by: Chris Wilson > > > Signed-off-by: Matthew Auld > > > Cc: Joonas Lahtinen > > > Cc: Chris Wilson > > > Cc: Paulo Zanoni > > > Cc: Ingo Molnar > > > Cc: H. Peter Anvin > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: x...@kernel.org > > > --- > > > arch/x86/kernel/early-quirks.c | 6 ++ > > > drivers/gpu/drm/i915/i915_gem_gtt.c| 51 +-- > > > drivers/gpu/drm/i915/i915_gem_stolen.c | 109 > > > + > > > include/drm/i915_drm.h | 3 + > > > 4 files changed, 13 insertions(+), 156 deletions(-) > > > > If it's truly identical: > > > > Acked-by: Ingo Molnar > > Are you fine with us merging this together with the rest of the series > through the DRM tree once it's all reviewed? > > That'd help not requiring so many backmerges. Yes, sure, feel free - that's also where most of the relevant testing is done for the affected hardware. Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: dma-mapping: Use vma_pages helper
Use vma_pages function on vma object instead of explicit computation. ./drivers/gpu/drm/rockchip/rockchip_drm_gem.c:223:34-40: WARNING: Consider using vma_pages helper on vma Generated by: scripts/coccinelle/api/vma_pages.cocci Signed-off-by: Vasyl Gomonovych --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index 1869c8bb76c8..1d9655576b6e 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c @@ -220,7 +220,7 @@ static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj, { struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj); unsigned int i, count = obj->size >> PAGE_SHIFT; - unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + unsigned long user_count = vma_pages(vma); unsigned long uaddr = vma->vm_start; unsigned long offset = vma->vm_pgoff; unsigned long end = user_count + offset; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/i915: export the stolen region as a resource
* Matthew Auld wrote: > We duplicate the stolen discovery code in early-quirks and in i915, > however if we just export the region as a resource from early-quirks we > can nuke the duplication. > > Suggested-by: Joonas Lahtinen > Suggested-by: Chris Wilson > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Paulo Zanoni > Cc: Ingo Molnar > Cc: H. Peter Anvin > Cc: dri-devel@lists.freedesktop.org > Cc: x...@kernel.org > --- > arch/x86/kernel/early-quirks.c | 6 ++ > drivers/gpu/drm/i915/i915_gem_gtt.c| 51 +-- > drivers/gpu/drm/i915/i915_gem_stolen.c | 109 > + > include/drm/i915_drm.h | 3 + > 4 files changed, 13 insertions(+), 156 deletions(-) If it's truly identical: Acked-by: Ingo Molnar Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage
On Wed, 22 Nov 2017 16:13:31 -0800 Eric Anholt wrote: > Boris Brezillon writes: > > > On Wed, 22 Nov 2017 13:16:08 -0800 > > Eric Anholt wrote: > > > >> Boris Brezillon writes: > >> > >> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's > >> > passed a refcount object that has its counter set to 0. In this driver, > >> > this is a valid use case since we want to increment ->usecnt only when > >> > the BO object starts to be used by real HW components and this is > >> > definitely not the case when the BO is created. > >> > > >> > Fix the problem by using refcount_inc_not_zero() instead of > >> > refcount_inc() and fallback to refcount_set(1) when > >> > refcount_inc_not_zero() returns false. Note that this 2-steps operation > >> > is not racy here because the whole section is protected by a mutex > >> > which guarantees that the counter does not change between the > >> > refcount_inc_not_zero() and refcount_set() calls. > >> > >> If we're not following the model, and protecting the refcount by a > >> mutex, shouldn't we just be using addition and subtraction instead of > >> refcount's atomics? > > > > Actually, this mutex is protecting the bo->madv value which has to be > > checked when the counter reaches 0 (when decrementing) or 1 (when > > incrementing). We just benefit from this protection here, but ideally > > it would be better to have an refcount_inc_allow_zero() as suggested by > > Daniel. > > Let me restate this to see if it makes sense: The refcount is always >= > 0, this is is the only path that increases the refcount from 0 to 1, and > it's (incidentally) protected by a mutex, so there's no race between the > attempted increase from nonzero and the set from nonzero to 1. Yep. > > This seems fine to me as a bugfix. The discussion is going on in the other thread, let's wait a bit before taking a decision. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: don't attempt to use hugepages if dma32 requested (v2)
Am 23.11.2017 um 03:41 schrieb Dave Airlie: From: Dave Airlie The commit below introduced thp support for ttm allocations, however it didn't take into account the case where dma32 was requested. Some drivers always request dma32, and the bochs driver is one of those. This fixes an oops: [ 30.108507] [ cut here ] [ 30.108920] kernel BUG at ./include/linux/gfp.h:408! [ 30.109356] invalid opcode: [#1] SMP [ 30.109700] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp mrp stp llc virtio_net [ 30.115605] virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop [ 30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted 4.15.0-0.rc0.git6.1.fc28.x86_64 #1 [ 30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 30.118866] task: 923a77e03380 task.stack: a78182228000 [ 30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430 [ 30.119810] RSP: :a7818222bba8 EFLAGS: 00010202 [ 30.120250] RAX: 0001 RBX: 014382c6 RCX: 0006 [ 30.120840] RDX: RSI: 0009 RDI: [ 30.121443] RBP: 923a760d6000 R08: R09: 0006 [ 30.122039] R10: 0040 R11: 0300 R12: 923a729273c0 [ 30.122629] R13: R14: R15: 923a7483d400 [ 30.123223] FS: 7fe48da7dac0() GS:923a7cc0() knlGS: [ 30.123896] CS: 0010 DS: ES: CR0: 80050033 [ 30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4: 06f0 [ 30.124968] Call Trace: [ 30.125186] ttm_pool_populate+0x19b/0x400 [ttm] [ 30.125578] ttm_bo_vm_fault+0x325/0x570 [ttm] [ 30.125964] __do_fault+0x19/0x11e [ 30.126255] __handle_mm_fault+0xcd3/0x1260 [ 30.126609] handle_mm_fault+0x14c/0x310 [ 30.126947] __do_page_fault+0x28c/0x530 [ 30.127282] do_page_fault+0x32/0x270 [ 30.127593] async_page_fault+0x22/0x30 [ 30.127922] RIP: 0033:0x7fe48aae39a8 [ 30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206 [ 30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX: 7fe457b73040 [ 30.129259] RDX: 0030 RSI: RDI: 7fe457b73000 [ 30.129855] RBP: 0300 R08: 000c R09: 0001 [ 30.130457] R10: 0001 R11: 0246 R12: 55cd4c1041a0 [ 30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15: 0400 [ 30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c [ 30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8 [ 30.133836] ---[ end trace d4f1deb60784f40a ]--- v2: handle free path as well. Reported-by: Laura Abbott Reported-by: Adam Williamson Fixes: 0284f1ead87463bc17cf5e81a24fc65c052486f3 (drm/ttm: add transparent huge page support for cached allocations v2) Signed-off-by: Dave Airlie Reviewed-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 36 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index 316f831..b0551aa 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -744,12 +744,14 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags, } #ifdef CONFIG_TRANSPARENT_HUGEPAGE - for (j = 0; j < HPAGE_PMD_NR; ++j) - if (p++ != pages[i + j]) - break; + if (!(flags & TTM_PAGE_FLAG_DMA32)) { + for (j = 0; j < HPAGE_PMD_NR; ++j) + if (p++ != pages[i + j]) + break; - if (j == HPAGE_PMD_NR) -
Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11/22/2017 05:09 AM, Christian König wrote: Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: On 11/21/2017 08:34 AM, Christian König wrote: Hi Boris, attached are two patches. The first one is a trivial fix for the infinite loop issue, it now correctly aborts the fixup when it can't find address space for the root window. The second is a workaround for your board. It simply checks if there is exactly one Processor Function to apply this fix on. Both are based on linus current master branch. Please test if they fix your issue. Yes, they do fix it but that's because the feature is disabled. Do you know what the actual problem was (on Xen)? I still haven't understood what you actually did with Xen. When you used PCI pass through with those devices then you have made a major configuration error. When the problem happened on dom0 then the explanation is most likely that some PCI device ended up in the configured space, but the routing was only setup correctly on one CPU socket. The problem is that dom0 can be (and was in my case() booted with less than full physical memory and so the "rest" of the host memory is not necessarily reflected in iomem. Your patch then tried to configure that memory for MMIO and the system hang. And so my guess is that this patch will break dom0 on a single-socket system as well. Oh, thanks! I've thought about that possibility before, but wasn't able to find a system which actually does that. May I ask why the rest of the memory isn't reported to the OS? That memory doesn't belong to the OS (dom0), it is owned by the hypervisor. Sounds like I can't trust Linux resource management and probably need to read the DRAM config to figure things out after all. My question is whether what you are trying to do should ever be done for a guest at all (any guest, not necessarily Xen). The issue is probably that I don't know enough about Xen: What exactly is dom0? My understanding was that dom0 is the hypervisor, but that seems to be incorrect. The issue is that under no circumstances *EVER* a virtualized guest should have access to the PCI devices marked as "Processor Function" on AMD platforms. Otherwise it is trivial to break out of the virtualization. When dom0 is something like the system domain with all hardware access then the approach seems legitimate, but then the hypervisor should report the stolen memory to the OS using the e820 table. When the hypervisor doesn't do that and the Linux kernel isn't aware that there is memory at a given location mapping PCI space there will obviously crash the hypervisor. Possible solutions as far as I can see are either disabling this feature when we detect that we are a Xen dom0, scanning the DRAM settings to update Linux resource handling or fixing Xen to report stolen memory to the dom0 OS as reserved. Opinions? Thanks, Christian. -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel