[Bug 50360] flightgear has absymal performance with the llvm shader compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50360 --- Comment #1 from Vadim Girlin 2012-05-25 15:21:57 PDT --- Created attachment 62113 --> https://bugs.freedesktop.org/attachment.cgi?id=62113 patch Does this patch help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #72 from thor at math.tu-berlin.de 2012-05-25 14:51:23 PDT --- Ok, I managed to cross-compile the patched kernel sources on a much faster x64 machine, so I now have an initrd and a vmlinuz with the patch in it. I won't have access to the machine until tomorrow. Is this already supposed to do anything interesting, or would anyone just be interested in the debug output? I also found a datasheet from national semiconductor for the DS90C2501, is this the right one? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Returned mail: see transcript for details
The original message was received at Fri, 25 May 2012 21:30:09 +0800 from astier.eu [37.146.110.142] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.freedesktop.org.: >>> MAIL From:anisse at astier.eu <<< 501 anisse at astier.eu... Refused -- next part -- A non-text attachment was scrubbed... Name: transcript.zip Type: application/octet-stream Size: 22216 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120525/8b29ee63/attachment-0001.obj>
[Bug 43207] radeon driver on HD6570 shows pixel noise
https://bugzilla.kernel.org/show_bug.cgi?id=43207 --- Comment #9 from Vladislav Tcendrovskii 2012-05-25 20:10:06 --- I've tried this patch on kernel 3.4, but the only visible result - switching from noisy X screen to framebuffer console is much faster. After such switching noise disappears. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 50360] New: flightgear has absymal performance with the llvm shader compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50360 Bug #: 50360 Summary: flightgear has absymal performance with the llvm shader compiler Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: aaalmosss at gmail.com I get ~3 fps with the LLVM compiler, while I get ~20 fps with `R600_LLVM=0 fgfs`. The only setting on the 'rendering options' dialog that affects framerate is 'material shaders', when it's off, I get ~50 fps with both compilers. Other games perform around the same with the two compilers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50232] screen redraw is wrong in sauerbraten with the llvm compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50232 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from almos 2012-05-25 10:55:10 PDT --- I see the fix was pushed to mesa master. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50230] offset mapping in nexuiz results in bad texturing with the llvm compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50230 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from almos 2012-05-25 10:54:31 PDT --- I see the fixes were pushed to mesa master. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
> > There are multiple ways synchronization can be achieved, > > fences/sync objects is one common approach, however we're > > presenting a different approach. Personally, I quite like > > fence sync objects, however we believe it requires a lot of > > userspace interfaces to be changed to pass around sync object > > handles. Our hope is that the kds approach will require less > > effort to make use of as no existing userspace interfaces need > > to be changed. E.g. To use explicit fences, the struct > > drm_mode_crtc_page_flip would need a new members to pass in the > > handle(s) of sync object(s) which the flip depends on (I.e. > > don't flip until these fences fire). The additional benefit of > > our approach is that it prevents userspace specifying dependency > > loops which can cause a deadlock (see kds.txt for an explanation > > of what I mean here). > > It is easy to cause cyclic dependencies with implicit fences unless you > are very sure that client can only cause linear implicit dependencies. I'm not sure I know what you mean by linear implicit dependencies? > But clients already have synchronization dependencies with userspace. > That makes implicit synchronization possibly cause unexpected > deadlocks. Again, not sure what you mean here? Do you mean that userspace can Submit a piece of work to a driver which depends on something else happening in userpsace? > Explicit synchronization is easier to debug because developer using > explicit synchronization can track the dependencies in userspace. But > of course that makes userspace API harder to use than API using > implicitly synchronization. > > But implicit synchronization can avoid client deadlock issues. > Providing if client may never block "fence" from triggering in finite > time when it is granted access. The page flip can be synchronized in > that manner if client can't block HW from processing queued rendering. Yes, I guess this is the critical point - this approach assumes that when a client starts using a resource, it will only do so for a finite amount of time. If userspace wanted to participate in the scheme, we would probably need some kind of timeout, otherwise userspace could prevent other devices from accessing a resource. > You were talking about adding new parameter to page flip ioctl. I fail > to see need for it because page flip already has fb object as parameter > that should map to the implicit synchronization fence through dma_buf. This is the point I was trying to make. With explicit fence objects you do have to add a new parameter, whereas with this kds implicit approach you do not - the buffer itself becomes the sync object. > > While KDS defines a very generic mechanism, I am proposing that > > this code or at least the concepts be merged with the existing > > > dma_buf code, so a the struct kds_resource members get moved to > > struct dma_buf, kds_* functions get renamed to dma_buf_* > > functions, etc. So I guess what I'm saying is please don't review > > the actual code just yet, only the concepts the code describes, > > where kds_resource == dma_duf. > > But the documented functionality sounds very much deadlock prone. If > userspace gets exclusive access and needs to wait for implicit access > synchronization. > > app A has access to buffer X > app B requests exclusive access to buffer X and blocks waiting for access > app A makes synchronous IPC call to app B > > I didn't read the actual code at all to figure out if that is possible > scenario. But it sounds like possible scenario based on documentation > talking EGL depending on exclusive access. The intention was to use this mechanism for synchronizing between drivers rather than between userspace processes, I think the userspace access is somewhat an afterthought which will probably need some more thought. In the example you give, app A making a synchronous IPC call to app B breaks the clients must guarantee they complete in a finite time, which in the case of userspace access could be enforced by a timeout. Though I would have thought there's a better way to handle this than just a timeout. Cheers, Tom
[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
On 25/05/12 14:08, Tom Cooksey wrote: > Hi All, > > I realise it's been a while since this was last discussed, however I'd like > to bring up kernel-side synchronization again. By kernel-side > synchronization, I mean allowing multiple drivers/devices wanting to access > the same buffer to do so without bouncing up to userspace to resolve > dependencies such as "the display controller can't start scanning out a > buffer until the GPU has finished rendering into it". As such, this is > really just an optimization which reduces latency between E.g. The GPU > finishing a rendering job and that buffer being scanned out. I appreciate > this particular example is already solved on desktop graphics cards as the > display controller and 3D core are both controlled by the same driver, so no > "generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM > Mali) and display controller tend to be driven by separate drivers, so some > mechanism is needed to allow both drivers to synchronize their access to > buffers. > > There are multiple ways synchronization can be achieved, fences/sync objects > is one common approach, however we're presenting a different approach. > Personally, I quite like fence sync objects, however we believe it requires > a lot of userspace interfaces to be changed to pass around sync object > handles. Our hope is that the kds approach will require less effort to make > use of as no existing userspace interfaces need to be changed. E.g. To use > explicit fences, the struct drm_mode_crtc_page_flip would need a new members > to pass in the handle(s) of sync object(s) which the flip depends on (I.e. > don't flip until these fences fire). The additional benefit of our approach > is that it prevents userspace specifying dependency loops which can cause a > deadlock (see kds.txt for an explanation of what I mean here). It is easy to cause cyclic dependencies with implicit fences unless you are very sure that client can only cause linear implicit dependencies. But clients already have synchronization dependencies with userspace. That makes implicit synchronization possibly cause unexpected deadlocks. Explicit synchronization is easier to debug because developer using explicit synchronization can track the dependencies in userspace. But of course that makes userspace API harder to use than API using implicitly synchronization. But implicit synchronization can avoid client deadlock issues. Providing if client may never block "fence" from triggering in finite time when it is granted access. The page flip can be synchronized in that manner if client can't block HW from processing queued rendering. You were talking about adding new parameter to page flip ioctl. I fail to see need for it because page flip already has fb object as parameter that should map to the implicit synchronization fence through dma_buf. > I have waited until now to bring this up again because I am now able to > share the code I was trying (and failing I think) to explain previously. The > code has now been released under the GPLv2 from ARM Mali's developer portal, > however I've attempted to turn that into a patch to allow it to be discussed > on this list. Please find the patch inline below. > > While KDS defines a very generic mechanism, I am proposing that this code or > at least the concepts be merged with the existing dma_buf code, so a the > struct kds_resource members get moved to struct dma_buf, kds_* functions get > renamed to dma_buf_* functions, etc. So I guess what I'm saying is please > don't review the actual code just yet, only the concepts the code describes, > where kds_resource == dma_duf. But the documented functionality sounds very much deadlock prone. If userspace gets exclusive access and needs to wait for implicit access synchronization. app A has access to buffer X app B requests exclusive access to buffer X and blocks waiting for access app A makes synchronous IPC call to app B I didn't read the actual code at all to figure out if that is possible scenario. But it sounds like possible scenario based on documentation talking EGL depending on exclusive access. > > Cheers, > > Tom > Pauli
[PATCH] gpu: remove gma500 stub driver
On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > In v3.3, the gma500 drm driver moved from staging to drm group by > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > brightness well and don't need gma500 stub driver anymore. > > Cc: randy.dunlap at oracle.com > Cc: mjg59 at srcf.ucam.org > Cc: gregkh at suse.de Note, my email address has changed :) Acked-by: Greg Kroah-Hartman
[PATCH] gpu: remove gma500 stub driver
? ??2012-05-25 ? 16:07 +0900?Greg KH ??? > On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > Cc: randy.dunlap at oracle.com > > Cc: mjg59 at srcf.ucam.org > > Cc: gregkh at suse.de > > Note, my email address has changed :) > Sorry~~~! I will keep in mind! :-) > Acked-by: Greg Kroah-Hartman > > Thanks a lot! Joey Lee
[Bug 50360] flightgear has absymal performance with the llvm shader compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50360 --- Comment #1 from Vadim Girlin 2012-05-25 15:21:57 PDT --- Created attachment 62113 --> https://bugs.freedesktop.org/attachment.cgi?id=62113 patch Does this patch help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: schedule gma500 stub driver for feature removal
On Fri, 25 May 2012 04:53:50 +0900 Greg KH wrote: > On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > Why not just remove it right now as it's not needed at all anymore? If there are distros not currently ahipping the GMA500 driver or people updating old kernels using vesa and not having the right server bits it might cause them problems - giving it 6 months isn't a bad idea IMHO
[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #72 from t...@math.tu-berlin.de 2012-05-25 14:51:23 PDT --- Ok, I managed to cross-compile the patched kernel sources on a much faster x64 machine, so I now have an initrd and a vmlinuz with the patch in it. I won't have access to the machine until tomorrow. Is this already supposed to do anything interesting, or would anyone just be interested in the debug output? I also found a datasheet from national semiconductor for the DS90C2501, is this the right one? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [PATCH] dma-buf: fix disabled vmap function
Hi Dave,
On 25 May 2012 14:34, Dave Airlie wrote:
> From: Dave Airlie
>
> include/linux/dma-buf.h: In function ?dma_buf_vmap?:
> include/linux/dma-buf.h:260:1: warning: no return statement in function
> returning non-void [-Wreturn-type]
>
> Reported-by: wfg at linux.intel.com
> Signed-off-by: Dave Airlie
> ---
> ?include/linux/dma-buf.h | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d8c2865..506bb7b 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
>
> ?static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
> ?{
> + ? ? ? return NULL;
> ?}
I fixed this as part of rebasing while applying your vmap patch to my
for-next - so it is already in my pull request.
Best regards,
~Sumit.
>
> ?static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> --
> 1.7.6
>
>
> ___
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
[GIT PULL]: dma-buf updates for 3.5
Hi Linus, On 25 May 2012 13:25, Sumit Semwal wrote: > Hi Linus, > > Here's the first signed-tag pull request for dma-buf framework. > > Could you please pull the dma-buf updates for 3.5? This includes the > following key items: > - mmap support > - vmap support > - related documentation updates > > These are needed by various drivers to allow mmap/vmap of dma-buf > shared buffers. Dave Airlie has some prime patches dependent on the > vmap pull as well. > > Thanks and best regards, > ~Sumit. > > > The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: > > ?Linux 3.4 (2012-05-20 15:29:13 -0700) > > are available in the git repository at: > > ?ssh://sumitsemwal at git.linaro.org/~/public_git/linux-dma-buf.git > tags/tag-for-linus-3.5 I am really sorry - I goofed up in the git URL (sent the ssh URL instead). Could you please use git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/tag-for-linus-3.5 instead, or should I send a new pull request with the corrected URL? Thanks, and best regards, ~Sumit. > > for you to fetch changes up to b25b086d23eb852bf3cfdeb60409b4967ebb3c0c: > > ?dma-buf: add initial vmap documentation (2012-05-25 12:51:11 +0530) > > > dma-buf updates for 3.5 > > > Daniel Vetter (1): > ? ? ?dma-buf: mmap support > > Dave Airlie (2): > ? ? ?dma-buf: add vmap interface > ? ? ?dma-buf: add initial vmap documentation > > Sumit Semwal (1): > ? ? ?dma-buf: minor documentation fixes. > > ?Documentation/dma-buf-sharing.txt | ?109 > ++--- > ?drivers/base/dma-buf.c ? ? ? ? ? ?| ? 99 - > ?include/linux/dma-buf.h ? ? ? ? ? | ? 33 +++ > ?3 files changed, 233 insertions(+), 8 deletions(-) -- Thanks and regards, Sumit Semwal Linaro Kernel Engineer - Graphics working group Linaro.org???Open source software for ARM SoCs Follow?Linaro:?Facebook?|?Twitter?|?Blog
drm: add helper to clflush a virtual address range
Hi Daniel,
I see you say you wanted the patch below for the stable tree, due to
some later patch needing it, yet this patch was not "marked" for the
stable tree, and I can't seem to figure out which "later patch" you are
referring to here.
Any hints on what I should do for the 3.4-stable kernel tree with this?
thanks,
greg k-h
On Thu, May 24, 2012 at 07:55:29PM +, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> Commit: 6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> Parent: dbf7bff074d5fdc87c61b1b41d8e809109cf0bf8
> Author: Daniel Vetter
> AuthorDate: Sun Mar 25 19:47:30 2012 +0200
> Committer: Daniel Vetter
> CommitDate: Tue Mar 27 13:19:45 2012 +0200
>
> drm: add helper to clflush a virtual address range
>
> Useful when the page is already mapped to copy date in/out.
>
> For -stable because the next patch (fixing phys obj pwrite) needs this
> little helper function.
>
> Tested-by: Chris Wilson
> Reviewed-by: Chris Wilson
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_cache.c | 23 +++
> include/drm/drmP.h |1 +
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 5928653..c7c8f6b 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -98,3 +98,26 @@ drm_clflush_pages(struct page *pages[], unsigned long
> num_pages)
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_pages);
> +
> +void
> +drm_clflush_virt_range(char *addr, unsigned long length)
> +{
> +#if defined(CONFIG_X86)
> + if (cpu_has_clflush) {
> + char *end = addr + length;
> + mb();
> + for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> + clflush(addr);
> + clflush(end - 1);
> + mb();
> + return;
> + }
> +
> + if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> + printk(KERN_ERR "Timed out waiting for cache flush.\n");
> +#else
> + printk(KERN_ERR "Architecture has no drm_cache.c support\n");
> + WARN_ON_ONCE(1);
> +#endif
> +}
> +EXPORT_SYMBOL(drm_clflush_virt_range);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 92f0981..d33597b 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1332,6 +1332,7 @@ extern int drm_remove_magic(struct drm_master *master,
> drm_magic_t magic);
>
> /* Cache management (drm_cache.c) */
> void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
> +void drm_clflush_virt_range(char *addr, unsigned long length);
>
> /* Locking IOCTL support (drm_lock.h) */
> extern int drm_lock(struct drm_device *dev, void *data,
> --
> To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[pull] drm-intel-fixes for 3.5
On Thu, May 24, 2012 at 05:56:24PM +0200, Daniel Vetter wrote: > Hi Dave, > > A set of fixes for 3.5: > - Fixes for regressions in 3.5: fix spurious gmbus NAK, fix module unload, > fix pch pll asserts. > - Fix up eDP panel power sequencing - turns out we need to keep vdd on > while switching everything off. > - Reject doubleclocked modes on dp. > - Fixup sdvo interlaced handling. It never worked, but the missing bits > are just a tiny patch. > - Re-add some accidentally killed tv modes, also re-add > a vblank wait in the tv detect code that we've lost somewhere around > 2.6.36. > - Preliminary ducttape for gpu turbo on snb+ - we're working the hw guys > to figure out what's missing, because this code /should/ be the same the > windows driver does. But that usually takes a while ... > - Fixup turbo for media workloads on snb+. > - And a no-lvds quirk. As dicussed on irc I've smashed 3 more patches onto this: - Shut up the noisy rps turbo message. - Don't complain about unbinding pinned buffers any more - we now use that check intentionally. - Limit broadwater/crestline (i.e. vintage i965g/gm) to DMA32 for shmfs. Note that this requires, like gma500 the improved shmfs code to make it really tight. But otoh the only a few indirect states can't be above 4G, so this should be sufficient in all but the most contrived cases. Yours, Daniel The following changes since commit f15b4ca2ccbc0a4661c35a744d254e1e32dd1e15: Merge tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next (2012-05-21 08:17:42 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to ef12dab779acdb907eb4c3fa723e1c6f035ee13c: drm/i915: tune down the noise of the RP irq limit fail (2012-05-25 10:29:15 +0200) Chris Wilson (4): drm/i915: Always update RPS interrupts thresholds along with frequency drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationship drm/i915: Limit page allocations to lowmem (dma32) for i965 drm/i915: Remove the error message for unbinding pinned buffers Daniel Vetter (7): drm/i915: be more careful when returning -ENXIO in gmbus transfer drm/i915: fix module unload since error_state rework drm/i915: properly handle interlaced bit for sdvo dtd conversion drm/i915: enable vdd when switching off the eDP panel drm/i915: wait for a vblank to pass after tv detect drm/i915: reject doubleclocked cea modes on dp drm/i915: tune down the noise of the RP irq limit fail Jan-Benedict Glaw (1): drm/i915: no lvds quirk for HP t5740e Thin Client Jesse Barnes (1): drm/i915: always use RPNSWREQ for turbo change requests Rodrigo Vivi (1): drm/i915: Adding TV Out Missing modes. drivers/gpu/drm/i915/i915_debugfs.c|2 + drivers/gpu/drm/i915/i915_gem.c| 16 +--- drivers/gpu/drm/i915/i915_irq.c| 37 -- drivers/gpu/drm/i915/intel_display.c | 56 drivers/gpu/drm/i915/intel_dp.c| 24 +++- drivers/gpu/drm/i915/intel_i2c.c | 21 ++- drivers/gpu/drm/i915/intel_lvds.c |8 drivers/gpu/drm/i915/intel_pm.c| 64 ++-- drivers/gpu/drm/i915/intel_sdvo.c | 12 -- drivers/gpu/drm/i915/intel_sdvo_regs.h |5 +++ drivers/gpu/drm/i915/intel_tv.c| 53 ++ 11 files changed, 197 insertions(+), 101 deletions(-) -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 43272] pink/purple line displays to the left of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=43272 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED CC||alan at lxorguk.ukuu.org.uk -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Intel-gfx] [PATCH 02/14] drm: handle HDP and polled connectors separately
On 5/24/12 3:26 PM, Daniel Vetter wrote: > Instead of reusing the polling code for hdp handling, split them up. > This has a few consequences: > - Don't touch HDP capable connectors in the poll loop. > - Only touch HDP capable connectors in drm_helper_hpd_irq_event. > - Run the HDP handling directly instead of going through a work item - >all callers already call drm_helper_hpd_irq_event from process >context without holding the mode_config mutex. "HPD". > - /* if this is HPD or polled don't check it - > -TV out for instance */ > - if (!connector->polled) > + /* Ignore HDP capable connectors and connectors where we don't > + * want any hotplug detection at all for polling. */ > + if (!connector->polled || connector->polled == > DRM_CONNECTOR_POLL_HPD) Here too. Also in the subject. - ajax
[GIT PULL]: dma-buf updates for 3.5
Hi Linus, Here's the first signed-tag pull request for dma-buf framework. Could you please pull the dma-buf updates for 3.5? This includes the following key items: - mmap support - vmap support - related documentation updates These are needed by various drivers to allow mmap/vmap of dma-buf shared buffers. Dave Airlie has some prime patches dependent on the vmap pull as well. Thanks and best regards, ~Sumit. The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: Linux 3.4 (2012-05-20 15:29:13 -0700) are available in the git repository at: ssh://sumitsemwal at git.linaro.org/~/public_git/linux-dma-buf.git tags/tag-for-linus-3.5 for you to fetch changes up to b25b086d23eb852bf3cfdeb60409b4967ebb3c0c: dma-buf: add initial vmap documentation (2012-05-25 12:51:11 +0530) dma-buf updates for 3.5 Daniel Vetter (1): dma-buf: mmap support Dave Airlie (2): dma-buf: add vmap interface dma-buf: add initial vmap documentation Sumit Semwal (1): dma-buf: minor documentation fixes. Documentation/dma-buf-sharing.txt | 109 ++--- drivers/base/dma-buf.c| 99 - include/linux/dma-buf.h | 33 +++ 3 files changed, 233 insertions(+), 8 deletions(-)
[Bug 43207] radeon driver on HD6570 shows pixel noise
https://bugzilla.kernel.org/show_bug.cgi?id=43207 --- Comment #9 from Vladislav Tcendrovskii 2012-05-25 20:10:06 --- I've tried this patch on kernel 3.4, but the only visible result - switching from noisy X screen to framebuffer console is much faster. After such switching noise disappears. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: introduce DRM_CONNECTOR_POLL_FORCE
Useful for ->detect functions that have different behaviour if force
is set. This way probe_single_connector can avoid to do the expensive
edid dance on connectors where this is not needed.
I've checked through all drivers and set this flag everywhere where
the connector->detect function has different behaviour if force is
set. For nouveau and radeon I've got lost in the code traces, so I've
set this flag unconditionally.
Note that we also need to update the poll_execute function to now
also ignore connectors which have only this new flag set.
v2: Change POLL_HDP checks so that they ignore POLL_FORCE for both the
poll and the hpd handling code.
v3: Sprinkle POLL_FORCE more liberally over drivers. It should be now
everywhere where a non-intel driver can return anything else than
connector_status_connected in its detect callback.
v4: Fixup psb compile fail.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |6 --
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 ++
drivers/gpu/drm/gma500/cdv_intel_crt.c|2 ++
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 ++
drivers/gpu/drm/gma500/mdfld_dsi_output.c |1 +
drivers/gpu/drm/gma500/oaktrail_hdmi.c|2 ++
drivers/gpu/drm/gma500/psb_intel_sdvo.c |2 ++
drivers/gpu/drm/i915/intel_crt.c |3 ++-
drivers/gpu/drm/i915/intel_tv.c |3 ++-
drivers/gpu/drm/nouveau/nouveau_connector.c |1 +
drivers/gpu/drm/radeon/radeon_connectors.c|5 +
drivers/gpu/drm/udl/udl_connector.c |2 ++
drivers/staging/omapdrm/omap_connector.c |2 ++
include/drm/drm_crtc.h|4
14 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b1d643d..8ea1c1e 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -944,7 +944,9 @@ static void output_poll_execute(struct work_struct *work)
/* Ignore HDP capable connectors and connectors where we don't
* want any hotplug detection at all for polling. */
- if (!connector->polled || connector->polled ==
DRM_CONNECTOR_POLL_HPD)
+ if (!connector->polled ||
+ connector->polled == DRM_CONNECTOR_POLL_FORCE ||
+ (connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
@@ -1029,7 +1031,7 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
/* Only handle HPD capable connectors. */
- if (connector->polled != DRM_CONNECTOR_POLL_HPD)
+ if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
old_status = connector->status;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index bf791fa..e5a8a27 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -327,6 +327,8 @@ struct drm_connector *exynos_drm_connector_create(struct
drm_device *dev,
drm_connector_init(dev, connector, &exynos_connector_funcs, type);
drm_connector_helper_add(connector, &exynos_connector_helper_funcs);
+ connector->polled |= DRM_CONNECTOR_POLL_FORCE;
+
err = drm_sysfs_connector_add(connector);
if (err)
goto err_connector;
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 1874220..e6b2e49 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -313,6 +313,8 @@ void cdv_intel_crt_init(struct drm_device *dev,
drm_connector_helper_add(connector,
&cdv_intel_crt_connector_helper_funcs);
+ connector->polled |= DRM_CONNECTOR_POLL_FORCE;
+
drm_sysfs_connector_add(connector);
return;
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 88b59d4..766aec8 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -373,6 +373,8 @@ void cdv_hdmi_init(struct drm_device *dev,
hdmi_priv->hdmi_i2c_adapter =
&(psb_intel_encoder->i2c_bus->adapter);
hdmi_priv->dev = dev;
+ connector->polled |= DRM_CONNECTOR_POLL_FORCE;
+
drm_sysfs_connector_add(connector);
return;
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 5675d93..0e97a91 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -604,6 +604,7 @@ void mdfld_
[Bug 12882] [855GM missing DVO driver] s-video not detected
https://bugs.freedesktop.org/show_bug.cgi?id=12882 Daniel Vetter changed: What|Removed |Added Summary|[855GM missng DVO driver] |[855GM missing DVO driver] |s-video not detected|s-video not detected -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
Hi All,
I realise it's been a while since this was last discussed, however I'd like
to bring up kernel-side synchronization again. By kernel-side
synchronization, I mean allowing multiple drivers/devices wanting to access
the same buffer to do so without bouncing up to userspace to resolve
dependencies such as "the display controller can't start scanning out a
buffer until the GPU has finished rendering into it". As such, this is
really just an optimization which reduces latency between E.g. The GPU
finishing a rendering job and that buffer being scanned out. I appreciate
this particular example is already solved on desktop graphics cards as the
display controller and 3D core are both controlled by the same driver, so no
"generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM
Mali) and display controller tend to be driven by separate drivers, so some
mechanism is needed to allow both drivers to synchronize their access to
buffers.
There are multiple ways synchronization can be achieved, fences/sync objects
is one common approach, however we're presenting a different approach.
Personally, I quite like fence sync objects, however we believe it requires
a lot of userspace interfaces to be changed to pass around sync object
handles. Our hope is that the kds approach will require less effort to make
use of as no existing userspace interfaces need to be changed. E.g. To use
explicit fences, the struct drm_mode_crtc_page_flip would need a new members
to pass in the handle(s) of sync object(s) which the flip depends on (I.e.
don't flip until these fences fire). The additional benefit of our approach
is that it prevents userspace specifying dependency loops which can cause a
deadlock (see kds.txt for an explanation of what I mean here).
I have waited until now to bring this up again because I am now able to
share the code I was trying (and failing I think) to explain previously. The
code has now been released under the GPLv2 from ARM Mali's developer portal,
however I've attempted to turn that into a patch to allow it to be discussed
on this list. Please find the patch inline below.
While KDS defines a very generic mechanism, I am proposing that this code or
at least the concepts be merged with the existing dma_buf code, so a the
struct kds_resource members get moved to struct dma_buf, kds_* functions get
renamed to dma_buf_* functions, etc. So I guess what I'm saying is please
don't review the actual code just yet, only the concepts the code describes,
where kds_resource == dma_duf.
Cheers,
Tom
Author: Tom Cooksey
Date: Fri May 25 10:45:27 2012 +0100
Add new system to allow synchronizing access to resources
See Documentation/kds.txt for details, however the general
idea is that this kds framework synchronizes multiple drivers
("clients") wanting to access the same resources, where a
resource is typically a 2D image buffer being shared around
using dma-buf.
Note: This patch is created by extracting the sources from the
tarball on and putting them in
roughly the right places.
diff --git a/Documentation/kds.txt b/Documentation/kds.txt
new file mode 100644
index 000..a96db21
--- /dev/null
+++ b/Documentation/kds.txt
@@ -0,0 +1,113 @@
+#
+# (C) COPYRIGHT 2012 ARM Limited. All rights reserved.
+#
+# This program is free software and is provided to you under the terms of
the GNU General Public License version 2
+# as published by the Free Software Foundation, and any use by you of this
program is subject to the terms of such GNU licence.
+#
+# A copy of the licence is included with the program, and can also be
obtained from Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
+#
+#
+
+
+==
+kds - Kernel Dependency System
+==
+
+Introduction
+
+kds provides a mechanism for clients to atomically lock down multiple
abstract resources.
+This can be done either synchronously or asynchronously.
+Abstract resources is used to allow a set of clients to use kds to control
access to any
+resource, an example is structured memory buffers.
+
+kds supports that buffer is locked for exclusive access and sharing of
buffers.
+
+kds can be built as either a integrated feature of the kernel or as a
module.
+It supports being compiled as a module both in-tree and out-of-tree.
+
+
+Concepts
+
+A core concept in kds is abstract resources.
+A kds resource is just an abstraction for some client object, kds doesn't
care what it is.
+Typically EGL will consider UMP buffers as being a resource, thus each UMP
buffer has
+a kds resource for synchronization to the buffer.
+
+kds allows a client to create and destroy the abstract resource objects.
+A new resource object is made available asap (it is just a simple malloc
with some initializations),
+whi
[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 Daniel Vetter changed: What|Removed |Added Summary|[830M] need support for |[830M missing dvo driver] |DVO-LVDS via na2501 |need support for DVO-LVDS ||via na2501 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 12882] [855GM missng DVO driver] s-video not detected
https://bugs.freedesktop.org/show_bug.cgi?id=12882 Daniel Vetter changed: What|Removed |Added Summary|[855GM DVO] s-video not |[855GM missng DVO driver] |detected (DVO TV not|s-video not detected |supported yet) | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30845] [855 missing dvo driver] DVI output unsupported
https://bugs.freedesktop.org/show_bug.cgi?id=30845 Daniel Vetter changed: What|Removed |Added Severity|normal |enhancement Priority|medium |lowest Summary|[855] DVI output|[855 missing dvo driver] |unsupported |DVI output unsupported --- Comment #6 from Daniel Vetter 2012-05-25 05:05:59 PDT --- Downgrading all missing dvo driver bugs to feature request level. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 17902] [830M] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 Chris Wilson changed: What|Removed |Added CC||thor at math.tu-berlin.de --- Comment #71 from Chris Wilson 2012-05-25 05:01:20 PDT --- *** Bug 50303 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50360] New: flightgear has absymal performance with the llvm shader compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50360 Bug #: 50360 Summary: flightgear has absymal performance with the llvm shader compiler Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: aaalmo...@gmail.com I get ~3 fps with the LLVM compiler, while I get ~20 fps with `R600_LLVM=0 fgfs`. The only setting on the 'rendering options' dialog that affects framerate is 'material shaders', when it's off, I get ~50 fps with both compilers. Other games perform around the same with the two compilers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 2/2] libdrm: atomic mode set
From: Ville Syrj?l?
---
include/drm/drm.h |1 +
include/drm/drm_mode.h | 13 +++
xf86drmMode.c | 270
xf86drmMode.h | 19
4 files changed, 303 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5e6cd29..c3236e1 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -733,6 +733,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
#define DRM_IOCTL_MODE_OBJ_GETPROPERTIES DRM_IOWR(0xB9, struct
drm_mode_obj_get_properties)
#define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct
drm_mode_obj_set_property)
+#define DRM_IOCTL_MODE_ATOMIC DRM_IOWR(0xBB, struct drm_mode_atomic)
/**
* Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 62ba997..5b2f294 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -462,4 +462,17 @@ struct drm_mode_destroy_dumb {
__u32 handle;
};
+#define DRM_MODE_ATOMIC_TEST_ONLY (1<<0)
+
+/* FIXME come up with some sane error reporting mechanism? */
+struct drm_mode_atomic {
+ __u32 flags;
+ __u32 count_objs;
+ __u64 objs_ptr;
+ __u64 count_props_ptr;
+ __u64 props_ptr;
+ __u64 prop_values_ptr;
+ __u64 blob_values_ptr;
+};
+
#endif
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 04fdf1f..18cd10b 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "xf86drmMode.h"
#include "xf86drm.h"
@@ -1057,3 +1058,272 @@ int drmModeObjectSetProperty(int fd, uint32_t
object_id, uint32_t object_type,
return DRM_IOCTL(fd, DRM_IOCTL_MODE_OBJ_SETPROPERTY, &prop);
}
+
+typedef struct _drmModePropertySetItem drmModePropertySetItem,
*drmModePropertySetItemPtr;
+
+struct _drmModePropertySetItem {
+ uint32_t object_id;
+ uint32_t property_id;
+ bool is_blob;
+ uint64_t value;
+ void *blob;
+ drmModePropertySetItemPtr next;
+};
+
+struct _drmModePropertySet {
+ unsigned int count_objs;
+ unsigned int count_props;
+ unsigned int count_blobs;
+ drmModePropertySetItem list;
+};
+
+drmModePropertySetPtr drmModePropertySetAlloc(void)
+{
+ drmModePropertySetPtr set;
+
+ set = drmMalloc(sizeof *set);
+ if (!set)
+ return NULL;
+
+ set->list.next = NULL;
+ set->count_props = 0;
+ set->count_objs = 0;
+
+ return set;
+}
+
+int drmModePropertySetAdd(drmModePropertySetPtr set,
+ uint32_t object_id,
+ uint32_t property_id,
+ uint64_t value)
+{
+ drmModePropertySetItemPtr prev = &set->list;
+ bool new_obj = false;
+
+ /* keep it sorted by object_id and property_id */
+ while (prev->next) {
+ if (prev->next->object_id > object_id) {
+ new_obj = true;
+ break;
+ }
+
+ if (prev->next->object_id == object_id &&
+ prev->next->property_id >= property_id)
+ break;
+
+ prev = prev->next;
+ }
+
+ if (!prev->next &&
+ (prev == &set->list || prev->object_id != object_id))
+ new_obj = true;
+
+ /* replace or add? */
+ if (prev->next &&
+ prev->next->object_id == object_id &&
+ prev->next->property_id == property_id) {
+ drmModePropertySetItemPtr item = prev->next;
+
+ if (item->is_blob)
+ return -EINVAL;
+
+ item->value = value;
+ } else {
+ drmModePropertySetItemPtr item;
+
+ item = drmMalloc(sizeof *item);
+ if (!item)
+ return -1;
+
+ item->object_id = object_id;
+ item->property_id = property_id;
+ item->value = value;
+ item->is_blob = false;
+ item->blob = NULL;
+
+ item->next = prev->next;
+ prev->next = item;
+
+ set->count_props++;
+ }
+
+ if (new_obj)
+ set->count_objs++;
+
+ return 0;
+}
+
+int drmModePropertySetAddBlob(drmModePropertySetPtr set,
+ uint32_t object_id,
+ uint32_t property_id,
+ uint64_t length,
+ void *data)
+{
+ drmModePropertySetItemPtr prev = &set->list;
+ bool new_obj = false;
+
+ /* keep it sorted by object_id and property_id */
+ while (prev->next) {
+ if (prev->next->object_id > object_id) {
+ new_obj = true;
+ break;
+ }
+
+ if (prev->next->object_id == object_id &&
+
[RFC][PATCH 1/2] libkms: YUYV support
From: Ville Syrj?l?
---
libkms/intel.c |6 +-
libkms/libkms.h |2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/libkms/intel.c b/libkms/intel.c
index 8b8249b..8aeb6ae 100644
--- a/libkms/intel.c
+++ b/libkms/intel.c
@@ -52,7 +52,7 @@ intel_get_prop(struct kms_driver *kms, unsigned key, unsigned
*out)
{
switch (key) {
case KMS_BO_TYPE:
- *out = KMS_BO_TYPE_SCANOUT_X8R8G8B8 |
KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8;
+ *out = KMS_BO_TYPE_SCANOUT_X8R8G8B8 |
KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 | KMS_BO_TYPE_SCANOUT_YUYV;
break;
default:
return -EINVAL;
@@ -100,6 +100,10 @@ intel_bo_create(struct kms_driver *kms,
pitch = width * 4;
pitch = (pitch + 512 - 1) & ~(512 - 1);
size = pitch * ((height + 4 - 1) & ~(4 - 1));
+ } else if (type == KMS_BO_TYPE_SCANOUT_YUYV) {
+ pitch = width * 2;
+ pitch = (pitch + 64 - 1) & ~(64 - 1);
+ size = pitch * height;
} else {
return -EINVAL;
}
diff --git a/libkms/libkms.h b/libkms/libkms.h
index 4664442..8cf3489 100644
--- a/libkms/libkms.h
+++ b/libkms/libkms.h
@@ -59,6 +59,8 @@ enum kms_bo_type
#define KMS_BO_TYPE_SCANOUT_X8R8G8B8 KMS_BO_TYPE_SCANOUT_X8R8G8B8
KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 = (1 << 1),
#define KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8
+ KMS_BO_TYPE_SCANOUT_YUYV = (1 << 2),
+#define KMS_BO_TYPE_SCANOUT_YUYV KMS_BO_TYPE_SCANOUT_YUYV
};
int kms_create(int fd, struct kms_driver **out);
--
1.7.3.4
[RFC][PATCH 0/2] libdrm: Atomic mode setting stuff
Here's the libdrm part of the atomic mode setting stuff. There's a new object I christened drmModePropertySet. It's an opaque object which is used to keep track of property changes for the user. Internally it's just a linked list of object_id/property_id/property_value tuples. The list is sorted based on object_id and property_id to avoid duplicates. The YUYV libkms patch is there just because my test app was more geared towards YUV than RGB, and I was too lazy to make the switch to RGB. I also stripped out a bunch of gunk from my test app and pushed the result to gitorious [1]. What it does is move/resize the plane and flips the CRTC fb at the same time using the new API. The app has a rudimentary keyboard control mechanism: 't' toggles an automatic test mode 's','z','x','c' move the plane 'S','Z','X','C' change the plane size 'f' fills the plane with a pattern, the color changes each time 'b' fills the plane with color bars 'l' loads a ppm (P6) image into the plane 'o' toggles the plane on/off 'q' quits [1] https://gitorious.org/vsyrjala/plane
Oops with Radeon/Uninorth on Maple
On Thu, May 24, 2012 at 2:18 AM, Dmitry Eremin-Solenikov wrote: > Hello, colleagues, > > I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX > board, with CPC925 (U3H) north bridge). > > ?For now I'm stuck with a problem: I use radeon card, drm-radeon driver with > KMS. > > If I force drm-radeon to think about a card as about PCI card (by commenting > corresponding lines in drm_radeon_kms.c), everything works, I get > framebuffer, working X11, etc. If I enable agpgart-uninorth driver > and RADEON_IS_AGP flag in drm driver, I get an Oops early during the > bootstrap. Relevant part of the log (I can send full dmesg of normal > bootstrap or this oops on request, if that would help). For future reference, you can disable AGP by loading radeon with the agpmode parameter set to -1, e.g., radeon.agpmode=-1 No need to edit the source. Alex
[Linaro-mm-sig] [PATCH] dma-buf: fix disabled vmap function
On Fri, May 25, 2012 at 10:18 AM, Sumit Semwal
wrote:
> Hi Dave,
>
> On 25 May 2012 14:34, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> include/linux/dma-buf.h: In function ?dma_buf_vmap?:
>> include/linux/dma-buf.h:260:1: warning: no return statement in function
>> returning non-void [-Wreturn-type]
>>
>> Reported-by: wfg at linux.intel.com
>> Signed-off-by: Dave Airlie
>> ---
>> ?include/linux/dma-buf.h | ? ?1 +
>> ?1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index d8c2865..506bb7b 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
>>
>> ?static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
>> ?{
>> + ? ? ? return NULL;
>> ?}
> I fixed this as part of rebasing while applying your vmap patch to my
> for-next - so it is already in my pull request.
>
Ah I didn't read the full warning mail, it was giving out about Tomasz
tree, he must have merged an older version.
Thanks,
Dave.
Oops with Radeon/Uninorth on Maple
On Thu, 2012-05-24 at 10:18 +0400, Dmitry Eremin-Solenikov wrote: > Hello, colleagues, > > I'm trying to enable an AGP slot (again) on my Maple board (dual > PPC970FX board, with CPC925 (U3H) north bridge). > > For now I'm stuck with a problem: I use radeon card, drm-radeon driver > with KMS. > > If I force drm-radeon to think about a card as about PCI card (by > commenting corresponding lines in drm_radeon_kms.c), everything works, I > get framebuffer, working X11, etc. If I enable agpgart-uninorth driver > and RADEON_IS_AGP flag in drm driver, I get an Oops early during the > bootstrap. Relevant part of the log (I can send full dmesg of normal > bootstrap or this oops on request, if that would help). Machine Check probably means that there's a HW configuration issue, possibly something missing in the initialization of the AGP hardware to make it actually work. Cheers, Ben. > [2.820647] Linux agpgart interface v0.103 > [2.824909] agpgart-uninorth :f0:0b.0: Apple U3H chipset > [2.830668] agpgart-uninorth :f0:0b.0: Found device u3, rev 35 > [2.843611] agpgart-uninorth :f0:0b.0: configuring for size idx: 64 > [2.850638] agpgart-uninorth :f0:0b.0: AGP aperture is 256M @ 0x0 > [2.857646] [drm] Initialized drm 1.1.0 20060810 > [2.862567] [drm] radeon defaulting to kernel modesetting. > [2.868091] [drm] radeon kernel modesetting enabled. > [2.873222] radeon :f0:10.0: enabling device ( -> 0003) > [2.880311] radeon :f0:10.0: enabling bus mastering > [2.885591] [drm] initializing kernel modesetting (RV350 > 0x1002:0x4152 0x18BC:0x0416). > [2.893629] [drm] register mmio base: 0xD002 > [2.898260] [drm] register mmio size: 65536 > [2.947112] [drm] GPU not posted. posting now... > [3.051033] agpgart-uninorth :f0:0b.0: putting AGP V3 device into > 8x mode > [3.058197] radeon :f0:10.0: putting AGP V3 device into 8x mode > [3.064666] radeon :f0:10.0: GTT: 256M 0x - 0x0FFF > [3.070864] [drm] Generation 2 PCI interface, using max accessible memory > [3.077672] radeon :f0:10.0: VRAM: 128M 0xC000 - > 0xC7FF (128M used) > [3.086487] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [3.093126] [drm] Driver supports precise vblank timestamp query. > [3.099291] [drm] radeon: irq initialized. > [3.103404] [drm] Detected VRAM RAM=128M, BAR=128M > [3.108214] [drm] RAM width 128bits DDR > [3.112263] [TTM] Zone kernel: Available graphics memory: 496682 kiB > [3.118732] [TTM] Initializing pool allocator > [3.123346] [drm] radeon: 128M of VRAM memory ready > [3.128256] [drm] radeon: 256M of GTT memory ready. > [3.133295] [drm] radeon: ib pool ready. > [3.137708] [drm] radeon: 1 quad pipes, 1 Z pipes initialized. > [3.144018] radeon :f0:10.0: WB disabled > [3.148326] [drm] fence driver on ring 0 use gpu addr 0x and > cpu addr 0xd0066000 > [3.157474] [drm] Loading R300 Microcode > [3.162480] [drm] radeon: ring at 0x1000 > [3.167569] [drm] ring test succeeded in 0 usecs > cpu 0x0: Vector: 200 (Machine Check) at [c0d63aa0] > pc: c00cc07c: .trace_hardirqs_on_caller+0x6c/0x190 > lr: c00152f4: .cpu_idle+0x1a4/0x220 > sp: c0d63d20 > msr: 90009032 >current = 0xc0c4db30 >paca= 0xc000 softe: 0irq_happened: 0x01 > pid = 0, comm = swapper/0 > enter ? for help > [c0d63db0] c00152f4 .cpu_idle+0x1a4/0x220 > [c0d63e50] c0008fb8 .rest_init+0xe8/0x110 > [c0d63ee0] c0ba2998 .start_kernel+0x3e4/0x408 > [c0d63f90] c0007558 .start_here_common+0x20/0x48 > 0:mon> x > [ 843.783295] Oops: Machine check, sig: 7 [#1] > [ 843.787589] SMP NR_CPUS=4 Maple > [ 843.790768] Modules linked in: > [ 843.793855] NIP: c00cc07c LR: c00152f4 CTR: > c0023eac > [ 843.800920] REGS: c0d63aa0 TRAP: 0200 Not tainted (3.4.0+) > [ 843.807376] MSR: 90009032 CR: > 2422 XER: 0006 > [ 843.815412] SOFTE: 0 > [ 843.817607] TASK = c0c4db30[0] 'swapper/0' THREAD: > c0d6 CPU: 0 > [ 843.825035] GPR00: c0d63d20 c0d63280 > c00152f4 > [ 843.833169] GPR04: c0099d10 0001 > 0002 > [ 843.841302] GPR08: 0100 c0e828e8 0140 > > [ 843.849436] GPR12: 4482 c000 > > [ 843.857570] GPR16: 00ff8750 00cdc890 010001e0 > > [ 843.865702] GPR20: 1dcd6500 > > [ 843.873835] GPR24: 00ec7b00 90009032 > c0d7b178 > [ 843.881979] GPR28: c00
[Bug 50232] screen redraw is wrong in sauerbraten with the llvm compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50232 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from almos 2012-05-25 10:55:10 PDT --- I see the fix was pushed to mesa master. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50230] offset mapping in nexuiz results in bad texturing with the llvm compiler
https://bugs.freedesktop.org/show_bug.cgi?id=50230 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from almos 2012-05-25 10:54:31 PDT --- I see the fixes were pushed to mesa master. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 02/14] drm: handle HDP and polled connectors separately
On 5/24/12 3:26 PM, Daniel Vetter wrote: Instead of reusing the polling code for hdp handling, split them up. This has a few consequences: - Don't touch HDP capable connectors in the poll loop. - Only touch HDP capable connectors in drm_helper_hpd_irq_event. - Run the HDP handling directly instead of going through a work item - all callers already call drm_helper_hpd_irq_event from process context without holding the mode_config mutex. "HPD". - /* if this is HPD or polled don't check it - - TV out for instance */ - if (!connector->polled) + /* Ignore HDP capable connectors and connectors where we don't +* want any hotplug detection at all for polling. */ + if (!connector->polled || connector->polled == DRM_CONNECTOR_POLL_HPD) Here too. Also in the subject. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43272] pink/purple line displays to the left of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=43272 Damien Churchill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Damien Churchill 2012-05-25 10:14:12 --- Hi, Setting radeon.audio=0 has resolved the problem. I still had radeon.audio=1 set in a modprobe.d file left over from when I had a HD4870. Thanks for the help! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] dma-buf: fix disabled vmap function
From: Dave Airlie
include/linux/dma-buf.h: In function ?dma_buf_vmap?:
include/linux/dma-buf.h:260:1: warning: no return statement in function
returning non-void [-Wreturn-type]
Reported-by: wfg at linux.intel.com
Signed-off-by: Dave Airlie
---
include/linux/dma-buf.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d8c2865..506bb7b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ return NULL;
}
static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
--
1.7.6
[PATCH] gpu: remove gma500 stub driver
In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.
Cc: randy.dunlap at oracle.com
Cc: mjg59 at srcf.ucam.org
Cc: gregkh at suse.de
Cc: trenn at suse.de
Cc: Valdis.Kletnieks at vt.edu
Cc: Dennis.Jansen at web.de
Cc: airlied at redhat.com
Cc: eric at anholt.net
Cc: alexdeucher at gmail.com
Cc: bskeggs at redhat.com
Cc: chris at chris-wilson.co.uk
Signed-off-by: Lee, Chun-Yi
---
drivers/gpu/Makefile |2 +-
drivers/gpu/stub/Kconfig | 18
drivers/gpu/stub/Makefile |1 -
drivers/gpu/stub/poulsbo.c | 64
drivers/video/Kconfig |2 -
5 files changed, 1 insertions(+), 86 deletions(-)
delete mode 100644 drivers/gpu/stub/Kconfig
delete mode 100644 drivers/gpu/stub/Makefile
delete mode 100644 drivers/gpu/stub/poulsbo.c
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y += drm/ vga/ stub/
+obj-y += drm/ vga/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
deleted file mode 100644
index 4199179..000
--- a/drivers/gpu/stub/Kconfig
+++ /dev/null
@@ -1,18 +0,0 @@
-config STUB_POULSBO
- tristate "Intel GMA500 Stub Driver"
- depends on PCI
- depends on NET # for THERMAL
- # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
- # but for select to work, need to select ACPI_VIDEO's dependencies, ick
- select BACKLIGHT_CLASS_DEVICE if ACPI
- select VIDEO_OUTPUT_CONTROL if ACPI
- select INPUT if ACPI
- select ACPI_VIDEO if ACPI
- select THERMAL if ACPI
- help
- Choose this option if you have a system that has Intel GMA500
- (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
- intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
deleted file mode 100644
index cd940cc..000
--- a/drivers/gpu/stub/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
deleted file mode 100644
index 7edfd27..000
--- a/drivers/gpu/stub/poulsbo.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Intel Poulsbo Stub driver
- *
- * Copyright (C) 2010 Novell
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- */
-
-#include
-#include
-#include
-#include
-
-#define DRIVER_NAME "poulsbo"
-
-enum {
- CHIP_PSB_8108 = 0,
- CHIP_PSB_8109 = 1,
-};
-
-static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
- {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
- {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
- {0, 0, 0}
-};
-
-static int poulsbo_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-{
- return acpi_video_register();
-}
-
-static void poulsbo_remove(struct pci_dev *pdev)
-{
- acpi_video_unregister();
-}
-
-static struct pci_driver poulsbo_driver = {
- .name = DRIVER_NAME,
- .id_table = pciidlist,
- .probe = poulsbo_probe,
- .remove = poulsbo_remove,
-};
-
-static int __init poulsbo_init(void)
-{
- return pci_register_driver(&poulsbo_driver);
-}
-
-static void __exit poulsbo_exit(void)
-{
- pci_unregister_driver(&poulsbo_driver);
-}
-
-module_init(poulsbo_init);
-module_exit(poulsbo_exit);
-
-MODULE_AUTHOR("Lee, Chun-Yi ");
-MODULE_DESCRIPTION("Poulsbo Stub Driver");
-MODULE_LICENSE("GPL");
-
-MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a290be5..8a12c6e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,8 +21,6 @@ source "drivers/gpu/vga/Kconfig"
source "drivers/gpu/drm/Kconfig"
-source "drivers/gpu/stub/Kconfig"
-
config VGASTATE
tristate
default n
--
1.6.0.2
RE: [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
> > There are multiple ways synchronization can be achieved, > > fences/sync objects is one common approach, however we're > > presenting a different approach. Personally, I quite like > > fence sync objects, however we believe it requires a lot of > > userspace interfaces to be changed to pass around sync object > > handles. Our hope is that the kds approach will require less > > effort to make use of as no existing userspace interfaces need > > to be changed. E.g. To use explicit fences, the struct > > drm_mode_crtc_page_flip would need a new members to pass in the > > handle(s) of sync object(s) which the flip depends on (I.e. > > don't flip until these fences fire). The additional benefit of > > our approach is that it prevents userspace specifying dependency > > loops which can cause a deadlock (see kds.txt for an explanation > > of what I mean here). > > It is easy to cause cyclic dependencies with implicit fences unless you > are very sure that client can only cause linear implicit dependencies. I'm not sure I know what you mean by linear implicit dependencies? > But clients already have synchronization dependencies with userspace. > That makes implicit synchronization possibly cause unexpected > deadlocks. Again, not sure what you mean here? Do you mean that userspace can Submit a piece of work to a driver which depends on something else happening in userpsace? > Explicit synchronization is easier to debug because developer using > explicit synchronization can track the dependencies in userspace. But > of course that makes userspace API harder to use than API using > implicitly synchronization. > > But implicit synchronization can avoid client deadlock issues. > Providing if client may never block "fence" from triggering in finite > time when it is granted access. The page flip can be synchronized in > that manner if client can't block HW from processing queued rendering. Yes, I guess this is the critical point - this approach assumes that when a client starts using a resource, it will only do so for a finite amount of time. If userspace wanted to participate in the scheme, we would probably need some kind of timeout, otherwise userspace could prevent other devices from accessing a resource. > You were talking about adding new parameter to page flip ioctl. I fail > to see need for it because page flip already has fb object as parameter > that should map to the implicit synchronization fence through dma_buf. This is the point I was trying to make. With explicit fence objects you do have to add a new parameter, whereas with this kds implicit approach you do not - the buffer itself becomes the sync object. > > While KDS defines a very generic mechanism, I am proposing that > > this code or at least the concepts be merged with the existing > > > dma_buf code, so a the struct kds_resource members get moved to > > struct dma_buf, kds_* functions get renamed to dma_buf_* > > functions, etc. So I guess what I'm saying is please don't review > > the actual code just yet, only the concepts the code describes, > > where kds_resource == dma_duf. > > But the documented functionality sounds very much deadlock prone. If > userspace gets exclusive access and needs to wait for implicit access > synchronization. > > app A has access to buffer X > app B requests exclusive access to buffer X and blocks waiting for access > app A makes synchronous IPC call to app B > > I didn't read the actual code at all to figure out if that is possible > scenario. But it sounds like possible scenario based on documentation > talking EGL depending on exclusive access. The intention was to use this mechanism for synchronizing between drivers rather than between userspace processes, I think the userspace access is somewhat an afterthought which will probably need some more thought. In the example you give, app A making a synchronous IPC call to app B breaks the clients must guarantee they complete in a finite time, which in the case of userspace access could be enforced by a timeout. Though I would have thought there's a better way to handle this than just a timeout. Cheers, Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL]: dma-buf updates for 3.5
On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal wrote: > > I am really sorry - I goofed up in the git URL (sent the ssh URL > instead). I was going to send you an acerbic email asking for your private ssh key, but then noticed that you had sent another email with the public version of the git tree.. > Could you please use > > git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git > tags/tag-for-linus-3.5 > > instead, or should I send a new pull request with the corrected URL? Done. However, while your tag seems to be signed, your key is not available publicly: [torvalds@i5 ~]$ gpg --recv-key 7126925D gpg: requesting key 7126925D from hkp server pgp.mit.edu gpgkeys: key 7126925D not found on keyserver so I can't check if it is signed by anybody. Please do something like gpg --keyserver pgp.mit.edu --send-keys 7126925D to actually make your public key public. Of course, if it isn't public, I assume it hasn't actually been signed by anybody, which makes it largely useless. But any future signing action will validate the pre-signing uses of the key, so that's fixable. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL]: dma-buf updates for 3.5
On Fri, May 25, 2012 at 2:17 AM, Sumit Semwal wrote: > > I am really sorry - I goofed up in the git URL (sent the ssh URL > instead). I was going to send you an acerbic email asking for your private ssh key, but then noticed that you had sent another email with the public version of the git tree.. > Could you please use > > git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git > tags/tag-for-linus-3.5 > > instead, or should I send a new pull request with the corrected URL? Done. However, while your tag seems to be signed, your key is not available publicly: [torvalds at i5 ~]$ gpg --recv-key 7126925D gpg: requesting key 7126925D from hkp server pgp.mit.edu gpgkeys: key 7126925D not found on keyserver so I can't check if it is signed by anybody. Please do something like gpg --keyserver pgp.mit.edu --send-keys 7126925D to actually make your public key public. Of course, if it isn't public, I assume it hasn't actually been signed by anybody, which makes it largely useless. But any future signing action will validate the pre-signing uses of the key, so that's fixable. Linus
drm: add helper to clflush a virtual address range
Hi Greg,
On Fri, May 25, 2012 at 02:24:32PM +0900, Greg KH wrote:
> I see you say you wanted the patch below for the stable tree, due to
> some later patch needing it, yet this patch was not "marked" for the
> stable tree, and I can't seem to figure out which "later patch" you are
> referring to here.
>
> Any hints on what I should do for the 3.4-stable kernel tree with this?
Oops, I've changed plans for that bug and sent a more minimal patch that
simply covers over the problem rather well than fixes it 100% perfect.
I've dropped the Cc: stable, bug forgot to adjust the commit message.
So this patch isn't for stable any more, sorry for wasting your time.
Yours, Daniel
>
> thanks,
>
> greg k-h
>
> On Thu, May 24, 2012 at 07:55:29PM +, Linux Kernel Mailing List wrote:
> > Gitweb:
> > http://git.kernel.org/linus/;a=commit;h=6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> > Commit: 6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> > Parent: dbf7bff074d5fdc87c61b1b41d8e809109cf0bf8
> > Author: Daniel Vetter
> > AuthorDate: Sun Mar 25 19:47:30 2012 +0200
> > Committer: Daniel Vetter
> > CommitDate: Tue Mar 27 13:19:45 2012 +0200
> >
> > drm: add helper to clflush a virtual address range
> >
> > Useful when the page is already mapped to copy date in/out.
> >
> > For -stable because the next patch (fixing phys obj pwrite) needs this
> > little helper function.
> >
> > Tested-by: Chris Wilson
> > Reviewed-by: Chris Wilson
> > Cc: dri-devel at lists.freedesktop.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_cache.c | 23 +++
> > include/drm/drmP.h |1 +
> > 2 files changed, 24 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> > index 5928653..c7c8f6b 100644
> > --- a/drivers/gpu/drm/drm_cache.c
> > +++ b/drivers/gpu/drm/drm_cache.c
> > @@ -98,3 +98,26 @@ drm_clflush_pages(struct page *pages[], unsigned long
> > num_pages)
> > #endif
> > }
> > EXPORT_SYMBOL(drm_clflush_pages);
> > +
> > +void
> > +drm_clflush_virt_range(char *addr, unsigned long length)
> > +{
> > +#if defined(CONFIG_X86)
> > + if (cpu_has_clflush) {
> > + char *end = addr + length;
> > + mb();
> > + for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> > + clflush(addr);
> > + clflush(end - 1);
> > + mb();
> > + return;
> > + }
> > +
> > + if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> > + printk(KERN_ERR "Timed out waiting for cache flush.\n");
> > +#else
> > + printk(KERN_ERR "Architecture has no drm_cache.c support\n");
> > + WARN_ON_ONCE(1);
> > +#endif
> > +}
> > +EXPORT_SYMBOL(drm_clflush_virt_range);
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 92f0981..d33597b 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1332,6 +1332,7 @@ extern int drm_remove_magic(struct drm_master
> > *master, drm_magic_t magic);
> >
> > /* Cache management (drm_cache.c) */
> > void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
> > +void drm_clflush_virt_range(char *addr, unsigned long length);
> >
> > /* Locking IOCTL support (drm_lock.h) */
> > extern int drm_lock(struct drm_device *dev, void *data,
> > --
> > To unsubscribe from this list: send the line "unsubscribe git-commits-head"
> > in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
drm/i915 3.5 merge window: gen6_sanitize_pm errors
On Thu, May 24, 2012 at 07:27:04PM -0700, Linus Torvalds wrote: > These guys seem to be recently introduced: > > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206 > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700 > > This is on my SNB Macbook Air. > > Everything seems to *work*, which makes me think: > > - that error isn't really so big a deal that you have to *SHOUT* about it. > > - I wonder how valid the discrepancy checking code is to begin with. > > Hmm? On snb/ivb we have a problem that the gpu turbo can get stuck, and most often it gets stuck at the lowest frequency, resulting in unhappy users. Chris noticed that this happens when the RP irq limit register reads a bogus value (and eventually gets stuck). Although your machine looks interesting, because usually we just read back 0. I've already sent a pull request to Dave with our current best effort to duct-tape over the problem. If that doesn't cut out the dmesg flood, I guess we need to tune down that message a bit. But we've added it in that obnoxious way in the first place to get bug reports, so that we actually know how bad the problem is. Hence I'd like to keep it around a bit. Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
drm/i915 3.5 merge window: gen6_sanitize_pm errors
On Thu, 24 May 2012 19:27:04 -0700, Linus Torvalds wrote: > These guys seem to be recently introduced: > > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206 > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700 > > This is on my SNB Macbook Air. > > Everything seems to *work*, which makes me think: > > - that error isn't really so big a deal that you have to *SHOUT* about it. > > - I wonder how valid the discrepancy checking code is to begin with. Extremely, it is accurately telling us that only half of the patches were applied... After that when it does shout, it just saved your system. However, even after fixing it to the best of our knowledge, it is still a far too regular occurrence (playing video seems to have just the right combination of turbo and rc6 to trigger it reliably) and even though it is a calamity we do now expect it to be seen in the wild and so will reduce the severity of the warning. -Chris -- Chris Wilson, Intel Open Source Technology Centre
Re: Oops with Radeon/Uninorth on Maple
On Thu, May 24, 2012 at 2:18 AM, Dmitry Eremin-Solenikov wrote: > Hello, colleagues, > > I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX > board, with CPC925 (U3H) north bridge). > > For now I'm stuck with a problem: I use radeon card, drm-radeon driver with > KMS. > > If I force drm-radeon to think about a card as about PCI card (by commenting > corresponding lines in drm_radeon_kms.c), everything works, I get > framebuffer, working X11, etc. If I enable agpgart-uninorth driver > and RADEON_IS_AGP flag in drm driver, I get an Oops early during the > bootstrap. Relevant part of the log (I can send full dmesg of normal > bootstrap or this oops on request, if that would help). For future reference, you can disable AGP by loading radeon with the agpmode parameter set to -1, e.g., radeon.agpmode=-1 No need to edit the source. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #24 from Santiago Garcia Mantinan 2012-05-25 07:35:48 --- About my previous message... when I talk about 3.0 and 3.1 I meant that they were also failing, not working, 2.6.39 was the last working one for me, I tested all the series since that one and they were all broken. Hope this clarifies a bit and sorry for the confusion. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 50325] Glyphy bad render on r600g (software render is fine)
https://bugs.freedesktop.org/show_bug.cgi?id=50325 --- Comment #3 from T?r?k Edwin 2012-05-25 00:22:27 PDT --- With the git version of Mesa I get an error, opened new bug here: https://bugs.freedesktop.org/show_bug.cgi?id=50338 EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50338] r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
https://bugs.freedesktop.org/show_bug.cgi?id=50338 --- Comment #1 from T?r?k Edwin 2012-05-25 00:22:02 PDT --- Created attachment 62088 --> https://bugs.freedesktop.org/attachment.cgi?id=62088 R600_DUMP_SHADERS=1 output from working Mesa 8.0.2 shader dump from working: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 OpenGL extensions: -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50338] New: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
https://bugs.freedesktop.org/show_bug.cgi?id=50338 Bug #: 50338 Summary: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: edwin+mesa at etorok.net Created attachment 62087 --> https://bugs.freedesktop.org/attachment.cgi?id=62087 R600_DUMP_SHADERS=1 output Trying to reproduce bug #50325 on Mesa git caused this error: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Bug can be reproduced by one of these: build/glretrace lt-glyphy-demo.trace demo/glyphy-demo I get the translation failed error both with R600_LLVM=0, and R600_LLVM=1. I've attached the R600_DUMP_SHADERS=1 output. glretrace is from https://github.com/apitrace/apitrace/tree/1.0 and glyphy is from https://code.google.com/p/glyphy/source/checkout lt-glypy-demo.trace is here: https://bugs.freedesktop.org/attachment.cgi?id=62078 git version of Mesa: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.1-devel (git-35f302d) OpenGL shading language version string: 1.30 OpenGL extensions: Built with (on Debian unstable): ./configure --with-dri-drivers= --with-gallium-drivers=r600,swrast --enable-glx-tls --enable-gallium-llvm LLVM_CONFIG=/usr/bin/llvm-config-3.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] gpu: schedule gma500 stub driver for feature removal
? ??2012-05-25 ? 04:53 +0900?Greg KH ??? > On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > Why not just remove it right now as it's not needed at all anymore? > > thanks, > > greg k-h > > . Just I thought remove anything from kernel need add to schedule file first. OK, I will send another patch to direct remove it. Thanks Joey Lee
Re: [PATCH] gpu: schedule gma500 stub driver for feature removal
On Fri, 25 May 2012 04:53:50 +0900 Greg KH wrote: > On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > Why not just remove it right now as it's not needed at all anymore? If there are distros not currently ahipping the GMA500 driver or people updating old kernels using vesa and not having the right server bits it might cause them problems - giving it 6 months isn't a bad idea IMHO ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
On 25/05/12 14:08, Tom Cooksey wrote: Hi All, I realise it's been a while since this was last discussed, however I'd like to bring up kernel-side synchronization again. By kernel-side synchronization, I mean allowing multiple drivers/devices wanting to access the same buffer to do so without bouncing up to userspace to resolve dependencies such as "the display controller can't start scanning out a buffer until the GPU has finished rendering into it". As such, this is really just an optimization which reduces latency between E.g. The GPU finishing a rendering job and that buffer being scanned out. I appreciate this particular example is already solved on desktop graphics cards as the display controller and 3D core are both controlled by the same driver, so no "generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM Mali) and display controller tend to be driven by separate drivers, so some mechanism is needed to allow both drivers to synchronize their access to buffers. There are multiple ways synchronization can be achieved, fences/sync objects is one common approach, however we're presenting a different approach. Personally, I quite like fence sync objects, however we believe it requires a lot of userspace interfaces to be changed to pass around sync object handles. Our hope is that the kds approach will require less effort to make use of as no existing userspace interfaces need to be changed. E.g. To use explicit fences, the struct drm_mode_crtc_page_flip would need a new members to pass in the handle(s) of sync object(s) which the flip depends on (I.e. don't flip until these fences fire). The additional benefit of our approach is that it prevents userspace specifying dependency loops which can cause a deadlock (see kds.txt for an explanation of what I mean here). It is easy to cause cyclic dependencies with implicit fences unless you are very sure that client can only cause linear implicit dependencies. But clients already have synchronization dependencies with userspace. That makes implicit synchronization possibly cause unexpected deadlocks. Explicit synchronization is easier to debug because developer using explicit synchronization can track the dependencies in userspace. But of course that makes userspace API harder to use than API using implicitly synchronization. But implicit synchronization can avoid client deadlock issues. Providing if client may never block "fence" from triggering in finite time when it is granted access. The page flip can be synchronized in that manner if client can't block HW from processing queued rendering. You were talking about adding new parameter to page flip ioctl. I fail to see need for it because page flip already has fb object as parameter that should map to the implicit synchronization fence through dma_buf. I have waited until now to bring this up again because I am now able to share the code I was trying (and failing I think) to explain previously. The code has now been released under the GPLv2 from ARM Mali's developer portal, however I've attempted to turn that into a patch to allow it to be discussed on this list. Please find the patch inline below. While KDS defines a very generic mechanism, I am proposing that this code or at least the concepts be merged with the existing dma_buf code, so a the struct kds_resource members get moved to struct dma_buf, kds_* functions get renamed to dma_buf_* functions, etc. So I guess what I'm saying is please don't review the actual code just yet, only the concepts the code describes, where kds_resource == dma_duf. But the documented functionality sounds very much deadlock prone. If userspace gets exclusive access and needs to wait for implicit access synchronization. app A has access to buffer X app B requests exclusive access to buffer X and blocks waiting for access app A makes synchronous IPC call to app B I didn't read the actual code at all to figure out if that is possible scenario. But it sounds like possible scenario based on documentation talking EGL depending on exclusive access. Cheers, Tom Pauli ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43272] pink/purple line displays to the left of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=43272 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED CC||a...@lxorguk.ukuu.org.uk -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 Santiago Garcia Mantinan changed: What|Removed |Added CC||manty at manty.net --- Comment #23 from Santiago Garcia Mantinan 2012-05-25 06:21:20 --- Hi, I'm the one that submitted the problem in Comment #19 From Jonathan Nieder, I have now uploaded to alsa the alsa-info.sh collected data and tests include 3.3.6. Here are the kernels for which I submitted the info and the link to the info submitted. ii linux-image-2.6.39-2-686-pae 2.6.39-3 ii linux-image-3.2.0-2-686-pae 3.2.17-1 ii linux-image-3.3.0-trunk-686-pae 3.3.6-1~experimental.1 3.2.17 http://www.alsa-project.org/db/?f=1065dc2b77cb999525747f08238309c2de1013c9 3.3.6 http://www.alsa-project.org/db/?f=499ea9e973c6119416e9356e23451250893048d5 2.6.39 http://www.alsa-project.org/db/?f=9c9b0c9e26c1bc570e15ed12b23d8b6ff1386ae5 I have previously tested 3.0 and 3.1 kernels and were also working, in I had to go to 2.6.39 to find a working kernel. I don't have access to the machine at anytime that is why it took so long to report back, I hope I can test 3.4 soon but I don't think that will make any change. Hope this helps identify the bug, regards. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: [Linaro-mm-sig] [PATCH] dma-buf: fix disabled vmap function
Hi Dave,
On 25 May 2012 14:34, Dave Airlie wrote:
> From: Dave Airlie
>
> include/linux/dma-buf.h: In function ‘dma_buf_vmap’:
> include/linux/dma-buf.h:260:1: warning: no return statement in function
> returning non-void [-Wreturn-type]
>
> Reported-by: w...@linux.intel.com
> Signed-off-by: Dave Airlie
> ---
> include/linux/dma-buf.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d8c2865..506bb7b 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
>
> static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
> {
> + return NULL;
> }
I fixed this as part of rebasing while applying your vmap patch to my
for-next - so it is already in my pull request.
Best regards,
~Sumit.
>
> static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> --
> 1.7.6
>
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL]: dma-buf updates for 3.5
Hi Linus, On 25 May 2012 13:25, Sumit Semwal wrote: > Hi Linus, > > Here's the first signed-tag pull request for dma-buf framework. > > Could you please pull the dma-buf updates for 3.5? This includes the > following key items: > - mmap support > - vmap support > - related documentation updates > > These are needed by various drivers to allow mmap/vmap of dma-buf > shared buffers. Dave Airlie has some prime patches dependent on the > vmap pull as well. > > Thanks and best regards, > ~Sumit. > > > The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: > > Linux 3.4 (2012-05-20 15:29:13 -0700) > > are available in the git repository at: > > ssh://sumitsem...@git.linaro.org/~/public_git/linux-dma-buf.git > tags/tag-for-linus-3.5 I am really sorry - I goofed up in the git URL (sent the ssh URL instead). Could you please use git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/tag-for-linus-3.5 instead, or should I send a new pull request with the corrected URL? Thanks, and best regards, ~Sumit. > > for you to fetch changes up to b25b086d23eb852bf3cfdeb60409b4967ebb3c0c: > > dma-buf: add initial vmap documentation (2012-05-25 12:51:11 +0530) > > > dma-buf updates for 3.5 > > > Daniel Vetter (1): > dma-buf: mmap support > > Dave Airlie (2): > dma-buf: add vmap interface > dma-buf: add initial vmap documentation > > Sumit Semwal (1): > dma-buf: minor documentation fixes. > > Documentation/dma-buf-sharing.txt | 109 > ++--- > drivers/base/dma-buf.c | 99 - > include/linux/dma-buf.h | 33 +++ > 3 files changed, 233 insertions(+), 8 deletions(-) -- Thanks and regards, Sumit Semwal Linaro Kernel Engineer - Graphics working group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL]: dma-buf updates for 3.5
Hi Linus, Here's the first signed-tag pull request for dma-buf framework. Could you please pull the dma-buf updates for 3.5? This includes the following key items: - mmap support - vmap support - related documentation updates These are needed by various drivers to allow mmap/vmap of dma-buf shared buffers. Dave Airlie has some prime patches dependent on the vmap pull as well. Thanks and best regards, ~Sumit. The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: Linux 3.4 (2012-05-20 15:29:13 -0700) are available in the git repository at: ssh://sumitsem...@git.linaro.org/~/public_git/linux-dma-buf.git tags/tag-for-linus-3.5 for you to fetch changes up to b25b086d23eb852bf3cfdeb60409b4967ebb3c0c: dma-buf: add initial vmap documentation (2012-05-25 12:51:11 +0530) dma-buf updates for 3.5 Daniel Vetter (1): dma-buf: mmap support Dave Airlie (2): dma-buf: add vmap interface dma-buf: add initial vmap documentation Sumit Semwal (1): dma-buf: minor documentation fixes. Documentation/dma-buf-sharing.txt | 109 ++--- drivers/base/dma-buf.c| 99 - include/linux/dma-buf.h | 33 +++ 3 files changed, 233 insertions(+), 8 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: remove gma500 stub driver
於 五，2012-05-25 於 16:07 +0900，Greg KH 提到： > On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > Cc: randy.dun...@oracle.com > > Cc: mj...@srcf.ucam.org > > Cc: gre...@suse.de > > Note, my email address has changed :) > Sorry~~~! I will keep in mind! :-) > Acked-by: Greg Kroah-Hartman > > Thanks a lot! Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: remove gma500 stub driver
On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > In v3.3, the gma500 drm driver moved from staging to drm group by > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > brightness well and don't need gma500 stub driver anymore. > > Cc: randy.dun...@oracle.com > Cc: mj...@srcf.ucam.org > Cc: gre...@suse.de Note, my email address has changed :) Acked-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: add helper to clflush a virtual address range
Hi Daniel,
I see you say you wanted the patch below for the stable tree, due to
some later patch needing it, yet this patch was not "marked" for the
stable tree, and I can't seem to figure out which "later patch" you are
referring to here.
Any hints on what I should do for the 3.4-stable kernel tree with this?
thanks,
greg k-h
On Thu, May 24, 2012 at 07:55:29PM +, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> Commit: 6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> Parent: dbf7bff074d5fdc87c61b1b41d8e809109cf0bf8
> Author: Daniel Vetter
> AuthorDate: Sun Mar 25 19:47:30 2012 +0200
> Committer: Daniel Vetter
> CommitDate: Tue Mar 27 13:19:45 2012 +0200
>
> drm: add helper to clflush a virtual address range
>
> Useful when the page is already mapped to copy date in/out.
>
> For -stable because the next patch (fixing phys obj pwrite) needs this
> little helper function.
>
> Tested-by: Chris Wilson
> Reviewed-by: Chris Wilson
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_cache.c | 23 +++
> include/drm/drmP.h |1 +
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 5928653..c7c8f6b 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -98,3 +98,26 @@ drm_clflush_pages(struct page *pages[], unsigned long
> num_pages)
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_pages);
> +
> +void
> +drm_clflush_virt_range(char *addr, unsigned long length)
> +{
> +#if defined(CONFIG_X86)
> + if (cpu_has_clflush) {
> + char *end = addr + length;
> + mb();
> + for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> + clflush(addr);
> + clflush(end - 1);
> + mb();
> + return;
> + }
> +
> + if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> + printk(KERN_ERR "Timed out waiting for cache flush.\n");
> +#else
> + printk(KERN_ERR "Architecture has no drm_cache.c support\n");
> + WARN_ON_ONCE(1);
> +#endif
> +}
> +EXPORT_SYMBOL(drm_clflush_virt_range);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 92f0981..d33597b 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1332,6 +1332,7 @@ extern int drm_remove_magic(struct drm_master *master,
> drm_magic_t magic);
>
> /* Cache management (drm_cache.c) */
> void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
> +void drm_clflush_virt_range(char *addr, unsigned long length);
>
> /* Locking IOCTL support (drm_lock.h) */
> extern int drm_lock(struct drm_device *dev, void *data,
> --
> To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: remove gma500 stub driver
In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.
Cc: randy.dun...@oracle.com
Cc: mj...@srcf.ucam.org
Cc: gre...@suse.de
Cc: tr...@suse.de
Cc: valdis.kletni...@vt.edu
Cc: dennis.jan...@web.de
Cc: airl...@redhat.com
Cc: e...@anholt.net
Cc: alexdeuc...@gmail.com
Cc: bske...@redhat.com
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Lee, Chun-Yi
---
drivers/gpu/Makefile |2 +-
drivers/gpu/stub/Kconfig | 18
drivers/gpu/stub/Makefile |1 -
drivers/gpu/stub/poulsbo.c | 64
drivers/video/Kconfig |2 -
5 files changed, 1 insertions(+), 86 deletions(-)
delete mode 100644 drivers/gpu/stub/Kconfig
delete mode 100644 drivers/gpu/stub/Makefile
delete mode 100644 drivers/gpu/stub/poulsbo.c
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y += drm/ vga/ stub/
+obj-y += drm/ vga/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
deleted file mode 100644
index 4199179..000
--- a/drivers/gpu/stub/Kconfig
+++ /dev/null
@@ -1,18 +0,0 @@
-config STUB_POULSBO
- tristate "Intel GMA500 Stub Driver"
- depends on PCI
- depends on NET # for THERMAL
- # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
- # but for select to work, need to select ACPI_VIDEO's dependencies, ick
- select BACKLIGHT_CLASS_DEVICE if ACPI
- select VIDEO_OUTPUT_CONTROL if ACPI
- select INPUT if ACPI
- select ACPI_VIDEO if ACPI
- select THERMAL if ACPI
- help
- Choose this option if you have a system that has Intel GMA500
- (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
- intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
deleted file mode 100644
index cd940cc..000
--- a/drivers/gpu/stub/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
deleted file mode 100644
index 7edfd27..000
--- a/drivers/gpu/stub/poulsbo.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Intel Poulsbo Stub driver
- *
- * Copyright (C) 2010 Novell
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- */
-
-#include
-#include
-#include
-#include
-
-#define DRIVER_NAME "poulsbo"
-
-enum {
- CHIP_PSB_8108 = 0,
- CHIP_PSB_8109 = 1,
-};
-
-static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
- {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
- {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
- {0, 0, 0}
-};
-
-static int poulsbo_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-{
- return acpi_video_register();
-}
-
-static void poulsbo_remove(struct pci_dev *pdev)
-{
- acpi_video_unregister();
-}
-
-static struct pci_driver poulsbo_driver = {
- .name = DRIVER_NAME,
- .id_table = pciidlist,
- .probe = poulsbo_probe,
- .remove = poulsbo_remove,
-};
-
-static int __init poulsbo_init(void)
-{
- return pci_register_driver(&poulsbo_driver);
-}
-
-static void __exit poulsbo_exit(void)
-{
- pci_unregister_driver(&poulsbo_driver);
-}
-
-module_init(poulsbo_init);
-module_exit(poulsbo_exit);
-
-MODULE_AUTHOR("Lee, Chun-Yi ");
-MODULE_DESCRIPTION("Poulsbo Stub Driver");
-MODULE_LICENSE("GPL");
-
-MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a290be5..8a12c6e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,8 +21,6 @@ source "drivers/gpu/vga/Kconfig"
source "drivers/gpu/drm/Kconfig"
-source "drivers/gpu/stub/Kconfig"
-
config VGASTATE
tristate
default n
--
1.6.0.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: schedule gma500 stub driver for feature removal
於 五，2012-05-25 於 04:53 +0900，Greg KH 提到： > On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > Why not just remove it right now as it's not needed at all anymore? > > thanks, > > greg k-h > > . Just I thought remove anything from kernel need add to schedule file first. OK, I will send another patch to direct remove it. Thanks Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: schedule gma500 stub driver for feature removal
On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > In v3.3, the gma500 drm driver moved from staging to drm group by > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > brightness well and don't need gma500 stub driver anymore. > > So, my plan is remove gma500 stub driver at Dec. 2012. Why not just remove it right now as it's not needed at all anymore? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics
> -Original Message- > From: Sylvain BERTRAND [mailto:sylw...@legeek.net] > Sent: Thursday, May 24, 2012 1:59 PM > To: Christian König > Cc: j.gli...@gmail.com; Koenig, Christian; dri-devel@lists.freedesktop.org > Subject: Re: [PATCH 08/10] drm/radeon: replace pflip and sw_int counters > with atomics > > > + atomic_tring_int[RADEON_NUM_RINGS]; > > bool > crtc_vblank_int[RADEON_MAX_CRTCS]; > > - boolpflip[RADEON_MAX_CRTCS]; > > - int > pflip_refcount[RADEON_MAX_CRTCS]; > > + atomic_tpflip[RADEON_MAX_CRTCS]; > > Hi, > > Does the linux API mandates atomic_t to be a 32bits word? AFAIK it is, at least for the platforms we care about. But since this depends on the vertical refresh frequency even a 8bit counter should do fine. On the other hand it was an accident that those patches hit the maillinglist in the first place, cause only the first four where supposed to be send out (my fault, sorry). This one isn't tested beside compiling, and I don't think it will work out of the box. Cheers, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch] drm/udl: unlock before returning in udl_gem_mmap()
On Thu, Mar 22, 2012 at 09:30:56AM +0300, Dan Carpenter wrote:
> If we hit an error here, then we should unlock and unreference obj
> before returning.
>
This is still present in linux-next.
regards,
dan carpenter
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> index 852642d..6de6130 100644
> --- a/drivers/gpu/drm/udl/udl_gem.c
> +++ b/drivers/gpu/drm/udl/udl_gem.c
> @@ -210,7 +210,7 @@ int udl_gem_mmap(struct drm_file *file, struct drm_device
> *dev,
>
> ret = udl_gem_get_pages(gobj, GFP_KERNEL);
> if (ret)
> - return ret;
> + goto out;
> if (!gobj->base.map_list.map) {
> ret = drm_gem_create_mmap_offset(obj);
> if (ret)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Oops with Radeon/Uninorth on Maple
Hello, colleagues, I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX board, with CPC925 (U3H) north bridge). For now I'm stuck with a problem: I use radeon card, drm-radeon driver with KMS. If I force drm-radeon to think about a card as about PCI card (by commenting corresponding lines in drm_radeon_kms.c), everything works, I get framebuffer, working X11, etc. If I enable agpgart-uninorth driver and RADEON_IS_AGP flag in drm driver, I get an Oops early during the bootstrap. Relevant part of the log (I can send full dmesg of normal bootstrap or this oops on request, if that would help). [2.820647] Linux agpgart interface v0.103 [2.824909] agpgart-uninorth :f0:0b.0: Apple U3H chipset [2.830668] agpgart-uninorth :f0:0b.0: Found device u3, rev 35 [2.843611] agpgart-uninorth :f0:0b.0: configuring for size idx: 64 [2.850638] agpgart-uninorth :f0:0b.0: AGP aperture is 256M @ 0x0 [2.857646] [drm] Initialized drm 1.1.0 20060810 [2.862567] [drm] radeon defaulting to kernel modesetting. [2.868091] [drm] radeon kernel modesetting enabled. [2.873222] radeon :f0:10.0: enabling device ( -> 0003) [2.880311] radeon :f0:10.0: enabling bus mastering [2.885591] [drm] initializing kernel modesetting (RV350 0x1002:0x4152 0x18BC:0x0416). [2.893629] [drm] register mmio base: 0xD002 [2.898260] [drm] register mmio size: 65536 [2.947112] [drm] GPU not posted. posting now... [3.051033] agpgart-uninorth :f0:0b.0: putting AGP V3 device into 8x mode [3.058197] radeon :f0:10.0: putting AGP V3 device into 8x mode [3.064666] radeon :f0:10.0: GTT: 256M 0x - 0x0FFF [3.070864] [drm] Generation 2 PCI interface, using max accessible memory [3.077672] radeon :f0:10.0: VRAM: 128M 0xC000 - 0xC7FF (128M used) [3.086487] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [3.093126] [drm] Driver supports precise vblank timestamp query. [3.099291] [drm] radeon: irq initialized. [3.103404] [drm] Detected VRAM RAM=128M, BAR=128M [3.108214] [drm] RAM width 128bits DDR [3.112263] [TTM] Zone kernel: Available graphics memory: 496682 kiB [3.118732] [TTM] Initializing pool allocator [3.123346] [drm] radeon: 128M of VRAM memory ready [3.128256] [drm] radeon: 256M of GTT memory ready. [3.133295] [drm] radeon: ib pool ready. [3.137708] [drm] radeon: 1 quad pipes, 1 Z pipes initialized. [3.144018] radeon :f0:10.0: WB disabled [3.148326] [drm] fence driver on ring 0 use gpu addr 0x and cpu addr 0xd0066000 [3.157474] [drm] Loading R300 Microcode [3.162480] [drm] radeon: ring at 0x1000 [3.167569] [drm] ring test succeeded in 0 usecs cpu 0x0: Vector: 200 (Machine Check) at [c0d63aa0] pc: c00cc07c: .trace_hardirqs_on_caller+0x6c/0x190 lr: c00152f4: .cpu_idle+0x1a4/0x220 sp: c0d63d20 msr: 90009032 current = 0xc0c4db30 paca= 0xc000 softe: 0irq_happened: 0x01 pid = 0, comm = swapper/0 enter ? for help [c0d63db0] c00152f4 .cpu_idle+0x1a4/0x220 [c0d63e50] c0008fb8 .rest_init+0xe8/0x110 [c0d63ee0] c0ba2998 .start_kernel+0x3e4/0x408 [c0d63f90] c0007558 .start_here_common+0x20/0x48 0:mon> x [ 843.783295] Oops: Machine check, sig: 7 [#1] [ 843.787589] SMP NR_CPUS=4 Maple [ 843.790768] Modules linked in: [ 843.793855] NIP: c00cc07c LR: c00152f4 CTR: c0023eac [ 843.800920] REGS: c0d63aa0 TRAP: 0200 Not tainted (3.4.0+) [ 843.807376] MSR: 90009032 CR: 2422 XER: 0006 [ 843.815412] SOFTE: 0 [ 843.817607] TASK = c0c4db30[0] 'swapper/0' THREAD: c0d6 CPU: 0 [ 843.825035] GPR00: c0d63d20 c0d63280 c00152f4 [ 843.833169] GPR04: c0099d10 0001 0002 [ 843.841302] GPR08: 0100 c0e828e8 0140 [ 843.849436] GPR12: 4482 c000 [ 843.857570] GPR16: 00ff8750 00cdc890 010001e0 [ 843.865702] GPR20: 1dcd6500 [ 843.873835] GPR24: 00ec7b00 90009032 c0d7b178 [ 843.881979] GPR28: c0d7b278 0008 c0c970f8 c00152f4 [ 843.890314] NIP [c00cc07c] .trace_hardirqs_on_caller+0x6c/0x190 [ 843.896942] LR [c00152f4] .cpu_idle+0x1a4/0x220 [ 843.902181] Call Trace: [ 843.904640] [c0d63d20] [c0d63db0] init_thread_union+0x3db0/0x4000 (unreliable) [ 843.913317] [c0d63db0] [c00152f4] .cpu_idle+0x1a4/0x220 [ 843.919964] [c0d63
Re: [PATCH] omap2+: add drm device
On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
>> Register OMAP DRM/KMS platform device. DMM is split into a
>> separate device using hwmod.
>>
>> Signed-off-by: Andy Gross
>
>
>
>> +static int __init omap_init_drm(void)
>> +{
>> + struct omap_hwmod *oh = NULL;
>> + struct platform_device *pdev;
>> +
>> + /* lookup and populate the DMM information, if present - OMAP4+ */
>> + oh = omap_hwmod_lookup("dmm");
>> +
>> + if (oh) {
>> + pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
>> + false);
>> + WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
>> + oh->name);
>> + }
>> +
>> + return platform_device_register(&omap_drm_device);
>> +
>> +}
>
> I still don't like fixing the tiler to drm. I would like to have basic
> tiler support in omapfb also, but with this approach I'll need to
> duplicate the code. And even if we disregard omapfb, wouldn't it be
> architecturally better to have the tiler as a separate independent
> library/driver?
Not easily, at least not if we want to manage to use tiler/dmm in a
more dynamic way, or to enable some additional features which are
still on the roadmap (like reprogramming dmm synchronized w/ scanout,
or some things which are coming if future hw generations). We need
one place to keep track of which buffers are potentially evictable to
make room for mapping a new buffer. And if you look at the tricks
that go on with mmap'ing tiled buffers to userspace, you *really*
don't want to duplicate that in N different drivers.
Fortunately with dmabuf there is not really a need for N different
drivers to need to use tiler/dmm directly. The dmabuf mechanism
provides what they need to import GEM buffers from omapdrm. That may
not really help omapfb because fbdev doesn't have a concept of
importing buffers. But OTOH this is unnecessary, because drm provides
an fbdev interface for legacy apps. The best thing I'd recommend is,
if you miss some features of omapfb in the drm fbdev implementation,
is to send some patches to add this missing features.
>> +struct omap_drm_platform_data {
>> + struct omap_kms_platform_data *kms_pdata;
>> +};
>
> This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
> didn't just move the struct. Is that on purpose?
the dmm pdata is no longer needed because we get what we need from
hwmod via platform_get_resource()
BR,
-R
> Tomi
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 12882] [855GM missing DVO driver] s-video not detected
https://bugs.freedesktop.org/show_bug.cgi?id=12882 Daniel Vetter changed: What|Removed |Added Summary|[855GM missng DVO driver] |[855GM missing DVO driver] |s-video not detected|s-video not detected -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 Daniel Vetter changed: What|Removed |Added Summary|[830M] need support for |[830M missing dvo driver] |DVO-LVDS via na2501 |need support for DVO-LVDS ||via na2501 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 12882] [855GM missng DVO driver] s-video not detected
https://bugs.freedesktop.org/show_bug.cgi?id=12882 Daniel Vetter changed: What|Removed |Added Summary|[855GM DVO] s-video not |[855GM missng DVO driver] |detected (DVO TV not|s-video not detected |supported yet) | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30845] [855 missing dvo driver] DVI output unsupported
https://bugs.freedesktop.org/show_bug.cgi?id=30845 Daniel Vetter changed: What|Removed |Added Severity|normal |enhancement Priority|medium |lowest Summary|[855] DVI output|[855 missing dvo driver] |unsupported |DVI output unsupported --- Comment #6 from Daniel Vetter 2012-05-25 05:05:59 PDT --- Downgrading all missing dvo driver bugs to feature request level. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17902] [830M] need support for DVO-LVDS via na2501
https://bugs.freedesktop.org/show_bug.cgi?id=17902 Chris Wilson changed: What|Removed |Added CC||t...@math.tu-berlin.de --- Comment #71 from Chris Wilson 2012-05-25 05:01:20 PDT --- *** Bug 50303 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: introduce DRM_CONNECTOR_POLL_FORCE
Useful for ->detect functions that have different behaviour if force
is set. This way probe_single_connector can avoid to do the expensive
edid dance on connectors where this is not needed.
I've checked through all drivers and set this flag everywhere where
the connector->detect function has different behaviour if force is
set. For nouveau and radeon I've got lost in the code traces, so I've
set this flag unconditionally.
Note that we also need to update the poll_execute function to now
also ignore connectors which have only this new flag set.
v2: Change POLL_HDP checks so that they ignore POLL_FORCE for both the
poll and the hpd handling code.
v3: Sprinkle POLL_FORCE more liberally over drivers. It should be now
everywhere where a non-intel driver can return anything else than
connector_status_connected in its detect callback.
v4: Fixup psb compile fail.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |6 --
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 ++
drivers/gpu/drm/gma500/cdv_intel_crt.c|2 ++
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 ++
drivers/gpu/drm/gma500/mdfld_dsi_output.c |1 +
drivers/gpu/drm/gma500/oaktrail_hdmi.c|2 ++
drivers/gpu/drm/gma500/psb_intel_sdvo.c |2 ++
drivers/gpu/drm/i915/intel_crt.c |3 ++-
drivers/gpu/drm/i915/intel_tv.c |3 ++-
drivers/gpu/drm/nouveau/nouveau_connector.c |1 +
drivers/gpu/drm/radeon/radeon_connectors.c|5 +
drivers/gpu/drm/udl/udl_connector.c |2 ++
drivers/staging/omapdrm/omap_connector.c |2 ++
include/drm/drm_crtc.h|4
14 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b1d643d..8ea1c1e 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -944,7 +944,9 @@ static void output_poll_execute(struct work_struct *work)
/* Ignore HDP capable connectors and connectors where we don't
* want any hotplug detection at all for polling. */
- if (!connector->polled || connector->polled ==
DRM_CONNECTOR_POLL_HPD)
+ if (!connector->polled ||
+ connector->polled == DRM_CONNECTOR_POLL_FORCE ||
+ (connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
@@ -1029,7 +1031,7 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
/* Only handle HPD capable connectors. */
- if (connector->polled != DRM_CONNECTOR_POLL_HPD)
+ if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
old_status = connector->status;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index bf791fa..e5a8a27 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -327,6 +327,8 @@ struct drm_connector *exynos_drm_connector_create(struct
drm_device *dev,
drm_connector_init(dev, connector, &exynos_connector_funcs, type);
drm_connector_helper_add(connector, &exynos_connector_helper_funcs);
+ connector->polled |= DRM_CONNECTOR_POLL_FORCE;
+
err = drm_sysfs_connector_add(connector);
if (err)
goto err_connector;
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 1874220..e6b2e49 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -313,6 +313,8 @@ void cdv_intel_crt_init(struct drm_device *dev,
drm_connector_helper_add(connector,
&cdv_intel_crt_connector_helper_funcs);
+ connector->polled |= DRM_CONNECTOR_POLL_FORCE;
+
drm_sysfs_connector_add(connector);
return;
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 88b59d4..766aec8 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -373,6 +373,8 @@ void cdv_hdmi_init(struct drm_device *dev,
hdmi_priv->hdmi_i2c_adapter =
&(psb_intel_encoder->i2c_bus->adapter);
hdmi_priv->dev = dev;
+ connector->polled |= DRM_CONNECTOR_POLL_FORCE;
+
drm_sysfs_connector_add(connector);
return;
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 5675d93..0e97a91 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -604,6 +604,7 @@ voi
Re: [pull] drm-intel-fixes for 3.5
On Thu, May 24, 2012 at 05:56:24PM +0200, Daniel Vetter wrote: > Hi Dave, > > A set of fixes for 3.5: > - Fixes for regressions in 3.5: fix spurious gmbus NAK, fix module unload, > fix pch pll asserts. > - Fix up eDP panel power sequencing - turns out we need to keep vdd on > while switching everything off. > - Reject doubleclocked modes on dp. > - Fixup sdvo interlaced handling. It never worked, but the missing bits > are just a tiny patch. > - Re-add some accidentally killed tv modes, also re-add > a vblank wait in the tv detect code that we've lost somewhere around > 2.6.36. > - Preliminary ducttape for gpu turbo on snb+ - we're working the hw guys > to figure out what's missing, because this code /should/ be the same the > windows driver does. But that usually takes a while ... > - Fixup turbo for media workloads on snb+. > - And a no-lvds quirk. As dicussed on irc I've smashed 3 more patches onto this: - Shut up the noisy rps turbo message. - Don't complain about unbinding pinned buffers any more - we now use that check intentionally. - Limit broadwater/crestline (i.e. vintage i965g/gm) to DMA32 for shmfs. Note that this requires, like gma500 the improved shmfs code to make it really tight. But otoh the only a few indirect states can't be above 4G, so this should be sufficient in all but the most contrived cases. Yours, Daniel The following changes since commit f15b4ca2ccbc0a4661c35a744d254e1e32dd1e15: Merge tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next (2012-05-21 08:17:42 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to ef12dab779acdb907eb4c3fa723e1c6f035ee13c: drm/i915: tune down the noise of the RP irq limit fail (2012-05-25 10:29:15 +0200) Chris Wilson (4): drm/i915: Always update RPS interrupts thresholds along with frequency drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationship drm/i915: Limit page allocations to lowmem (dma32) for i965 drm/i915: Remove the error message for unbinding pinned buffers Daniel Vetter (7): drm/i915: be more careful when returning -ENXIO in gmbus transfer drm/i915: fix module unload since error_state rework drm/i915: properly handle interlaced bit for sdvo dtd conversion drm/i915: enable vdd when switching off the eDP panel drm/i915: wait for a vblank to pass after tv detect drm/i915: reject doubleclocked cea modes on dp drm/i915: tune down the noise of the RP irq limit fail Jan-Benedict Glaw (1): drm/i915: no lvds quirk for HP t5740e Thin Client Jesse Barnes (1): drm/i915: always use RPNSWREQ for turbo change requests Rodrigo Vivi (1): drm/i915: Adding TV Out Missing modes. drivers/gpu/drm/i915/i915_debugfs.c|2 + drivers/gpu/drm/i915/i915_gem.c| 16 +--- drivers/gpu/drm/i915/i915_irq.c| 37 -- drivers/gpu/drm/i915/intel_display.c | 56 drivers/gpu/drm/i915/intel_dp.c| 24 +++- drivers/gpu/drm/i915/intel_i2c.c | 21 ++- drivers/gpu/drm/i915/intel_lvds.c |8 drivers/gpu/drm/i915/intel_pm.c| 64 ++-- drivers/gpu/drm/i915/intel_sdvo.c | 12 -- drivers/gpu/drm/i915/intel_sdvo_regs.h |5 +++ drivers/gpu/drm/i915/intel_tv.c| 53 ++ 11 files changed, 197 insertions(+), 101 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: schedule gma500 stub driver for feature removal
On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > In v3.3, the gma500 drm driver moved from staging to drm group by > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > brightness well and don't need gma500 stub driver anymore. > > So, my plan is remove gma500 stub driver at Dec. 2012. Why not just remove it right now as it's not needed at all anymore? thanks, greg k-h
[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
Hi All,
I realise it's been a while since this was last discussed, however I'd like
to bring up kernel-side synchronization again. By kernel-side
synchronization, I mean allowing multiple drivers/devices wanting to access
the same buffer to do so without bouncing up to userspace to resolve
dependencies such as "the display controller can't start scanning out a
buffer until the GPU has finished rendering into it". As such, this is
really just an optimization which reduces latency between E.g. The GPU
finishing a rendering job and that buffer being scanned out. I appreciate
this particular example is already solved on desktop graphics cards as the
display controller and 3D core are both controlled by the same driver, so no
"generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM
Mali) and display controller tend to be driven by separate drivers, so some
mechanism is needed to allow both drivers to synchronize their access to
buffers.
There are multiple ways synchronization can be achieved, fences/sync objects
is one common approach, however we're presenting a different approach.
Personally, I quite like fence sync objects, however we believe it requires
a lot of userspace interfaces to be changed to pass around sync object
handles. Our hope is that the kds approach will require less effort to make
use of as no existing userspace interfaces need to be changed. E.g. To use
explicit fences, the struct drm_mode_crtc_page_flip would need a new members
to pass in the handle(s) of sync object(s) which the flip depends on (I.e.
don't flip until these fences fire). The additional benefit of our approach
is that it prevents userspace specifying dependency loops which can cause a
deadlock (see kds.txt for an explanation of what I mean here).
I have waited until now to bring this up again because I am now able to
share the code I was trying (and failing I think) to explain previously. The
code has now been released under the GPLv2 from ARM Mali's developer portal,
however I've attempted to turn that into a patch to allow it to be discussed
on this list. Please find the patch inline below.
While KDS defines a very generic mechanism, I am proposing that this code or
at least the concepts be merged with the existing dma_buf code, so a the
struct kds_resource members get moved to struct dma_buf, kds_* functions get
renamed to dma_buf_* functions, etc. So I guess what I'm saying is please
don't review the actual code just yet, only the concepts the code describes,
where kds_resource == dma_duf.
Cheers,
Tom
Author: Tom Cooksey
Date: Fri May 25 10:45:27 2012 +0100
Add new system to allow synchronizing access to resources
See Documentation/kds.txt for details, however the general
idea is that this kds framework synchronizes multiple drivers
("clients") wanting to access the same resources, where a
resource is typically a 2D image buffer being shared around
using dma-buf.
Note: This patch is created by extracting the sources from the
tarball on and putting them in
roughly the right places.
diff --git a/Documentation/kds.txt b/Documentation/kds.txt
new file mode 100644
index 000..a96db21
--- /dev/null
+++ b/Documentation/kds.txt
@@ -0,0 +1,113 @@
+#
+# (C) COPYRIGHT 2012 ARM Limited. All rights reserved.
+#
+# This program is free software and is provided to you under the terms of
the GNU General Public License version 2
+# as published by the Free Software Foundation, and any use by you of this
program is subject to the terms of such GNU licence.
+#
+# A copy of the licence is included with the program, and can also be
obtained from Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
+#
+#
+
+
+==
+kds - Kernel Dependency System
+==
+
+Introduction
+
+kds provides a mechanism for clients to atomically lock down multiple
abstract resources.
+This can be done either synchronously or asynchronously.
+Abstract resources is used to allow a set of clients to use kds to control
access to any
+resource, an example is structured memory buffers.
+
+kds supports that buffer is locked for exclusive access and sharing of
buffers.
+
+kds can be built as either a integrated feature of the kernel or as a
module.
+It supports being compiled as a module both in-tree and out-of-tree.
+
+
+Concepts
+
+A core concept in kds is abstract resources.
+A kds resource is just an abstraction for some client object, kds doesn't
care what it is.
+Typically EGL will consider UMP buffers as being a resource, thus each UMP
buffer has
+a kds resource for synchronization to the buffer.
+
+kds allows a client to create and destroy the abstract resource objects.
+A new resource object is made available asap (it is just a simple malloc
with some initialization
[Bug 43272] pink/purple line displays to the left of the screen
https://bugzilla.kernel.org/show_bug.cgi?id=43272 Damien Churchill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Damien Churchill 2012-05-25 10:14:12 --- Hi, Setting radeon.audio=0 has resolved the problem. I still had radeon.audio=1 set in a modprobe.d file left over from when I had a HD4870. Thanks for the help! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: fix disabled vmap function
On Fri, May 25, 2012 at 10:18 AM, Sumit Semwal wrote:
> Hi Dave,
>
> On 25 May 2012 14:34, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> include/linux/dma-buf.h: In function ‘dma_buf_vmap’:
>> include/linux/dma-buf.h:260:1: warning: no return statement in function
>> returning non-void [-Wreturn-type]
>>
>> Reported-by: w...@linux.intel.com
>> Signed-off-by: Dave Airlie
>> ---
>> include/linux/dma-buf.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index d8c2865..506bb7b 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
>>
>> static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
>> {
>> + return NULL;
>> }
> I fixed this as part of rebasing while applying your vmap patch to my
> for-next - so it is already in my pull request.
>
Ah I didn't read the full warning mail, it was giving out about Tomasz
tree, he must have merged an older version.
Thanks,
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: remove gma500 stub driver
On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > In v3.3, the gma500 drm driver moved from staging to drm group by > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > brightness well and don't need gma500 stub driver anymore. Looks good to me. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH] dma-buf: fix disabled vmap function
From: Dave Airlie
include/linux/dma-buf.h: In function ‘dma_buf_vmap’:
include/linux/dma-buf.h:260:1: warning: no return statement in function
returning non-void [-Wreturn-type]
Reported-by: w...@linux.intel.com
Signed-off-by: Dave Airlie
---
include/linux/dma-buf.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d8c2865..506bb7b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ return NULL;
}
static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
--
1.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 1/2] libkms: YUYV support
From: Ville Syrjälä
---
libkms/intel.c |6 +-
libkms/libkms.h |2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/libkms/intel.c b/libkms/intel.c
index 8b8249b..8aeb6ae 100644
--- a/libkms/intel.c
+++ b/libkms/intel.c
@@ -52,7 +52,7 @@ intel_get_prop(struct kms_driver *kms, unsigned key, unsigned
*out)
{
switch (key) {
case KMS_BO_TYPE:
- *out = KMS_BO_TYPE_SCANOUT_X8R8G8B8 |
KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8;
+ *out = KMS_BO_TYPE_SCANOUT_X8R8G8B8 |
KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 | KMS_BO_TYPE_SCANOUT_YUYV;
break;
default:
return -EINVAL;
@@ -100,6 +100,10 @@ intel_bo_create(struct kms_driver *kms,
pitch = width * 4;
pitch = (pitch + 512 - 1) & ~(512 - 1);
size = pitch * ((height + 4 - 1) & ~(4 - 1));
+ } else if (type == KMS_BO_TYPE_SCANOUT_YUYV) {
+ pitch = width * 2;
+ pitch = (pitch + 64 - 1) & ~(64 - 1);
+ size = pitch * height;
} else {
return -EINVAL;
}
diff --git a/libkms/libkms.h b/libkms/libkms.h
index 4664442..8cf3489 100644
--- a/libkms/libkms.h
+++ b/libkms/libkms.h
@@ -59,6 +59,8 @@ enum kms_bo_type
#define KMS_BO_TYPE_SCANOUT_X8R8G8B8 KMS_BO_TYPE_SCANOUT_X8R8G8B8
KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 = (1 << 1),
#define KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8 KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8
+ KMS_BO_TYPE_SCANOUT_YUYV = (1 << 2),
+#define KMS_BO_TYPE_SCANOUT_YUYV KMS_BO_TYPE_SCANOUT_YUYV
};
int kms_create(int fd, struct kms_driver **out);
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 2/2] libdrm: atomic mode set
From: Ville Syrjälä
---
include/drm/drm.h |1 +
include/drm/drm_mode.h | 13 +++
xf86drmMode.c | 270
xf86drmMode.h | 19
4 files changed, 303 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5e6cd29..c3236e1 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -733,6 +733,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
#define DRM_IOCTL_MODE_OBJ_GETPROPERTIES DRM_IOWR(0xB9, struct
drm_mode_obj_get_properties)
#define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct
drm_mode_obj_set_property)
+#define DRM_IOCTL_MODE_ATOMIC DRM_IOWR(0xBB, struct drm_mode_atomic)
/**
* Device specific ioctls should only be in their respective headers
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 62ba997..5b2f294 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -462,4 +462,17 @@ struct drm_mode_destroy_dumb {
__u32 handle;
};
+#define DRM_MODE_ATOMIC_TEST_ONLY (1<<0)
+
+/* FIXME come up with some sane error reporting mechanism? */
+struct drm_mode_atomic {
+ __u32 flags;
+ __u32 count_objs;
+ __u64 objs_ptr;
+ __u64 count_props_ptr;
+ __u64 props_ptr;
+ __u64 prop_values_ptr;
+ __u64 blob_values_ptr;
+};
+
#endif
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 04fdf1f..18cd10b 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "xf86drmMode.h"
#include "xf86drm.h"
@@ -1057,3 +1058,272 @@ int drmModeObjectSetProperty(int fd, uint32_t
object_id, uint32_t object_type,
return DRM_IOCTL(fd, DRM_IOCTL_MODE_OBJ_SETPROPERTY, &prop);
}
+
+typedef struct _drmModePropertySetItem drmModePropertySetItem,
*drmModePropertySetItemPtr;
+
+struct _drmModePropertySetItem {
+ uint32_t object_id;
+ uint32_t property_id;
+ bool is_blob;
+ uint64_t value;
+ void *blob;
+ drmModePropertySetItemPtr next;
+};
+
+struct _drmModePropertySet {
+ unsigned int count_objs;
+ unsigned int count_props;
+ unsigned int count_blobs;
+ drmModePropertySetItem list;
+};
+
+drmModePropertySetPtr drmModePropertySetAlloc(void)
+{
+ drmModePropertySetPtr set;
+
+ set = drmMalloc(sizeof *set);
+ if (!set)
+ return NULL;
+
+ set->list.next = NULL;
+ set->count_props = 0;
+ set->count_objs = 0;
+
+ return set;
+}
+
+int drmModePropertySetAdd(drmModePropertySetPtr set,
+ uint32_t object_id,
+ uint32_t property_id,
+ uint64_t value)
+{
+ drmModePropertySetItemPtr prev = &set->list;
+ bool new_obj = false;
+
+ /* keep it sorted by object_id and property_id */
+ while (prev->next) {
+ if (prev->next->object_id > object_id) {
+ new_obj = true;
+ break;
+ }
+
+ if (prev->next->object_id == object_id &&
+ prev->next->property_id >= property_id)
+ break;
+
+ prev = prev->next;
+ }
+
+ if (!prev->next &&
+ (prev == &set->list || prev->object_id != object_id))
+ new_obj = true;
+
+ /* replace or add? */
+ if (prev->next &&
+ prev->next->object_id == object_id &&
+ prev->next->property_id == property_id) {
+ drmModePropertySetItemPtr item = prev->next;
+
+ if (item->is_blob)
+ return -EINVAL;
+
+ item->value = value;
+ } else {
+ drmModePropertySetItemPtr item;
+
+ item = drmMalloc(sizeof *item);
+ if (!item)
+ return -1;
+
+ item->object_id = object_id;
+ item->property_id = property_id;
+ item->value = value;
+ item->is_blob = false;
+ item->blob = NULL;
+
+ item->next = prev->next;
+ prev->next = item;
+
+ set->count_props++;
+ }
+
+ if (new_obj)
+ set->count_objs++;
+
+ return 0;
+}
+
+int drmModePropertySetAddBlob(drmModePropertySetPtr set,
+ uint32_t object_id,
+ uint32_t property_id,
+ uint64_t length,
+ void *data)
+{
+ drmModePropertySetItemPtr prev = &set->list;
+ bool new_obj = false;
+
+ /* keep it sorted by object_id and property_id */
+ while (prev->next) {
+ if (prev->next->object_id > object_id) {
+ new_obj = true;
+ break;
+ }
+
+ if (prev->next->object_id == object_id &&
+
[RFC][PATCH 0/2] libdrm: Atomic mode setting stuff
Here's the libdrm part of the atomic mode setting stuff. There's a new object I christened drmModePropertySet. It's an opaque object which is used to keep track of property changes for the user. Internally it's just a linked list of object_id/property_id/property_value tuples. The list is sorted based on object_id and property_id to avoid duplicates. The YUYV libkms patch is there just because my test app was more geared towards YUV than RGB, and I was too lazy to make the switch to RGB. I also stripped out a bunch of gunk from my test app and pushed the result to gitorious [1]. What it does is move/resize the plane and flips the CRTC fb at the same time using the new API. The app has a rudimentary keyboard control mechanism: 't' toggles an automatic test mode 's','z','x','c' move the plane 'S','Z','X','C' change the plane size 'f' fills the plane with a pattern, the color changes each time 'b' fills the plane with color bars 'l' loads a ppm (P6) image into the plane 'o' toggles the plane on/off 'q' quits [1] https://gitorious.org/vsyrjala/plane ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #24 from Santiago Garcia Mantinan 2012-05-25 07:35:48 --- About my previous message... when I talk about 3.0 and 3.1 I meant that they were also failing, not working, 2.6.39 was the last working one for me, I tested all the series since that one and they were all broken. Hope this clarifies a bit and sorry for the confusion. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: add helper to clflush a virtual address range
Hi Greg,
On Fri, May 25, 2012 at 02:24:32PM +0900, Greg KH wrote:
> I see you say you wanted the patch below for the stable tree, due to
> some later patch needing it, yet this patch was not "marked" for the
> stable tree, and I can't seem to figure out which "later patch" you are
> referring to here.
>
> Any hints on what I should do for the 3.4-stable kernel tree with this?
Oops, I've changed plans for that bug and sent a more minimal patch that
simply covers over the problem rather well than fixes it 100% perfect.
I've dropped the Cc: stable, bug forgot to adjust the commit message.
So this patch isn't for stable any more, sorry for wasting your time.
Yours, Daniel
>
> thanks,
>
> greg k-h
>
> On Thu, May 24, 2012 at 07:55:29PM +, Linux Kernel Mailing List wrote:
> > Gitweb:
> > http://git.kernel.org/linus/;a=commit;h=6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> > Commit: 6d5cd9cb1e32e4f4e4468704430b26bcb0bfb129
> > Parent: dbf7bff074d5fdc87c61b1b41d8e809109cf0bf8
> > Author: Daniel Vetter
> > AuthorDate: Sun Mar 25 19:47:30 2012 +0200
> > Committer: Daniel Vetter
> > CommitDate: Tue Mar 27 13:19:45 2012 +0200
> >
> > drm: add helper to clflush a virtual address range
> >
> > Useful when the page is already mapped to copy date in/out.
> >
> > For -stable because the next patch (fixing phys obj pwrite) needs this
> > little helper function.
> >
> > Tested-by: Chris Wilson
> > Reviewed-by: Chris Wilson
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_cache.c | 23 +++
> > include/drm/drmP.h |1 +
> > 2 files changed, 24 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> > index 5928653..c7c8f6b 100644
> > --- a/drivers/gpu/drm/drm_cache.c
> > +++ b/drivers/gpu/drm/drm_cache.c
> > @@ -98,3 +98,26 @@ drm_clflush_pages(struct page *pages[], unsigned long
> > num_pages)
> > #endif
> > }
> > EXPORT_SYMBOL(drm_clflush_pages);
> > +
> > +void
> > +drm_clflush_virt_range(char *addr, unsigned long length)
> > +{
> > +#if defined(CONFIG_X86)
> > + if (cpu_has_clflush) {
> > + char *end = addr + length;
> > + mb();
> > + for (; addr < end; addr += boot_cpu_data.x86_clflush_size)
> > + clflush(addr);
> > + clflush(end - 1);
> > + mb();
> > + return;
> > + }
> > +
> > + if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> > + printk(KERN_ERR "Timed out waiting for cache flush.\n");
> > +#else
> > + printk(KERN_ERR "Architecture has no drm_cache.c support\n");
> > + WARN_ON_ONCE(1);
> > +#endif
> > +}
> > +EXPORT_SYMBOL(drm_clflush_virt_range);
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 92f0981..d33597b 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1332,6 +1332,7 @@ extern int drm_remove_magic(struct drm_master
> > *master, drm_magic_t magic);
> >
> > /* Cache management (drm_cache.c) */
> > void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
> > +void drm_clflush_virt_range(char *addr, unsigned long length);
> >
> > /* Locking IOCTL support (drm_lock.h) */
> > extern int drm_lock(struct drm_device *dev, void *data,
> > --
> > To unsubscribe from this list: send the line "unsubscribe git-commits-head"
> > in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/i915 3.5 merge window: gen6_sanitize_pm errors
On Thu, May 24, 2012 at 07:27:04PM -0700, Linus Torvalds wrote: > These guys seem to be recently introduced: > > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206 > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700 > > This is on my SNB Macbook Air. > > Everything seems to *work*, which makes me think: > > - that error isn't really so big a deal that you have to *SHOUT* about it. > > - I wonder how valid the discrepancy checking code is to begin with. > > Hmm? On snb/ivb we have a problem that the gpu turbo can get stuck, and most often it gets stuck at the lowest frequency, resulting in unhappy users. Chris noticed that this happens when the RP irq limit register reads a bogus value (and eventually gets stuck). Although your machine looks interesting, because usually we just read back 0. I've already sent a pull request to Dave with our current best effort to duct-tape over the problem. If that doesn't cut out the dmesg flood, I guess we need to tune down that message a bit. But we've added it in that obnoxious way in the first place to get bug reports, so that we actually know how bad the problem is. Hence I'd like to keep it around a bit. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50325] Glyphy bad render on r600g (software render is fine)
https://bugs.freedesktop.org/show_bug.cgi?id=50325 --- Comment #3 from Török Edwin 2012-05-25 00:22:27 PDT --- With the git version of Mesa I get an error, opened new bug here: https://bugs.freedesktop.org/show_bug.cgi?id=50338 EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50338] r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
https://bugs.freedesktop.org/show_bug.cgi?id=50338 --- Comment #1 from Török Edwin 2012-05-25 00:22:02 PDT --- Created attachment 62088 --> https://bugs.freedesktop.org/attachment.cgi?id=62088 R600_DUMP_SHADERS=1 output from working Mesa 8.0.2 shader dump from working: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 OpenGL extensions: -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50338] New: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
https://bugs.freedesktop.org/show_bug.cgi?id=50338 Bug #: 50338 Summary: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: edwin+m...@etorok.net Created attachment 62087 --> https://bugs.freedesktop.org/attachment.cgi?id=62087 R600_DUMP_SHADERS=1 output Trying to reproduce bug #50325 on Mesa git caused this error: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Bug can be reproduced by one of these: build/glretrace lt-glyphy-demo.trace demo/glyphy-demo I get the translation failed error both with R600_LLVM=0, and R600_LLVM=1. I've attached the R600_DUMP_SHADERS=1 output. glretrace is from https://github.com/apitrace/apitrace/tree/1.0 and glyphy is from https://code.google.com/p/glyphy/source/checkout lt-glypy-demo.trace is here: https://bugs.freedesktop.org/attachment.cgi?id=62078 git version of Mesa: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.1-devel (git-35f302d) OpenGL shading language version string: 1.30 OpenGL extensions: Built with (on Debian unstable): ./configure --with-dri-drivers= --with-gallium-drivers=r600,swrast --enable-glx-tls --enable-gallium-llvm LLVM_CONFIG=/usr/bin/llvm-config-3.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/i915 3.5 merge window: gen6_sanitize_pm errors
On Thu, 24 May 2012 19:27:04 -0700, Linus Torvalds wrote: > These guys seem to be recently introduced: > > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206 > [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: > GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700 > > This is on my SNB Macbook Air. > > Everything seems to *work*, which makes me think: > > - that error isn't really so big a deal that you have to *SHOUT* about it. > > - I wonder how valid the discrepancy checking code is to begin with. Extremely, it is accurately telling us that only half of the patches were applied... After that when it does shout, it just saved your system. However, even after fixing it to the best of our knowledge, it is still a far too regular occurrence (playing video seems to have just the right combination of turbo and rc6 to trigger it reliably) and even though it is a calamity we do now expect it to be seen in the wild and so will reduce the severity of the warning. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
