[PATCH] lib/prime_numbers: Suppress warn on kmalloc failure
The allocation for the bitmap may become very large, larger than MAX_ORDER, for large requests. We fail gracefully by falling back to trail-division, so disable the warning from kmalloc: 521.961092] WARNING: CPU: 0 PID: 30637 at mm/page_alloc.c:3548 __alloc_pages_slowpath+0x237/0x9a0 [ 521.961105] Modules linked in: i915(+) drm_kms_helper intel_gtt prime_numbers [last unloaded: drm_kms_helper] [ 521.961126] CPU: 0 PID: 30637 Comm: drv_selftest Tainted: G U W 4.10.0-rc3+ #321 [ 521.961137] Hardware name: /, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 521.961148] Call Trace: [ 521.961161] dump_stack+0x4d/0x6f [ 521.961172] __warn+0xc1/0xe0 [ 521.961181] warn_slowpath_null+0x18/0x20 [ 521.961189] __alloc_pages_slowpath+0x237/0x9a0 [ 521.961200] ? sg_init_table+0x1a/0x40 [ 521.961208] ? get_page_from_freelist+0x3fa/0x910 [ 521.961275] ? i915_gem_object_get_sg+0x272/0x2b0 [i915] [ 521.961285] __alloc_pages_nodemask+0x1ea/0x220 [ 521.961295] kmalloc_order+0x1c/0x50 [ 521.961304] __kmalloc+0x115/0x170 [ 521.961314] expand_to_next_prime+0x43/0x180 [prime_numbers] [ 521.961324] next_prime_number+0x47/0xc0 [prime_numbers] [ 521.961377] igt_vma_rotate+0x386/0x590 [i915] [ 521.961429] i915_subtests+0x37/0xc0 [i915] [ 521.961481] i915_vma_mock_selftests+0x3d/0x70 [i915] [ 521.961532] run_selftests+0x16e/0x1f0 [i915] [ 521.961541] ? 0xa02a4000 [ 521.961592] i915_mock_selftests+0x29/0x40 [i915] [ 521.961638] i915_init+0xa/0x5e [i915] [ 521.961646] ? 0xa02a4000 [ 521.961655] do_one_initcall+0x3e/0x160 [ 521.961664] ? __vunmap+0x7c/0xc0 [ 521.961672] ? vfree+0x29/0x70 [ 521.961680] ? kmem_cache_alloc+0xcf/0x120 [ 521.961690] do_init_module+0x55/0x1c4 [ 521.961699] load_module+0x1f3f/0x25b0 [ 521.961707] ? __symbol_put+0x40/0x40 [ 521.961716] ? kernel_read_file+0x100/0x190 [ 521.961725] SYSC_finit_module+0xbc/0xf0 [ 521.961734] SyS_finit_module+0x9/0x10 [ 521.961744] entry_SYSCALL_64_fastpath+0x17/0x98 [ 521.961752] RIP: 0033:0x7f111aca4119 [ 521.961760] RSP: 002b:7ffd8be6cbe8 EFLAGS: 0246 ORIG_RAX: 0139 [ 521.961773] RAX: ffda RBX: 0006 RCX: 7f111aca4119 [ 521.961781] RDX: RSI: 55dfc18bc8e0 RDI: 0006 [ 521.961789] RBP: 7ffd8be6bbe0 R08: R09: [ 521.961796] R10: 0006 R11: 0246 R12: 0005 [ 521.961805] R13: 55dfc18bd3a0 R14: 7ffd8be6bbc0 R15: 0005 Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Daniel Vetter --- lib/prime_numbers.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/prime_numbers.c b/lib/prime_numbers.c index c9b3c29614aa..550eec457c2e 100644 --- a/lib/prime_numbers.c +++ b/lib/prime_numbers.c @@ -124,7 +124,8 @@ static bool expand_to_next_prime(unsigned long x) return false; sz = round_up(sz, BITS_PER_LONG); - new = kmalloc(sizeof(*new) + bitmap_size(sz), GFP_KERNEL); + new = kmalloc(sizeof(*new) + bitmap_size(sz), + GFP_KERNEL | __GFP_NOWARN); if (!new) return false; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 10/12] firmware: qcom_scm: Add qcom_scm_gpu_zap_resume()
On Fri, Jan 13, 2017 at 11:12:41AM -0600, Andy Gross wrote:
> On Mon, Nov 28, 2016 at 12:28:35PM -0700, Jordan Crouse wrote:
> > Add an interface to trigger the remote processor to reinitialize the GPU
> > zap shader on power-up.
> >
> > Signed-off-by: Jordan Crouse
> > ---
>
>
>
> > +int __qcom_scm_gpu_zap_resume(struct device *dev)
> > +{
> > + struct qcom_scm_desc desc = {0};
> > + struct arm_smccc_res res;
> > + int ret;
> > +
> > + desc.args[0] = 0;
This is an opcode to force the state to resume.
QCOM_SCM_BOOT_SET_STATE_RESUME perhaps? Or something similar but shorter.
> > + desc.args[1] = 13;
This is the same as the SCM id of the GPU but I think that is a coincidence.
We've always used it to identify the GPU in this call.
QCOM_SCM_BOOT_SET_STATE_GPU would be fine here - or something similar.
> Can I get a define here for these two? Or maybe a comment on what these
> values
> are?
>
> > + desc.arginfo = QCOM_SCM_ARGS(2);
> > +
> > + ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, 0x0A, &desc, &res);
>
> Same with the 0xA. We usually throw a #define in for the command definitions.
0x0A sets the state of the device - for us it is always 0 (resume) and always
the GPU.
#define QCOM_SCM_BOOT_SET_STATE 0x0A
> Otherwise this all looks fine. If you can get back to me with either the
> values
> or a new patch I can include this in the next pull.
I'll make the changes and start the song and dance, but you'll no doubt be
faster than I.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of 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
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #51 from Jani Kärkkäinen --- Sent a support ticket to Psyonix about this (and the request for a debug build). Hopefully a random persons support ticket gets to the dev team and they deem it something that's in the realm of possibility. On a good note, already got a positive response from the first-level support, so, fingers crossed. :D -- You are receiving this mail because: You are on the CC list for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?
On Thu 12 Jan 2017, Gustavo Padovan wrote: > 2017-01-12 Laurent Pinchart : > > > Hi Daniel, > > > > On Thursday 12 Jan 2017 20:26:40 Daniel Vetter wrote: > > > On Thu, Jan 12, 2017 at 05:17:26PM -0200, Gustavo Padovan wrote: > > > > 2017-01-10 Laurent Pinchart : > > > >> On Monday 09 Jan 2017 11:23:23 Daniel Vetter wrote: > > > >>> On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote: > > > Was this a mistake in the API? If so, can we fix this ABI mistake > > > before kernel consumers rely on this? [...] > I'd expect users defining an int and hitting the issue Chad hit instead > of going to long types. So I hope we are safe here. I'll prepare a > patch to make it s32. Thanks for fixing this. I'm glad we caught it before the uabi became frozen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fence: fix memory overwrite when setting out_fence fd
On Fri 13 Jan 2017, Gustavo Padovan wrote: > From: Gustavo Padovan > > Currently if the userspace declares a int variable to store the out_fence > fd and pass it to OUT_FENCE_PTR the kernel will overwrite the 32 bits > above the int variable on 64 bits systems. > > Fix this by making the internal storage of out_fence in the kernel a s32 > pointer. > > Reported-by: Chad Versace > Signed-off-by: Gustavo Padovan > Cc: Daniel Vetter > Cc: Rafael Antognolli > Cc: Laurent Pinchart > Cc: sta...@vger.kernel.org Reviewed-and-Tested-by: Chad Versace I applied this to my kernel branch, updated kmscube, and the spinning cube still looks good. For reference, here are the tags I tested with: mesa: http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/i965-exec-fence-v03 libdrm: http://git.kiwitree.net/cgit/~chadv/libdrm/tag/?h=chadv/review/intel-exec-fence-v01 linux: http://git.kiwitree.net/cgit/~chadv/linux/tag/?h=chadv/test/i915-exec-fence-v04 kmscube: http://git.kiwitree.net/cgit/~chadv/kmscube/tag/?h=chadv/test/fences-v03 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: fix valgrind warning in drmParsePciBusInfo
On 01/13/2017 09:57 AM, Emil Velikov wrote: On 13 January 2017 at 11:34, Jan Vesely wrote: On Thu, 2017-01-12 at 18:16 -0800, Nicholas Miell wrote: From 714d07f600db39498c87d7816f4dd3a7e6d9bbca Mon Sep 17 00:00:00 2001 From: Nicholas Miell Date: Thu, 12 Jan 2017 15:43:07 -0800 Subject: [PATCH libdrm] xf86drm: fix valgrind warning in drmParsePciBusInfo The current implementation reads (up to) 513 bytes, overwrites the 513th byte with '\0' and then passes the buffer off to strstr() and sscanf() without ever initializing the middle bytes. This causes valgrind warnings and potentially fails to parse PCI_SLOT_NAME if the uevent is unexpectedly large. a simpler fix should also get rid of the valgrind warning: - ret = read(fd, data, sizeof(data)); - data[sizeof(data)-1] = '\0'; + ret = read(fd, data, sizeof(data) - 1); close(fd); if (ret < 0) return -errno + data[ret] = '\0'; We had this (better imho) patch a week or so ago. In either case the issue is virtually since (iirc) if the string is malformed we'll bail out either way. Simpler, but potentially stops working in the future. It already stopped working once. I think that dynamic memory allocation is still a more robust approach. Yes that might be the better solution, or one could even use getline(). The latter might be pushing it's only POSIX 2008. POSIX isn't relevant, this is a Linux-specific function. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).
https://bugs.freedesktop.org/show_bug.cgi?id=99403 Bug ID: 99403 Summary: Graphical glitches in witcher-1 with wine nine and r600g (rv740). Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: roman.els...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 128941 --> https://bugs.freedesktop.org/attachment.cgi?id=128941&action=edit screenshot Very similar (but visually not exactly identical) glitches exists without nine, but there are workaround in wine: [HKEY_CURRENT_USER\Software\Wine\Direct3D] CheckFloatConstants="enabled" which helps with it. This key does not make a difference with nine. There are no such problem with nouveau (750ti) here, os ubuntu-16.04 with oibaf and commendsarnex ppa. -- 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 98619] amdgpu 0000:01:00.0: GPU fault detected: 146 0x09d88404
https://bugs.freedesktop.org/show_bug.cgi?id=98619 --- Comment #4 from Brandon Egbert --- I'm experiencing an almost identical error in many games. I'm able to reproduce this on demand by trying to view the world map in X-COM 2 when not on minimum settings. I would be happy to provide more info if it would be helpful. -- 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 95306] Random Blank(black) screens on "Carrizo"
https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #50 from cyrwyn --- Has anyone read my xorg.log and xorg.conf files? Two things I noticed that might be relevant. There is a Screen1, but not a Screen0 in the conf file. Should XFdrake have created this file designating Screen0? The log file shows that modesetting isn't supported. Why? Is this problem just a faulty configuration problem? -- 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 99392] Ark survival evolved won't start
https://bugs.freedesktop.org/show_bug.cgi?id=99392 --- Comment #2 from predator-...@web.de --- yes it sounds like it, but the "solution" doesn't work. Do you have any guide to debug this problem ? -- 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 192271] kernel 4.9 hangs during shutdown or reboot
https://bugzilla.kernel.org/show_bug.cgi?id=192271 upcwt...@emltmp.com changed: What|Removed |Added Component|Video(DRI - non Intel) |Power-Off Product|Drivers |ACPI Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2
This and all the remaining patches on this series (6,7,8 and 9) got
merged to dinq.
Thanks for the patches.
On Thu, Jan 12, 2017 at 12:12 PM, Vivi, Rodrigo wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Fri, 2017-01-13 at 00:31 +0530, vathsala nagaraju wrote:
>> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
>> psr2 enable sequence.
>> bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for
>> PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable
>> header packet.
>> bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported
>>
>> v2: (Rodrigo)
>> - move CHICKEN_TRANS_EDP bit set logic right after setup_vsc
>>
>> v3:(Rodrigo)
>> - initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0
>>
>> v4:(chris wilson)
>> - use BIT(12), remove CHICKEN_TRANS_BIT12
>> - remove unnecessary comments
>> - update commit message
>>
>> v5:
>> - rename bit 12 PSR2_VSC_ENABLE_PROG_HEADER
>> - rename bit 15 PSR2_ADD_VERTICAL_LINE_COUNT
>>
>> v6:(Rodrigo)
>> - remove TRANS_EDP=3, use cpu_transcoder
>>
>> Cc: Rodrigo Vivi
>> Cc: Jim Bride
>> Signed-off-by: vathsala nagaraju
>> Signed-off-by: Patil Deepti
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 6 ++
>> drivers/gpu/drm/i915/intel_psr.c | 7 +++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 7830e6e..c9c1ccd 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6449,6 +6449,12 @@ enum {
>> #define BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
>> #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A,
>> _CHICKEN_PIPESL_1_B)
>>
>> +#define CHICKEN_TRANS_A 0x420c0
>> +#define CHICKEN_TRANS_B 0x420c4
>> +#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
>> CHICKEN_TRANS_B)
>> +#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
>> +#define PSR2_ADD_VERTICAL_LINE_COUNT (1<<15)
>> +
>> #define DISP_ARB_CTL _MMIO(0x45000)
>> #define DISP_FBC_MEMORY_WAKE(1<<31)
>> #define DISP_TILE_SURFACE_SWIZZLING (1<<13)
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> b/drivers/gpu/drm/i915/intel_psr.c
>> index 36c4045..935402e 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -480,6 +480,9 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> struct drm_device *dev = intel_dig_port->base.base.dev;
>> struct drm_i915_private *dev_priv = to_i915(dev);
>> + struct intel_crtc *crtc =
>> to_intel_crtc(intel_dig_port->base.base.crtc);
>> + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
>> + u32 chicken;
>>
>> if (!HAS_PSR(dev_priv)) {
>> DRM_DEBUG_KMS("PSR not supported on this platform\n");
>> @@ -505,6 +508,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>> if (HAS_DDI(dev_priv)) {
>> if (dev_priv->psr.psr2_support) {
>> skl_psr_setup_su_vsc(intel_dp);
>> + chicken = PSR2_VSC_ENABLE_PROG_HEADER;
>> + if (dev_priv->psr.y_cord_support)
>> + chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
>> + I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
>> } else {
>> /* set up vsc header for psr1 */
>> hsw_psr_setup_vsc(intel_dp);
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: fix valgrind warning in drmParsePciBusInfo
On 13 January 2017 at 11:34, Jan Vesely wrote: > On Thu, 2017-01-12 at 18:16 -0800, Nicholas Miell wrote: >> From 714d07f600db39498c87d7816f4dd3a7e6d9bbca Mon Sep 17 00:00:00 2001 >> From: Nicholas Miell >> Date: Thu, 12 Jan 2017 15:43:07 -0800 >> Subject: [PATCH libdrm] xf86drm: fix valgrind warning in drmParsePciBusInfo >> >> The current implementation reads (up to) 513 bytes, overwrites the 513th >> byte with '\0' and then passes the buffer off to strstr() and sscanf() >> without ever initializing the middle bytes. This causes valgrind >> warnings and potentially fails to parse PCI_SLOT_NAME if the uevent is >> unexpectedly large. > > a simpler fix should also get rid of the valgrind warning: > > - ret = read(fd, data, sizeof(data)); > - data[sizeof(data)-1] = '\0'; > + ret = read(fd, data, sizeof(data) - 1); >close(fd); >if (ret < 0) >return -errno > + data[ret] = '\0'; > We had this (better imho) patch a week or so ago. In either case the issue is virtually since (iirc) if the string is malformed we'll bail out either way. > > I think that dynamic memory allocation is still a more robust approach. > Yes that might be the better solution, or one could even use getline(). The latter might be pushing it's only POSIX 2008. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93760] radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
https://bugs.freedesktop.org/show_bug.cgi?id=93760 Andy Furniss changed: What|Removed |Added Attachment #121115|0 |1 is obsolete|| -- 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 93760] radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
https://bugs.freedesktop.org/show_bug.cgi?id=93760 --- Comment #5 from Andy Furniss --- (In reply to Christian König from comment #3) > Sorry totally missed that bug. > > The problem is most likely that GStreamer sends multiple slices in one > request to VA-API and we can't handle that in the state tracker. Though it seems gstreamer also has issues, I only first tried it today. This bug is testing with mpv. -- 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 v11 01/12] dt-bindings: display: mediatek: update supported chips
On Wed, Jan 11, 2017 at 02:51:02PM +0800, YT Shen wrote: > Add decriptions about supported chips, including MT2701 & MT8173 > > Signed-off-by: YT Shen > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++ > Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++ > 2 files changed, 4 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: don't link DP aux i2c adapter to the hardware device node
The i2c adapter on DP AUX is purely a software construct. Linking it to the device node of the parent device is wrong, as it leads to 2 devices sharing the same device node, which is bad practice, as well as the i2c trying to populate children of the i2c adapter by looking at the child device nodes of the parent device. Signed-off-by: Lucas Stach --- drivers/gpu/drm/drm_dp_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 3e6fe82c6d64..f91ade1edbde 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1020,7 +1020,6 @@ int drm_dp_aux_register(struct drm_dp_aux *aux) aux->ddc.class = I2C_CLASS_DDC; aux->ddc.owner = THIS_MODULE; aux->ddc.dev.parent = aux->dev; - aux->ddc.dev.of_node = aux->dev->of_node; strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev), sizeof(aux->ddc.name)); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93760] radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
https://bugs.freedesktop.org/show_bug.cgi?id=93760 --- Comment #4 from Nayan Deshmukh --- I can reproduce the issue. I will look more into this over the weekend and also read more about VA-API. -- 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 v8 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
On Wed, Jan 11, 2017 at 03:33:57PM +0900, Hoegeun Kwon wrote: > The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected > using MIPI-DSI interfaces. > > Signed-off-by: Donghwa Lee > Signed-off-by: Hyungwon Hwang > Signed-off-by: Hoegeun Kwon > Tested-by: Chanwoo Choi > Reviewed-by: Andrzej Hajda > --- > .../bindings/display/panel/samsung,s6e3ha2.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/12] firmware: qcom_scm: Add qcom_scm_gpu_zap_resume()
On Fri, Jan 13, 2017 at 11:12:41AM -0600, Andy Gross wrote:
> On Mon, Nov 28, 2016 at 12:28:35PM -0700, Jordan Crouse wrote:
> > Add an interface to trigger the remote processor to reinitialize the GPU
> > zap shader on power-up.
> >
> > Signed-off-by: Jordan Crouse
> > ---
>
>
>
> > +int __qcom_scm_gpu_zap_resume(struct device *dev)
> > +{
> > + struct qcom_scm_desc desc = {0};
> > + struct arm_smccc_res res;
> > + int ret;
> > +
> > + desc.args[0] = 0;
> > + desc.args[1] = 13;
>
> Can I get a define here for these two? Or maybe a comment on what these
> values
> are?
>
> > + desc.arginfo = QCOM_SCM_ARGS(2);
> > +
> > + ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, 0x0A, &desc, &res);
>
> Same with the 0xA. We usually throw a #define in for the command definitions.
>
> Otherwise this all looks fine. If you can get back to me with either the
> values
> or a new patch I can include this in the next pull.
Thanks for reaching out. Since this isn't my usual area I'll need to work out
some terminology with the SCM folks to make sure I don't accidentally do
anything that will get me in trouble.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of 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] drm/bridge: tc358767: add copyright lines
Add copyright lines for Zodiac who paid for driver development. Signed-off-by: Andrey Gusakov --- drivers/gpu/drm/bridge/tc358767.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index de9ffb4..f117673 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -6,6 +6,8 @@ * * Copyright (C) 2016 Pengutronix, Philipp Zabel * + * Copyright (C) 2016 Zodiac Inflight Innovations + * * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c * * Copyright (C) 2012 Texas Instruments -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fence: fix memory overwrite when setting out_fence fd
2017-01-13 Laurent Pinchart : > Hi Gustavo, > > Thank you for the patch. > > On Friday 13 Jan 2017 12:22:09 Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Currently if the userspace declares a int variable to store the out_fence > > fd and pass it to OUT_FENCE_PTR the kernel will overwrite the 32 bits > > above the int variable on 64 bits systems. > > > > Fix this by making the internal storage of out_fence in the kernel a s32 > > pointer. > > > > Reported-by: Chad Versace > > Signed-off-by: Gustavo Padovan > > Cc: Daniel Vetter > > Cc: Rafael Antognolli > > Cc: Laurent Pinchart > > Acked-by: Laurent Pinchart > > > Cc: sta...@vger.kernel.org > > I don't think this is needed, given that the code was merged in v4.10-rc1, > and > this patch should be merged as a v4.10-rc fix. Hmm, yeah. I got confused. Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99292] GPU hang in High Fidelity
https://bugs.freedesktop.org/show_bug.cgi?id=99292 --- Comment #3 from Samuel Pitoiset --- Confirmed, I can reproduce the hang on my rx 480 with latest mesa/llvm. It hangs at draw call 680247, looks like an infinite loop in the fragment shader. -- 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 93760] radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
https://bugs.freedesktop.org/show_bug.cgi?id=93760 --- Comment #3 from Christian König --- Sorry totally missed that bug. The problem is most likely that GStreamer sends multiple slices in one request to VA-API and we can't handle that in the state tracker. Should be easy to fix actually, but we need somebody to look into it and reproduce this. Another task for Nayan maybe? -- 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/4] video: add HDMI state notifier support
Am Dienstag, den 13.12.2016, 16:08 +0100 schrieb Hans Verkuil:
> From: Hans Verkuil
>
> Add support for HDMI hotplug and EDID notifiers, which is used to convey
> information from HDMI drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patchwork.kernel.org/patch/9277043/
>
> The hdmi_notifier is a reference counted object containing the HDMI state
> of an HDMI device.
>
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
>
> Signed-off-by: Hans Verkuil
Acked-by: Philipp Zabel
regards
Philipp
> ---
> drivers/video/Kconfig | 3 +
> drivers/video/Makefile| 1 +
> drivers/video/hdmi-notifier.c | 134
> ++
> include/linux/hdmi-notifier.h | 109 ++
> 4 files changed, 247 insertions(+)
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..1ee7b9f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
> config HDMI
> bool
>
> +config HDMI_NOTIFIERS
> + bool
> +
> if VT
> source "drivers/video/console/Kconfig"
> endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17..65f5649 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_VGASTATE)+= vgastate.o
> obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
>
> obj-$(CONFIG_VT) += console/
> obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> new file mode 100644
> index 000..29e4225
> --- /dev/null
> +++ b/drivers/video/hdmi-notifier.c
> @@ -0,0 +1,134 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static LIST_HEAD(hdmi_notifiers);
> +static DEFINE_MUTEX(hdmi_notifiers_lock);
> +
> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> +{
> + struct hdmi_notifier *n;
> +
> + mutex_lock(&hdmi_notifiers_lock);
> + list_for_each_entry(n, &hdmi_notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(&hdmi_notifiers_lock);
> + kref_get(&n->kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + n->dev = dev;
> + mutex_init(&n->lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> + kref_init(&n->kref);
> + list_add_tail(&n->head, &hdmi_notifiers);
> +unlock:
> + mutex_unlock(&hdmi_notifiers_lock);
> + return n;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> +
> +static void hdmi_notifier_release(struct kref *kref)
> +{
> + struct hdmi_notifier *n =
> + container_of(kref, struct hdmi_notifier, kref);
> +
> + mutex_lock(&hdmi_notifiers_lock);
> + list_del(&n->head);
> + mutex_unlock(&hdmi_notifiers_lock);
> + kfree(n->edid);
> + kfree(n);
> +}
> +
> +void hdmi_notifier_put(struct hdmi_notifier *n)
> +{
> + kref_put(&n->kref, hdmi_notifier_release);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> +
> +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block
> *nb)
> +{
> + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> +
> + if (ret)
> + return ret;
> + kref_get(&n->kref);
> + mutex_lock(&n->lock);
> + if (n->connected) {
> + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> + if (n->edid_size)
> + blocking_notifier_call_chain(&n->notifiers,
> HDMI_NEW_EDID, n);
> + if (n->has_eld)
> + blocking_notifier_call_chain(&n->notifiers,
> HDMI_NEW_ELD, n);
> + }
> + mutex_unlock(&n->lock);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> +
> +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block
> *nb)
> +{
> + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> +
> + if (ret == 0)
> + hdmi_notifier_put(n);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> +
> +void hdmi_event_connect(struct hdmi_notifier *n)
> +{
> + mutex_lock(&n->lock);
> + n->connected = true;
> + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> + mutex_unlock(&n->lock);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> +
> +void hdmi_event_disconnect(struct hdmi_notifier *n)
> +{
> + mutex_lock(&n->lock);
> + n->connected = false;
> + n->has_eld = false;
> + n->edid_size = 0;
> + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> + mutex_unloc
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #27 from MirceaKitsune --- I still get GPU hangs with the 4.9.0 Kernel & Mesa 13.0.3. I'm noticing them with a Second Life viewer now, which will occasionally cause GPU hands when some things are loaded and / or rendered. -- 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 93760] radeonsi vaapi mpeg2 decode slightly corrupt or asserts.
https://bugs.freedesktop.org/show_bug.cgi?id=93760 --- Comment #2 from Andy Furniss --- Time moves on - I can't actually lock (so far) testing now, but output is still corrupt. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm: Use atomic state for FB in legacy ioctls
Hi Dan,
On 13 January 2017 at 12:56, Dan Carpenter wrote:
> drivers/gpu/drm/drm_crtc.c:392 drm_mode_getcrtc()
> error: we previously assumed 'crtc->primary->state' could be null
> (see line 384)
>
> drivers/gpu/drm/drm_crtc.c
>383
>384 if (crtc->primary->state && crtc->primary->state->fb)
>
> New check for NULL.
>
>385 crtc_resp->fb_id = crtc->primary->state->fb->base.id;
>386 else if (!crtc->primary->state && crtc->primary->fb)
>387 crtc_resp->fb_id = crtc->primary->fb->base.id;
>388 else
>389 crtc_resp->fb_id = 0;
>390
>391 if (crtc->state) {
>392 crtc_resp->x = crtc->primary->state->src_x >> 16;
>^^^
> Old unchecked dereference. It's possible that non-NULL "crtc->state"
> implies a non-NULL "crtc->primary->state", but I didn't spot the
> relationship immediately.
Thanks for this. I believe this is indeed an invariant; Dan Vetter
could confirm, if he's managed to find internet in Hobart. Assuming
this is the case, what's the best way to communicate this to smatch;
would that be through a BUG_ON or similar?
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fence: fix memory overwrite when setting out_fence fd
Hi Gustavo,
Thank you for the patch.
On Friday 13 Jan 2017 12:22:09 Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Currently if the userspace declares a int variable to store the out_fence
> fd and pass it to OUT_FENCE_PTR the kernel will overwrite the 32 bits
> above the int variable on 64 bits systems.
>
> Fix this by making the internal storage of out_fence in the kernel a s32
> pointer.
>
> Reported-by: Chad Versace
> Signed-off-by: Gustavo Padovan
> Cc: Daniel Vetter
> Cc: Rafael Antognolli
> Cc: Laurent Pinchart
Acked-by: Laurent Pinchart
> Cc: sta...@vger.kernel.org
I don't think this is needed, given that the code was merged in v4.10-rc1, and
this patch should be merged as a v4.10-rc fix.
> ---
> drivers/gpu/drm/drm_atomic.c | 12 ++--
> include/drm/drm_atomic.h | 2 +-
> include/drm/drm_mode_config.h | 2 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 6414bcf..723392f 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -286,15 +286,15 @@ drm_atomic_get_crtc_state(struct drm_atomic_state
> *state, EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
> static void set_out_fence_for_crtc(struct drm_atomic_state *state,
> -struct drm_crtc *crtc, s64 __user
*fence_ptr)
> +struct drm_crtc *crtc, s32 __user
*fence_ptr)
> {
> state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
> }
>
> -static s64 __user *get_out_fence_for_crtc(struct drm_atomic_state *state,
> +static s32 __user *get_out_fence_for_crtc(struct drm_atomic_state *state,
> struct drm_crtc *crtc)
> {
> - s64 __user *fence_ptr;
> + s32 __user *fence_ptr;
>
> fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
> state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
> @@ -507,7 +507,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> state->color_mgmt_changed |= replaced;
> return ret;
> } else if (property == config->prop_out_fence_ptr) {
> - s64 __user *fence_ptr = u64_to_user_ptr(val);
> + s32 __user *fence_ptr = u64_to_user_ptr(val);
>
> if (!fence_ptr)
> return 0;
> @@ -1914,7 +1914,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb);
> */
>
> struct drm_out_fence_state {
> - s64 __user *out_fence_ptr;
> + s32 __user *out_fence_ptr;
> struct sync_file *sync_file;
> int fd;
> };
> @@ -1951,7 +1951,7 @@ static int prepare_crtc_signaling(struct drm_device
> *dev, return 0;
>
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - u64 __user *fence_ptr;
> + s32 __user *fence_ptr;
>
> fence_ptr = get_out_fence_for_crtc(crtc_state->state, crtc);
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index f96220e..f1cb2b0 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -144,7 +144,7 @@ struct __drm_crtcs_state {
> struct drm_crtc *ptr;
> struct drm_crtc_state *state;
> struct drm_crtc_commit *commit;
> - s64 __user *out_fence_ptr;
> + s32 __user *out_fence_ptr;
> unsigned last_vblank_count;
> };
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 17942c0..fe230f1 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -496,7 +496,7 @@ struct drm_mode_config {
> /**
>* @prop_out_fence_ptr: Sync File fd pointer representing the
>* outgoing fences for a CRTC. Userspace should provide a pointer to a
> - * value of type s64, and then cast that pointer to u64.
> + * value of type s32, and then cast that pointer to u64.
>*/
> struct drm_property *prop_out_fence_ptr;
> /**
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Enabling peer to peer device transactions for PCIe devices
Am 12.01.2017 um 16:11 schrieb Jerome Glisse: On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote: On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: On 06/01/17 11:26 AM, Jason Gunthorpe wrote: Make a generic API for all of this and you'd have my vote.. IMHO, you must support basic pinning semantics - that is necessary to support generic short lived DMA (eg filesystem, etc). That hardware can clearly do that if it can support ODP. I agree completely. What we want is for RDMA, O_DIRECT, etc to just work with special VMAs (ie. at least those backed with ZONE_DEVICE memory). Then GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace (using whatever interface is most appropriate) and userspace can do what it pleases with them. This makes _so_ much sense and actually largely already works today (as demonstrated by iopmem). +1 for iopmem ;-) I feel like we are going around and around on this topic. I would like to see something that is upstream that enables P2P even if it is only the minimum viable useful functionality to begin. I think aiming for the moon (which is what HMM and things like it are) are simply going to take more time if they ever get there. There is a use case for in-kernel P2P PCIe transfers between two NVMe devices and between an NVMe device and an RDMA NIC (using NVMe CMBs or BARs on the NIC). I am even seeing users who now want to move data P2P between FPGAs and NVMe SSDs and the upstream kernel should be able to support these users or they will look elsewhere. The iopmem patchset addressed all the use cases above and while it is not an in kernel API it could have been modified to be one reasonably easily. As Logan states the driver can then choose to pass the VMAs to user-space in a manner that makes sense. Earlier in the thread someone mentioned LSF/MM. There is already a proposal to discuss this topic so if you are interested please respond to the email letting the committee know this topic is of interest to you [1]. Also earlier in the thread someone discussed the issues around the IOMMU. Given the known issues around P2P transfers in certain CPU root complexes [2] it might just be a case of only allowing P2P when a PCIe switch connects the two EPs. Another option is just to use CONFIG_EXPERT and make sure people are aware of the pitfalls if they invoke the P2P option. iopmem is not applicable to GPU what i propose is to split the issue in 2 so that everyone can reuse the part that needs to be common namely the DMA API part where you have to create IOMMU mapping for one device to point to the other device memory. We can have a DMA API that is agnostic to how the device memory is manage (so does not matter if device memory have struct page or not). This what i have been arguing in this thread. To make progress on this issue we need to stop conflicting different use case. So i say let solve the IOMMU issue first and let everyone use it in their own way with their device. I do not think we can share much more than that. Yeah, exactly what I said from the very beginning as well. Just hacking together quick solutions doesn't really solve the problem in the long term. What we need is proper adjusting of the DMA API towards handling of P2P and then build solutions for the different use cases on top of that. We should also avoid falling into the trap of trying to just handle the existing get_user_pages and co interfaces so that the existing code doesn't need to change. P2P needs to be validated for each use case individually and not implemented in workarounds with fingers crossed and hoped for the best. Regards, Christian. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fence: fix memory overwrite when setting out_fence fd
From: Gustavo Padovan
Currently if the userspace declares a int variable to store the out_fence
fd and pass it to OUT_FENCE_PTR the kernel will overwrite the 32 bits
above the int variable on 64 bits systems.
Fix this by making the internal storage of out_fence in the kernel a s32
pointer.
Reported-by: Chad Versace
Signed-off-by: Gustavo Padovan
Cc: Daniel Vetter
Cc: Rafael Antognolli
Cc: Laurent Pinchart
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_atomic.c | 12 ++--
include/drm/drm_atomic.h | 2 +-
include/drm/drm_mode_config.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6414bcf..723392f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -286,15 +286,15 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
EXPORT_SYMBOL(drm_atomic_get_crtc_state);
static void set_out_fence_for_crtc(struct drm_atomic_state *state,
- struct drm_crtc *crtc, s64 __user *fence_ptr)
+ struct drm_crtc *crtc, s32 __user *fence_ptr)
{
state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
}
-static s64 __user *get_out_fence_for_crtc(struct drm_atomic_state *state,
+static s32 __user *get_out_fence_for_crtc(struct drm_atomic_state *state,
struct drm_crtc *crtc)
{
- s64 __user *fence_ptr;
+ s32 __user *fence_ptr;
fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
@@ -507,7 +507,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
state->color_mgmt_changed |= replaced;
return ret;
} else if (property == config->prop_out_fence_ptr) {
- s64 __user *fence_ptr = u64_to_user_ptr(val);
+ s32 __user *fence_ptr = u64_to_user_ptr(val);
if (!fence_ptr)
return 0;
@@ -1914,7 +1914,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb);
*/
struct drm_out_fence_state {
- s64 __user *out_fence_ptr;
+ s32 __user *out_fence_ptr;
struct sync_file *sync_file;
int fd;
};
@@ -1951,7 +1951,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
return 0;
for_each_crtc_in_state(state, crtc, crtc_state, i) {
- u64 __user *fence_ptr;
+ s32 __user *fence_ptr;
fence_ptr = get_out_fence_for_crtc(crtc_state->state, crtc);
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index f96220e..f1cb2b0 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -144,7 +144,7 @@ struct __drm_crtcs_state {
struct drm_crtc *ptr;
struct drm_crtc_state *state;
struct drm_crtc_commit *commit;
- s64 __user *out_fence_ptr;
+ s32 __user *out_fence_ptr;
unsigned last_vblank_count;
};
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 17942c0..fe230f1 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -496,7 +496,7 @@ struct drm_mode_config {
/**
* @prop_out_fence_ptr: Sync File fd pointer representing the
* outgoing fences for a CRTC. Userspace should provide a pointer to a
-* value of type s64, and then cast that pointer to u64.
+* value of type s32, and then cast that pointer to u64.
*/
struct drm_property *prop_out_fence_ptr;
/**
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses
Hi Nickey,
On Friday 13 Jan 2017 09:32:54 Nickey.Yang wrote:
> 在 2017年01月12日 23:26, Laurent Pinchart 写道:
> > On Thursday 12 Jan 2017 09:45:31 Nickey.Yang wrote:
> >> 在 2017年01月12日 07:49, Laurent Pinchart 写道:
> >>> Replace the hardcoded register address numerical values with macros to
> >>> clarify the code.
> >>>
> >>> This change has been tested by comparing the assembly code before and
> >>> after the change.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>>
> >>> ---
> >>>
> >>> drivers/gpu/drm/bridge/dw-hdmi.c | 35 -
> >>> drivers/gpu/drm/bridge/dw-hdmi.h | 66 +
> >>> 2 files changed, 86 insertions(+), 15 deletions(-)
[snip]
> >>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h
> >>> b/drivers/gpu/drm/bridge/dw-hdmi.h index a4fd64a203c9..f3c149c88d71
> >>> 100644
> >>> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> >>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> >>> @@ -1085,4 +1085,70 @@ enum {
> >>>
> >>> HDMI_I2CM_CTLINT_ARB_MASK = 0x4,
> >>>
> >>>};
> >>>
> >>> +/*
> >>> + * HDMI 3D TX PHY registers
> >>> + */
> >>
> >> Why is there 3D related words？
> >
> > The register names come from the i.MX6 datasheet. I don't have access to
> > any PHY datasheet from Synopsys, and the Rockchip RK3288 manuals I've
> > been able to find don't document the HDMI PHY register. As the PHY used
> > by i.MX6 is a "DWC HDMI 3D TX PHY", I'd used that name in the code.
> >
> > The "DWC MHL PHY" used by RK3288 seems to be use a similar (if not
> > identical) registers map, at least for the registers configured by the
> > driver. The "DWC HDMI 2.0 TX PHY" PHY used by R-Car Gen3, however, seems
> > not to have a compatible register interface, except for the
> > HDMI_3D_TX_PHY_PTRPT_ENBL register.
> >
> > I'm open to suggestions for a better naming scheme. If you have additional
> > information that I don't have access to, please feel free to use them to
> > propose improvements or to point out my mistakes :-)
> >
> >> I did not find "3D" words in PHY IP vendor document.
> >
> > How is the PHY named in the documentation you have access to ?
>
> just remove 3D word，such as name HDMI_TX_PHY_PWRCTRL instead of
> HDMI_3D_TX_PHY_PWRCTRL
> in doc: HDMI Tx PHY for GLOBAL FOUNDRIES 28-nm SLP/1.8 V Databook,
> LCA Edition
>11.1 Control Registers Module Design Architecture
https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_14_csds_tx doesn't list that
document, but mentions "DesignWare Cores HDMI 3D TX PHY for GLOBALFOUNDARIES
28-nm SLP/1.8 V Databook". The description of the corresponding PHY, however,
is "HDMI 1.4 TX PHY 3.4Gbps in GF 28nm SLP 1.8V, East/West Poly Orientation".
I assume that HDMI 1.4 TX PHYs originally didn't have 3D support, and new PHYs
with 3D support were then named "HDMI 3D TX PHY". After some time PHYs without
3D support were dropped from the product line, and 3D then got dropped from
the name.
We could use the "HDMI_14_TX_PHY" prefix, to differentiate the registers from
the HDMI 2.0 TX PHY registers that would use a "HDMI_20_TX_PHY" prefix.
"HDMI_TX_PHY" prefix could be used for registers common between the two PHY
types. I'm sure that wouldn't cover the whole product range, but with no
additional information it's hard to come up with a better proposal (actually
even this wouldn't be very easy, as I don't have much documentation about the
HDMI 2.0 TX PHY registers).
By the way, does your HDMI TX controller databook (not the TX PHY but the TX
controller) mention "HDMI 3D TX PHY" in the config2_id register (0x0006)
documentation ? How does it name PHY type 0xF2 for instance ? And PHY type
0xC2, which I believe is the PHY used by the RK3288 (please correct me if I'm
wrong there) ?
> >>> +#define HDMI_3D_TX_PHY_PWRCTRL 0x00
> >>> +#define HDMI_3D_TX_PHY_SERDIVCTRL0x01
> >>> +#define HDMI_3D_TX_PHY_SERCKCTRL 0x02
> >>> +#define HDMI_3D_TX_PHY_SERCKKILLCTRL 0x03
> >>> +#define HDMI_3D_TX_PHY_TXRESCTRL 0x04
> >>> +#define HDMI_3D_TX_PHY_CKCALCTRL 0x05
> >>> +#define HDMI_3D_TX_PHY_CPCE_CTRL 0x06
> >>> +#define HDMI_3D_TX_PHY_TXCLKMEASCTRL 0x07
> >>> +#define HDMI_3D_TX_PHY_TXMEASCTRL0x08
> >>> +#define HDMI_3D_TX_PHY_CKSYMTXCTRL 0x09
> >>> +#define HDMI_3D_TX_PHY_CMPSEQCTRL0x0a
> >>> +#define HDMI_3D_TX_PHY_CMPPWRCTRL0x0b
> >>> +#define HDMI_3D_TX_PHY_CMPMODECTRL 0x0c
> >>> +#define HDMI_3D_TX_PHY_MEASCTRL 0x0d
> >>> +#define HDMI_3D_TX_PHY_VLEVCTRL 0x0e
> >>> +#define HDMI_3D_TX_PHY_D2ACTRL 0x0f
> >>> +#define HDMI_3D_TX_PHY_CURRCTRL 0x10
> >>> +#define HDMI_3D_TX_PHY_DRVANACTRL0x11
> >>> +#define HDMI_3D_TX_PHY_PLLMEASCTRL 0x12
> >>> +#define HDMI_3D_TX_PHY_PLLPHBYCTRL 0x13
> >>> +#define HDMI_3D_TX_PHY_GRP_CTRL 0x14
Re: [PATCH 1/3] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses
Hi Laurent,
在 2017年01月12日 23:26, Laurent Pinchart 写道:
Hi Nickey,
On Thursday 12 Jan 2017 09:45:31 Nickey.Yang wrote:
在 2017年01月12日 07:49, Laurent Pinchart 写道:
Replace the hardcoded register address numerical values with macros to
clarify the code.
This change has been tested by comparing the assembly code before and
after the change.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 35 -
drivers/gpu/drm/bridge/dw-hdmi.h | 66
2 files changed, 86 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
b/drivers/gpu/drm/bridge/dw-hdmi.c index ef4f2f96ed2c..6e605fd910ef
100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -997,21 +997,26 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
int cscon)
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);
- hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
- hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
-
- /* CURRCTRL */
- hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
-
- hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
- hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
-
- hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19); /* TXTERM */
- hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL */
- hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
-
- /* REMOVE CLK TERM */
- hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
+ hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
+ HDMI_3D_TX_PHY_CPCE_CTRL);
+ hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
+ HDMI_3D_TX_PHY_GMPCTRL);
+ hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
+ HDMI_3D_TX_PHY_CURRCTRL);
+
+ hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
+ hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
+ HDMI_3D_TX_PHY_MSM_CTRL);
+
+ hdmi_phy_i2c_write(hdmi, phy_config->term, HDMI_3D_TX_PHY_TXTERM);
+ hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr,
+ HDMI_3D_TX_PHY_CKSYMTXCTRL);
+ hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr,
+ HDMI_3D_TX_PHY_VLEVCTRL);
+
+ /* Override and disable clock termination. */
+ hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
+ HDMI_3D_TX_PHY_CKCALCTRL);
dw_hdmi_phy_enable_powerdown(hdmi, false);
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h
b/drivers/gpu/drm/bridge/dw-hdmi.h index a4fd64a203c9..f3c149c88d71
100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -1085,4 +1085,70 @@ enum {
HDMI_I2CM_CTLINT_ARB_MASK = 0x4,
};
+/*
+ * HDMI 3D TX PHY registers
+ */
Why is there 3D related words？
The register names come from the i.MX6 datasheet. I don't have access to any
PHY datasheet from Synopsys, and the Rockchip RK3288 manuals I've been able to
find don't document the HDMI PHY register. As the PHY used by i.MX6 is a "DWC
HDMI 3D TX PHY", I'd used that name in the code.
The "DWC MHL PHY" used by RK3288 seems to be use a similar (if not identical)
registers map, at least for the registers configured by the driver. The "DWC
HDMI 2.0 TX PHY" PHY used by R-Car Gen3, however, seems not to have a
compatible register interface, except for the HDMI_3D_TX_PHY_PTRPT_ENBL
register.
I'm open to suggestions for a better naming scheme. If you have additional
information that I don't have access to, please feel free to use them to
propose improvements or to point out my mistakes :-)
I did not find "3D" words in PHY IP vendor document.
How is the PHY named in the documentation you have access to ?
just remove 3D word，such as name HDMI_TX_PHY_PWRCTRL instead of
HDMI_3D_TX_PHY_PWRCTRL
in doc: HDMI Tx PHY for GLOBAL FOUNDRIES 28-nm SLP/1.8 V Databook,
LCA Edition
11.1 Control Registers Module Design Architecture
+#define HDMI_3D_TX_PHY_PWRCTRL 0x00
+#define HDMI_3D_TX_PHY_SERDIVCTRL 0x01
+#define HDMI_3D_TX_PHY_SERCKCTRL 0x02
+#define HDMI_3D_TX_PHY_SERCKKILLCTRL 0x03
+#define HDMI_3D_TX_PHY_TXRESCTRL 0x04
+#define HDMI_3D_TX_PHY_CKCALCTRL 0x05
+#define HDMI_3D_TX_PHY_CPCE_CTRL 0x06
+#define HDMI_3D_TX_PHY_TXCLKMEASCTRL 0x07
+#define HDMI_3D_TX_PHY_TXMEASCTRL 0x08
+#define HDMI_3D_TX_PHY_CKSYMTXCTRL 0x09
+#define HDMI_3D_TX_PHY_CMPSEQCTRL 0x0a
+#define HDMI_3D_TX_PHY_CMPPWRCTRL 0x0b
+#define HDMI_3D_TX_PHY_CMPMODECTRL 0x0c
+#define HDMI_3D_TX_PHY_MEASCTRL0x0d
+#define HDMI_3D_TX_PHY_VLEVCTRL0x0e
+#define HDMI_3D_TX_PHY_D2ACTRL
[bug report] drm: Use atomic state for FB in legacy ioctls
Hello Daniel Stone,
This is a semi-automatic email about new static checker warnings.
The patch de7b6be7f300: "drm: Use atomic state for FB in legacy
ioctls" from Dec 13, 2016, leads to the following Smatch complaint:
drivers/gpu/drm/drm_crtc.c:392 drm_mode_getcrtc()
error: we previously assumed 'crtc->primary->state' could be null (see
line 384)
drivers/gpu/drm/drm_crtc.c
383
384 if (crtc->primary->state && crtc->primary->state->fb)
New check for NULL.
385 crtc_resp->fb_id = crtc->primary->state->fb->base.id;
386 else if (!crtc->primary->state && crtc->primary->fb)
387 crtc_resp->fb_id = crtc->primary->fb->base.id;
388 else
389 crtc_resp->fb_id = 0;
390
391 if (crtc->state) {
392 crtc_resp->x = crtc->primary->state->src_x >> 16;
^^^
Old unchecked dereference. It's possible that non-NULL "crtc->state"
implies a non-NULL "crtc->primary->state", but I didn't spot the
relationship immediately.
393 crtc_resp->y = crtc->primary->state->src_y >> 16;
394 if (crtc->state->enable) {
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 2/4] xf86drm: Add USB support
> From: Thierry Reding
> Date: Thu, 12 Jan 2017 23:04:27 +0100
>
> Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
> infrastructure.
>
> v2:
> - make sysfs_uevent_get() more flexible using a format string
>
> Signed-off-by: Thierry Reding
All this sysfs parsing stuff is highly Linux-specific and should
probably be #ifdef __linux__. Returning -EINVAL on non-Linux
platforms for usb and host1x should be fine.
Cheers,
Mark
> ---
> xf86drm.c | 163
> ++
> xf86drm.h | 13 +
> 2 files changed, 176 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index c123650a1e23..27cd6eb5193e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2906,6 +2906,9 @@ static int drmParseSubsystemType(int maj, int min)
> if (strncmp(name, "/pci", 4) == 0)
> return DRM_BUS_PCI;
>
> +if (strncmp(name, "/usb", 4) == 0)
> +return DRM_BUS_USB;
> +
> return -EINVAL;
> #elif defined(__OpenBSD__)
> return DRM_BUS_PCI;
> @@ -2992,6 +2995,10 @@ static int drmCompareBusInfo(drmDevicePtr a,
> drmDevicePtr b)
> switch (a->bustype) {
> case DRM_BUS_PCI:
> return memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo));
> +
> +case DRM_BUS_USB:
> +return memcmp(a->businfo.usb, b->businfo.usb, sizeof(drmUsbBusInfo));
> +
> default:
> break;
> }
> @@ -3235,6 +3242,145 @@ free_device:
> return ret;
> }
>
> +static char * DRM_PRINTFLIKE(2, 3)
> +sysfs_uevent_get(const char *path, const char *fmt, ...)
> +{
> +char filename[PATH_MAX + 1], *key, *line = NULL, *value = NULL;
> +size_t size = 0, len;
> +ssize_t num;
> +va_list ap;
> +FILE *fp;
> +
> +va_start(ap, fmt);
> +num = vasprintf(&key, fmt, ap);
> +va_end(ap);
> +len = num;
> +
> +snprintf(filename, sizeof(filename), "%s/uevent", path);
> +
> +fp = fopen(filename, "r");
> +if (!fp) {
> +free(key);
> +return NULL;
> +}
> +
> +while ((num = getline(&line, &size, fp)) >= 0) {
> +if ((strncmp(line, key, len) == 0) && (line[len] == '=')) {
> +char *start = line + len + 1, *end = line + num - 1;
> +
> +if (*end != '\n')
> +end++;
> +
> +value = strndup(start, end - start);
> +break;
> +}
> +}
> +
> +free(line);
> +fclose(fp);
> +
> +free(key);
> +
> +return value;
> +}
> +
> +static int drmParseUsbBusInfo(int maj, int min, drmUsbBusInfoPtr info)
> +{
> +char path[PATH_MAX + 1], *value;
> +unsigned int bus, dev;
> +int ret;
> +
> +snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
> +
> +value = sysfs_uevent_get(path, "BUSNUM");
> +if (!value)
> +return -ENOENT;
> +
> +ret = sscanf(value, "%03u", &bus);
> +free(value);
> +
> +if (ret <= 0)
> +return -errno;
> +
> +value = sysfs_uevent_get(path, "DEVNUM");
> +if (!value)
> +return -ENOENT;
> +
> +ret = sscanf(value, "%03u", &dev);
> +free(value);
> +
> +if (ret <= 0)
> +return -errno;
> +
> +info->bus = bus;
> +info->dev = dev;
> +
> +return 0;
> +}
> +
> +static int drmParseUsbDeviceInfo(int maj, int min, drmUsbDeviceInfoPtr info)
> +{
> +char path[PATH_MAX + 1], *value;
> +unsigned int vendor, product;
> +int ret;
> +
> +snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
> +
> +value = sysfs_uevent_get(path, "PRODUCT");
> +if (!value)
> +return -ENOENT;
> +
> +ret = sscanf(value, "%x/%x", &vendor, &product);
> +free(value);
> +
> +if (ret <= 0)
> +return -errno;
> +
> +info->vendor = vendor;
> +info->product = product;
> +
> +return 0;
> +}
> +
> +static int drmProcessUsbDevice(drmDevicePtr *device, const char *node,
> + int node_type, int maj, int min,
> + bool fetch_deviceinfo, uint32_t flags)
> +{
> +drmDevicePtr dev;
> +char *ptr;
> +int ret;
> +
> +dev = drmDeviceAlloc(node_type, node, sizeof(drmUsbBusInfo),
> + sizeof(drmUsbDeviceInfo), &ptr);
> +if (!dev)
> +return -ENOMEM;
> +
> +dev->bustype = DRM_BUS_USB;
> +
> +dev->businfo.usb = (drmUsbBusInfoPtr)ptr;
> +
> +ret = drmParseUsbBusInfo(maj, min, dev->businfo.usb);
> +if (ret < 0)
> +goto free_device;
> +
> +if (fetch_deviceinfo) {
> +ptr += sizeof(drmUsbBusInfo);
> +dev->deviceinfo.usb = (drmUsbDeviceInfoPtr)ptr;
> +
> +ret = drmParseUsbDeviceInfo(maj, min, dev->deviceinfo.usb);
> +if (ret < 0)
> +goto free_device;
> +}
> +
> +*device = dev;
> +
> +return 0;
> +
> +free_device:
> +free(dev);
> +return ret;
> +}
> +
> /* Consider devices located on the same bus as duplicate and fold the
> respective
> * entries into a single on
Re: [PATCH libdrm] xf86drm: fix valgrind warning in drmParsePciBusInfo
On Thu, 2017-01-12 at 18:16 -0800, Nicholas Miell wrote:
> From 714d07f600db39498c87d7816f4dd3a7e6d9bbca Mon Sep 17 00:00:00 2001
> From: Nicholas Miell
> Date: Thu, 12 Jan 2017 15:43:07 -0800
> Subject: [PATCH libdrm] xf86drm: fix valgrind warning in drmParsePciBusInfo
>
> The current implementation reads (up to) 513 bytes, overwrites the 513th
> byte with '\0' and then passes the buffer off to strstr() and sscanf()
> without ever initializing the middle bytes. This causes valgrind
> warnings and potentially fails to parse PCI_SLOT_NAME if the uevent is
> unexpectedly large.
a simpler fix should also get rid of the valgrind warning:
- ret = read(fd, data, sizeof(data));
- data[sizeof(data)-1] = '\0';
+ ret = read(fd, data, sizeof(data) - 1);
close(fd);
if (ret < 0)
return -errno
+ data[ret] = '\0';
I think that dynamic memory allocation is still a more robust approach.
regards,
Jan
>
> Rewrite it using getline() to fix the valgrind errors and future-proof
> the function against uevent files larger than 513 bytes.
>
> Signed-off-by: Nicholas Miell
> ---
> xf86drm.c | 34 +-
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index b8b2cfe..33261ac 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2919,31 +2919,31 @@ static int drmParsePciBusInfo(int maj, int min,
> drmPciBusInfoPtr info)
> {
> #ifdef __linux__
> char path[PATH_MAX + 1];
> -char data[512 + 1];
> -char *str;
> +FILE *uevent;
> +char *line = NULL;
> +size_t n = 0;
> +bool found = false;
> int domain, bus, dev, func;
> -int fd, ret;
>
> snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/uevent", maj, min);
> -fd = open(path, O_RDONLY);
> -if (fd < 0)
> +uevent = fopen(path, "r");
> +if (uevent == NULL)
> return -errno;
>
> -ret = read(fd, data, sizeof(data));
> -data[sizeof(data)-1] = '\0';
> -close(fd);
> -if (ret < 0)
> -return -errno;
> +while (getline(&line, &n, uevent) != -1) {
> +if (sscanf(line, "PCI_SLOT_NAME=%04x:%02x:%02x.%1u",
> + &domain, &bus, &dev, &func) == 4)
> +{
> + found = true;
> + break;
> +}
> +}
> +free(line);
>
> -#define TAG "PCI_SLOT_NAME="
> -str = strstr(data, TAG);
> -if (str == NULL)
> -return -EINVAL;
> +fclose(uevent);
>
> -if (sscanf(str, TAG "%04x:%02x:%02x.%1u",
> - &domain, &bus, &dev, &func) != 4)
> +if (!found)
> return -EINVAL;
> -#undef TAG
>
> info->domain = domain;
> info->bus = bus;
--
Jan Vesely
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
[Bug 98025] [radeonsi] incorrect primitive restart index used
https://bugs.freedesktop.org/show_bug.cgi?id=98025 James Legg changed: What|Removed |Added Status|RESOLVED|VERIFIED -- 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 5/6] drm/ttm: revert "implement LRU add callbacks v2"
From: Christian König
The additional housekeeping had to much CPU overhead,
let's use the BO priorities instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
drivers/gpu/drm/ast/ast_ttm.c | 2 --
drivers/gpu/drm/bochs/bochs_mm.c| 2 --
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 --
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 --
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 --
drivers/gpu/drm/qxl/qxl_ttm.c | 2 --
drivers/gpu/drm/radeon/radeon_ttm.c | 2 --
drivers/gpu/drm/ttm/ttm_bo.c| 19 +--
drivers/gpu/drm/virtio/virtgpu_ttm.c| 2 --
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 2 --
include/drm/ttm/ttm_bo_driver.h | 9 -
12 files changed, 5 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dd086d8..0402a11 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1086,8 +1086,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_free = &amdgpu_ttm_io_mem_free,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int amdgpu_ttm_init(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 2a1368f..50c910e 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -236,8 +236,6 @@ struct ttm_bo_driver ast_bo_driver = {
.verify_access = ast_bo_verify_access,
.io_mem_reserve = &ast_ttm_io_mem_reserve,
.io_mem_free = &ast_ttm_io_mem_free,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int ast_mm_init(struct ast_private *ast)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 099a3c6..e4c1125 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -205,8 +205,6 @@ struct ttm_bo_driver bochs_bo_driver = {
.verify_access = bochs_bo_verify_access,
.io_mem_reserve = &bochs_ttm_io_mem_reserve,
.io_mem_free = &bochs_ttm_io_mem_free,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int bochs_mm_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index d6da848..f53aa8f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -236,8 +236,6 @@ struct ttm_bo_driver cirrus_bo_driver = {
.verify_access = cirrus_bo_verify_access,
.io_mem_reserve = &cirrus_ttm_io_mem_reserve,
.io_mem_free = &cirrus_ttm_io_mem_free,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int cirrus_mm_init(struct cirrus_device *cirrus)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 5e20220..657598b 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -236,8 +236,6 @@ struct ttm_bo_driver mgag200_bo_driver = {
.verify_access = mgag200_bo_verify_access,
.io_mem_reserve = &mgag200_ttm_io_mem_reserve,
.io_mem_free = &mgag200_ttm_io_mem_free,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int mgag200_mm_init(struct mga_device *mdev)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5b0a28b..3949a74 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1570,8 +1570,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
.fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
struct nvkm_vma *
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index f3939a9..2955f91 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -395,8 +395,6 @@ static struct ttm_bo_driver qxl_bo_driver = {
.io_mem_reserve = &qxl_ttm_io_mem_reserve,
.io_mem_free = &qxl_ttm_io_mem_free,
.move_notify = &qxl_bo_move_notify,
- .lru_tail = &ttm_bo_default_lru_tail,
- .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int qxl_ttm_init(struct qxl_device *qdev)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 0cf03cc..d610481 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -871,8 +871,6 @@ stati
[PATCH 4/6] drm/amdgpu: double the priority of kernel allocations
From: Christian König Give kernel allocations a higher priority cause it is often more work to swap them back in. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index f399d98..2de1dda 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -387,6 +387,8 @@ int amdgpu_bo_create_restricted(struct amdgpu_device *adev, return r; bo->tbo.priority = ilog2(bo->tbo.num_pages); + if (kernel) + bo->tbo.priority *= 2; bo->tbo.priority = min(bo->tbo.priority, TTM_MAX_BO_PRIORITY - 1); if (flags & AMDGPU_GEM_CREATE_VRAM_CLEARED && -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/ttm: revert "add optional LRU removal callback v2"
From: Christian König
Without the custom LRU management the callback is not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 12 +---
include/drm/ttm/ttm_bo_driver.h | 6 --
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 59fac2f..dfaeac4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -186,12 +186,8 @@ EXPORT_SYMBOL(ttm_bo_add_to_lru);
int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
- struct ttm_bo_device *bdev = bo->bdev;
int put_count = 0;
- if (bdev->driver->lru_removal)
- bdev->driver->lru_removal(bo);
-
if (!list_empty(&bo->swap)) {
list_del_init(&bo->swap);
++put_count;
@@ -201,6 +197,11 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
++put_count;
}
+ /*
+* TODO: Add a driver hook to delete from
+* driver-specific LRU's here.
+*/
+
return put_count;
}
@@ -234,9 +235,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
lockdep_assert_held(&bo->resv->lock.base);
- if (bdev->driver->lru_removal)
- bdev->driver->lru_removal(bo);
-
put_count = ttm_bo_del_from_lru(bo);
ttm_bo_list_ref_sub(bo, put_count, true);
ttm_bo_add_to_lru(bo);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index a1235fa..4395db1 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -462,12 +462,6 @@ struct ttm_bo_driver {
struct ttm_mem_reg *mem);
void (*io_mem_free)(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem);
-
- /**
-* Optional driver callback for when BO is removed from the LRU.
-* Called with LRU lock held immediately before the removal.
-*/
- void (*lru_removal)(struct ttm_buffer_object *bo);
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
amdgpu: fix performance drop
Hi Roger, as promised the proper fix for the performance drop during command submission. Please test the attached set of patches with your OpenCL test case. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/ttm: add BO priorities for the LRUs
From: Christian König
This way the driver can specify a priority for a BO which has the effect that
a BO is only evicted when all other BOs with a lower priority are evicted
first.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo.c| 67 ++---
include/drm/ttm/ttm_bo_api.h| 2 +
include/drm/ttm/ttm_bo_driver.h | 6 ++-
4 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0717dd1..0a61930 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1166,8 +1166,8 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
struct amdgpu_mman_lru *lru = &adev->mman.log2_size[i];
for (j = 0; j < TTM_NUM_MEM_TYPES; ++j)
- lru->lru[j] = &adev->mman.bdev.man[j].lru;
- lru->swap_lru = &adev->mman.bdev.glob->swap_lru;
+ lru->lru[j] = &adev->mman.bdev.man[j].lru[0];
+ lru->swap_lru = &adev->mman.bdev.glob->swap_lru[0];
}
for (j = 0; j < TTM_NUM_MEM_TYPES; ++j)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6683399..f078b43 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -242,13 +242,13 @@ EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
struct list_head *ttm_bo_default_lru_tail(struct ttm_buffer_object *bo)
{
- return bo->bdev->man[bo->mem.mem_type].lru.prev;
+ return bo->bdev->man[bo->mem.mem_type].lru[bo->priority].prev;
}
EXPORT_SYMBOL(ttm_bo_default_lru_tail);
struct list_head *ttm_bo_default_swap_lru_tail(struct ttm_buffer_object *bo)
{
- return bo->glob->swap_lru.prev;
+ return bo->glob->swap_lru[bo->priority].prev;
}
EXPORT_SYMBOL(ttm_bo_default_swap_lru_tail);
@@ -741,20 +741,27 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_buffer_object *bo;
int ret = -EBUSY, put_count;
+ unsigned i;
spin_lock(&glob->lru_lock);
- list_for_each_entry(bo, &man->lru, lru) {
- ret = __ttm_bo_reserve(bo, false, true, NULL);
- if (ret)
- continue;
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ list_for_each_entry(bo, &man->lru[i], lru) {
+ ret = __ttm_bo_reserve(bo, false, true, NULL);
+ if (ret)
+ continue;
- if (place && !bdev->driver->eviction_valuable(bo, place)) {
- __ttm_bo_unreserve(bo);
- ret = -EBUSY;
- continue;
+ if (place && !bdev->driver->eviction_valuable(bo,
+ place)) {
+ __ttm_bo_unreserve(bo);
+ ret = -EBUSY;
+ continue;
+ }
+
+ break;
}
- break;
+ if (!ret)
+ break;
}
if (ret) {
@@ -1197,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
}
atomic_inc(&bo->glob->bo_count);
drm_vma_node_reset(&bo->vma_node);
+ bo->priority = 0;
/*
* For ttm_bo_type_device buffers, allocate
@@ -1297,18 +1305,21 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
struct ttm_bo_global *glob = bdev->glob;
struct fence *fence;
int ret;
+ unsigned i;
/*
* Can't use standard list traversal since we're unlocking.
*/
spin_lock(&glob->lru_lock);
- while (!list_empty(&man->lru)) {
- spin_unlock(&glob->lru_lock);
- ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
- if (ret)
- return ret;
- spin_lock(&glob->lru_lock);
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ while (!list_empty(&man->lru[i])) {
+ spin_unlock(&glob->lru_lock);
+ ret = ttm_mem_evict_first(bdev, mem_type, NULL, false,
false);
+ if (ret)
+ return ret;
+ spin_lock(&glob->lru_lock);
+ }
}
spin_unlock(&glob->lru_lock);
@@ -1385,6 +1396,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
{
int ret = -EINVAL;
struct ttm_mem_type_manager *man;
+ unsigned i;
BUG_ON(type >= TTM_NUM_MEM_TYPES);
man = &bdev->man[type];
@@ -1410,7 +1422,8 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
[PATCH 1/6] drm/ttm: remove allow_errors parameter from ttm_bo_force_list_clean
From: Christian König
Not allowing errors here is completely pointless and actually dangerous
cause trying to continue on an error can cause an endless loop.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b5038c5..6683399 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1291,7 +1291,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
EXPORT_SYMBOL(ttm_bo_create);
static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
- unsigned mem_type, bool allow_errors)
+ unsigned mem_type)
{
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
@@ -1306,13 +1306,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
while (!list_empty(&man->lru)) {
spin_unlock(&glob->lru_lock);
ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
- if (ret) {
- if (allow_errors) {
- return ret;
- } else {
- pr_err("Cleanup eviction failed\n");
- }
- }
+ if (ret)
+ return ret;
spin_lock(&glob->lru_lock);
}
spin_unlock(&glob->lru_lock);
@@ -1324,13 +1319,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
if (fence) {
ret = fence_wait(fence, false);
fence_put(fence);
- if (ret) {
- if (allow_errors) {
- return ret;
- } else {
- pr_err("Cleanup eviction failed\n");
- }
- }
+ if (ret)
+ return ret;
}
return 0;
@@ -1359,7 +1349,11 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned
mem_type)
ret = 0;
if (mem_type > 0) {
- ttm_bo_force_list_clean(bdev, mem_type, false);
+ ret = ttm_bo_force_list_clean(bdev, mem_type);
+ if (ret) {
+ pr_err("Cleanup eviction failed\n");
+ return ret;
+ }
ret = (*man->func->takedown)(man);
}
@@ -1382,7 +1376,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned
mem_type)
return 0;
}
- return ttm_bo_force_list_clean(bdev, mem_type, true);
+ return ttm_bo_force_list_clean(bdev, mem_type);
}
EXPORT_SYMBOL(ttm_bo_evict_mm);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/amdgpu: user BO priority instead of self coding it
From: Christian König
Keeping groups of BOs on the LRU is to time consuming on command submission.
Instead use the newly added BO priority to give a certain eviction order.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 69 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 12 --
3 files changed, 5 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 5076bc2..f399d98 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -386,6 +386,9 @@ int amdgpu_bo_create_restricted(struct amdgpu_device *adev,
if (unlikely(r != 0))
return r;
+ bo->tbo.priority = ilog2(bo->tbo.num_pages);
+ bo->tbo.priority = min(bo->tbo.priority, TTM_MAX_BO_PRIORITY - 1);
+
if (flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct fence *fence;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0a61930..dd086d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1048,56 +1048,6 @@ uint32_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
return flags;
}
-static void amdgpu_ttm_lru_removal(struct ttm_buffer_object *tbo)
-{
- struct amdgpu_device *adev = amdgpu_ttm_adev(tbo->bdev);
- unsigned i, j;
-
- for (i = 0; i < AMDGPU_TTM_LRU_SIZE; ++i) {
- struct amdgpu_mman_lru *lru = &adev->mman.log2_size[i];
-
- for (j = 0; j < TTM_NUM_MEM_TYPES; ++j)
- if (&tbo->lru == lru->lru[j])
- lru->lru[j] = tbo->lru.prev;
-
- if (&tbo->swap == lru->swap_lru)
- lru->swap_lru = tbo->swap.prev;
- }
-}
-
-static struct amdgpu_mman_lru *amdgpu_ttm_lru(struct ttm_buffer_object *tbo)
-{
- struct amdgpu_device *adev = amdgpu_ttm_adev(tbo->bdev);
- unsigned log2_size = min(ilog2(tbo->num_pages),
-AMDGPU_TTM_LRU_SIZE - 1);
-
- return &adev->mman.log2_size[log2_size];
-}
-
-static struct list_head *amdgpu_ttm_lru_tail(struct ttm_buffer_object *tbo)
-{
- struct amdgpu_mman_lru *lru = amdgpu_ttm_lru(tbo);
- struct list_head *res = lru->lru[tbo->mem.mem_type];
-
- lru->lru[tbo->mem.mem_type] = &tbo->lru;
- while ((++lru)->lru[tbo->mem.mem_type] == res)
- lru->lru[tbo->mem.mem_type] = &tbo->lru;
-
- return res;
-}
-
-static struct list_head *amdgpu_ttm_swap_lru_tail(struct ttm_buffer_object
*tbo)
-{
- struct amdgpu_mman_lru *lru = amdgpu_ttm_lru(tbo);
- struct list_head *res = lru->swap_lru;
-
- lru->swap_lru = &tbo->swap;
- while ((++lru)->swap_lru == res)
- lru->swap_lru = &tbo->swap;
-
- return res;
-}
-
static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
@@ -1136,14 +1086,12 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_free = &amdgpu_ttm_io_mem_free,
- .lru_removal = &amdgpu_ttm_lru_removal,
- .lru_tail = &amdgpu_ttm_lru_tail,
- .swap_lru_tail = &amdgpu_ttm_swap_lru_tail,
+ .lru_tail = &ttm_bo_default_lru_tail,
+ .swap_lru_tail = &ttm_bo_default_swap_lru_tail,
};
int amdgpu_ttm_init(struct amdgpu_device *adev)
{
- unsigned i, j;
int r;
r = amdgpu_ttm_global_init(adev);
@@ -1161,19 +1109,6 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
}
-
- for (i = 0; i < AMDGPU_TTM_LRU_SIZE; ++i) {
- struct amdgpu_mman_lru *lru = &adev->mman.log2_size[i];
-
- for (j = 0; j < TTM_NUM_MEM_TYPES; ++j)
- lru->lru[j] = &adev->mman.bdev.man[j].lru[0];
- lru->swap_lru = &adev->mman.bdev.glob->swap_lru[0];
- }
-
- for (j = 0; j < TTM_NUM_MEM_TYPES; ++j)
- adev->mman.guard.lru[j] = NULL;
- adev->mman.guard.swap_lru = NULL;
-
adev->mman.initialized = true;
r = ttm_bo_init_mm(&adev->mman.bdev, TTM_PL_VRAM,
adev->mc.real_vram_size >> PAGE_SHIFT);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index d1c00c0..0eabbb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -34,13 +34,6 @@
#define AMDGPU_PL_FLAG_GWS (TTM_PL_FLAG_PRIV << 1)
#define AMDGP
[Bug 99143] r9 390: Hardware cursor invisible after hibernate/resume
https://bugs.freedesktop.org/show_bug.cgi?id=99143 --- Comment #7 from Harald Judt --- After applying the patch to revert the commits, hw cursor works fine. Feel free to close as resolved. 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: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2
Hey, On 13 January 2017 at 09:37, Ville Syrjälä wrote: > On Thu, Jan 12, 2017 at 07:27:03PM +, Daniel Stone wrote: >> It would make sense, but then gbm_surface_create_with_modifiers takes >> a fixed pixel format and a list of acceptable modifiers (which to me >> seems like the right way around as an API), so whenever I was creating >> a surface, I'd have to walk through and create a new list, flipped >> back the other way. > > Yeah, for that your original order makes more sense, even if it > potentially uses more memory. Given the size of framebuffers, I'm really not concerned by the in-memory size of a format list. :) Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2
On Thu, Jan 12, 2017 at 07:27:03PM +, Daniel Stone wrote:
> Hi,
>
> On 12 January 2017 at 18:11, Ville Syrjälä
> wrote:
> > On Thu, Jan 12, 2017 at 05:50:15PM +, Daniel Stone wrote:
> >> struct drm_plane {
> >> struct {
> >> uint32_t format;
> >> uint64_t modifiers[];
> >> } formats[];
> >> }
> >
> > Flipping formats[] vs. modifiers[] here would seem like it should make
> > this easier with the proposed kernel API. And if the kernel will also
> > uarantee that multiple instances of the same modifier must be returned
> > contiguously, then it should be even easier.
> >
> > Oh and flipping formats[] and modifiers[] should also save a quite a
> > bit of space since each format takes twice as much space as each
> > modifier. But I suppose that might come at a runtime cost if you have
> > to look for a specific format in each modifier's format list instead
> > of having to look at just the modifier list of a specific format. So
> > I suppose not flipping might be better after all, which I guess would
> > complicate populating the infromation somewhat.
> >
> > Anyways, that's all a bit unrelated to the matter at hand, so I'll stop
> > now and just state that I don't mind having an explicit offset if
> > people really want it.
>
> It would make sense, but then gbm_surface_create_with_modifiers takes
> a fixed pixel format and a list of acceptable modifiers (which to me
> seems like the right way around as an API), so whenever I was creating
> a surface, I'd have to walk through and create a new list, flipped
> back the other way.
Yeah, for that your original order makes more sense, even if it
potentially uses more memory.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel
On Thu, Jan 12, 2017 at 10:56:17AM -0800, Ben Widawsky wrote:
> On 17-01-12 20:32:07, Ville Syrjälä wrote:
> >On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:
> >> On 17-01-12 12:51:20, Ville Syrjälä wrote:
> >> >On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> >> >> This was based on a patch originally by Kristian. It has been modified
> >> >> pretty heavily to use the new callbacks from the previous patch.
> >> >>
> >> >> Cc: Kristian H. Kristensen
> >> >> Signed-off-by: Ben Widawsky
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_display.c | 109
> >> >> ++-
> >> >> drivers/gpu/drm/i915/intel_sprite.c | 33 ++-
> >> >> 2 files changed, 137 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> >> b/drivers/gpu/drm/i915/intel_display.c
> >> >> index 8715b1083d1d..26f3a911b999 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> >> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
> >> >> DRM_FORMAT_XRGB,
> >> >> };
> >> >>
> >> >> +static const uint64_t i8xx_format_modifiers[] = {
> >> >> + I915_FORMAT_MOD_X_TILED,
> >> >
> >> >Did we want to list the linear modifier in these as well?
> >> >
> >>
> >> Yeah. My initial response was no, but yes. We should. I was using
> >> DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be
> >> defined
> >> in the array.
> >>
> >> >> + DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >> +
> >> >> /* Primary plane formats for gen >= 4 */
> >> >> static const uint32_t i965_primary_formats[] = {
> >> >> DRM_FORMAT_C8,
> >> >> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
> >> >> DRM_FORMAT_XBGR2101010,
> >> >> };
> >> >>
> >> >> +static const uint64_t i965_format_modifiers[] = {
> >> >> + I915_FORMAT_MOD_X_TILED,
> >> >> + DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >
> >> >We could just share the i8xx array. The name of the array should perhaps
> >> >be i9xx_format_modifiers[] in that case. That's sort of the naming
> >> >convention we've been left with for things that apply to more or less
> >> >all the platforms.
> >> >
> >>
> >> Got it thanks. This is a relic from Kristian's original patch which tied
> >> the
> >> modifiers to the formats in place. It made more sense there to have a
> >> separate
> >> i8xx
> >>
> >> >> +
> >> >> static const uint32_t skl_primary_formats[] = {
> >> >> DRM_FORMAT_C8,
> >> >> DRM_FORMAT_RGB565,
> >> >> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
> >> >> DRM_FORMAT_VYUY,
> >> >> };
> >> >>
> >> >> +static const uint64_t skl_format_modifiers[] = {
> >> >> + I915_FORMAT_MOD_Y_TILED,
> >> >
> >> >Yf missing? and linear
> >> >
> >>
> >> Yes, thanks. I'm kind of scared to add Yf to be honest :P
> >>
> >> >> + I915_FORMAT_MOD_X_TILED,
> >> >> + DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >> +
> >> >> /* Cursor formats */
> >> >> static const uint32_t intel_cursor_formats[] = {
> >> >> DRM_FORMAT_ARGB,
> >> >> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane
> >> >> *plane)
> >> >> kfree(to_intel_plane(plane));
> >> >> }
> >> >>
> >> >> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> + if (modifier == DRM_FORMAT_MOD_NONE)
> >> >> + return true;
> >> >> +
> >> >> + switch (format) {
> >> >> + case DRM_FORMAT_C8:
> >> >> + case DRM_FORMAT_RGB565:
> >> >> + case DRM_FORMAT_XRGB1555:
> >> >> + case DRM_FORMAT_XRGB:
> >> >> + return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> + default:
> >> >> + return false;
> >> >> + }
> >> >> +}
> >> >> +
> >> >> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> + switch (format) {
> >> >> + case DRM_FORMAT_C8:
> >> >> + case DRM_FORMAT_RGB565:
> >> >> + case DRM_FORMAT_XRGB:
> >> >> + case DRM_FORMAT_XBGR:
> >> >> + case DRM_FORMAT_XRGB2101010:
> >> >> + case DRM_FORMAT_XBGR2101010:
> >> >> + return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> + default:
> >> >> + return false;
> >> >> + }
> >> >> +}
> >> >
> >> >Hmm. There should be no format vs. tiling restrictions on these
> >> >platforms, so presumably a simple "return true" should cover it all.
> >> >That does perhaps remove the usefulness of these functions for
> >> >verifying that the format or modifier is supported at all
> >>
> >> One of the reasons for changing to this current format-modifier lookup at
> >> all
> >> was Kristian's approach was considered fragile. If for whatever reason
> >> formats
> >> are added, or removed, we'll catch it here. Also, it maybe let's us do
> >> something
> >> on cursor plane at
Re: [PATCH v3] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
2017년 01월 13일 18:20에 Andrzej Hajda 이(가) 쓴 글:
> STANDALONE_UPDATE_F should be set if something changed in plane
> configurations,
> including plane disable.
> The patch fixes page-faults bugs, caused by decon still using framebuffers
> of disabled planes.
Excellent! Applied and this patch will go to -fixes with below another one[1],
[1] [PATCH] drm/exynos/decon5433: update shadow registers iff there are active
windows
Thanks.
>
> Signed-off-by: Andrzej Hajda
> Tested-by: Joonyoung Shim
> ---
> v2: fixed clear-bit code (Thx Marek)
> v3: use test_and_clear_bit (Thx Joonyoung)
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index ef7fcb5..09e8cc3 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -46,7 +46,8 @@ enum decon_flag_bits {
> BIT_CLKS_ENABLED,
> BIT_IRQS_ENABLED,
> BIT_WIN_UPDATED,
> - BIT_SUSPENDED
> + BIT_SUSPENDED,
> + BIT_REQUEST_UPDATE
> };
>
> struct decon_context {
> @@ -313,6 +314,7 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
>
> /* window enable */
> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
> + set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
> }
>
> static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -325,6 +327,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
> *crtc,
> return;
>
> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
> + set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
> }
>
> static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
> @@ -338,8 +341,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc
> *crtc)
> for (i = ctx->first_win; i < WINDOWS_NR; i++)
> decon_shadow_protect_win(ctx, i, false);
>
> - /* update iff there are active windows */
> - if (crtc->base.state->plane_mask)
> + if (test_and_clear_bit(BIT_REQUEST_UPDATE, &ctx->flags))
> decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>
> if (ctx->out_type & IFTYPE_I80)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
STANDALONE_UPDATE_F should be set if something changed in plane configurations,
including plane disable.
The patch fixes page-faults bugs, caused by decon still using framebuffers
of disabled planes.
Signed-off-by: Andrzej Hajda
Tested-by: Joonyoung Shim
---
v2: fixed clear-bit code (Thx Marek)
v3: use test_and_clear_bit (Thx Joonyoung)
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index ef7fcb5..09e8cc3 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -46,7 +46,8 @@ enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
- BIT_SUSPENDED
+ BIT_SUSPENDED,
+ BIT_REQUEST_UPDATE
};
struct decon_context {
@@ -313,6 +314,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -325,6 +327,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
*crtc,
return;
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
@@ -338,8 +341,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);
- /* update iff there are active windows */
- if (crtc->base.state->plane_mask)
+ if (test_and_clear_bit(BIT_REQUEST_UPDATE, &ctx->flags))
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
if (ctx->out_type & IFTYPE_I80)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
Hi Andrzej,
On 01/13/2017 05:42 PM, Andrzej Hajda wrote:
> @@ -339,8 +342,10 @@ static void decon_atomic_flush(struct exynos_drm_crtc
> *crtc)
> decon_shadow_protect_win(ctx, i, false);
>
> /* update iff there are active windows */
> - if (crtc->base.state->plane_mask)
> + if (test_bit(BIT_REQUEST_UPDATE, &ctx->flags)) {
It's better to just use test_and_clear_bit?
> decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> + clear_bit(BIT_REQUEST_UPDATE, &ctx->flags);
> + }
>
> if (ctx->out_type & IFTYPE_I80)
> set_bit(BIT_WIN_UPDATED, &ctx->flags);
>
I tested on TM2E board,
Tested-by: Joonyoung Shim
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
On 13.01.2017 09:37, Joonyoung Shim wrote: > > There is no code to clear BIT_REQUEST_UPDATE, is it right? Marek has already pointed it out, v2 sent. Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
STANDALONE_UPDATE_F should be set if something changed in plane configurations,
including plane disable.
The patch fixes page-faults bugs, caused by decon still using framebuffers
of disabled planes.
Signed-off-by: Andrzej Hajda
---
v2: fixed clear-bit code (Thx Marek)
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index ef7fcb5..77a614d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -46,7 +46,8 @@ enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
- BIT_SUSPENDED
+ BIT_SUSPENDED,
+ BIT_REQUEST_UPDATE
};
struct decon_context {
@@ -313,6 +314,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -325,6 +327,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
*crtc,
return;
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
@@ -339,8 +342,10 @@ static void decon_atomic_flush(struct exynos_drm_crtc
*crtc)
decon_shadow_protect_win(ctx, i, false);
/* update iff there are active windows */
- if (crtc->base.state->plane_mask)
+ if (test_bit(BIT_REQUEST_UPDATE, &ctx->flags)) {
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
+ clear_bit(BIT_REQUEST_UPDATE, &ctx->flags);
+ }
if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, &ctx->flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
Hi Andrzej,
On 01/13/2017 05:10 PM, Andrzej Hajda wrote:
> STANDALONE_UPDATE_F should be set if something changed in plane
> configurations,
> including plane disable.
> The patch fixes page-faults bugs, caused by decon still using framebuffers
> of disabled planes.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index ef7fcb5..3999e88 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -46,7 +46,8 @@ enum decon_flag_bits {
> BIT_CLKS_ENABLED,
> BIT_IRQS_ENABLED,
> BIT_WIN_UPDATED,
> - BIT_SUSPENDED
> + BIT_SUSPENDED,
> + BIT_REQUEST_UPDATE
> };
>
> struct decon_context {
> @@ -313,6 +314,7 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
>
> /* window enable */
> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
> + set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
> }
>
> static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -325,6 +327,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
> *crtc,
> return;
>
> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
> + set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
> }
>
> static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
> @@ -339,8 +342,10 @@ static void decon_atomic_flush(struct exynos_drm_crtc
> *crtc)
> decon_shadow_protect_win(ctx, i, false);
>
> /* update iff there are active windows */
> - if (crtc->base.state->plane_mask)
> + if (test_bit(BIT_REQUEST_UPDATE, &ctx->flags)) {
> decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> + set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
> + }
There is no code to clear BIT_REQUEST_UPDATE, is it right?
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos: mic: Add runtime PM support
This patch adds runtime support calls to notify device core when MIC
device is really in use. Runtime PM is implemented by enabling and
disabling clocks like in other Exynos DRM subdrivers. Adding runtime
PM support is needed to let power domain with this device to be turned
off when display is not used.
Signed-off-by: Marek Szyprowski
---
Changelog:
v2:
- moved clock control to runtime PM callbacks as requested by Inki Dae
v1: http://www.spinics.net/lists/dri-devel/msg129095.html
- initial version
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 82 -
1 file changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0be6d65..430f67c63707 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -312,7 +313,6 @@ static void mic_disable(struct drm_bridge *bridge) { }
static void mic_post_disable(struct drm_bridge *bridge)
{
struct exynos_mic *mic = bridge->driver_private;
- int i;
mutex_lock(&mic_mutex);
if (!mic->enabled)
@@ -320,9 +320,7 @@ static void mic_post_disable(struct drm_bridge *bridge)
mic_set_path(mic, 0);
- for (i = NUM_CLKS - 1; i > -1; i--)
- clk_disable_unprepare(mic->clks[i]);
-
+ pm_runtime_put(mic->dev);
mic->enabled = 0;
already_disabled:
@@ -332,27 +330,22 @@ static void mic_post_disable(struct drm_bridge *bridge)
static void mic_pre_enable(struct drm_bridge *bridge)
{
struct exynos_mic *mic = bridge->driver_private;
- int ret, i;
+ int ret;
mutex_lock(&mic_mutex);
if (mic->enabled)
- goto already_enabled;
+ goto unlock;
- for (i = 0; i < NUM_CLKS; i++) {
- ret = clk_prepare_enable(mic->clks[i]);
- if (ret < 0) {
- DRM_ERROR("Failed to enable clock (%s)\n",
- clk_names[i]);
- goto turn_off_clks;
- }
- }
+ ret = pm_runtime_get_sync(mic->dev);
+ if (ret < 0)
+ goto unlock;
mic_set_path(mic, 1);
ret = mic_sw_reset(mic);
if (ret) {
DRM_ERROR("Failed to reset\n");
- goto turn_off_clks;
+ goto turn_off;
}
if (!mic->i80_mode)
@@ -365,10 +358,9 @@ static void mic_pre_enable(struct drm_bridge *bridge)
return;
-turn_off_clks:
- while (--i > -1)
- clk_disable_unprepare(mic->clks[i]);
-already_enabled:
+turn_off:
+ pm_runtime_put(mic->dev);
+unlock:
mutex_unlock(&mic_mutex);
}
@@ -401,14 +393,12 @@ static void exynos_mic_unbind(struct device *dev, struct
device *master,
void *data)
{
struct exynos_mic *mic = dev_get_drvdata(dev);
- int i;
mutex_lock(&mic_mutex);
if (!mic->enabled)
goto already_disabled;
- for (i = NUM_CLKS - 1; i > -1; i--)
- clk_disable_unprepare(mic->clks[i]);
+ pm_runtime_put(mic->dev);
already_disabled:
mutex_unlock(&mic_mutex);
@@ -421,6 +411,41 @@ static void exynos_mic_unbind(struct device *dev, struct
device *master,
.unbind = exynos_mic_unbind,
};
+#ifdef CONFIG_PM
+static int exynos_mic_suspend(struct device *dev)
+{
+ struct exynos_mic *mic = dev_get_drvdata(dev);
+ int i;
+
+ for (i = NUM_CLKS - 1; i > -1; i--)
+ clk_disable_unprepare(mic->clks[i]);
+
+ return 0;
+}
+
+static int exynos_mic_resume(struct device *dev)
+{
+ struct exynos_mic *mic = dev_get_drvdata(dev);
+ int ret, i;
+
+ for (i = 0; i < NUM_CLKS; i++) {
+ ret = clk_prepare_enable(mic->clks[i]);
+ if (ret < 0) {
+ DRM_ERROR("Failed to enable clock (%s)\n",
+ clk_names[i]);
+ while (--i > -1)
+ clk_disable_unprepare(mic->clks[i]);
+ return ret;
+ }
+ }
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_mic_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos_mic_suspend, exynos_mic_resume, NULL)
+};
+
static int exynos_mic_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -473,9 +498,18 @@ static int exynos_mic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mic);
+ pm_runtime_enable(dev);
+
+ ret = component_add(dev, &exynos_mic_component_ops);
+ if (ret)
+ goto err_pm;
+
DRM_DEBUG_KMS("MIC has been probed\n");
- return component_add(dev, &exynos_mic_component_ops);
+ return 0;
+
+err
[PULL] drm-misc-fixes
Hi Dave, As promised a few more core fixes. One more pending for the mst issue on driver load, but Dave Hansen didn't yet send in the tested-by, so I figured I'll hold that one off. cu in Hobart! Cheers, Daniel The following changes since commit 9afe69d5a9495f8b023017e4c328fa717e00f092: Merge tag 'drm-misc-fixes-2017-01-09' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-01-10 08:18:53 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-13 for you to fetch changes up to 3846fd9b86001bea171943cc3bb9222cb6da6b42: drm/probe-helpers: Drop locking from poll_enable (2017-01-12 20:31:17 +0100) Daniel Vetter (1): drm/probe-helpers: Drop locking from poll_enable Peter Ujfalusi (1): drm: Schedule the output_poll_work with 1s delay if we have delayed event Takashi Iwai (1): drm: Fix broken VT switch with video=1366x768 option drivers/gpu/drm/drm_modes.c | 7 drivers/gpu/drm/drm_probe_helper.c | 63 ++-- drivers/gpu/drm/i915/intel_hotplug.c | 4 +-- include/drm/drm_crtc_helper.h| 1 - 4 files changed, 40 insertions(+), 35 deletions(-) -- 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
[PATCH] drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
STANDALONE_UPDATE_F should be set if something changed in plane configurations,
including plane disable.
The patch fixes page-faults bugs, caused by decon still using framebuffers
of disabled planes.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index ef7fcb5..3999e88 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -46,7 +46,8 @@ enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
- BIT_SUSPENDED
+ BIT_SUSPENDED,
+ BIT_REQUEST_UPDATE
};
struct decon_context {
@@ -313,6 +314,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -325,6 +327,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
*crtc,
return;
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
@@ -339,8 +342,10 @@ static void decon_atomic_flush(struct exynos_drm_crtc
*crtc)
decon_shadow_protect_win(ctx, i, false);
/* update iff there are active windows */
- if (crtc->base.state->plane_mask)
+ if (test_bit(BIT_REQUEST_UPDATE, &ctx->flags)) {
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
+ set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
+ }
if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, &ctx->flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
