[PATCH v4 1/2] create SMAF module
n -EINVAL;
120
121 handle->is_secure = true;
122 return 0;
123 }
124
125 static int smaf_unsecure_handle(struct smaf_handle *handle)
126 {
127 if (!handle->is_secure)
128 return 0;
129
130 if (!smaf_dev.secure)
131 return -EINVAL;
132
133 if (!smaf_dev.secure->destroy_context)
134 return -EINVAL;
135
> 136 if (smaf_dev.secure->destroy_context(handle->secure_ctx))
137 return -EINVAL;
138
139 handle->secure_ctx = NULL;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 38491 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/ccebfb1e/attachment-0001.obj>
[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote: > + cec->adap = cec_create_adapter(&s5p_cec_adap_ops, cec, > + CEC_NAME, CEC_CAP_STATE | > + CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO | > + CEC_CAP_IS_SOURCE, > + 0, THIS_MODULE, &pdev->dev); > + ret = PTR_ERR_OR_ZERO(cec->adap); > + if (ret) > + return ret; > + cec->adap->available_log_addrs = 1; > + > + platform_set_drvdata(pdev, cec); > + pm_runtime_enable(dev); This is really not a good interface. "cec_create_adapter" creates and registers the adapter, at which point it becomes available to userspace. However, you haven't finished setting it up, so it's possible to nip in here and start using it before the setup has completed. This needs fixing. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] drm/gma500: fix double freeing
On Fri, Oct 2, 2015 at 5:56 PM, Sudip Mukherjee wrote: > On Thu, Oct 01, 2015 at 07:07:33PM +0200, Patrik Jakobsson wrote: >> On Wed, Sep 30, 2015 at 8:12 AM, Sudip Mukherjee >> wrote: >> > On Tue, Sep 29, 2015 at 03:20:35PM +0200, Patrik Jakobsson wrote: >> >> On Thu, Sep 24, 2015 at 5:57 PM, Sudip Mukherjee >> >> wrote: >> >> > On Wed, Sep 09, 2015 at 06:20:40PM +0530, Sudip Mukherjee wrote: >> >> >> If backing->stolen is true then we were freeing backing by calling >> >> >> psb_gtt_free_range() but we called it again after unlocking the mutex. >> >> >> Lets make it NULL after freeing in psb_gtt_free_range() and check for >> >> >> NULL before calling the function for the second time. >> >> >> >> >> >> Signed-off-by: Sudip Mukherjee >> >> >> --- >> >> > Hi Patrik, >> >> > A gentle ping. >> >> > >> >> > regards >> >> > sudip >> >> >> >> Hi, sorry for the late reply. >> >> >> >> Why are we freeing the range twice in the first case? >> > I think, >> > if backing->stolen is true then backing is released using >> > psb_gtt_free_range() but if backing->stolen is false then the gem object >> > is freed but the backing is not yet freed. To free that backing >> > psb_gtt_free_range() has been called second time. My patch tried to fix >> > the possibility of backing->stolen being true and backing being freed 2 >> > times. >> > >> > regards >> > sudip >> >> There are some special handling of the stolen framebuffer that I don't >> remember entirely but the basic concept is that we free the backing >> when we drop the last reference on a gem object. That will trigger a >> psb_gtt_free_range(). So in this case it looks to me that the extra >> free is not needed at all. That's my quick reasoning, feel free to >> prove me wrong :) > > In this case we are allocating backing using psbfb_alloc() and so > backing->stolen is always true. So we can remove the backing->stolen > condition. And if drm_fb_helper_alloc_fbi() fails then we > are jumping to out_err1. So the fitst free will not be needed. Sounds good, could you also rename the labels to what they're doing now. I'm thinking out_release and out_unlock or something you feel is suitable. Thanks Patrik > diff --git a/drivers/gpu/drm/gma500/framebuffer.c > b/drivers/gpu/drm/gma500/framebuffer.c > index 2eaf1b3..932f07b 100644 > --- a/drivers/gpu/drm/gma500/framebuffer.c > +++ b/drivers/gpu/drm/gma500/framebuffer.c > @@ -466,11 +466,6 @@ static int psbfb_create(struct psb_fbdev *fbdev, > mutex_unlock(&dev->struct_mutex); > return 0; > out_unref: > - if (backing->stolen) > - psb_gtt_free_range(dev, backing); > - else > - drm_gem_object_unreference(&backing->gem); > - > drm_fb_helper_release_fbi(&fbdev->psb_fb_helper); > out_err1: > mutex_unlock(&dev->struct_mutex); > > > If it is ok, I can submit the v2. > > regards > sudip
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #29 from Michel Dänzer --- That is interesting, though; the radeonsi driver seems to think there should be something mapped at the faulting address. This indicates that either the kernel driver fails to handle the mapping properly, or maybe there's a problem with communicating the buffer mapping information from userspace to the kernel driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/19b3edcf/attachment-0001.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #1 from Michel Dänzer --- Please attach the corresponding Xorg.0.log file and output of dmesg and glxinfo. Are the 32-bit Mesa binaries up to date? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/7912d718/attachment.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #1 from Michel Dänzer --- Please attach the corresponding Xorg.0.log file and output of dmesg and glxinfo. Are the 32-bit Mesa binaries up to date? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/6b72f932/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 Bug ID: 92309 Summary: Box drawn around cursor in multiple 3D games Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: acutiator at outlook.com QA Contact: dri-devel at lists.freedesktop.org When playing Legend of Grimrock or Natural Selection 2 on the radeonsi drivers on Cape Verde there is a box drawn around the cursor. This does not occur in other games such as Risk of Rain, Starbound, and Left 4 Dead 2. This is when running Mesa 11.1.0-devel on Fedora 22, git 9932142. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/e12f1107/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #1 from acutiator at outlook.com --- Created attachment 118696 --> https://bugs.freedesktop.org/attachment.cgi?id=118696&action=edit Natural Selection 2 cursor corruption -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/ee970b69/attachment-0001.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 acutiator at outlook.com changed: What|Removed |Added Attachment #118696|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/9f09ac85/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #2 from Michel Dänzer --- Reminds me of bug 91641, which turned out to be a game bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/a00035b0/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #3 from acutiator at outlook.com --- Indeed looks to be a game specific bug: http://www.grimrock.net/forum/viewtopic.php?f=12&t=4583 Should I just close this with a NOTOURBUG or what's the procedure? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/3273a090/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #4 from acutiator at outlook.com --- And same for Natural Selection 2: http://forums.unknownworlds.com/discussion/131798/linux-mouse-cursor-has-a-rectangle-around-it -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/d0eab21a/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #5 from acutiator at outlook.com --- There are 10 people who reported it for Grimrock and 3 in Natural Selection 2, all but 1 who are running AMD drivers open and closed. I'd like to use apitrace to look at the texture used for the cursor to confirm it's a game bug for both of these games, but I can't get apitrace to work with Steam games for me and the internet is being little help. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/1aef3b15/attachment.html>
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 --- Comment #9 from Daniel Scharrer --- This looks like an application bug to me - here's what the game does with the minimap fog of war in the apitrace (right at the start of each frame, so it's easy to find): 1. Uploads the fog of war to GL_ALPHA texture 2487 2. Binds framebuffer 2 3. Attaches texture 6613 as the color0 buffer 4. Clears color to (0, 0, 0, 0) 5. Unbinds framebuffer 2 6. Binds framebuffer 2 7. Attaches texture 6613 as the color0 buffer 8. Binds 6613 as texture0 9. Binds 2487 as texture1 10. Draws a full-screen quad with a shader that boils down to a = pow(texture1.a, 8); color0 = a * (0, 0, 0, 1) + (1 - a) * texture0; Reading from and writing to the same texture in this way is undefined without inserting the appropriate memory barriers. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/c74bb3d1/attachment-0001.html>
[PATCH v4 0/2] RFC: Secure Memory Allocation Framework
I have mind few uses cases:
- the basic one when an HW device need contiguous memory.
- I have a device that could not cross some memory boundaries so I
need a specific allocator for it.
- when allocating memory for security some platform have address
constraints or need to allocate memory in specific areas (most of the
time because of firewall limited capacities in terms of regions)
2015-10-06 4:07 GMT+02:00 Laura Abbott :
> On 10/05/2015 03:11 AM, Benjamin Gaignard wrote:
>>
>> version 4 changes:
>> - rebased on kernel 4.3-rc3
>> - fix missing EXPORT_SYMBOL for smaf_create_handle()
>>
>> version 3 changes:
>> - Remove ioctl for allocator selection instead provide the name of
>> the targeted allocator with allocation request.
>> Selecting allocator from userland isn't the prefered way of working
>> but is needed when the first user of the buffer is a software
>> component.
>> - Fix issues in case of error while creating smaf handle.
>> - Fix module license.
>> - Update libsmaf and tests to care of the SMAF API evolution
>> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>>
>> version 2 changes:
>> - Add one ioctl to allow allocator selection from userspace.
>> This is required for the uses case where the first user of
>> the buffer is a software IP which can't perform dma_buf attachement.
>> - Add name and ranking to allocator structure to be able to sort them.
>> - Create a tiny library to test SMAF:
>> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>> - Fix one issue when try to secure buffer without secure module
>> registered
>>
>> The outcome of the previous RFC about how do secure data path was the need
>> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>>
>> SMAF goal is to provide a framework that allow allocating and securing
>> memory by using dma_buf. Each platform have it own way to perform those
>> two
>> features so SMAF design allow to register helper modules to perform them.
>>
>> To be sure to select the best allocation method for devices SMAF implement
>> deferred allocation mechanism: memory allocation is only done when the
>> first
>> device effectively required it.
>> Allocator modules have to implement a match() to let SMAF know if they are
>> compatibles with devices needs.
>> This patch set provide an example of allocator module which use
>> dma_{alloc/free/mmap}_attrs() and check if at least one device have
>> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
>> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
>> a better name could be found for this file.
>>
>> Secure modules are responsibles of granting and revoking devices access
>> rights
>> on the memory. Secure module is also called to check if CPU map memory
>> into
>> kernel and user address spaces.
>> An example of secure module implementation can be found here:
>> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
>> This code isn't yet part of the patch set because it depends on generic
>> TEE
>> which is still under discussion (https://lwn.net/Articles/644646/)
>>
>> For allocation part of SMAF code I get inspirated by Sumit Semwal work
>> about
>> constraint aware allocator.
>>
>
> Overall I like the abstraction. Do you have a use case in mind right now for
> the best allocation method? Some of the classic examples (mmu vs. no mmu)
> are gradually becoming less relevant as the systems have evolved. I was
> discussing constraints with Sumit w.r.t. Ion at plumbers so I'm curious
> about
> your uses.
>
> Thanks,
> Laura
>
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH v3 1/6] vga_switcheroo: Add support for switching only the DDC
On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wunner wrote: > Originally by Seth Forshee , 2012-10-04: > During graphics driver initialization it's useful to be able to mux > only the DDC to the inactive client in order to read the EDID. Add > a switch_ddc callback to allow capable handlers to provide this > functionality, and add vga_switcheroo_switch_ddc() to allow DRM > to mux only the DDC. > > Modified by Dave Airlie , 2012-12-22: > I can't figure out why I didn't like this, but I rewrote this [...] > to lock/unlock the ddc lines [...]. I think I'd prefer something > like that otherwise the interface got really ugly. > > Modified by Lukas Wunner , 2015-08-14: > Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it can cause > deadlocks because (a) during switch (with vgasr_mutex already held), > GPU is woken and probes its outputs, tries to re-acquire vgasr_mutex > to lock DDC lines; (b) Likewise during switch, GPU is suspended and > calls cancel_delayed_work_sync() to stop output polling, if poll > task is running at this moment we may wait forever for it to finish. > > Instead, lock ddc_lock when unregistering the handler because the > only reason why we'd want to lock vgasr_mutex in _lock_ddc() / > _unlock_ddc() is to block the handler from disappearing while DDC > lines are switched. Shouldn't we also take the new look in register_handler, for consistency? I know that if you look the mux provider too late it's fairly hopeless ... Also while reading the patch I realized that the new lock really protects hw state (instead of our software-side tracking and driver resume/suspend code). And at least myself I have no idea what vgasr means, so what about renaming it to hw_mutex? We have this pattern of low-level locks to avoid concurrent hw access in a lot of places like i2c, dp_aux, and it's very often called hw_lock or similar. Otherwise patch looks good. Wrt the overall patch series, can you pls haggle driver-maintainers (gmux, radeon, nouveau) for acks/reviews? scripts/get_maintainers.pl should help. Also, the revised docbook patch seems to be missing from this iteration, please follow up with that one. Thanks, Daniel > Also lock ddc_lock in stage2 to avoid race condition where reading > the EDID and switching happens simultaneously. Likewise on MIGD / > MDIS commands and on runtime suspend. > > Retain semantics of ->switchto handler callback to switch all pins, > including DDC. Change semantics of ->switch_ddc handler callback to > return previous DDC owner. Original version tried to determine > previous DDC owner with find_active_client() but this fails if the > inactive client registers before the active client. > > v2.1: Overhaul locking, squash commits > (requested by Daniel Vetter ) > > v2.2: Readability improvements > (requested by Thierry Reding ) > > v2.3: Overhaul locking once more > > v2.4: Retain semantics of ->switchto handler callback to switch all pins > (requested by Daniel Vetter ) > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 > Tested-by: Pierre Moreau > [MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"] > Tested-by: William Brown > [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] > Tested-by: Lukas Wunner > [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] > > Cc: Seth Forshee > Cc: Dave Airlie > Signed-off-by: Lukas Wunner > --- > drivers/gpu/vga/vga_switcheroo.c | 98 > +++- > include/linux/vga_switcheroo.h | 9 > 2 files changed, 105 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/vga/vga_switcheroo.c > b/drivers/gpu/vga/vga_switcheroo.c > index aa077aa..9b6946e 100644 > --- a/drivers/gpu/vga/vga_switcheroo.c > +++ b/drivers/gpu/vga/vga_switcheroo.c > @@ -73,9 +73,19 @@ > * there can thus be up to three clients: Two vga clients (GPUs) and one > audio > * client (on the discrete GPU). The code is mostly prepared to support > * machines with more than two GPUs should they become available. > + * > * The GPU to which the outputs are currently switched is called the > * active client in vga_switcheroo parlance. The GPU not in use is the > - * inactive client. > + * inactive client. When the inactive client's DRM driver is loaded, > + * it will be unable to probe the panel's EDID and hence depends on > + * VBIOS to provide its display modes. If the VBIOS modes are bogus or > + * if there is no VBIOS at all (which is common on the MacBook Pro), > + * a client may alternatively request that the DDC lines are temporarily > + * switched to it, provided that the handler supports this. Switching > + * only the DDC lines and not the entire output avoids unnecessary > + * flickering. On machines which are able to mux external connectors, > + * VBIOS cannot know of
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #2 from MC Return --- Created attachment 118697 --> https://bugs.freedesktop.org/attachment.cgi?id=118697&action=edit console output of glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/38dc2519/attachment.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #2 from MC Return --- Created attachment 118698 --> https://bugs.freedesktop.org/attachment.cgi?id=118698&action=edit console output of glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/0ffdefd6/attachment-0001.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #3 from MC Return --- Created attachment 118699 --> https://bugs.freedesktop.org/attachment.cgi?id=118699&action=edit console output of dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/d7ec3fd1/attachment.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #3 from MC Return --- Created attachment 118700 --> https://bugs.freedesktop.org/attachment.cgi?id=118700&action=edit console output of dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/95a18707/attachment.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #4 from MC Return --- Hi Michel, thanks a lot for the swift response. I've built Mesa by checking out origin/11.0 and configuring the build with ./autogen.sh --prefix=/usr --enable-texture-float --libdir=/usr/lib/x86_64-linux-gnu/ --with-gallium-drivers=nouveau,radeonsi,r600 --with-egl-platforms=drm,x11 --enable-glx-tls --enable-shared-glapi --enable-glx --enable-driglx-direct --enable-gles1 --enable-gles2 --enable-experimental-targets=R600 How can I find out if my 32-bit Mesa binaries are up to date ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/0e7aedc4/attachment.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #4 from MC Return --- Hi Michel, thanks a lot for the swift response. I've built Mesa by checking out origin/11.0 and configuring the build with ./autogen.sh --prefix=/usr --enable-texture-float --libdir=/usr/lib/x86_64-linux-gnu/ --with-gallium-drivers=nouveau,radeonsi,r600 --with-egl-platforms=drm,x11 --enable-glx-tls --enable-shared-glapi --enable-glx --enable-driglx-direct --enable-gles1 --enable-gles2 --enable-experimental-targets=R600 How can I find out if my 32-bit Mesa binaries are up to date ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/0e2ea7f7/attachment.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #5 from Michel Dänzer --- (In reply to MC Return from comment #4) > How can I find out if my 32-bit Mesa binaries are up to date ? It sounds like you only built 64-bit binaries of Mesa yourself, so you're probably still using the 32-bit binaries from Ubuntu. What does apt-cache policy libgl1-mesa-dri:i386 say? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/8b6e27ed/attachment.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #5 from Andy Furniss --- (In reply to MC Return from comment #4) > Hi Michel, > thanks a lot for the swift response. > > I've built Mesa by checking out origin/11.0 and configuring the build with > ./autogen.sh --prefix=/usr --enable-texture-float > --libdir=/usr/lib/x86_64-linux-gnu/ > --with-gallium-drivers=nouveau,radeonsi,r600 --with-egl-platforms=drm,x11 > --enable-glx-tls --enable-shared-glapi --enable-glx --enable-driglx-direct > --enable-gles1 --enable-gles2 --enable-experimental-targets=R600 > > How can I find out if my 32-bit Mesa binaries are up to date ? Maybe nothing to do with the issue here, but there are some unigine workarounds in drirc that may not get read if (historically at least) you don't specify that they should go in /etc. I haven't looked recently but in the past with your options they would end up in /usr/etc and not get used so add - --sysconfdir=/etc -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/d536aa2f/attachment.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #6 from MC Return --- (In reply to Michel Dänzer from comment #5) > > It sounds like you only built 64-bit binaries of Mesa yourself, so you're > probably still using the 32-bit binaries from Ubuntu. What does > > apt-cache policy libgl1-mesa-dri:i386 > > say? libgl1-mesa-dri:i386: Installed: 11.1~git1509280730.e413d2~gd~v Candidate: 11.1~git1509280730.e413d2~gd~v Version table: *** 11.1~git1509280730.e413d2~gd~v 0 100 /var/lib/dpkg/status 11.0.1~git20150928+11.0.7f1a77ae-0ubuntu0ricotz~trusty 0 500 http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ trusty/main i386 Packages 10.1.3-0ubuntu0.4 0 500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main i386 Packages 10.1.0-4ubuntu5 0 500 http://archive.ubuntu.com/ubuntu/ trusty/main i386 Packages -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/31abe38d/attachment-0001.html>
[PATCH v4 1/2] create SMAF module
Thanks for your review I will add a lock in smaf_handle structure.
One of the goal of smaf is to create a standard kernel API to allocate
and secure buffers to avoid forking
while implementing buffer securing feature.
One concern about ION is that the selection of the heap is done by userland
so hardware constraints need to be known by the userland, which is
problematic from my point of view.
Compare to ION I have try to introduce features like securing API,
flexible allocator selection on kernel
and the possibility to add custom allocator and securing modules.
Benjamin
2015-10-06 3:58 GMT+02:00 Laura Abbott :
> On 10/05/2015 03:11 AM, Benjamin Gaignard wrote:
>>
>> diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
>> new file mode 100644
>> index 000..37914e7
>> --- /dev/null
>> +++ b/drivers/smaf/smaf-core.c
>> @@ -0,0 +1,736 @@
>> +/*
>> + * smaf.c
>> + *
>> + * Copyright (C) Linaro SA 2015
>> + * Author: Benjamin Gaignard for Linaro.
>> + * License terms: GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct smaf_handle {
>> + struct dma_buf *dmabuf;
>> + struct smaf_allocator *allocator;
>> + struct dma_buf *db_alloc;
>> + size_t length;
>> + unsigned int flags;
>> + int fd;
>> + bool is_secure;
>> + void *secure_ctx;
>> +};
>> +
>> +/**
>> + * struct smaf_device - smaf device node private data
>> + * @misc_dev: the misc device
>> + * @head: list of allocator
>> + * @lock: list and secure pointer mutex
>> + * @secure:pointer to secure functions helpers
>> + */
>> +struct smaf_device {
>> + struct miscdevice misc_dev;
>> + struct list_head head;
>> + /* list and secure pointer lock*/
>> + struct mutex lock;
>> + struct smaf_secure *secure;
>> +};
>> +
>> +static struct smaf_device smaf_dev;
>> +
>> +/**
>> + * smaf_allow_cpu_access return true if CPU can access to memory
>> + * if their is no secure module associated to SMAF assume that CPU can
>> get
>> + * access to the memory.
>> + */
>> +static bool smaf_allow_cpu_access(struct smaf_handle *handle,
>> + unsigned long flags)
>> +{
>> + if (!handle->is_secure)
>> + return true;
>> +
>> + if (!smaf_dev.secure)
>> + return true;
>> +
>> + if (!smaf_dev.secure->allow_cpu_access)
>> + return true;
>> +
>> + return smaf_dev.secure->allow_cpu_access(handle->secure_ctx,
>> flags);
>> +}
>> +
>> +static int smaf_grant_access(struct smaf_handle *handle, struct device
>> *dev,
>> +dma_addr_t addr, size_t size,
>> +enum dma_data_direction dir)
>> +{
>> + if (!handle->is_secure)
>> + return 0;
>> +
>> + if (!smaf_dev.secure)
>> + return -EINVAL;
>> +
>> + if (!smaf_dev.secure->grant_access)
>> + return -EINVAL;
>> +
>> + return smaf_dev.secure->grant_access(handle->secure_ctx,
>> +dev, addr, size, dir);
>> +}
>> +
>> +static void smaf_revoke_access(struct smaf_handle *handle, struct device
>> *dev,
>> + dma_addr_t addr, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + if (!handle->is_secure)
>> + return;
>> +
>> + if (!smaf_dev.secure)
>> + return;
>> +
>> + if (!smaf_dev.secure->revoke_access)
>> + return;
>> +
>> + smaf_dev.secure->revoke_access(handle->secure_ctx,
>> + dev, addr, size, dir);
>> +}
>> +
>> +static int smaf_secure_handle(struct smaf_handle *handle)
>> +{
>> + if (handle->is_secure)
>> + return 0;
>> +
>> + if (!smaf_dev.secure)
>> + return -EINVAL;
>> +
>> + if (!smaf_dev.secure->create_context)
>> + return -EINVAL;
>> +
>> + handle->secure_ctx = smaf_dev.secure->create_context();
>> +
>> + if (!handle->secure_ctx)
>> + return -EINVAL;
>> +
>> + handle->is_secure = true;
>> + return 0;
>> +}
>> +
>> +static int smaf_unsecure_handle(struct smaf_handle *handle)
>> +{
>> + if (!handle->is_secure)
>> + return 0;
>> +
>> + if (!smaf_dev.secure)
>> + return -EINVAL;
>> +
>> + if (!smaf_dev.secure->destroy_context)
>> + return -EINVAL;
>> +
>> + if (smaf_dev.secure->destroy_context(handle->secure_ctx))
>> + return -EINVAL;
>> +
>> + handle->secure_ctx = NULL;
>> + handle->is_secure = false;
>> + return 0;
>> +}
>
>
> All these functions need to be protected by a lock, otherwise the
> secure state could change. For that
[PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support
On Mon, Oct 05, 2015 at 05:25:33PM +0200, Maciej S. Szmigiero wrote: > Hi Thierry, > > On 05.10.2015 13:01, Thierry Reding wrote: > >> On 01.09.2015 15:50, Maciej S. Szmigiero wrote: > >>> This patch adds support for United Radiant Technology > >>> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels > >>> (both LVDS and parallel versions) to DRM > >>> panel-simple driver. > >>> > >>> Signed-off-by: Maciej Szmigiero > >>> --- > >>> This is a resend without changes. > >>> > >>> diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > >>> b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > >>> new file mode 100644 > >>> index 000..2990e6b > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > >>> @@ -0,0 +1,11 @@ > >>> +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel > >>> + > >>> +Supported are LVDS versions (-11T, -19T) and parallel ones > >>> +(-T, -1T, -7T, -20T). > > > > Please don't use this kind of wildcard compatible values. If these are > > different models then each of them deserves a separate compatible > > string. > > The differences between these revisions are like different maximum backlight > luminance or presence / absence of touch panel. > > None of this changes panel timings - should they be split into different > compatible values anyway? Yes, absolutely. The compatible doesn't only define what the video timings are, it defines the specific piece of hardware. While it is true that the panel-simple driver currently doesn't use any other information the DT compatible value characterizes the full hardware and therefore should take into account all of the device's properties. Presence of a touch panel sounds like a very important property and the maximum backlight brightness might also become important at some ponit. > >>> You might want to > >>> split the DT binding and vendor prefix to separate patches. > >> > >> Do you mean to first submit new vendor prefix then panel patch with docs? > >> Or even docs separately? > > > > This should be three patches: the vendor prefix is usually a separate > > patch and needs an Acked-by from one of the device tree bindings > > maintainers. The binding itself should also be a separate patch and the > > driver changes should come last. > > I will split the patch and first submit DT binding docs. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/83f999b6/attachment.sig>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #6 from MC Return --- (In reply to Andy Furniss from comment #5) > > Maybe nothing to do with the issue here, but there are some unigine > workarounds in drirc that may not get read if (historically at least) you > don't specify that they should go in /etc. I haven't looked recently but in > the past with your options they would end up in /usr/etc and not get used so > add - > > --sysconfdir=/etc Hey Andi, thanks a lot for your help also. I have rebuilt and reinstalled Mesa/11.0 now, but the result is the same. I start tropics (even just in 1024x768 windowed), the benchmark loads and the 3d flight to the islands starts with some flickering and visual annoyances until the camera turns and the computer hardlocks so bad I cannot even open one of the other consoles and I have to do a hard reset and reboot. :( -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/fc3ca57c/attachment.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 --- Comment #7 from MC Return --- The crash seems to be so severe, that the last messages are not saved in .xsession-errors anymore, but once I managed to see some related errors printed out. I will try to reproduce this situation and report the errors. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/e1549d72/attachment.html>
[RFC v2 0/5] drm/dsi: DSI for devices with different control bus
We are currently restricted when it comes to supporting DSI on devices that have a non-DSI control bus. For example, DSI encoder chips are available in the market that are configured via i2c. Configuring their registers via DSI bus is either optional or not available at all. These devices still need to pass DSI parameters (data lanes, mode flags etc) to the DSI host they are connected to. We don't have a way to do that at the moment. After some discussions on the previous RFC[1], we decided to support this by providing additional API in drm_mipi_dsi which lets us create new DSI devices without the need of them to have a DT node. There are a couple of concerns I have about this patchset which I couldn't figure out a solution to (they are addressed in the individual patches too): - Matching of non-DT devices: buses like i2c/spi populate id_table in their drivers to perform a match for the non-DT case. Is this something that we should do too? - Race between host_unregister and device_unregister: The new API provides peripheral drivers to unregister the DSI devices they created by using mipi_dsi_device_unregister. If the dsi host unregisters first, the peripheral driver might have an unregistered device pointer without being aware of it. Some comments on these would help. [1]: https://lkml.org/lkml/2015/6/30/42 Archit Taneja (5): drm/dsi: Refactor device creation drm/dsi: Try to match non-DT dsi devices drm/dsi: Check for used channels drm/dsi: Add routine to unregister dsi device drm/dsi: Get DSI host by DT device node drivers/gpu/drm/drm_mipi_dsi.c | 135 - include/drm/drm_mipi_dsi.h | 27 + 2 files changed, 132 insertions(+), 30 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[RFC v2 1/5] drm/dsi: Refactor device creation
Simplify the mipi dsi device creation process. device_initialize and
device_add don't need to be called separately when creating
mipi_dsi_device's. Use device_register instead to simplify things.
Create a helper function mipi_dsi_device_new which takes in struct
mipi_dsi_device_info and mipi_dsi_host. It clubs the functions
mipi_dsi_device_alloc and mipi_dsi_device_add into one.
mipi_dsi_device_info acts as a template to populate the dsi device
information. This is populated by of_mipi_dsi_device_add and passed to
mipi_dsi_device_new.
Later on, we'll provide mipi_dsi_device_new as a standalone way to create
a dsi device not available via DT.
The new device creation process tries to closely follow what's been done
in i2c_new_device in i2c-core.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 61 +-
include/drm/drm_mipi_dsi.h | 15 +++
2 files changed, 40 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 2d5ca8ee..245ecfe 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -102,9 +102,18 @@ static const struct device_type mipi_dsi_device_type = {
.release = mipi_dsi_dev_release,
};
-static struct mipi_dsi_device *mipi_dsi_device_alloc(struct mipi_dsi_host
*host)
+struct mipi_dsi_device *mipi_dsi_device_new(struct mipi_dsi_host *host,
+ struct mipi_dsi_device_info *info)
{
struct mipi_dsi_device *dsi;
+ struct device *dev = host->dev;
+ int r;
+
+ if (info->reg > 3) {
+ dev_err(dev, "device node has invalid reg property: %u\n",
+ info->reg);
+ return ERR_PTR(-EINVAL);
+ }
dsi = kzalloc(sizeof(*dsi), GFP_KERNEL);
if (!dsi)
@@ -114,26 +123,27 @@ static struct mipi_dsi_device
*mipi_dsi_device_alloc(struct mipi_dsi_host *host)
dsi->dev.bus = &mipi_dsi_bus_type;
dsi->dev.parent = host->dev;
dsi->dev.type = &mipi_dsi_device_type;
+ dsi->dev.of_node = info->node;
+ dsi->channel = info->reg;
- device_initialize(&dsi->dev);
-
- return dsi;
-}
-
-static int mipi_dsi_device_add(struct mipi_dsi_device *dsi)
-{
- struct mipi_dsi_host *host = dsi->host;
+ dev_set_name(&dsi->dev, "%s.%d", dev_name(host->dev), info->reg);
- dev_set_name(&dsi->dev, "%s.%d", dev_name(host->dev), dsi->channel);
+ r = device_register(&dsi->dev);
+ if (r) {
+ dev_err(dev, "failed to register device: %d\n", r);
+ kfree(dsi);
+ return ERR_PTR(r);
+ }
- return device_add(&dsi->dev);
+ return dsi;
}
+EXPORT_SYMBOL(mipi_dsi_device_new);
static struct mipi_dsi_device *
of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
{
- struct mipi_dsi_device *dsi;
struct device *dev = host->dev;
+ struct mipi_dsi_device_info info = { };
int ret;
u32 reg;
@@ -144,31 +154,10 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct
device_node *node)
return ERR_PTR(-EINVAL);
}
- if (reg > 3) {
- dev_err(dev, "device node %s has invalid reg property: %u\n",
- node->full_name, reg);
- return ERR_PTR(-EINVAL);
- }
-
- dsi = mipi_dsi_device_alloc(host);
- if (IS_ERR(dsi)) {
- dev_err(dev, "failed to allocate DSI device %s: %ld\n",
- node->full_name, PTR_ERR(dsi));
- return dsi;
- }
-
- dsi->dev.of_node = of_node_get(node);
- dsi->channel = reg;
+ info.reg = reg;
+ info.node = of_node_get(node);
- ret = mipi_dsi_device_add(dsi);
- if (ret) {
- dev_err(dev, "failed to add DSI device %s: %d\n",
- node->full_name, ret);
- kfree(dsi);
- return ERR_PTR(ret);
- }
-
- return dsi;
+ return mipi_dsi_device_new(host, &info);
}
int mipi_dsi_host_register(struct mipi_dsi_host *host)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..90f4f3c 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -140,6 +140,19 @@ enum mipi_dsi_pixel_format {
};
/**
+ * struct mipi_dsi_device_info - template for creating a mipi_dsi_device
+ * @reg: DSI virtual channel assigned to peripheral
+ * @node: pointer to OF device node
+ *
+ * This is populated and passed to mipi_dsi_device_new to create a new
+ * DSI device
+ */
+struct mipi_dsi_device_info {
+ u32 reg;
+ struct device_node *node;
+};
+
+/**
* struct mipi_dsi_device - DSI peripheral device
* @host: DSI host for this peripheral
* @dev: driver model device node for this peripheral
@@ -174,6 +187,8 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi,
const vo
[RFC v2 2/5] drm/dsi: Try to match non-DT dsi devices
Add a device name field in mipi_dsi_device. This name is different from
the actual dev name (which is of the format "hostname.reg"). When the
device is created via DT, this name is set to the modalias string.
In the non-DT case, the driver creating the DSI device provides the
name by populating a filed in mipi_dsi_device_info.
Matching for DT case would be as it was before. For the non-DT case,
we compare the device and driver names. Matching by comparing driver and
device names isn't the best thing to do. I'd appreciate some suggestions
here.
Other buses (like i2c/spi) perform a non-DT match by comparing the
device name and entries in the driver's id_table. The id_table structs
for different buses are defined in "include/linux/mod_devicetable.h", I
didn't want to touch that for now.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 29 -
include/drm/drm_mipi_dsi.h | 8
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 245ecfe..46ee515 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -45,9 +45,30 @@
* subset of the MIPI DCS command set.
*/
+static const struct device_type mipi_dsi_device_type;
+
static int mipi_dsi_device_match(struct device *dev, struct device_driver *drv)
{
- return of_driver_match_device(dev, drv);
+ struct mipi_dsi_device *dsi;
+
+ if (dev->type == &mipi_dsi_device_type)
+ dsi = to_mipi_dsi_device(dev);
+ else
+ return 0;
+
+ /* Attempt OF style match */
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ /*
+* Try to compare dsi device and driver names. If this matching approach
+* isn't strong, we'd probably want the dsi drivers to populate the
+* id_table field and use that instead
+*/
+ if (!strcmp(dsi->name, drv->name))
+ return 1;
+
+ return 0;
}
static const struct dev_pm_ops mipi_dsi_device_pm_ops = {
@@ -125,6 +146,7 @@ struct mipi_dsi_device *mipi_dsi_device_new(struct
mipi_dsi_host *host,
dsi->dev.type = &mipi_dsi_device_type;
dsi->dev.of_node = info->node;
dsi->channel = info->reg;
+ strlcpy(dsi->name, info->name, sizeof(dsi->name));
dev_set_name(&dsi->dev, "%s.%d", dev_name(host->dev), info->reg);
@@ -147,6 +169,11 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct
device_node *node)
int ret;
u32 reg;
+ if (of_modalias_node(node, info.name, sizeof(info.name)) < 0) {
+ dev_err(dev, "modalias failure on %s\n", node->full_name);
+ return ERR_PTR(-EINVAL);
+ }
+
ret = of_property_read_u32(node, "reg", ®);
if (ret) {
dev_err(dev, "device node %s has no valid reg property: %d\n",
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 90f4f3c..93dec7b 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -139,8 +139,11 @@ enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB565,
};
+#define DSI_DEV_NAME_SIZE 20
+
/**
* struct mipi_dsi_device_info - template for creating a mipi_dsi_device
+ * @name: name of the dsi peripheral
* @reg: DSI virtual channel assigned to peripheral
* @node: pointer to OF device node
*
@@ -148,14 +151,17 @@ enum mipi_dsi_pixel_format {
* DSI device
*/
struct mipi_dsi_device_info {
+ char name[DSI_DEV_NAME_SIZE];
u32 reg;
struct device_node *node;
};
+
/**
* struct mipi_dsi_device - DSI peripheral device
* @host: DSI host for this peripheral
* @dev: driver model device node for this peripheral
+ * @name: name of the dsi peripheral
* @channel: virtual channel assigned to the peripheral
* @format: pixel format for video mode
* @lanes: number of active data lanes
@@ -165,6 +171,8 @@ struct mipi_dsi_device {
struct mipi_dsi_host *host;
struct device dev;
+ char name[DSI_DEV_NAME_SIZE];
+
unsigned int channel;
unsigned int lanes;
enum mipi_dsi_pixel_format format;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[RFC v2 3/5] drm/dsi: Check for used channels
We don't check whether a previously registered mipi_dsi_device under the
same host shares the same virtual channel.
Before registering, check if any of the registered devices doesn't
already have the same virtual channel.
This wasn't crucial when all the devices under a host were populated via
DT. Now that we also support creating devices manually, we could end up
in a situation where a driver tries to create a device with a virtual
channel already taken by a device populated in DT.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 46ee515..db6130a 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -123,6 +123,22 @@ static const struct device_type mipi_dsi_device_type = {
.release = mipi_dsi_dev_release,
};
+static int __dsi_check_chan_busy(struct device *dev, void *data)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);
+ u32 reg = *(u32 *) data;
+
+ if (dsi && dsi->channel == reg)
+ return -EBUSY;
+
+ return 0;
+}
+
+static int mipi_dsi_check_chan_busy(struct mipi_dsi_host *host, u32 reg)
+{
+ return device_for_each_child(host->dev, ®, __dsi_check_chan_busy);
+}
+
struct mipi_dsi_device *mipi_dsi_device_new(struct mipi_dsi_host *host,
struct mipi_dsi_device_info *info)
{
@@ -150,14 +166,20 @@ struct mipi_dsi_device *mipi_dsi_device_new(struct
mipi_dsi_host *host,
dev_set_name(&dsi->dev, "%s.%d", dev_name(host->dev), info->reg);
+ r = mipi_dsi_check_chan_busy(host, info->reg);
+ if (r)
+ goto err;
+
r = device_register(&dsi->dev);
if (r) {
dev_err(dev, "failed to register device: %d\n", r);
- kfree(dsi);
- return ERR_PTR(r);
+ goto err;
}
return dsi;
+err:
+ kfree(dsi);
+ return ERR_PTR(r);
}
EXPORT_SYMBOL(mipi_dsi_device_new);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[RFC v2 4/5] drm/dsi: Add routine to unregister dsi device
A driver calling mipi_dsi_device_new might want to unregister the device
once it's done. It might also require it in an error handling path in
case something didn't go right.
When the dsi host driver calls mipi_dsi_host_unregister, the devices
created by both DT and and without DT will be removed. This does leave
the possibility of the host removing the dsi device without the
peripheral driver being aware of it. I don't know a good way to solve
this. Some suggestions here would be of help too.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 7 +++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index db6130a..cbb7373 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -183,6 +183,13 @@ err:
}
EXPORT_SYMBOL(mipi_dsi_device_new);
+void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi)
+{
+ if (dsi)
+ device_unregister(&dsi->dev);
+}
+EXPORT_SYMBOL(mipi_dsi_device_unregister);
+
static struct mipi_dsi_device *
of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
{
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 93dec7b..68f49f4 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -197,6 +197,8 @@ ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi,
const void *params,
struct mipi_dsi_device *mipi_dsi_device_new(struct mipi_dsi_host *host,
struct mipi_dsi_device_info *info);
+void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi);
+
/**
* enum mipi_dsi_dcs_tear_mode - Tearing Effect Output Line mode
* @MIPI_DSI_DCS_TEAR_MODE_VBLANK: the TE output line consists of V-Blanking
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[RFC v2 5/5] drm/dsi: Get DSI host by DT device node
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list of all the hosts DSI that are currently registered.
This list will be used to find the mipi_dsi_host corresponding to the
device_node passed in of_find_mipi_dsi_host_by_node.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 30 ++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index cbb7373..c51d73e 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -216,6 +216,28 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct
device_node *node)
return mipi_dsi_device_new(host, &info);
}
+static DEFINE_MUTEX(host_lock);
+static LIST_HEAD(host_list);
+
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node)
+{
+ struct mipi_dsi_host *host;
+
+ mutex_lock(&host_lock);
+
+ list_for_each_entry(host, &host_list, list) {
+ if (host->dev->of_node == node) {
+ mutex_unlock(&host_lock);
+ return host;
+ }
+ }
+
+ mutex_unlock(&host_lock);
+
+ return NULL;
+}
+EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
@@ -227,6 +249,10 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
of_mipi_dsi_device_add(host, node);
}
+ mutex_lock(&host_lock);
+ list_add_tail(&host->list, &host_list);
+ mutex_unlock(&host_lock);
+
return 0;
}
EXPORT_SYMBOL(mipi_dsi_host_register);
@@ -243,6 +269,10 @@ static int mipi_dsi_remove_device_fn(struct device *dev,
void *priv)
void mipi_dsi_host_unregister(struct mipi_dsi_host *host)
{
device_for_each_child(host->dev, NULL, mipi_dsi_remove_device_fn);
+
+ mutex_lock(&host_lock);
+ list_del_init(&host->list);
+ mutex_unlock(&host_lock);
}
EXPORT_SYMBOL(mipi_dsi_host_unregister);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 68f49f4..15d3068 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -100,10 +100,12 @@ struct mipi_dsi_host_ops {
struct mipi_dsi_host {
struct device *dev;
const struct mipi_dsi_host_ops *ops;
+ struct list_head list;
};
int mipi_dsi_host_register(struct mipi_dsi_host *host);
void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node);
/* DSI mode flags */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
5): error: no function with name 'texelFetch2DOffset' 0:516(15): error: no function with name 'texelFetch2DOffset' 0:517(15): error: no function with name 'texelFetch2DOffset' 0:518(15): error: no function with name 'texelFetch2DOffset' 0:519(15): error: no function with name 'texelFetch2DOffset' 0:520(15): error: no function with name 'texelFetch2DOffset' 0:521(16): error: no function with name 'texelFetch2DOffset' 0:522(16): error: no function with name 'texelFetch2DOffset' 0:523(16): error: no function with name 'texelFetch2DOffset' 0:524(16): error: no function with name 'texelFetch2DOffset' 0:525(16): error: no function with name 'texelFetch2DOffset' 0:526(16): error: no function with name 'texelFetch2DOffset' I noticed it reports GPU: Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.6.2) 3.0 Mesa 11.1.0-devel (git-e413d2f 2015-09-28 vivid-oibaf-ppa) with 256 Mb video-memory (should be 8Gb)... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/8494d4da/attachment-0001.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
no function with name 'texelFetch2DOffset' 0:514(15): error: no function with name 'texelFetch2DOffset' 0:515(15): error: no function with name 'texelFetch2DOffset' 0:516(15): error: no function with name 'texelFetch2DOffset' 0:517(15): error: no function with name 'texelFetch2DOffset' 0:518(15): error: no function with name 'texelFetch2DOffset' 0:519(15): error: no function with name 'texelFetch2DOffset' 0:520(15): error: no function with name 'texelFetch2DOffset' 0:521(16): error: no function with name 'texelFetch2DOffset' 0:522(16): error: no function with name 'texelFetch2DOffset' 0:523(16): error: no function with name 'texelFetch2DOffset' 0:524(16): error: no function with name 'texelFetch2DOffset' 0:525(16): error: no function with name 'texelFetch2DOffset' 0:526(16): error: no function with name 'texelFetch2DOffset' I noticed not only multiple reported errors, but also that it reports using: GPU: Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.6.2) 3.0 Mesa 11.1.0-devel (git-e413d2f 2015-09-28 vivid-oibaf-ppa) This is not the one I've built, is it ? - should be LLVM 3.8-dev 4.1 Mesa 11.0.2 ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/a8226ec7/attachment.html>
[PATCH 2/2] drm: s/int pipe/unsigned int pipe/
On Fri, Oct 02, 2015 at 04:12:49PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 02, 2015 at 03:07:50PM +0200, Vincent ABRIOU wrote:
> > Hi,
> >
> > On 09/30/2015 03:46 PM, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Make the 'pipe' argument to drm_vblank_count() unsigned as it is
> > > everwhere else.
> > >
> > > Cc: Vincent Abriou
> > > Cc: Thierry Reding
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_irq.c | 2 +-
> > > include/drm/drmP.h| 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index 7d70b7c..f24c57c 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -876,7 +876,7 @@ drm_get_last_vbltimestamp(struct drm_device *dev,
> > > unsigned int pipe,
> > >* Returns:
> > >* The software vblank counter.
> > >*/
> > > -u32 drm_vblank_count(struct drm_device *dev, int pipe)
> > > +u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > > {
> > > struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> > >
> > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > > index f56..8df4de7 100644
> > > --- a/include/drm/drmP.h
> > > +++ b/include/drm/drmP.h
> > > @@ -928,7 +928,7 @@ extern int drm_irq_uninstall(struct drm_device *dev);
> > > extern int drm_vblank_init(struct drm_device *dev, unsigned int
> > > num_crtcs);
> > > extern int drm_wait_vblank(struct drm_device *dev, void *data,
> > > struct drm_file *filp);
> > > -extern u32 drm_vblank_count(struct drm_device *dev, int pipe);
> > > +extern u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe);
> > > extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> > > extern u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned
> > > int pipe,
> > >struct timeval *vblanktime);
> > >
> >
> >
> > If you update drm_vblank_count you also need to update
> > drm_vblank_no_hw_counter and need to change the u32
> > (*get_vblank_counter) prototype.
>
> No. drm_vblank_count() != .get_vblank_counter()
>
> >
> > Thierry already done the job with "drm/irq: Use unsigned int pipe in
> > public API" patch
>
> Yes I know. Except all the driver hooks still have signed ints. I looked
> at changing that, and it looked like quite a bit of work, so probably
> a job for coccinelle. I wonder if it has a way to figure out which
> functions are plugged into these hooks and do the job entirely
> automatically...
Actually the above-mentioned patch updated drivers as well, otherwise
there would've been tons of warnings from mismatched types.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/f75309f1/attachment.sig>
[RFC v2 5/5] drm/dsi: Get DSI host by DT device node
'file' description in 'intel_execlists_submission'
drivers/gpu/drm/i915/intel_lrc.c:837: warning: Excess function parameter
'ring' description in 'intel_execlists_submission'
vim +/list +104 include/drm/drm_mipi_dsi.h
068a0023 Andrzej Hajda 2013-12-04 88 struct
mipi_dsi_device *dsi);
068a0023 Andrzej Hajda 2013-12-04 89 int (*detach)(struct
mipi_dsi_host *host,
068a0023 Andrzej Hajda 2013-12-04 90 struct
mipi_dsi_device *dsi);
068a0023 Andrzej Hajda 2013-12-04 91 ssize_t (*transfer)(struct
mipi_dsi_host *host,
ed6ff40e Thierry Reding 2014-08-05 92 const
struct mipi_dsi_msg *msg);
068a0023 Andrzej Hajda 2013-12-04 93 };
068a0023 Andrzej Hajda 2013-12-04 94
068a0023 Andrzej Hajda 2013-12-04 95 /**
068a0023 Andrzej Hajda 2013-12-04 96 * struct mipi_dsi_host - DSI host
device
068a0023 Andrzej Hajda 2013-12-04 97 * @dev: driver model device node for
this DSI host
068a0023 Andrzej Hajda 2013-12-04 98 * @ops: DSI host operations
068a0023 Andrzej Hajda 2013-12-04 99 */
068a0023 Andrzej Hajda 2013-12-04 100 struct mipi_dsi_host {
068a0023 Andrzej Hajda 2013-12-04 101 struct device *dev;
068a0023 Andrzej Hajda 2013-12-04 102 const struct mipi_dsi_host_ops
*ops;
b3e0f8f8 Archit Taneja 2015-10-06 103 struct list_head list;
068a0023 Andrzej Hajda 2013-12-04 @104 };
068a0023 Andrzej Hajda 2013-12-04 105
068a0023 Andrzej Hajda 2013-12-04 106 int mipi_dsi_host_register(struct
mipi_dsi_host *host);
068a0023 Andrzej Hajda 2013-12-04 107 void mipi_dsi_host_unregister(struct
mipi_dsi_host *host);
b3e0f8f8 Archit Taneja 2015-10-06 108 struct mipi_dsi_host
*of_find_mipi_dsi_host_by_node(struct device_node *node);
068a0023 Andrzej Hajda 2013-12-04 109
068a0023 Andrzej Hajda 2013-12-04 110 /* DSI mode flags */
068a0023 Andrzej Hajda 2013-12-04 111
068a0023 Andrzej Hajda 2013-12-04 112 /* video mode */
:: The code at line 104 was first introduced by commit
:: 068a00233969833f1ba925e7627797489efd6041 drm: Add MIPI DSI bus support
:: TO: Andrzej Hajda
:: CC: Thierry Reding
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6062 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/fc583281/attachment-0001.obj>
[PATCH v3 1/6] vga_switcheroo: Add support for switching only the DDC
Hi Daniel,
thank you for taking a look at the patch set and shepherding this
through the review process.
On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote:
> On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wunner wrote:
> > Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it can cause
> > deadlocks because (a) during switch (with vgasr_mutex already held),
> > GPU is woken and probes its outputs, tries to re-acquire vgasr_mutex
> > to lock DDC lines; (b) Likewise during switch, GPU is suspended and
> > calls cancel_delayed_work_sync() to stop output polling, if poll
> > task is running at this moment we may wait forever for it to finish.
> >
> > Instead, lock ddc_lock when unregistering the handler because the
> > only reason why we'd want to lock vgasr_mutex in _lock_ddc() /
> > _unlock_ddc() is to block the handler from disappearing while DDC
> > lines are switched.
>
> Shouldn't we also take the new look in register_handler, for consistency?
> I know that if you look the mux provider too late it's fairly hopeless ...
With the chosen approach that's not necessary: vga_switcheroo_lock_ddc()
records in vgasr_priv.old_ddc_owner if there's no mux:
if (!vgasr_priv.handler || !vgasr_priv.handler->switch_ddc) {
vgasr_priv.old_ddc_owner = -ENODEV;
return -ENODEV;
}
And vga_switcheroo_unlock_ddc() does nothing if vgasr_priv.old_ddc_owner
is negative, it just releases the lock and returns:
if (vgasr_priv.old_ddc_owner >= 0) {
id = vgasr_priv.handler->get_client_id(pdev);
if (vgasr_priv.old_ddc_owner != id)
ret = vgasr_priv.handler->switch_ddc(
vgasr_priv.old_ddc_owner);
}
mutex_unlock(&vgasr_priv.ddc_lock);
So it has no consequences if the mux registers between the calls to
_lock_ddc() and _unlock_ddc().
> Also while reading the patch I realized that the new lock really protects
> hw state (instead of our software-side tracking and driver resume/suspend
> code). And at least myself I have no idea what vgasr means, so what about
> renaming it to hw_mutex? We have this pattern of low-level locks to avoid
> concurrent hw access in a lot of places like i2c, dp_aux, and it's very
> often called hw_lock or similar.
Hm, hw_lock sounds a bit ambiguous.
vgasr_mutex is really a catch-all that protects access to the vgasr_priv
structure and also protects various hardware state. (Power state of each
GPU, mux state.) Up until now this approach worked fine, it looks like
there was no need for additional locks. We may need to move to more
fine-grained locking as new features get added to vga_switcheroo.
The newly introduced ddc_lock is a first step and I think is aptly
named since it only protects the mux state for the DDC lines.
> Wrt the overall patch series, can you pls haggle driver-maintainers (gmux,
> radeon, nouveau) for acks/reviews? scripts/get_maintainers.pl should help.
Will do.
> Also, the revised docbook patch seems to be missing from this iteration,
> please follow up with that one.
The docbook patch posted September 17 automatically picks up the
kernel-doc for the new functions through the !E directive.
However I used markdown syntax for the unsorted lists in the DOC
sections, so it will look a bit funny unless markdown gets merged,
which as we all know is contentious. (Which is sad, though I can
understand Jonathan Corbet's concerns.)
By the way, Jani has kindly provided a Reviewed-By: for patch 6 of
the vga_switcheroo docs series. The patch is not dependent on the
preceding patch 5 which is awaiting an ack from Takashi, so could
be merged now:
[PATCH 06/15] vga_switcheroo: Use enum vga_switcheroo_state instead
Patches 7 and 8 are similarly trivial cleanups:
[PATCH 07/15] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead
[PATCH 08/15] vga_switcheroo: Use enum vga_switcheroo_client_id
And patch 10 has gotten a Reviewed-By: from Takashi:
[PATCH 10/15] ALSA: hda - Spell vga_switcheroo consistently
Kind regards,
Lukas
> > Also lock ddc_lock in stage2 to avoid race condition where reading
> > the EDID and switching happens simultaneously. Likewise on MIGD /
> > MDIS commands and on runtime suspend.
> >
> > Retain semantics of ->switchto handler callback to switch all pins,
> > including DDC. Change semantics of ->switch_ddc handler callback to
> > return previous DDC owner. Original version tried to determine
> > previous DDC owner with find_active_client() but this fails if the
> > inactive client registers before the active client.
> >
> > v2.1: Overhaul locking, squash commits
> > (requested by Daniel Vetter )
> >
> > v2.2: Readability improvements
> > (requested by Thierry Reding )
> >
> > v2.3: Overhaul locking once more
> >
> > v2.4: Retain semantics of ->switchto handler callback to switch all pins
>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #8 from Andy Furniss --- (In reply to MC Return from comment #6) > (In reply to Andy Furniss from comment #5) > > > > Maybe nothing to do with the issue here, but there are some unigine > > workarounds in drirc that may not get read if (historically at least) you > > don't specify that they should go in /etc. I haven't looked recently but in > > the past with your options they would end up in /usr/etc and not get used so > > add - > > > > --sysconfdir=/etc > > Hey Andi, > thanks a lot for your help also. > > I have rebuilt and reinstalled Mesa/11.0 now, but the result is the same. > I start tropics (even just in 1024x768 windowed), the benchmark loads and > the 3d flight to the islands starts with some flickering and visual > annoyances until the camera turns and the computer hardlocks so bad I cannot > even open one of the other consoles and I have to do a hard reset and > reboot. :( Oh, Ok, Not that I have the same card anyway, but I can't test Tropics as I am on a pure 64bit setup. WRT the hard lock did you try SysRq? Apologies if you already know all this - Press and hold both and keys, while still holding them press and release wait a sec, then press and release then . If it works then this is a cleaner way than a hard reset as the syncs disks and the remounts them read only then hopefully the reboots. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/43ae9ce6/attachment.html>
[PATCH 09/16] drm/irq: Use unsigned int pipe in public API
On Thu, Sep 24, 2015 at 06:35:31PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This continues the pattern started in commit cc1ef118fc09 ("drm/irq:
> Make pipe unsigned and name consistent"). This is applied to the public
> APIs and driver callbacks, so pretty much all drivers need to be updated
> to match the new prototypes.
Quickly scanned through this one, didn't spot anything alarming.
Reviewed-by: Ville Syrjälä
>
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Russell King
> Cc: Inki Dae
> Cc: Jianwei Wang
> Cc: Alison Wang
> Cc: Patrik Jakobsson
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Mark Yao
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Thomas Hellstrom
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 36 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 9 +++
> drivers/gpu/drm/armada/armada_drv.c | 8 +++---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 +++--
> drivers/gpu/drm/drm_irq.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +--
> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 4 +--
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--
> drivers/gpu/drm/gma500/psb_drv.h | 6 ++---
> drivers/gpu/drm/gma500/psb_irq.c | 8 +++---
> drivers/gpu/drm/gma500/psb_irq.h | 6 ++---
> drivers/gpu/drm/i915/i915_irq.c | 34 -
> drivers/gpu/drm/imx/imx-drm-core.c | 8 +++---
> drivers/gpu/drm/mga/mga_drv.h| 6 ++---
> drivers/gpu/drm/mga/mga_irq.c| 20 +++
> drivers/gpu/drm/msm/msm_drv.c| 12 -
> drivers/gpu/drm/nouveau/nouveau_display.c| 23 +
> drivers/gpu/drm/nouveau/nouveau_display.h| 12 -
> drivers/gpu/drm/omapdrm/omap_drv.h | 4 +--
> drivers/gpu/drm/omapdrm/omap_irq.c | 16 ++--
> drivers/gpu/drm/qxl/qxl_drv.c| 7 ++---
> drivers/gpu/drm/r128/r128_drv.h | 6 ++---
> drivers/gpu/drm/r128/r128_irq.c | 16 ++--
> drivers/gpu/drm/radeon/radeon_display.c | 25 +-
> drivers/gpu/drm/radeon/radeon_drv.c | 13 +-
> drivers/gpu/drm/radeon/radeon_drv.h | 6 ++---
> drivers/gpu/drm/radeon/radeon_irq.c | 38
> ++--
> drivers/gpu/drm/radeon/radeon_mode.h | 5 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c| 8 +++---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 +++--
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +--
> drivers/gpu/drm/sti/sti_crtc.c | 16 ++--
> drivers/gpu/drm/sti/sti_crtc.h | 4 +--
> drivers/gpu/drm/tegra/drm.c | 7 ++---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 +--
> drivers/gpu/drm/via/via_drv.h| 6 ++---
> drivers/gpu/drm/via/via_irq.c| 17 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 ++---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 ++---
> include/drm/drmP.h | 25 +-
> 42 files changed, 239 insertions(+), 232 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 668939a14206..d7b8e4b31d78 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -2348,10 +2348,10 @@ void amdgpu_driver_preclose_kms(struct drm_device
> *dev,
> struct drm_file *file_priv);
> int amdgpu_suspend_kms(struct drm_device *dev, bool suspend, bool fbcon);
> int amdgpu_resume_kms(struct drm_device *dev, bool resume, bool fbcon);
> -u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, int crtc);
> -int amdgpu_enable_vblank_kms(struct drm_device *dev, int crtc);
> -void amdgpu_disable_vblank_kms(struct drm_device *dev, int crtc);
> -int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, int crtc,
> +u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
> +int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> +void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
> +int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int
> pipe,
> int *max_error,
> struct timeval *vblank_time,
> unsigned flags);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 9b34a3410c32..de116398fa49 10064
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #9 from Andy Furniss --- (In reply to MC Return from comment #7) > I noticed not only multiple reported errors, but also that it reports using: > GPU: Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.6.2) 3.0 Mesa > 11.1.0-devel (git-e413d2f 2015-09-28 vivid-oibaf-ppa) > This is not the one I've built, is it ? - should be LLVM 3.8-dev 4.1 Mesa > 11.0.2 ? The Mesa 11.1.0-devel is correct for git. The 3.0 is probably OK, if you look at the output from (a new enough) glxinfo then you will see both 3.0 and 4.1 listed. DRM and LLVM are old as IIRC oibaf doesn't do git versions of those. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/c575b420/attachment.html>
[PATCH 1/3] drm: Track drm_mm nodes with an interval tree
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the number of nodes in the range manager as opposed to O(N).
Insertion however gains an extra O(lg(N)) step for all nodes
irrespective of whether the interval tree is in use. For future i915
patches, eliminating the linear walk is a significant improvement.
Signed-off-by: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_mm.c | 71
include/drm/drm_mm.h | 5
3 files changed, 54 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 06ae5008c5ed..e25050a5a843 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+ select INTERVAL_TREE
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 04de6fd88f8c..e3acd860f738 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -153,6 +153,10 @@ static void drm_mm_insert_helper(struct drm_mm_node
*hole_node,
INIT_LIST_HEAD(&node->hole_stack);
list_add(&node->node_list, &hole_node->node_list);
+ node->it.start = node->start;
+ node->it.last = node->start + size - 1;
+ interval_tree_insert(&node->it, &mm->interval_tree);
+
BUG_ON(node->start + node->size > adj_end);
node->hole_follows = 0;
@@ -178,39 +182,53 @@ static void drm_mm_insert_helper(struct drm_mm_node
*hole_node,
*/
int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
{
- struct drm_mm_node *hole;
u64 end = node->start + node->size;
- u64 hole_start;
- u64 hole_end;
-
- BUG_ON(node == NULL);
+ struct interval_tree_node *it;
+ struct drm_mm_node *hole;
+ u64 hole_start, hole_end;
/* Find the relevant hole to add our node to */
- drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
- if (hole_start > node->start || hole_end < end)
- continue;
+ it = interval_tree_iter_first(&mm->interval_tree,
+ node->start, (u64)-1);
+ if (it == NULL) {
+ hole = list_last_entry(&mm->head_node.node_list,
+ struct drm_mm_node, node_list);
+ } else {
+ hole = container_of(it, typeof(*hole), it);
+ if (hole->start <= node->start)
+ return -ENOSPC;
+
+ hole = list_last_entry(&hole->node_list,
+ struct drm_mm_node, node_list);
+ }
- node->mm = mm;
- node->allocated = 1;
+ hole_start = drm_mm_hole_node_start(hole);
+ hole_end = drm_mm_hole_node_end(hole);
+ if (hole_start > node->start || hole_end < end)
+ return -ENOSPC;
- INIT_LIST_HEAD(&node->hole_stack);
- list_add(&node->node_list, &hole->node_list);
+ node->mm = mm;
+ node->allocated = 1;
- if (node->start == hole_start) {
- hole->hole_follows = 0;
- list_del_init(&hole->hole_stack);
- }
+ INIT_LIST_HEAD(&node->hole_stack);
+ list_add(&node->node_list, &hole->node_list);
- node->hole_follows = 0;
- if (end != hole_end) {
- list_add(&node->hole_stack, &mm->hole_stack);
- node->hole_follows = 1;
- }
+ node->it.start = node->start;
+ node->it.last = node->start + node->size - 1;
+ interval_tree_insert(&node->it, &mm->interval_tree);
- return 0;
+ if (node->start == hole_start) {
+ hole->hole_follows = 0;
+ list_del_init(&hole->hole_stack);
}
- return -ENOSPC;
+ node->hole_follows = 0;
+ if (end != hole_end) {
+ list_add(&node->hole_stack, &mm->hole_stack);
+ node->hole_follows = 1;
+ }
+
+ return 0;
}
EXPORT_SYMBOL(drm_mm_reserve_node);
@@ -300,6 +318,10 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
INIT_LIST_HEAD(&node->hole_stack);
list_add(&node->node_list, &hole_node->node_list);
+ node->it.start = node->start;
+ node->it.last = node->start + node->size - 1;
+ interval_tree_insert(&node->it, &mm->interval_tree);
+
BUG_ON(node->start < start);
[PATCH v3 1/6] vga_switcheroo: Add support for switching only the DDC
On Tue, Oct 06, 2015 at 12:10:48PM +0200, Lukas Wunner wrote:
> Hi Daniel,
>
> thank you for taking a look at the patch set and shepherding this
> through the review process.
>
> On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wunner wrote:
> > > Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it can cause
> > > deadlocks because (a) during switch (with vgasr_mutex already held),
> > > GPU is woken and probes its outputs, tries to re-acquire vgasr_mutex
> > > to lock DDC lines; (b) Likewise during switch, GPU is suspended and
> > > calls cancel_delayed_work_sync() to stop output polling, if poll
> > > task is running at this moment we may wait forever for it to finish.
> > >
> > > Instead, lock ddc_lock when unregistering the handler because the
> > > only reason why we'd want to lock vgasr_mutex in _lock_ddc() /
> > > _unlock_ddc() is to block the handler from disappearing while DDC
> > > lines are switched.
> >
> > Shouldn't we also take the new look in register_handler, for consistency?
> > I know that if you look the mux provider too late it's fairly hopeless ...
>
> With the chosen approach that's not necessary: vga_switcheroo_lock_ddc()
> records in vgasr_priv.old_ddc_owner if there's no mux:
>
> if (!vgasr_priv.handler || !vgasr_priv.handler->switch_ddc) {
> vgasr_priv.old_ddc_owner = -ENODEV;
> return -ENODEV;
> }
>
> And vga_switcheroo_unlock_ddc() does nothing if vgasr_priv.old_ddc_owner
> is negative, it just releases the lock and returns:
>
> if (vgasr_priv.old_ddc_owner >= 0) {
> id = vgasr_priv.handler->get_client_id(pdev);
> if (vgasr_priv.old_ddc_owner != id)
> ret = vgasr_priv.handler->switch_ddc(
>vgasr_priv.old_ddc_owner);
> }
> mutex_unlock(&vgasr_priv.ddc_lock);
>
> So it has no consequences if the mux registers between the calls to
> _lock_ddc() and _unlock_ddc().
>
>
> > Also while reading the patch I realized that the new lock really protects
> > hw state (instead of our software-side tracking and driver resume/suspend
> > code). And at least myself I have no idea what vgasr means, so what about
> > renaming it to hw_mutex? We have this pattern of low-level locks to avoid
> > concurrent hw access in a lot of places like i2c, dp_aux, and it's very
> > often called hw_lock or similar.
>
> Hm, hw_lock sounds a bit ambiguous.
>
> vgasr_mutex is really a catch-all that protects access to the vgasr_priv
> structure and also protects various hardware state. (Power state of each
> GPU, mux state.) Up until now this approach worked fine, it looks like
> there was no need for additional locks. We may need to move to more
> fine-grained locking as new features get added to vga_switcheroo.
> The newly introduced ddc_lock is a first step and I think is aptly
> named since it only protects the mux state for the DDC lines.
Oops sorry mixed up the names. I meant rename the ddc_lock to hw_lock
since it protects a bit more than just the ddc (it protects the entire hw
switch state since we grab it both for dcc switching and for full-blown
switching of everything).
>
>
> > Wrt the overall patch series, can you pls haggle driver-maintainers (gmux,
> > radeon, nouveau) for acks/reviews? scripts/get_maintainers.pl should help.
>
> Will do.
>
>
> > Also, the revised docbook patch seems to be missing from this iteration,
> > please follow up with that one.
>
> The docbook patch posted September 17 automatically picks up the
> kernel-doc for the new functions through the !E directive.
I asked for the inclusion to be moved to drm.tmpl instead of creating a
new docbook.
> However I used markdown syntax for the unsorted lists in the DOC
> sections, so it will look a bit funny unless markdown gets merged,
> which as we all know is contentious. (Which is sad, though I can
> understand Jonathan Corbet's concerns.)
>
>
> By the way, Jani has kindly provided a Reviewed-By: for patch 6 of
> the vga_switcheroo docs series. The patch is not dependent on the
> preceding patch 5 which is awaiting an ack from Takashi, so could
> be merged now:
> [PATCH 06/15] vga_switcheroo: Use enum vga_switcheroo_state instead
>
> Patches 7 and 8 are similarly trivial cleanups:
> [PATCH 07/15] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead
> [PATCH 08/15] vga_switcheroo: Use enum vga_switcheroo_client_id
>
> And patch 10 has gotten a Reviewed-By: from Takashi:
> [PATCH 10/15] ALSA: hda - Spell vga_switcheroo consistently
Hm those patches aren't in this series, that makes it really hard for me
to know what's still pending. I think it would be best to resend
_everything_, so including docs and cleanups and all that. Otherwise I
think this will take a lot longer than necessary to pull in.
Also when resending patches unchanged please dir
[Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree
On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookups for a particular address will then be O(lg(N)), where N
> is the number of nodes in the range manager as opposed to O(N).
> Insertion however gains an extra O(lg(N)) step for all nodes
> irrespective of whether the interval tree is in use. For future i915
> patches, eliminating the linear walk is a significant improvement.
>
> Signed-off-by: Chris Wilson
> Cc: dri-devel at lists.freedesktop.org
For the vma manager David Herrman put the interval tree outside of drm_mm.
Whichever way we pick, but I think we should be consistent about this.
-Daniel
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/drm_mm.c | 71
>
> include/drm/drm_mm.h | 5
> 3 files changed, 54 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 06ae5008c5ed..e25050a5a843 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -12,6 +12,7 @@ menuconfig DRM
> select I2C
> select I2C_ALGOBIT
> select DMA_SHARED_BUFFER
> + select INTERVAL_TREE
> help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 04de6fd88f8c..e3acd860f738 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -153,6 +153,10 @@ static void drm_mm_insert_helper(struct drm_mm_node
> *hole_node,
> INIT_LIST_HEAD(&node->hole_stack);
> list_add(&node->node_list, &hole_node->node_list);
>
> + node->it.start = node->start;
> + node->it.last = node->start + size - 1;
> + interval_tree_insert(&node->it, &mm->interval_tree);
> +
> BUG_ON(node->start + node->size > adj_end);
>
> node->hole_follows = 0;
> @@ -178,39 +182,53 @@ static void drm_mm_insert_helper(struct drm_mm_node
> *hole_node,
> */
> int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
> {
> - struct drm_mm_node *hole;
> u64 end = node->start + node->size;
> - u64 hole_start;
> - u64 hole_end;
> -
> - BUG_ON(node == NULL);
> + struct interval_tree_node *it;
> + struct drm_mm_node *hole;
> + u64 hole_start, hole_end;
>
> /* Find the relevant hole to add our node to */
> - drm_mm_for_each_hole(hole, mm, hole_start, hole_end) {
> - if (hole_start > node->start || hole_end < end)
> - continue;
> + it = interval_tree_iter_first(&mm->interval_tree,
> + node->start, (u64)-1);
> + if (it == NULL) {
> + hole = list_last_entry(&mm->head_node.node_list,
> +struct drm_mm_node, node_list);
> + } else {
> + hole = container_of(it, typeof(*hole), it);
> + if (hole->start <= node->start)
> + return -ENOSPC;
> +
> + hole = list_last_entry(&hole->node_list,
> +struct drm_mm_node, node_list);
> + }
>
> - node->mm = mm;
> - node->allocated = 1;
> + hole_start = drm_mm_hole_node_start(hole);
> + hole_end = drm_mm_hole_node_end(hole);
> + if (hole_start > node->start || hole_end < end)
> + return -ENOSPC;
>
> - INIT_LIST_HEAD(&node->hole_stack);
> - list_add(&node->node_list, &hole->node_list);
> + node->mm = mm;
> + node->allocated = 1;
>
> - if (node->start == hole_start) {
> - hole->hole_follows = 0;
> - list_del_init(&hole->hole_stack);
> - }
> + INIT_LIST_HEAD(&node->hole_stack);
> + list_add(&node->node_list, &hole->node_list);
>
> - node->hole_follows = 0;
> - if (end != hole_end) {
> - list_add(&node->hole_stack, &mm->hole_stack);
> - node->hole_follows = 1;
> - }
> + node->it.start = node->start;
> + node->it.last = node->start + node->size - 1;
> + interval_tree_insert(&node->it, &mm->interval_tree);
>
> - return 0;
> + if (node->start == hole_start) {
> + hole->hole_follows = 0;
> + list_del_init(&hole->hole_stack);
> }
>
> - return -ENOSPC;
> + node->hole_follows = 0;
> + if (end != hole_end) {
> + list_add(&node->hole_stack, &mm->hole_stack);
> + node->hole_follows = 1;
> + }
> +
> + return 0;
> }
> EXPORT_SYMBOL(drm_mm_reserve_node);
>
> @@ -300,6 +318,10 @@ static void drm_mm_insert_helper_range(stru
[Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree
On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote: > On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: > > In addition to the last-in/first-out stack for accessing drm_mm nodes, > > we occasionally and in the future often want to find a drm_mm_node by an > > address. To do so efficiently we need to track the nodes in an interval > > tree - lookups for a particular address will then be O(lg(N)), where N > > is the number of nodes in the range manager as opposed to O(N). > > Insertion however gains an extra O(lg(N)) step for all nodes > > irrespective of whether the interval tree is in use. For future i915 > > patches, eliminating the linear walk is a significant improvement. > > > > Signed-off-by: Chris Wilson > > Cc: dri-devel at lists.freedesktop.org > > For the vma manager David Herrman put the interval tree outside of drm_mm. > Whichever way we pick, but I think we should be consistent about this. Given that the basis of this patch is that functionality exposed by drm_mm (i.e. drm_mm_reserve_node) is too slow for our use case (i.e. there is a measurable perf degradation if we switch over from the mru stack to using fixed addresses) it makes sense to improve that functionality. The question is then why the drm_vma_manager didn't use and improve the existing functionality... -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 --- Comment #10 from MC Return --- > > Oh, Ok, Not that I have the same card anyway, but I can't test Tropics as I > am on a pure 64bit setup. > Well, I am not sure if you would like the experience with the R390X. My cards before this one were a HD6950 and before that a HD5750 and I have to admit that I liked the prec-GCN experience a lot more - those hard lockups are really ugly and frustrating at the moment, I am happy that at least Compiz runs as expected so I can use my desktop normally... but it seems almost all other OpenGL applications I've tried seem to have major problems with the radeonsi/R390X combi. > WRT the hard lock did you try SysRq? Apologies if you already know all this - > > Press and hold both and keys, while still holding them press > and release wait a sec, then press and release then . If it works > then this is a cleaner way than a hard reset as the syncs disks and the > remounts them read only then hopefully the reboots. No need for any apologies, I appreciate any help I can get. And no, I did not know about the Magic SysRq key magic - very useful - I will try that next time: "Raising Elephants Is So Utterly Boring" or "Reboot Even If System Utterly Broken" magic, haha. Great tip, thanks a lot. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/61e4bdba/attachment.html>
[Bug 105581] New: amdgpu: r9 380 Dual Monitor Setup: rotation not working
https://bugzilla.kernel.org/show_bug.cgi?id=105581 Bug ID: 105581 Summary: amdgpu: r9 380 Dual Monitor Setup: rotation not working Product: Drivers Version: 2.5 Kernel Version: 4.2.2, 4.3-rc3, 4.3-rc4 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: f.otti at gmx.at Regression: No Created attachment 189561 --> https://bugzilla.kernel.org/attachment.cgi?id=189561&action=edit Xorg log of 4.3.rc3 Lengthy explanation posted here: https://forums.gentoo.org/viewtopic-p-7824374.html Dual Monitor setup doesn't seem to work at all when both are connected via DVI. When one is connected to HDMI and the other to the first DVI, dual monitor only works when one of them is connected after boot. Both only work when one is connected to HDMI and the other to the second DVI. With neither configuration does rotating any screen work. Results in crash of the X server (attachment). Everything works as intended under Windows. What I mean with "dual monitor is not working" is that both screens are recognized as connected but one of the screens shows only a black picture, but I can move applications to it (which I can't see). Steps to reproduce: Boot computer and try to rotate one of the screens with the KDE system settings or xrandr. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree
On Tue, Oct 06, 2015 at 12:19:43PM +0100, Chris Wilson wrote: > On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote: > > On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: > > > In addition to the last-in/first-out stack for accessing drm_mm nodes, > > > we occasionally and in the future often want to find a drm_mm_node by an > > > address. To do so efficiently we need to track the nodes in an interval > > > tree - lookups for a particular address will then be O(lg(N)), where N > > > is the number of nodes in the range manager as opposed to O(N). > > > Insertion however gains an extra O(lg(N)) step for all nodes > > > irrespective of whether the interval tree is in use. For future i915 > > > patches, eliminating the linear walk is a significant improvement. > > > > > > Signed-off-by: Chris Wilson > > > Cc: dri-devel at lists.freedesktop.org > > > > For the vma manager David Herrman put the interval tree outside of drm_mm. > > Whichever way we pick, but I think we should be consistent about this. > > Given that the basis of this patch is that functionality exposed by > drm_mm (i.e. drm_mm_reserve_node) is too slow for our use case (i.e. > there is a measurable perf degradation if we switch over from the mru > stack to using fixed addresses) it makes sense to improve that > functionality. The question is then why the drm_vma_manager didn't use > and improve the existing functionality... Yeah I'm trying to volunteer you to add a lookup-function and rework the vma-manager ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[hsakmt] hsakmt organization and formal releases
Hi, I had some time during the recent local holidays, so I thought I improve the hsakmt library in terms of releases: 1. I added automake/autoconf files to standardize the package to be created using configure/make/make install. 2. I created a very simple scheme of numbering so we could track releases. 3. I created a git repository under freedesktop.org amd's folder that will hold hsakmt code (instead of using my private git repo). You can clone the new repo from: git://anongit.freedesktop.org/amd/hsakmt 4. I created two new sub-components in freedesktop.org bugzilla, under DRI, for hsakmt and amdkfd, so bugs can be filed correctly. As part of point 1, I rearranged the layout of the source files a bit, although I kept the formation of the include files so it would be easy to use inside AMD :) I would like to get (positive) feedback on this, and then I will create the first official release and also F22, F23 and F24 (rawhide) rpm packages that will be part of the distribution. As a reminder, this repository will be used to manage only the upstream version of hsakmt. Private/non-yet-upstreamed releases of AMD are done in GitHub. Thanks, Oded
[Bug 105581] amdgpu: r9 380 Dual Monitor Setup: rotation not working
https://bugzilla.kernel.org/show_bug.cgi?id=105581 --- Comment #1 from f.otti at gmx.at --- Created attachment 189571 --> https://bugzilla.kernel.org/attachment.cgi?id=189571&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 --- Comment #10 from Marek Olšák --- It should be fine as long as the texture(x,y) maps to the same coordinates in the color buffer. If there is only one draw call, a barrier isn't required. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/585e9368/attachment.html>
[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
On 10/5/2015 7:06 PM, Kristian Høgsberg wrote: > On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry > wrote: >> On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote: >>> >>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote: Gen8+ supports 48-bit virtual addresses, but some objects must always be allocated inside the 32-bit address range. In specific, any resource used with flat/heapless (0x-0xf000) General State Heap (GSH) or Instruction State Heap (ISH) must be in a 32-bit range, because the General State Offset and Instruction State Offset are limited to 32-bits. The i915 driver has been modified to provide a flag to set when the 4GB limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS). 48-bit range will only be used when explicitly requested. Callers to the existing drm_intel_bo_emit_reloc function should set the use_48b_address_range flag beforehand, in order to use full ppgtt range. v2: Make set/clear functions nops on pre-gen8 platforms, and use them internally in emit_reloc functions (Ben) s/48BADDRESS/48B_ADDRESS/ (Dave) v3: Keep set/clear functions internal, no-one needs to use them directly. v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type before enabling set/clear function, print full offsets in debug statements, using port of lower_32_bits and upper_32_bits from linux kernel (MichaÅ) References: http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html Cc: Ben Widawsky Cc: MichaÅ Winiarski >>> >>> >>> +Kristian >>> >>> LGTM. >>> Acked-by: MichaÅ Winiarski >>> Signed-off-by: Michel Thierry >> >> >> >> Hi Kristian, >> >> More comments on this? >> I've resent the mesa patch with the last changes >> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html). >> >> MichaÅ has agreed with the interface and will use it for his work. >> If mesa doesn't plan to use this for now, it's ok. The kernel changes have >> been done to prevent any regressions when the support 48-bit flag is not >> set. > > I didn't get any replies to my last comments on this: > > http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html > > Basically, I tried explicitly placing buffers above 8G and didn't see > the HW problem described (ie it all worked fine). I still think > there's some confusion as to what the W/A is about. > > Here's my take: the W/A is a SW-only workaround to handle the cases > where a driver uses heapless and 48-bit ppgtt. The problem is that the > heaps are limited to 4G but with 48bit ppgtt a buffer can be placed > anywhere it the 48 bit address space. If that happens it's consideredd > out-of-bounds for the heap and access fails. To prevent this we need > to make sure the bos we address in a heapless fashion are placed below > 4g. > > For mesa, we only configure general state base as heap-less, which > affects scratch bos. What this boils down to is that we need the 4G > restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS > and 3DSTATE_PS (and tesselation stage eventually). Look for the > OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c > and gen8_ps_state.c I think it also affects _3DSTATE_VIEWPORT_STATE_POINTERS_CC, maybe it isn't exclusive to the scratch bos (the error state points to that instruction).
WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized
On 2015/10/5 18:03, Joerg Roedel wrote:
> Hi Jiang,
>
> On Sat, Oct 03, 2015 at 03:36:35PM +0800, Jiang Liu wrote:
>> So to summary, I think we only need following change to fix the
>> regression:
>> int pcibios_alloc_irq(struct pci_dev *dev)
>> {
>> +if (pci_dev_msi_enabled(dev))
>> +return -EBUSY;
>>
>> What do you think?
>
> Yes, that works too and has the added benefit that no driver can attach
> to the iommu device and get in the way of the driver.
>
> Will you send the patch for this change or should I do it?
Hi Joerg,
We are on leave for Chinese National Holiday and has limited
access to my working environment. It would be appreciated if you could
help to send out a patch for it. Otherwise I will send out a patch
within 2-3 days.
Thanks!
Gerry
[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
On Tue, 6 Oct 2015 11:23:03 +0200 Arnaud Pouliquen wrote: [snip] > As API is defined in DRM, it seems more logical to match it with the one > defined for video. From my windows, i didn't see any blocking point to > connect codec callback with this API. > But anyway, this API is not freezed, it could be improved with your help. Arnaud, your implementation seems more heavy than Jyri's, and I don't feel the DRM bridge. For HDMI, the exchanges between DRM and ALSA are only: - DRM -> ALSA - device connection with the audio constraints - device disconnection - ALSA -> DRM - start audio with the chosen audio parameters - stop audio and, in the system, the HDMI devices are seen as DRM connectors (video view) and as ASoC CODECs (audio view). We just need a link between these entities. I don't think that the bridge offers this. (going further, it seems natural to me that both entities would be supported by the same kernel device and that the exchange functions and values could be defined both ways from a common structure - audio constraints, playback parameters, connector2codec functions, codec2connector functions - but this is an other story...) -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 --- Comment #11 from Daniel Scharrer --- There is also a glClear though. Currently the texture read ends up with the data before the clear (uninitialized for the first frame, unitialized content with the fog of war blended on top n times for subsequent frames). Are you saying the texture reads should get the color from the clear without any synchronization? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/02056ffe/attachment.html>
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 Alex Deucher changed: What|Removed |Added CC||jrafante89 at gmail.com --- Comment #4 from Alex Deucher --- *** Bug 91330 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/61de75da/attachment.html>
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 --- Comment #5 from Alex Deucher --- Created attachment 118719 --> https://bugs.freedesktop.org/attachment.cgi?id=118719&action=edit Mark iceland as experimental (In reply to Christian König from comment #2) > > @Alex: How well did we already tested Topaz? If not we might want to disable > the PCI-ID for now. We haven't really tested them much. How about the attached patch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/a97cb8e5/attachment.html>
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 --- Comment #6 from Christian König --- (In reply to Alex Deucher from comment #5) > Created attachment 118719 [details] [review] > Mark iceland as experimental > > (In reply to Christian König from comment #2) > > > > @Alex: How well did we already tested Topaz? If not we might want to disable > > the PCI-ID for now. > > We haven't really tested them much. How about the attached patch? Yeah, probably a good idea until we have time to fix those. Patch is Reviewed-by: Christian König -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/afa5a48e/attachment.html>
[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
On 10/06/15 12:23, Arnaud Pouliquen wrote: > Hello Jyri, > > Thanks your feedback, my answers in line > > > On 10/05/2015 03:27 PM, Jyri Sarha wrote: >> On 10/01/15 19:50, Arnaud Pouliquen wrote: >>> >>> Version 2: >>> This version integrates missing features upgraded to be aligned when >>> possible >>> with patch set: >>> [PATCH RFC v4 0/8] Implement generic ASoC HDMI codec and use it in >>> tda998x >>> >> >> There are still some details I would like to change if we decide to go >> the drm audio bridge way. But before all that, I would like to ask, >> why should we go forward with your approach? Is there anything that >> can be done with your approach, but can not be done with mine? >> >> Don't take me wrong, I do not see anything fundamentally wrong with >> your approach. I would just like hear some justification why we should >> abandon my approach - that I've been working on for some time - and go >> forward with yours. > > Both implementations are similar in term of feature. And i think both > have advantages and drawbacks... > The main difference, is that my approach is based on a standard service > client-provider model. > Means that ops are defined by code in charge of providing the service > (DRM) and not by the client (ALSA). > I don't want to impose my implementation but just propose an alternative > that makes sense for me. > My model merely sees a driver providing access to a piece standard HDMI HW with audio functionality trough ASoC codec DAI API. > In a first step, before going deep in discussion on the approach, it > should be interesting to have maintainers feedback, to be sure that my > approach could make sense from DRM and ALSA point of view. > Absolutely. In the end the maintainers need to make the final decision any way. > @DRM (and ALSA) maintainers: > Please, could you give a first feedback on such implementation based on > DRM API extension? > Is it something that could be acceptable (or not) from your point of view? > >> >> Here is couple of benefits I can name in my approach: >> Â Video side agnostic implementation >> The ASoC side does not need to know anything about video side >> implementation. There is no real exposure ASoC side internals in >> video side either. Even fbdev driver, or some other non DRM video >> driver, could use my implementation. > My approach is the reverse: DRM driver does not need to know anything > about audio side. As ALSA is the client of DRM, seems more logical from > my point of view ... > Now if a generic solution must be found for all video drivers, sure, > your solution is more flexible. > But if i well understood fbdev drivers are no more accepted for upstream > (please correct me if I'm wrong). > So i don't know we have to keep fbdev in picture... > I am not promoting fbdev support. I am merely asking if we want to force all HDMI drivers to implement a drm_bridge if they want to support audio. >> - HDMI encoder driver implementations that do not use DRM bridge >> abstraction do not need add an extra DRM object just to get the >> audio working. >> >> Short comings I see in the current HDMI audio bridge approach: >> >> In its current from the DRM audio bridge abstraction pretends to be a >> generic audio abstraction for DRM devices, but the implementation is >> quite specific to external HDMI encoders with spdif and/or i2s >> interface. There is a lot of HDMI video devices that provide the >> digital audio interface (ASoC DAI) directly and there is no need for >> anything but dummy codec implementation (if following ASoC >> paradigm). Before going forward I think we should at least consider >> how this abstraction would serve those devices. > Sorry, but i don't see any difference between both implementations for > this point.In both implementations, ops are called only if defined. > Could you give me name of the drivers you have in mind? I am not talking about Beaglebone-Black or tda998x here. There are platforms where video HW provides the digital audio interface for HDMI audio directly. For instance OMAP4 and OMAP5 (see sound/soc/omap/omap-hdmi-audio.c and drivers/video/fbdev/omap2/dss/) are like that. >> >> Also, I am not entirely happy how the drm_audio_bridge_funcs are used >> at the moment. The do not map too well to ASoC DAI callbacks and I do >> not see too much point in creating a completely new audio-callback >> abstraction, that is sligtly incompatible with ALSA, and then >> translating alsa callbacks to these new callbacks. I think the >> callbacks should map more or less directly ALSA callbacks. > > As API is defined in DRM, it seems more logical to match it with the one > defined for video. From my windows, i didn't see any blocking point to > connect codec callback with this API. > But anyway, this API is not freezed, it could be improved with your help. The most usual things can be made to work with your API too, but the translation is not the most efficient one and some features are
[PATCH v2] drm/gma500: fix double freeing
We are allocating backing using psbfb_alloc() and so
backing->stolen is always true. So we were freeing backing two times.
Moreover if we follow the execution path then we should be freeing
backing after we have released the helper. So remove the one which frees
backing before the helper is released.
While at it the error labels are also renamed to give a meaningful
name.
Cc: Patrik Jakobsson
Signed-off-by: Sudip Mukherjee
---
Hi Patrik,
If you donot like the labels I will change them according to what you
have suggested.
drivers/gpu/drm/gma500/framebuffer.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 2eaf1b3..52e2bf3 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -411,7 +411,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
info = drm_fb_helper_alloc_fbi(&fbdev->psb_fb_helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto out_err1;
+ goto err_alloc_fbi;
}
info->par = fbdev;
@@ -419,7 +419,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
ret = psb_framebuffer_init(dev, psbfb, &mode_cmd, backing);
if (ret)
- goto out_unref;
+ goto err_framebuffer_init;
fb = &psbfb->base;
psbfb->fbdev = info;
@@ -465,14 +465,9 @@ static int psbfb_create(struct psb_fbdev *fbdev,
mutex_unlock(&dev->struct_mutex);
return 0;
-out_unref:
- if (backing->stolen)
- psb_gtt_free_range(dev, backing);
- else
- drm_gem_object_unreference(&backing->gem);
-
+err_framebuffer_init:
drm_fb_helper_release_fbi(&fbdev->psb_fb_helper);
-out_err1:
+err_alloc_fbi:
mutex_unlock(&dev->struct_mutex);
psb_gtt_free_range(dev, backing);
return ret;
--
1.9.1
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #5 from Krzysztof A. Sobiecki --- It was recorded on git version, with llvm3.8 But r600 on 11.0 works fine too. Apitrace of r600 on 11.0: https://drive.google.com/file/d/0B3J0Mg89izcbZ2ZESENjSkZMTGM/view?usp=sharing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/4fc2bdd4/attachment.html>
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #6 from Daniel Scharrer --- Then this might be a duplicate of bug #92122. There is a patch series on the ML waiting for review: http://patchwork.freedesktop.org/patch/61011/ http://patchwork.freedesktop.org/patch/61012/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/fc4c9b8a/attachment.html>
[PATCHv9 07/15] cec: add HDMI CEC framework
On Mon, Sep 07, 2015 at 03:44:36PM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > The added HDMI CEC framework provides a generic kernel interface for > HDMI CEC devices. > > Signed-off-by: Hans Verkuil > [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil] > [k.debski at samsung.com: Merged Update author commit by Hans Verkuil] > [k.debski at samsung.com: change kthread handling when setting logical > address] > [k.debski at samsung.com: code cleanup and fixes] > [k.debski at samsung.com: add missing CEC commands to match spec] > [k.debski at samsung.com: add RC framework support] > [k.debski at samsung.com: move and edit documentation] > [k.debski at samsung.com: add vendor id reporting] > [k.debski at samsung.com: add possibility to clear assigned logical > addresses] > [k.debski at samsung.com: documentation fixes, clenaup and expansion] > [k.debski at samsung.com: reorder of API structs and add reserved fields] > [k.debski at samsung.com: fix handling of events and fix 32/64bit timespec > problem] > [k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild] > [k.debski at samsung.com: add sequence number handling] > [k.debski at samsung.com: add passthrough mode] > [k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands] > minor additions] > Signed-off-by: Kamil Debski > Signed-off-by: Hans Verkuil I don't see much in the way of support for source devices in this: how do we handle hotplug of the sink, and how to do we configure the physical address? Surely you aren't proposing that drivers should write directly to adap->phys_addr without calling some notification function that the physical address has changed? Please can you give some guidance on how a HDMI source bridge driver should deal with these issues. Thanks. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #7 from Krzysztof A. Sobiecki --- (In reply to Daniel Scharrer from comment #6) > Then this might be a duplicate of bug #92122. > > There is a patch series on the ML waiting for review: > http://patchwork.freedesktop.org/patch/61011/ > http://patchwork.freedesktop.org/patch/61012/ I'm going to bisect it on my end anyway, it's fast enough so it shouldn't be a problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/851f40b5/attachment.html>
[PATCH 03/12] gpu: imx: simplify sync polarity setting
On Sat, Aug 8, 2015 at 1:03 PM, Russell King wrote: > Use a function to convert the sync pin to a bit mask for the DI_GENERAL > register, and move this out of the interlace/non-interlace path to the > common path. > > Signed-off-by: Russell King Reviewed-by: Fabio Estevam
[PATCH 04/12] gpu: imx: fix support for interlaced modes
On Sat, Aug 8, 2015 at 1:03 PM, Russell King wrote: > The support for interlaced video modes seems to be broken; we don't use > anything other than the vtotal/htotal from the timing information to > define the various sync counters. > > Freescale patches for interlaced video support contain an alternative > sync counter setup, which we include here. This setup produces the > hsync and vsync via the normal counter 2 and 3, but moves the display > enable signal from counter 5 to counter 6. Therefore, we need to > change the display controller setup as well. > > The corresponding Freescale patches for this change are: > iMX6-HDMI-support-interlaced-display-mode.patch > IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch > > This produces a working interlace format output from the IPU. > > Signed-off-by: Russell King Reviewed-by: Fabio Estevam
[PATCH 05/12] drm: bridge/dw_hdmi: add support for interlaced video modes
On Sat, Aug 8, 2015 at 1:03 PM, Russell King wrote: > Add support for interlaced video modes to the dw_hdmi bridge. This > mainly involves halving the vertical parameters to be programmed into > the bridge registers, and setting the interlace_allowed connector flag. > > This brings working 1080i support. However, 480i and 576i fail to > work due to the lack of proper pixel repetition support, which is not > trivial to add due to the tabular PLL parameterisation. Hence, we > filter out these modes in our mode_valid() method. > > Signed-off-by: Russell King Reviewed-by: Fabio Estevam
[PATCH 11/12] drm: bridge/dw_hdmi: add connector mode forcing
On Sat, Aug 8, 2015 at 1:04 PM, Russell King wrote: > When connected to HDMI sources, some DVI monitors de-assert their HPD > signal and TDMS loads for one seconds every four seconds when there is > no signal present on the connection. > > Unfortunately, this behaviour is indistinguishable from a proper HDMI > setup with an AV receiver in the path to the display: the HDMI spec > requires us to detect HPD deassertions as short as 100ms, which indicate > that the EDID has changed. > > Since it is possible to connect a DVI monitor to an AV receiver and then > to a HDMI source, merely working around this by detecting the lack of > HDMI vendor block in the EDID is insufficient - the AV receiver is at > liberty to modify the EDID as it sees fit, and it will place its own > parameters into the EDID including the HDMI vendor block. > > DRM has support for forcing the state of a connector, which we should > implement to allow us to work around these broken DVI monitors - we can > tell DRM to force the connection state to indicate that there is always > a device connected to work around this problem. Although this requires > manual configuration, it is better than nothing at all. > > When a forced connection state has been set, there is no point handling > our RXSENSE interrupts, so disable them in this circumstance. > > Signed-off-by: Russell King Reviewed-by: Fabio Estevam at freescale.com
[PATCH 12/12] drm: bridge/dw_hdmi: improve HDMI enable/disable handling
On Sat, Aug 8, 2015 at 1:04 PM, Russell King wrote: > HDMI sinks are permitted to de-assert and re-assert the HPD signal to > indicate that their EDID has been updated, which may not involve a > change of video information. > > An example of where such a situation can arise is when an AV receiver > is connected between the source and the display device. Events which > can cause the HPD to be deasserted include: > > * turning on or switching to standby the AV receiver. > * turning on or switching to standby the display device. > > Each of these can change the entire EDID data, or just a part of the > EDID data - it's up to the connected HDMI sink to do what they desire > here. For example > > - with the AV receiver and display device both in standby, a source >connected to the AV receiver may provide its own EDID to the source. > - turning on the display device causes the display device's EDID to be >made available in an unmodified form to the source. > - subsequently turning on the AV receiver then provides a modified >version of the display device's EDID. > > Moreover, HPD doesn't tell us whether something is actually listening > on the HDMI TDMS signals. The phy gives us a set of RXSENSE indications > which tell us whether there is a sink connected to the TMDS signals. > > Currently, we use the HPD signal to enable or disable the HDMI block, > which is questionable when HPD is used in this manner. Using the > RXSENSE would be more appropriate, but there is some bad behaviour > which needs to be coped with. The iMX6 implementation lets the TMDS > signals float when the phy is "powered down", which cause spurious > interrupts. Rather than just using RXSENSE, use RXSENSE and HPD > becoming both active to signal the presence of a device, but loss > of RXSENSE to indicate that the device has been unplugged. > > The side effect of this change is that a sink deasserting the HPD > signal to cause a re-read of the EDID data will not cause the bridge > to immediately disable the video signal. > > Signed-off-by: Russell King Reviewed-by: Fabio Estevam
[PATCHv9 06/15] rc: Add HDMI CEC protocol handling
On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add handling of remote control events coming from the HDMI CEC bus.
> This patch includes a new keymap that maps values found in the CEC
> messages to the keys pressed and released. Also, a new protocol has
> been added to the core.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Hans Verkuil
(Added Mauro)
Hmm, how is rc-cec supposed to be loaded?
At boot, I see:
[ 16.577704] IR keymap rc-cec not found
[ 16.586675] Registered IR keymap rc-empty
[ 16.591668] input: RC for dw_hdmi as
/devices/soc0/soc/12.hdmi/rc/rc1/input3
[ 16.597769] rc1: RC for dw_hdmi as /devices/soc0/soc/12.hdmi/rc/rc1
Yet the rc-cec is a module in the filesystem, but it doesn't seem to
be loaded automatically - even after the system has booted, the module
hasn't been loaded.
It looks like it _should_ be loaded, but this plainly isn't working:
map = seek_rc_map(name);
#ifdef MODULE
if (!map) {
int rc = request_module("%s", name);
if (rc < 0) {
printk(KERN_ERR "Couldn't load IR keymap %s\n", name);
return NULL;
}
msleep(20); /* Give some time for IR to register */
map = seek_rc_map(name);
}
#endif
if (!map) {
printk(KERN_ERR "IR keymap %s not found\n", name);
return NULL;
}
Any ideas?
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver
On Sat, Aug 8, 2015 at 1:10 PM, Russell King wrote: > Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer > format supported by the hardware is its own special IEC958 based format, > which is not compatible with any ALSA format. To avoid doing too much > data manipulation within the driver, we support only ALSAs IEC958 LE and > 24-bit PCM formats for 2 to 6 channels, which we convert to its hardware > format. > > A more desirable solution would be to have this conversion in userspace, > but ALSA does not appear to allow such transformations outside of > libasound itself. > > Signed-off-by: Russell King I applied this series, but the HDMI audio card is not registered. I guess I missed the dts pieces. Are the dts patches available? Thanks
[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver
On Tue, Oct 06, 2015 at 03:07:40PM -0300, Fabio Estevam wrote:
> On Sat, Aug 8, 2015 at 1:10 PM, Russell King
> wrote:
> > Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer
> > format supported by the hardware is its own special IEC958 based format,
> > which is not compatible with any ALSA format. To avoid doing too much
> > data manipulation within the driver, we support only ALSAs IEC958 LE and
> > 24-bit PCM formats for 2 to 6 channels, which we convert to its hardware
> > format.
> >
> > A more desirable solution would be to have this conversion in userspace,
> > but ALSA does not appear to allow such transformations outside of
> > libasound itself.
> >
> > Signed-off-by: Russell King
>
> I applied this series, but the HDMI audio card is not registered. I
> guess I missed the dts pieces. Are the dts patches available?
Sorry, I've been out for most of the day. There's no DT patches required.
The dw_hdmi bridge driver creates its own platform device for the audio,
which should then bind to the dw_hdmi-ahb-audio driver using normal Linux
methods.
I don't know what's wrong with your setup, for me, it just works:
[1.358829] dwhdmi-imx 12.hdmi: Detected HDMI controller
0x13:0xa:0xa0:0xc1
[1.377173] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops)
...
[2.851343] ALSA device list:
[2.857364] #0: DW-HDMI rev 0x0a, irq 21
as it always has done for me. There's nothing special about it.
There's nothing special about it - it's a standard ALSA PCM audio driver,
it doesn't have any requirements over and above having ALSA and ALSA's PCM
support enabled. If you didn't have those enabled, but somehow had the
dw_hdmi-ahb-audio set as built-in, you'd get a link time error, so it's
not a configuration issue.
It works for me on all iMX6 platforms (solo, dual-lite, dual and quad).
As it's a straight ALSA device, it doesn't need any codec or any of the
ASoC infrastructure either.
I guess the thing to start looking at is whether the device and driver
appear in /sys/bus/platform/{devices,drivers}/. You should have:
/sys/bus/platform/devices/dw-hdmi-ahb-audio.0.auto
/sys/bus/platform/drivers/dw-hdmi-ahb-audio
and obviously the latter should contain the symlink to the device. If
that is present, then the driver has bound, and it should appear in
/proc/asound/cards.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH v3 1/6] vga_switcheroo: Add support for switching only the DDC
Hi Daniel, On Tue, Oct 06, 2015 at 01:10:00PM +0200, Daniel Vetter wrote: > On Tue, Oct 06, 2015 at 12:10:48PM +0200, Lukas Wunner wrote: > > On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote: > > > Also while reading the patch I realized that the new lock really protects > > > hw state (instead of our software-side tracking and driver resume/suspend > > > code). And at least myself I have no idea what vgasr means, so what about > > > renaming it to hw_mutex? We have this pattern of low-level locks to avoid > > > concurrent hw access in a lot of places like i2c, dp_aux, and it's very > > > often called hw_lock or similar. > > > > Hm, hw_lock sounds a bit ambiguous. > > > > vgasr_mutex is really a catch-all that protects access to the vgasr_priv > > structure and also protects various hardware state. (Power state of each > > GPU, mux state.) Up until now this approach worked fine, it looks like > > there was no need for additional locks. We may need to move to more > > fine-grained locking as new features get added to vga_switcheroo. > > The newly introduced ddc_lock is a first step and I think is aptly > > named since it only protects the mux state for the DDC lines. > > Oops sorry mixed up the names. I meant rename the ddc_lock to hw_lock > since it protects a bit more than just the ddc (it protects the entire hw > switch state since we grab it both for dcc switching and for full-blown > switching of everything). Interesting observation. Actually the intention is to use ddc_lock to only lock hardware state of the DDC switch, but you're right, it also locks hardware state of the panel switch. That's an unintended consequence of the ->switchto callback in apple-gmux also switching DDC, and the need to avoid races because of this. Now that you mention it I'm contemplating removing DDC switching from the ->switchto callback in apple-gmux. Then I don't need to take the ddc_lock when switching the full panel. > > > Also, the revised docbook patch seems to be missing from this iteration, > > > please follow up with that one. > > > > The docbook patch posted September 17 automatically picks up the > > kernel-doc for the new functions through the !E directive. > > I asked for the inclusion to be moved to drm.tmpl instead of creating a > new docbook. Your argument was that including it in drm.tmpl will increase the chances it's read. Quite honestly I think that reasoning is a bit thin. One might as well argue that people won't find the information in the juggernaut of 180 kByte XML text that is drm.tmpl. The (honest) question is this, vga_switcheroo is not located in the DRM tree, so it's a separate subsystem. Then why should someone be looking for its documentation in the DRM DocBook? > > By the way, Jani has kindly provided a Reviewed-By: for patch 6 of > > the vga_switcheroo docs series. The patch is not dependent on the > > preceding patch 5 which is awaiting an ack from Takashi, so could > > be merged now: > > [PATCH 06/15] vga_switcheroo: Use enum vga_switcheroo_state instead > > > > Patches 7 and 8 are similarly trivial cleanups: > > [PATCH 07/15] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead > > [PATCH 08/15] vga_switcheroo: Use enum vga_switcheroo_client_id > > > > And patch 10 has gotten a Reviewed-By: from Takashi: > > [PATCH 10/15] ALSA: hda - Spell vga_switcheroo consistently > > Hm those patches aren't in this series, that makes it really hard for me > to know what's still pending. I think it would be best to resend > _everything_, so including docs and cleanups and all that. Otherwise I > think this will take a lot longer than necessary to pull in. I updated my vga_switcheroo_docs branch on GitHub as the Reviewed-Bys came in and just rebased it to current topic/drm-misc, so you can pull from there if you're comfortable with that: https://github.com/l1k/linux/commits/vga_switcheroo_docs If on the other hand you prefer merging stuff via the mailing list, I'll be happy to resend. Thanks, Lukas
[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver
On Tue, Oct 6, 2015 at 3:18 PM, Russell King - ARM Linux wrote: > Sorry, I've been out for most of the day. There's no DT patches required. > > The dw_hdmi bridge driver creates its own platform device for the audio, > which should then bind to the dw_hdmi-ahb-audio driver using normal Linux > methods. > > I don't know what's wrong with your setup, for me, it just works: > > [1.358829] dwhdmi-imx 12.hdmi: Detected HDMI controller > 0x13:0xa:0xa0:0xc1 > [1.377173] imx-drm display-subsystem: bound 12.hdmi (ops > dw_hdmi_imx_ops) > ... > [2.851343] ALSA device list: > [2.857364] #0: DW-HDMI rev 0x0a, irq 21 > > as it always has done for me. There's nothing special about it. Great, got it to probe now: [7.454760] ALSA device list: [7.457764] #0: DW-HDMI rev 0x0a, irq 19 [7.461990] #1: wm8962-audio There was a conflict and I resolved incorrectly here. Will try to play a wav file via aplay now. Thanks
[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
On Tue, Oct 06, 2015 at 05:46:02PM +0100, Mark Brown wrote:
> On Tue, Oct 06, 2015 at 06:44:34PM +0300, Jyri Sarha wrote:
> > On 10/06/15 12:23, Arnaud Pouliquen wrote:
>
> > >In a first step, before going deep in discussion on the approach, it
> > >should be interesting to have maintainers feedback, to be sure that my
> > >approach could make sense from DRM and ALSA point of view.
>
> > Absolutely. In the end the maintainers need to make the final decision any
> > way.
>
> As I keep saying at least for me a very big part of that is going to be
> seeing some degree of consensus among the people working on HDMI. I
> really don't want to get something merged and then having people turn up
> shortly afterwards saying that there's some reason to redo everything
> and I don't have much familiarity with the video stuff so I'm largely
> relying on consensus and review from the DRM side (which seems to have
> been absent thus far).
As I've found, having also looked at getting CEC up and running both on
TDA998x and on dw-hdmi, having some kind of fixed structure between the
video side and the audio side doesn't work.
We at least need some kind of notification system from the video part
to the other parts, so that we can sanely transmit connect/disconnect/
edid updates to different parts of the system *not* that I'm suggesting
that in the case of the Dove Cubox, seeing a disconnect on HDMI should
kill the audio - it most _certainly_ _never_ should there, it would be
utterly insane, and I'm going to play hard-ball on that case.
CEC is much more critical to getting these events - knowing when the
sink device has been plugged in or unplugged is critical to proper
operation of CEC, as is knowing the CEC physical bus address - and
that comes from the EDID. Hence why a notification system that drivers
can hook into is critical.
Audio is just another example of needing to have communication between
the video and audio parts.
I'm not saying that I have something that's a perfect solution; I've
been rapidly losing interest in iMX6 recently due to the glacial
progress of everything in that arena, and the endless stream of new
bugs being introduced (I'm pretty sure Freescale have a bug quota
which must be maintained at a certain level in all software.) As I
now have a couple of new Armada 388 boards, this has taken my focus
almost completely off iMX6 and onto that right now.
However, here's the kind of thing that I prototyped to get CEC working
on iMX6 and Dove. It's not a patch set, because that requires me to
pull together patches from two different trees and sort out out properly,
so this is to give some ideas.
It's also pending sorting out what CEC subsystem is going to make it
into the kernel - I've only last night managed to find the time to try
out the framework which Hans Verkuil posted at the start of September,
which I still have a few concerns with, especially with the publication
of the device prior to driver setup having been completed.
Anyway, here's the prototype patch. Obviously won't apply to any
kernel version anyone has, but should give some food for thought.
drivers/cec/Makefile | 1 +
drivers/cec/cec-dw_hdmi.c| 90
drivers/cec/hdmi-not.c | 61 +++
drivers/gpu/drm/bridge/dw_hdmi.c | 9
include/linux/hdmi-not.h | 39 +
5 files changed, 200 insertions(+)
diff --git a/drivers/cec/Makefile b/drivers/cec/Makefile
index 9e31a9333294..69c354c60b07 100644
--- a/drivers/cec/Makefile
+++ b/drivers/cec/Makefile
@@ -1,3 +1,4 @@
+obj-y += hdmi-not.o
obj-$(CONFIG_HDMI_CEC_CORE) += cec-dev.o
obj-$(CONFIG_HDMI_CEC_EVDEV) += cec-input.o
diff --git a/drivers/cec/cec-dw_hdmi.c b/drivers/cec/cec-dw_hdmi.c
index b56844296d3e..a693808a881a 100644
--- a/drivers/cec/cec-dw_hdmi.c
+++ b/drivers/cec/cec-dw_hdmi.c
@@ -1,14 +1,18 @@
/* http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
* tree/drivers/mxc/hdmi-cec/mxc_hdmi-cec.c?h=imx_3.0.35_4.1.0 */
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
+
#define DEV_NAME "mxc_hdmi_cec"
enum {
@@ -47,6 +51,8 @@ struct dw_hdmi_cec {
void *ops_data;
int retries;
int irq;
+ struct cec_dev *cecdev;
+ struct notifier_block nb;
};
static void dw_hdmi_set_address(struct cec_dev *cecdev, unsigned addresses)
@@ -162,6 +168,83 @@ static const struct cec_dev_ops dw_hdmi_cec_dev_ops = {
.set_address = dw_hdmi_set_address,
};
+static unsigned int cea_len(const u8 *ext, unsigned int offset)
+{
+ return ext[offset] & 0x1f;
+}
+
+static unsigned int cea_tag(const u8 *ext, unsigned int offset)
+{
+ return ext[offset] >> 5;
+}
+
+static unsigned int parse_hdmi_addr(const struct edid *edid)
+{
+ unsigned int i, end;
+ const u8 *edid_ext = NULL;
+
+ if (!edid || edid->extensions == 0)
+
[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver
On Tue, Oct 06, 2015 at 03:45:32PM -0300, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 3:18 PM, Russell King - ARM Linux
> wrote:
>
> > Sorry, I've been out for most of the day. There's no DT patches required.
> >
> > The dw_hdmi bridge driver creates its own platform device for the audio,
> > which should then bind to the dw_hdmi-ahb-audio driver using normal Linux
> > methods.
> >
> > I don't know what's wrong with your setup, for me, it just works:
> >
> > [1.358829] dwhdmi-imx 12.hdmi: Detected HDMI controller
> > 0x13:0xa:0xa0:0xc1
> > [1.377173] imx-drm display-subsystem: bound 12.hdmi (ops
> > dw_hdmi_imx_ops)
> > ...
> > [2.851343] ALSA device list:
> > [2.857364] #0: DW-HDMI rev 0x0a, irq 21
> >
> > as it always has done for me. There's nothing special about it.
>
> Great, got it to probe now:
>
> [7.454760] ALSA device list:
> [7.457764] #0: DW-HDMI rev 0x0a, irq 19
> [7.461990] #1: wm8962-audio
>
> There was a conflict and I resolved incorrectly here. Will try to play
> a wav file via aplay now.
Make sure you have the ALSA config file, as alsalib won't get on
with dw-hdmi only accepting 24-bit audio without this. A copy is
attached. It also tells ALSA how to deal with multi-channel audio
as well.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
-- next part --
#
# All PCM must be 24-bit for easy kernel conversion.
# IEC958 formatted output can be sent directly.
#
# Direct-to-hardware converting to 24-bit output.
#
dw-hdmi-ahb-aud.pcm.hw-s24le {
@args [ CARD ]
@args.CARD { type string }
type linear
slave.pcm {
type hw
card $CARD
}
slave.format S24_LE
}
#
# Dmix hardware 24-bit output.
#
dw-hdmi-ahb-aud.pcm.dmix-s24le {
@args [ CARD ]
@args.CARD { type string }
type plug
slave.pcm { @func concat strings [ "dmix:" $CARD ",FORMAT=S24_LE" ] }
}
#
# Softvol with dmix output
#
dw-hdmi-ahb-aud.pcm.default {
@args [ CARD ]
@args.CARD { type string }
type asym
playback.pcm {
type softvol
slave.pcm {
@func refer name {
@func concat strings [
"cards."
{ @func card_driver card $CARD }
".pcm.dmix-s24le:CARD=" $CARD
]
}
}
control {
name "PCM Playback Volume"
card $CARD
}
}
}
#
# Common output path for front and surround outputs
#
dw-hdmi-ahb-aud.pcm.common.0 {
@args [ CARD ]
@args.CARD { type string }
type asym
playback.pcm {
type softvol
slave.pcm {
@func refer name {
@func concat strings [
"cards."
{ @func card_driver card $CARD }
".pcm.hw-s24le:CARD=" $CARD
]
}
}
control {
name "PCM Playback Volume"
card $CARD
}
}
}
dw-hdmi-ahb-aud.pcm.front.0 cards.dw-hdmi-ahb-aud.pcm.common.0
# The mapping of ALSA channels to surround channels is very imprecise.
# ALSA uses a different terminology and speaker placement to the CEA
# surround positioning. CEA has the positioning of:
#
# LFE
# FL FLC FC FRC FR
#
#
# RL RLC RC RRC RR
#
# ALSA's idea is:
#
# LFE
# FL C FR
#
# SL SR
#
# RL RR
#
# We do our best to map between these representations.
dw-hdmi-ahb-aud.pcm.surround40.0 {
@args [ CARD ]
@args.CARD { type string }
type empty
slave.pcm {
@func refer
name {
@func concat strings [
"cards.dw-hdmi-ahb-aud.pcm.common.0:CARD="
$CARD
]
}
}
}
# surround 41 and surround50 are (annoyingly) mapped to surround51
# We could do without stacking two 'route' plugins on top of each other
dw-hdmi-ahb-aud.pcm.surround51.0 {
@args [ CARD ]
@args.CARD { type string }
type route
slave.pcm {
@func refer
name {
@func concat strings [
"cards.dw-hdmi-ahb-aud.pcm.common.0:CARD="
$CARD
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 Krzysztof A. Sobiecki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Krzysztof A. Sobiecki --- (In reply to Daniel Scharrer from comment #6) > Then this might be a duplicate of bug #92122. > > There is a patch series on the ML waiting for review: > http://patchwork.freedesktop.org/patch/61011/ > http://patchwork.freedesktop.org/patch/61012/ Yes it is a duplicate. Does this two patches fix it? *** This bug has been marked as a duplicate of bug 92122 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/5353bd19/attachment.html>
[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver
On Tue, Oct 6, 2015 at 3:54 PM, Russell King - ARM Linux wrote: > Make sure you have the ALSA config file, as alsalib won't get on > with dw-hdmi only accepting 24-bit audio without this. A copy is > attached. It also tells ALSA how to deal with multi-channel audio > as well. Thanks, Russell! Got audio to play on my HDMI TV :-) For the entire series: Tested-by: Fabio Estevam
[Bug 105601] New: drm_wait_vblank log spam with reverse PRIME (intel+nouveau)
https://bugzilla.kernel.org/show_bug.cgi?id=105601 Bug ID: 105601 Summary: drm_wait_vblank log spam with reverse PRIME (intel+nouveau) Product: Drivers Version: 2.5 Kernel Version: 4.2.2 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: mschiffer+misc at universe-factory.net Regression: No Setup: I use reverse PRIME with a primary intel and a secondary nouveau card. I have enabled one output on each of the cards. The reverse PRIME (nouveau) output is set as primary output via xrandr. Whenever there's a DRI user on the reverse PRIME screen, the following message gets written to my kernel log once for each buffer swap: [drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x7d, supported mask 0x743f Both DRI2 and DRI3 cause this behaviour. Depending on the exact setup (DRI2/DRI3, different DRI users), I also get slightly different messages: [drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x15d, supported mask 0x743f [drm:drm_wait_vblank [drm]] *ERROR* Unsupported type value 0x400015d, supported mask 0x743f Hardware: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [Quadro NVS 4200M] (rev a1) -- You are receiving this mail because: You are watching the assignee of the bug.
i.mx6 video out in mainline
On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu wrote: > Hi All, > > I'm attempting to use a standard fb console (using the > imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p > portion of the screen. This is also true when running the userspace > tool fb-test. Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with 1024x768 resolution. I sent a patch that allows LDB and HDMI to work simultaneously: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/imx6qdl-sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b Can you try to adapt it for imx6qdl-gw54xx.dtsi? If this still does not help your HDMI output, please try disabling the LVDS.
[PATCH] drm: Check fb against plane size rather than CRTC mode for pageflip
The legacy pageflip ioctl calls drm_crtc_check_viewport() to determine
whether the framebuffer being flipped is big enough to fill the display
it is being flipped to. However some drivers support "windowing" of
their primary planes (i.e., a primary plane that does not cover the
entire CRTC dimensions); in such situations we can wind up rejecting
valid pageflips of buffers that are smaller than the display mode, but
still large enough to fill the entire primary plane.
What we really want to be comparing against for pageflips is the size of
the primary plane, which can be found in crtc->primary->state for atomic
drivers (and drivers in the process of transitioning to atomic). There
are no non-atomic drivers that support primary plane windowing at the
moment, so we'll continue to use the current behavior of looking at the
CRTC mode size on drivers that don't have a crtc->primary->state. We'll
also continue to use the existing logic for SetCrtc, which is the other
callsite for drm_crtc_check_viewport(), since legacy modesets reprogram
the primary plane and remove windowing.
Note that the existing code was checking a crtc->invert_dimensions field
to determine whether the width/height of the mode needed to be swapped.
A bonus of checking plane size is that the source width/height we get
already take rotation into account so that check is no longer necessary
when using the plane size.
Testcase: igt/universal-plane-gen9-features-pipe-#
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 87 +-
1 file changed, 71 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e600a5f..35cd4dc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2534,9 +2534,76 @@ void drm_crtc_get_hv_timing(const struct
drm_display_mode *mode,
}
EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+static int check_viewport(int hdisplay,
+ int vdisplay,
+ int x,
+ int y,
+ bool invert_dimensions,
+ const struct drm_framebuffer *fb)
+{
+ if (invert_dimensions)
+ swap(hdisplay, vdisplay);
+
+ if (hdisplay > fb->width ||
+ vdisplay > fb->height ||
+ x > fb->width - hdisplay ||
+ y > fb->height - vdisplay) {
+ DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height, hdisplay, vdisplay, x, y,
+ invert_dimensions ? " (inverted)" : "");
+ return -ENOSPC;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_plane_check_viewport - Checks that a framebuffer is big enough for the
+ * plane's viewport
+ * @plane: Plane that framebuffer will be displayed on
+ * @x: x panning
+ * @y: y panning
+ * @fb: framebuffer to check size of
+ *
+ * Atomic drivers (or transitioning drivers that support proper plane state)
+ * may call this function on any plane. Non-atomic drivers may only call this
+ * for the primary plane while the CRTC is active (we'll assume that the
+ * primary plane covers the entire CRTC in that case).
+ */
+int drm_plane_check_viewport(const struct drm_plane *plane,
+int x,
+int y,
+const struct drm_framebuffer *fb)
+
+{
+ struct drm_crtc *crtc = plane->crtc;
+ int hdisplay, vdisplay;
+
+ if (WARN_ON(plane->state == NULL &&
+ plane->type != DRM_PLANE_TYPE_PRIMARY))
+ return -EINVAL;
+
+ /*
+* Non-atomic drivers may not have valid plane state to look at. But
+* those drivers also don't support windowing of the primary plane, so
+* we can fall back to looking at the mode of the owning CRTC.
+*/
+ if (plane->state) {
+ hdisplay = plane->state->src_w >> 16;
+ vdisplay = plane->state->src_h >> 16;
+ } else if (WARN_ON(!crtc)) {
+ hdisplay = vdisplay = 0;
+ } else {
+ drm_crtc_get_hv_timing(&crtc->mode, &hdisplay, &vdisplay);
+ }
+
+ return check_viewport(hdisplay, vdisplay, x, y, false, fb);
+}
+EXPORT_SYMBOL(drm_plane_check_viewport);
+
/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
- * CRTC viewport
+ * CRTC viewport when running in the specified mode
* @crtc: CRTC that framebuffer will be displayed on
* @x: x panning
* @y: y panning
@@ -2553,20 +2620,8 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
drm_crtc_get_hv_timing(mode, &hdisplay, &vdisplay);
- if (crtc->invert_dimensions)
- swap(hdisplay, vdisplay);
-
- if (hdisplay > fb->width ||
- vdisplay > fb->height ||
- x > fb->width -
[PATCH 0/7] get_user_pages() cleanup
From: Jan Kara Hello, Now when the usage of get_user_pages() in media drivers got cleaned up, here comes a series which removes knowledge about mmap_sem from a couple of other drivers. Patches are trivial and standalone but please check, they are only compile tested. If you are OK with them, either take them through your respective trees or ack them and I can take care of pushing them to Linus (probably through mm tree). Thanks. After these patches there are some 12 call sites of get_user_pages() outside of core code (mostly infiniband and RDMA). So we are slowly getting to the goal of removing knowledge about page fault locking from drivers which will consequently allow us to change the locking rules with reasonable effort. Honza CC: Jesper Nilsson CC: linux-cris-kernel at axis.com CC: Mikael Starvik CC: linux-ia64 at vger.kernel.org CC: Tony Luck CC: David Airlie CC: dri-devel at lists.freedesktop.org CC: Timur Tabi CC: linux-rdma at vger.kernel.org CC: Roland Dreier CC: Daniel Vetter CC: David Airlie CC: dri-devel at lists.freedesktop.org CC: Andy Walls CC: linux-media at vger.kernel.org CC: Mauro Carvalho Chehab
[PATCH 6/7] drm/i915: Convert to use get_user_page_unlocked()
From: Jan Kara
Convert __i915_gem_userptr_get_pages_worker() to use
get_user_page_unlocked() so that we don't unnecessarily leak knowledge of
mm locking into driver code.
CC: Daniel Vetter
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Jan Kara
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 8fd431bcdfd3..5138fe61d2fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -585,19 +585,18 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
- down_read(&mm->mmap_sem);
while (pinned < num_pages) {
- ret = get_user_pages(work->task, mm,
-obj->userptr.ptr + pinned *
PAGE_SIZE,
-num_pages - pinned,
-!obj->userptr.read_only, 0,
-pvec + pinned, NULL);
+ ret = get_user_pages_unlocked(
+ work->task, mm,
+ obj->userptr.ptr + pinned * PAGE_SIZE,
+ num_pages - pinned,
+ !obj->userptr.read_only, 0,
+ pvec + pinned);
if (ret < 0)
break;
pinned += ret;
}
- up_read(&mm->mmap_sem);
}
mutex_lock(&dev->struct_mutex);
--
2.1.4
kernel NULL pointer dereference, IP: rs600_pm_prepare - huh?
Hi, > Looks like she installed some tool that attempts to change the power > state via sysfs during init which could happen before the driver has > finished loading. that was probably me, installing the "tlp" thinkpad tool remotely. Thanks for pointing me in the right direction: disabling solved it for now. > The attached kernel patch should fix it. Unfortunately wasn't able to test because she had bandwidth bottlenecks and I had next to no time to fix it.. Might be able to test it on my thinkpad in a while. #Best Regards!Marcel
PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)
Hi,
This issue is still present in 4.3-rc4.
On 9/24/15, Nick Bowler wrote:
> Testing out 4.3-rc2, first thing I notice is that the VGA output is
> not working. Specifically, the display is continuously powering on
> and off -- at no point is any image visible on the screen (I am expecting
> to see the console output). The display connected to the HDMI output is
> working fine.
>
> Linux 4.2 did not suffer from this problem.
>
> In dmesg I see the following messages, which I do not see on a working
> kernel. Full dmesg from 4.3-rc2 is attached (gzipped).
>
> [0.115339] [drm:drm_calc_timestamping_constants] *ERROR* crtc
> 21: Can't calculate constants, dotclock = 0!
> [0.117582] [drm:intel_opregion_init] *ERROR* No ACPI video bus found
>
> This is an older machine with Intel G45 graphics.
I was able to identify the commit which fixed my boot crashes, so I
cherry-picked 80aa93128653 ("drm/i915: disable_shared_pll doesn't
work on pre-gen5") on top of all otherwise untestable commits. This
allowed bisection to proceed:
b8afb9113c519a8bd742f7df8c424b0af69a75cd is the first bad commit
commit b8afb9113c519a8bd742f7df8c424b0af69a75cd
Author: Ville Syrjälä
Date: Mon Jun 29 15:25:48 2015 +0300
drm/i915: Keep GMCH DPLL VGA mode always disabled
We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
disabled. And let's just do that on all GMCH platforms to keep things
as similar as possible between them.
Signed-off-by: Ville Syrjälä
Reviewed-by: Sivakumar Thulasimani
Signed-off-by: Daniel Vetter
:04 04 7797d596e73ecf75723375028decd25fbe332ee0
9f90a92eec483919853d68563bbb09a71a305532 M drivers
Unfortunately it does not revert cleanly on master.
Regards,
Nick
i.mx6 video out in mainline
On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam wrote: > On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu wrote: >> Hi All, >> >> I'm attempting to use a standard fb console (using the >> imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p >> portion of the screen. This is also true when running the userspace >> tool fb-test. > > Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with > 1024x768 resolution. > > I sent a patch that allows LDB and HDMI to work simultaneously: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/imx6qdl-sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b > > Can you try to adapt it for imx6qdl-gw54xx.dtsi? > > If this still does not help your HDMI output, please try disabling the LVDS. When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I found that HDMI video out was slightly shifted to the left and resolution remained at 1024x768p. I also found that when I disabled DRM_IMX_LDB, HDMI out stopped working altogether, though if I stripped out the ldb section in device tree, the resolution comes back at 1080p (regardless of setting DRM_IMX_LDB or not). There is definitely some strange interdependency between lvds and hdmi here. Do you have an idea of where I should start looking for this problem? - Pushpal
[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
Hello Jyri, Thanks your feedback, my answers in line On 10/05/2015 03:27 PM, Jyri Sarha wrote: > On 10/01/15 19:50, Arnaud Pouliquen wrote: >> >> Version 2: >> This version integrates missing features upgraded to be aligned when possible >> with patch set: >> [PATCH RFC v4 0/8] Implement generic ASoC HDMI codec and use it in tda998x >> > > There are still some details I would like to change if we decide to go > the drm audio bridge way. But before all that, I would like to ask, > why should we go forward with your approach? Is there anything that > can be done with your approach, but can not be done with mine? > > Don't take me wrong, I do not see anything fundamentally wrong with > your approach. I would just like hear some justification why we should > abandon my approach - that I've been working on for some time - and go > forward with yours. Both implementations are similar in term of feature. And i think both have advantages and drawbacks... The main difference, is that my approach is based on a standard service client-provider model. Means that ops are defined by code in charge of providing the service (DRM) and not by the client (ALSA). I don't want to impose my implementation but just propose an alternative that makes sense for me. In a first step, before going deep in discussion on the approach, it should be interesting to have maintainers feedback, to be sure that my approach could make sense from DRM and ALSA point of view. @DRM (and ALSA) maintainers: Please, could you give a first feedback on such implementation based on DRM API extension? Is it something that could be acceptable (or not) from your point of view? > > Here is couple of benefits I can name in my approach: > Â Video side agnostic implementation > The ASoC side does not need to know anything about video side > implementation. There is no real exposure ASoC side internals in > video side either. Even fbdev driver, or some other non DRM video > driver, could use my implementation. My approach is the reverse: DRM driver does not need to know anything about audio side. As ALSA is the client of DRM, seems more logical from my point of view ... Now if a generic solution must be found for all video drivers, sure, your solution is more flexible. But if i well understood fbdev drivers are no more accepted for upstream (please correct me if I'm wrong). So i don't know we have to keep fbdev in picture... > - HDMI encoder driver implementations that do not use DRM bridge > abstraction do not need add an extra DRM object just to get the > audio working. > > Short comings I see in the current HDMI audio bridge approach: > > In its current from the DRM audio bridge abstraction pretends to be a > generic audio abstraction for DRM devices, but the implementation is > quite specific to external HDMI encoders with spdif and/or i2s > interface. There is a lot of HDMI video devices that provide the > digital audio interface (ASoC DAI) directly and there is no need for > anything but dummy codec implementation (if following ASoC > paradigm). Before going forward I think we should at least consider > how this abstraction would serve those devices. Sorry, but i don't see any difference between both implementations for this point.In both implementations, ops are called only if defined. Could you give me name of the drivers you have in mind? > > Also, I am not entirely happy how the drm_audio_bridge_funcs are used > at the moment. The do not map too well to ASoC DAI callbacks and I do > not see too much point in creating a completely new audio-callback > abstraction, that is sligtly incompatible with ALSA, and then > translating alsa callbacks to these new callbacks. I think the > callbacks should map more or less directly ALSA callbacks. As API is defined in DRM, it seems more logical to match it with the one defined for video. From my windows, i didn't see any blocking point to connect codec callback with this API. But anyway, this API is not freezed, it could be improved with your help. Best Regards, Arnaud
[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
On Tue, Oct 06, 2015 at 06:44:34PM +0300, Jyri Sarha wrote: > On 10/06/15 12:23, Arnaud Pouliquen wrote: > >In a first step, before going deep in discussion on the approach, it > >should be interesting to have maintainers feedback, to be sure that my > >approach could make sense from DRM and ALSA point of view. > Absolutely. In the end the maintainers need to make the final decision any > way. As I keep saying at least for me a very big part of that is going to be seeing some degree of consensus among the people working on HDMI. I really don't want to get something merged and then having people turn up shortly afterwards saying that there's some reason to redo everything and I don't have much familiarity with the video stuff so I'm largely relying on consensus and review from the DRM side (which seems to have been absent thus far). -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/07dfbcf3/attachment-0001.sig>
i.mx6 video out in mainline
Hi All, I'm attempting to use a standard fb console (using the imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p portion of the screen. This is also true when running the userspace tool fb-test. When I $(cat /sys/class/graphics/fb0/modes), I see only the 1024x768p resolution there. I verified that the edid read from the monitor is correct, and that all of it's modes were properly read (in the drm_mode_std function and enumerated in /sys/devices/soc0/display-subsystem/drm/card0/card0-HDMI-A-1/modes), but I can't figure out how to choose a different resolution. I've also verified that dpms is 'On'. The monitor appears to think that a 1080p signal is coming in, which might have to do with the virtual size being set to 1080p. I should note that I'm not running X11. Is there something I am missing that's required for changing framebuffer resolutions? Thanks ahead of time. - Pushpal
[PATCH 3/7] drm: Convert via driver to use get_user_pages_fast()
From: Jan Kara
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Jan Kara
---
drivers/gpu/drm/via/via_dmablit.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/via/via_dmablit.c
b/drivers/gpu/drm/via/via_dmablit.c
index d0cbd5ecd7f0..d71add236e62 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -238,14 +238,10 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,
drm_via_dmablit_t *xfer)
vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
if (NULL == vsg->pages)
return -ENOMEM;
- down_read(¤t->mm->mmap_sem);
- ret = get_user_pages(current, current->mm,
-(unsigned long)xfer->mem_addr,
-vsg->num_pages,
-(vsg->direction == DMA_FROM_DEVICE),
-0, vsg->pages, NULL);
-
- up_read(¤t->mm->mmap_sem);
+ ret = get_user_pages_fast((unsigned long)xfer->mem_addr,
+ vsg->num_pages,
+ (vsg->direction == DMA_FROM_DEVICE),
+ vsg->pages);
if (ret != vsg->num_pages) {
if (ret < 0)
return ret;
--
2.1.4
periodic wakeup from DPMS suspend
Hi, I have a NEC EA244WMi monitor connected to an Asus P8H77-V mainboard with Ivy Bridge Core i5-3550 via DVI. If DPMS suspend is enabled (by xscreensaver, or for testing by "xset dpms force off/suspend/standby"), the monitor enters standby mode but wakes up every 10...30 seconds for 6 seconds to display a "DVI-D: no signal" message. How can I find out if this is an issue of the NEC monitor or the Intel graphics? - when I pull the DVI cable the monitor stays in suspend - I tried to use drm.debug=6 and ftrace to see if something is periodically accessing DDC or similar, but it didn't reveal anything to me, but then I know nothing about graphics drivers and probably didn't do it right I noticed there is some hotplug detection code, my initial thought was that this could cause the wakeup. But since the period is somewhat irregular maybe it is some floating signal line causing the monitor to misdetect activity? Currently I'm running 4.2.3, but the same issue happens with older kernels, I tried 3.17+. Let me know if you have any ideas what to try. BTW, in sysfs the output shows up as HDMI-A-2: (the board has VGA, DVI, HDMI and DP) $ find /sys -name edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-1/edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-3/edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-1/edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-2/edid /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-3/edid Another observation is that the HDMI-A-* outputs don't have an i2c node to link the matching DDC channel, while the DP outputs have? $ grep . /sys/class/i2c-dev/i2c-*/name /sys/class/i2c-dev/i2c-0/name:i915 gmbus ssc /sys/class/i2c-dev/i2c-1/name:i915 gmbus vga /sys/class/i2c-dev/i2c-2/name:i915 gmbus panel /sys/class/i2c-dev/i2c-3/name:i915 gmbus dpc /sys/class/i2c-dev/i2c-4/name:i915 gmbus dpb /sys/class/i2c-dev/i2c-5/name:i915 gmbus dpd /sys/class/i2c-dev/i2c-6/name:DPDDC-B /sys/class/i2c-dev/i2c-7/name:DPDDC-C /sys/class/i2c-dev/i2c-8/name:DPDDC-D The monitor brightness can be controlled via /dev/i2c-3 with ddccontrol. TIA, Johannes
periodic wakeup from DPMS suspend
On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach wrote: > Hi, > > I have a NEC EA244WMi monitor connected to an Asus P8H77-V > mainboard with Ivy Bridge Core i5-3550 via DVI. > If DPMS suspend is enabled (by xscreensaver, or for testing by > "xset dpms force off/suspend/standby"), the monitor > enters standby mode but wakes up every 10...30 seconds for > 6 seconds to display a "DVI-D: no signal" message. > > How can I find out if this is an issue of the NEC monitor > or the Intel graphics? > > - when I pull the DVI cable the monitor stays in suspend > > - I tried to use drm.debug=6 and ftrace to see if something > is periodically accessing DDC or similar, but it didn't > reveal anything to me, but then I know nothing about > graphics drivers and probably didn't do it right > > I noticed there is some hotplug detection code, > my initial thought was that this could cause the > wakeup. But since the period is somewhat irregular > maybe it is some floating signal line causing the > monitor to misdetect activity? > > Currently I'm running 4.2.3, but the same issue > happens with older kernels, I tried 3.17+. > > Let me know if you have any ideas what to try. Some monitors periodically scan all of their inputs if they are not actively being driven by anything to try and automatically switch to the connected input. When the monitor scans the DVI input, it sees load on the pins and turns on, only to realize it's not getting a signal and then turns off. If your monitor has an option to turn off input probing, that might help. Alex > > > > > > BTW, in sysfs the output shows up as HDMI-A-2: > (the board has VGA, DVI, HDMI and DP) > > $ find /sys -name edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-1/edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-3/edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-1/edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-2/edid > /sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-3/edid > > Another observation is that the HDMI-A-* outputs don't > have an i2c node to link the matching DDC channel, > while the DP outputs have? > > $ grep . /sys/class/i2c-dev/i2c-*/name > /sys/class/i2c-dev/i2c-0/name:i915 gmbus ssc > /sys/class/i2c-dev/i2c-1/name:i915 gmbus vga > /sys/class/i2c-dev/i2c-2/name:i915 gmbus panel > /sys/class/i2c-dev/i2c-3/name:i915 gmbus dpc > /sys/class/i2c-dev/i2c-4/name:i915 gmbus dpb > /sys/class/i2c-dev/i2c-5/name:i915 gmbus dpd > /sys/class/i2c-dev/i2c-6/name:DPDDC-B > /sys/class/i2c-dev/i2c-7/name:DPDDC-C > /sys/class/i2c-dev/i2c-8/name:DPDDC-D > > The monitor brightness can be controlled via > /dev/i2c-3 with ddccontrol. > > > TIA, > Johannes > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
