[PATCH 1/1] drm/exynos: Remove redundant OF dependency
Now that DRM_EXYNOS depends on OF, we do not need individual drivers to depend on it. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/gpu/drm/exynos/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 4752f22..45b6ef5 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -56,7 +56,7 @@ config DRM_EXYNOS_IPP config DRM_EXYNOS_FIMC bool Exynos DRM FIMC - depends on DRM_EXYNOS_IPP MFD_SYSCON OF + depends on DRM_EXYNOS_IPP MFD_SYSCON help Choose this option if you want to use Exynos FIMC for DRM. -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/exynos: Fix address space warning in exynos_drm_buf.c
Fixes the following warning:
drivers/gpu/drm/exynos/exynos_drm_buf.c:66:29: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_buf.c:66:29:
expected void [noderef] asn:2*kvaddr
drivers/gpu/drm/exynos/exynos_drm_buf.c:66:29: got void *
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_buf.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 3445a0f..d20a7af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -63,7 +63,8 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
return -ENOMEM;
}
- buf-kvaddr = dma_alloc_attrs(dev-dev, buf-size,
+ buf-kvaddr = (void __iomem *)dma_alloc_attrs(dev-dev,
+ buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
if (!buf-kvaddr) {
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: Fix address space warnings in exynos_drm_fbdev.c
Silences the following warnings:
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40:
expected void [noderef] asn:2*kvaddr
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:102:40:got void *
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:107:48: warning:
incorrect type in assignment (different address spaces)
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:107:48:
expected void [noderef] asn:2*kvaddr
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:107:48:got void *
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 78e868b..e7c2f2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -99,12 +99,13 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
if (is_drm_iommu_supported(dev)) {
unsigned int nr_pages = buffer-size PAGE_SHIFT;
- buffer-kvaddr = vmap(buffer-pages, nr_pages, VM_MAP,
+ buffer-kvaddr = (void __iomem *) vmap(buffer-pages,
+ nr_pages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
} else {
phys_addr_t dma_addr = buffer-dma_addr;
if (dma_addr)
- buffer-kvaddr = phys_to_virt(dma_addr);
+ buffer-kvaddr = (void __iomem
*)phys_to_virt(dma_addr);
else
buffer-kvaddr = (void __iomem *)NULL;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Discussion starters for ION session at Linux Plumbers Android+Graphics microconf
On Thu, Sep 5, 2013 at 8:49 PM, John Stultz john.stu...@linaro.org wrote: Hey everyone, In preparation for the Plumbers Android+Graphics microconf, I wanted to send out some background documentation to try to get all the context we can out there prior to the discussion, as time will be limited and it would be best to spend it discussing solutions rather then re-hashing problems and requirements. I'm sure many folks on this list could probably do a better job summarizing the issues, but I wanted to get this out there to try to enumerate the problems and the different perspectives on the issues that I'm aware of. The document is on LWN here: http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ oh, I had missed that article.. fwiw Another possible solution is to allow dma-buf exporters to not allocate the backing buffers immediately. This would allow multiple drivers to attach to a dma-buf before the allocation occurs. Then, when the buffer is first used, the allocation is done; at that time, the allocator could scan the list of attached drivers and be able to determine the constraints of the attached devices and allocate memory accordingly. This would allow user space to not have to deal with any constraint solving. That is actually how dma-buf works today. And at least with GEM buffers exported as dma-buf's, the allocation is deferred. It does require attaching the buffers in all the devices that will be sharing the buffer up front (but I suppose you need to know the involved devices one way or another with any solution, so this approach seems as good as any). We *do* still need to spiff up dev-dma_parms a bit more, and there might be some room for some helpers to figure out the union of all attached devices constraints, and allocate suitable backing pages... so perhaps this is one thing we should be talking about. At any rate, it might not matter if ION cannot import dma-buf's (as long as every other device importing does not have to differentiate between importing dma-buf's that are also ION buffers vs dma-buf's allocated in some other way). But to be useful upstream, we'd have to ensure that existing drm drivers can somehow plug-in their existing allocation mechanisms in to ION. BR, -R But I wanted to start a discussion thread here, since the LWN comment threads (while *much* better then most comment sections) aren't really the right place for this sort of thing. So please feel free to reply to correct any inaccuracies in my summary, provide your thoughts on the various proposed solutions, or suggest new solutions that we should also discuss at the micro-conference! thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 19:20, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt
(https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy
setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by
resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided
by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch
set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please
re-
post
your patch set after discussing how to
Re: Discussion starters for ION session at Linux Plumbers Android+Graphics microconf
On 09/05/2013 08:26 PM, Rob Clark wrote: On Thu, Sep 5, 2013 at 8:49 PM, John Stultz john.stu...@linaro.org wrote: Hey everyone, In preparation for the Plumbers Android+Graphics microconf, I wanted to send out some background documentation to try to get all the context we can out there prior to the discussion, as time will be limited and it would be best to spend it discussing solutions rather then re-hashing problems and requirements. I'm sure many folks on this list could probably do a better job summarizing the issues, but I wanted to get this out there to try to enumerate the problems and the different perspectives on the issues that I'm aware of. The document is on LWN here: http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ oh, I had missed that article.. fwiw It was published just moments before I sent out this thread, so I wouldn't have expected anyone to have seen it yet. :) Another possible solution is to allow dma-buf exporters to not allocate the backing buffers immediately. This would allow multiple drivers to attach to a dma-buf before the allocation occurs. Then, when the buffer is first used, the allocation is done; at that time, the allocator could scan the list of attached drivers and be able to determine the constraints of the attached devices and allocate memory accordingly. This would allow user space to not have to deal with any constraint solving. That is actually how dma-buf works today. And at least with GEM buffers exported as dma-buf's, the allocation is deferred. It does require attaching the buffers in all the devices that will be sharing the buffer up front (but I suppose you need to know the involved devices one way or another with any solution, so this approach seems as good as any). We *do* still need to spiff up dev-dma_parms a bit more, and there might be some room for some helpers to figure out the union of all attached devices constraints, and allocate suitable backing pages... so perhaps this is one thing we should be talking about. Ok. I had gone looking for an example of the deferred allocation, but didn't find it. I'll go look again, but if you have a pointer, that could be useful. So yea, I do think this is the most promising approach, but sorting out the next steps for doing a proof of concept is one thing I'd like to discuss (as mentioned in the article, via a ion-like generic allocator, or trying to wire in the constraint solving to some limited set of drivers via generic helper functions). As well as getting a better understanding the Android developers concern about any non-deterministic cost of allocating at mmap time. Thanks for the feedback and thoughts! I'm hopeful some approach to resolving the various issues can be found, but I suspect it will have a few different parts. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #120 from lucky_beta lucky_b...@126.com --- I've read the previous comments carefully and I'm using the ati3470 GPU card which is the same as Sergey, also the problem similar, when trying to boot with radeon.dmp=1, the screen goes white gradually and just hang there, sometimes it can boot but the windows respond very slowly. I want to know whether the problem has been fixed. I just can't find any sure answers from the comments above. -- 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 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #121 from Sergey orbitg...@ukr.net --- Hi lucky_beta, For me it was not 100% fixed. At the moment with Kernel 3.11 it is ~50% chance that system hangs during boot or the windows are slow. It better than it was initially, but the issue is not fully resolved. (Don't have white screen issue even without patches) -- 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: [PULL] drm-intel-fixes
Blergh, forgotten to cc: mailing lists ... -Daniel On Fri, Sep 6, 2013 at 9:48 AM, Daniel Vetter dan...@ffwll.ch wrote: Hi Dave, Already a decent pile of fixes and a few stragglers for the merge window. Nothing in here though to appease Linus :( - Early stolen mem reservation from Jesse in x86 boot code. Acked by Ingo and hpa. This was ready much earlier but somehow I've thought it'd go in through x86 trees, hence why this is late. Avoids the pci resource code to plant mmiobars in the middle of stolen mem and other ugliness. - vgaarb improvements from Alex Williamson plus the fix from Ville for the vgacon-fbcon smooth transition feature. - Render pageflips on ivb/hsw to avoid stalls due to the ring switching when only flipping on the blitter (Chris). - Deadlock fixes around our flush_workqueue which crept back in - lockdep isn't clever enough :( - Shrinker recursion fix from Chris - this is the thing that blew the vma patches from Ben I've taken out of 3.12. - Fixup for the relocation refactoring. Also an igt testcase to make sure we don't break this again. - Pile of smaller fixups all over, shortlog has full details. Cheers, Daniel The following changes since commit f33bcab9e816c5bf56b74c3007790f2a256910eb: drm/radeon: support render nodes (2013-09-02 10:51:53 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-09-06 for you to fetch changes up to cac6a5ae0118832936eb162ec4cedb30f2422bcc: drm/i915: try not to lose backlight CBLV precision (2013-09-06 09:41:20 +0200) Alex Williamson (3): vgaarb: Don't disable resources that are not owned vgaarb: Fix VGA decodes changes i915: Update VGA arbiter support for newer devices Chris Wilson (9): drm/i915: Adjust available RPS information through sysfs for vlv drm/i915: Apply the force-detect VGA w/a to Valleyview drm/i915: Report requested frequency alongside current frequency in debugfs drm/i915: Embed the ring-private within the struct intel_ring_buffer drm/i915: Use RCS flips on Ivybridge+ drm/i915: Pin pages whilst mapping the dma-buf drm/i915: Hold an object reference whilst we shrink it drm/i915: Skip stolen region initialisation if none is reserved drm/i915: Confine page flips to BCS on Valleyview Damien Lespiau (1): drm/i915: Don't call sg_free_table() if sg_alloc_table() fails Daniel Vetter (6): drm/i915: tune down hangcheck noise drm/i915: fix up the relocate_entry refactoring drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock drm/i915: handle sdvo input pixel multiplier correctly again drm/i915: fix i9xx_crtc_clock_get for multiplied pixels drm/i915: fix gpu hang vs. flip stall deadlocks Imre Deak (1): drm/i915: fix lvds/dp panel fitter setting Jani Nikula (1): drm/i915: try not to lose backlight CBLV precision Jesse Barnes (2): drm/i915: split PCI IDs out into i915_drm.h v4 x86: add early quirk for reserving Intel graphics stolen memory v5 Joe Perches (1): i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc Mika Kuoppala (2): drm/i915: Don't mask EI UP interrupt on IVB|SNB drm/i915: sanitize forcewake registers on reset Paulo Zanoni (1): drm/i915: enable trickle feed on Haswell Ville Syrjälä (1): drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode arch/x86/kernel/early-quirks.c | 154 + drivers/gpu/drm/i915/i915_debugfs.c| 11 +- drivers/gpu/drm/i915/i915_dma.c| 9 +- drivers/gpu/drm/i915/i915_drv.c| 164 +- drivers/gpu/drm/i915/i915_drv.h| 7 + drivers/gpu/drm/i915/i915_gem.c| 48 +-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 41 +++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 + drivers/gpu/drm/i915/i915_gem_stolen.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_irq.c| 23 +++- drivers/gpu/drm/i915/i915_reg.h| 34 +++-- drivers/gpu/drm/i915/i915_sysfs.c | 36 - drivers/gpu/drm/i915/intel_crt.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 78 +-- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 8 +- drivers/gpu/drm/i915/intel_opregion.c | 2 +- drivers/gpu/drm/i915/intel_panel.c | 14 +- drivers/gpu/drm/i915/intel_pm.c| 14 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 99 -- drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +- drivers/gpu/drm/i915/intel_sdvo.c | 17 +-- drivers/gpu/drm/i915/intel_sprite.c| 7 +-
Re: Update: UVD status on loongson 3a platform
Am 06.09.2013 04:52, schrieb cee1:
2013/9/6 Jerome Glisse j.gli...@gmail.com:
On Thu, Sep 05, 2013 at 03:29:52PM -0400, Jerome Glisse wrote:
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recently find some interesting thing about UVD based playback on
loongson 3a plaform, and also find a way to fix the problem.
First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
caused the problem:
* If memcpy is implemented though 16B or 8B load/store instructions,
it will normally caused video mosaic. When insert a memcmp after the
copying code in memcpy, it will report the src and dest are not equal.
* If memcpy use 1B load/store instructions only, the memcmp after the
copying code reports equal.
Then we find the following changeset fixs out problem:
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 2f98de2..f9599b6 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
unsigned size)
{
buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
- RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
+ RADEON_DOMAIN_GTT);
if (!buffer-buf)
return false;
The VRAM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using 4B load/store
instructions in UVD workflow? Any idea?
How do you map the VRAM into user process mapping ? ie do you have
something like Intel PAT or something like MTRR or something else.
In other word, can you map into process address space a region of
io memory (GPU VRAM in this case) and mark it as uncached so that
none of the access to it goes through CPU cache.
Cheers,
Jerome
Also it might be that you can't do write combining on your platform,
which would be a major drawback as it's assume by radeon userspace.
I would need to check the pcie specification, but write combining is
probably not mandatory meaning that your architecture might not have
it. This would explain why only memset with byte size copy works.
Don't think there is any easy way to work around that.
The original mesa code allows to allocate buffer in GTT and VRAM
domain. And we change it so that all buffers are allocated in GTT
domain, it seems fix our problem.
Actually it's not a fix, but a quite ugly hack instead.
Depending on the UVD generation some buffer *must* be allocated in VRAM,
only starting with NI+ most buffers can be in GTT space instead and I'm
not even 100% sure that this feature is validated/working reliable.
Anyway, not having a reliable CPU access to VRAM is a quite critical
platform bug that should be fixed before even thinking about UVD support.
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55819] Mouse cursor corruption when moving between monitors
https://bugs.freedesktop.org/show_bug.cgi?id=55819 --- Comment #9 from 91k...@gmail.com --- I can confirm that this bug (with the exact same corruption shown in the screenshot) is still occurring on Linux 3.8.0-29-generic. Additional information: $ uname -a Linux 91KK 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -rd Description:Ubuntu 12.04.3 LTS Release:12.04 $ fglrxinfo display: :0 screen: 0 OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: AMD Radeon HD 6500M/5600/5700 Series OpenGL version string: 4.2.12002 Compatibility Profile Context 9.012 -- 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: Discussion starters for ION session at Linux Plumbers Android+Graphics microconf
On Thu, Sep 05, 2013 at 10:06:52PM -0700, John Stultz wrote: On 09/05/2013 08:26 PM, Rob Clark wrote: On Thu, Sep 5, 2013 at 8:49 PM, John Stultz john.stu...@linaro.org wrote: Hey everyone, In preparation for the Plumbers Android+Graphics microconf, I wanted to send out some background documentation to try to get all the context we can out there prior to the discussion, as time will be limited and it would be best to spend it discussing solutions rather then re-hashing problems and requirements. I'm sure many folks on this list could probably do a better job summarizing the issues, but I wanted to get this out there to try to enumerate the problems and the different perspectives on the issues that I'm aware of. The document is on LWN here: http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ oh, I had missed that article.. fwiw It was published just moments before I sent out this thread, so I wouldn't have expected anyone to have seen it yet. :) Another possible solution is to allow dma-buf exporters to not allocate the backing buffers immediately. This would allow multiple drivers to attach to a dma-buf before the allocation occurs. Then, when the buffer is first used, the allocation is done; at that time, the allocator could scan the list of attached drivers and be able to determine the constraints of the attached devices and allocate memory accordingly. This would allow user space to not have to deal with any constraint solving. That is actually how dma-buf works today. And at least with GEM buffers exported as dma-buf's, the allocation is deferred. It does require attaching the buffers in all the devices that will be sharing the buffer up front (but I suppose you need to know the involved devices one way or another with any solution, so this approach seems as good as any). We *do* still need to spiff up dev-dma_parms a bit more, and there might be some room for some helpers to figure out the union of all attached devices constraints, and allocate suitable backing pages... so perhaps this is one thing we should be talking about. Ok. I had gone looking for an example of the deferred allocation, but didn't find it. I'll go look again, but if you have a pointer, that could be useful. So yea, I do think this is the most promising approach, but sorting out the next steps for doing a proof of concept is one thing I'd like to discuss (as mentioned in the article, via a ion-like generic allocator, or trying to wire in the constraint solving to some limited set of drivers via generic helper functions). As well as getting a better understanding the Android developers concern about any non-deterministic cost of allocating at mmap time. Thanks for the feedback and thoughts! I'm hopeful some approach to resolving the various issues can be found, but I suspect it will have a few different parts. My main gripe with ION is that it creates a parallel infrastructure for figuring out allocation constraints of devices. Upstream already has all the knowledge (or at least most of it) for cache flushing, mapping into iommus and allocating from special pools stored in association with the device structure. So imo an upstream ION thing should reuse the information each device and its driver already has available. Now I also see that a central allocator has upsides since reinventing this wheel for every device driver is not a great idea. One idea to get there and keep the benefits of ION with up-front allocations would be. 1) Allcoate the dma-buf handle at the central allocator. No backing storage gets allocated. 2) Import that dma-buf everywhere you want it to be used. That way userspace doesn't need to deal with whatever hw madness is actually used to implement the drm/v4l/whatever devices nodes internally. 3) Ask the central allocator to finalize the buffer allocation placement and grab backing storage. If any further attaching happens that doesn't work out it would simply fail, and userspace gets to keep the pieces. Which is already the case in today's upstream when userspace is unlucky and doesn't pick the most constrained device. This only tackles the make memory allocation predictable issue ION solves, which leaves the optimized cache flushing. We can add caches for pre-flushed objects for that (not rocket science, most of the drm drivers have that wheel reinvented, too). That leaves us with optimizing cache flushes (i.e. leaving them out when switching between devices without cpu accesss in-between). The current linux dma api doesn't really support this, so we need to add a bit of interfaces there to be able to do device-to-device cache flushing (which safe for maybe iommu flushes I expect to be noops). And the central allocator obviously needs to keep track of where the current cache domain is. Aside: Intel Atom SoCs have the same cache flushing challenges since all the gfx blocks (gpu, display, camera, ...)
Re: Discussion starters for ION session at Linux Plumbers Android+Graphics microconf
On Fri, Sep 6, 2013 at 1:06 AM, John Stultz john.stu...@linaro.org wrote: On 09/05/2013 08:26 PM, Rob Clark wrote: On Thu, Sep 5, 2013 at 8:49 PM, John Stultz john.stu...@linaro.org wrote: Hey everyone, In preparation for the Plumbers Android+Graphics microconf, I wanted to send out some background documentation to try to get all the context we can out there prior to the discussion, as time will be limited and it would be best to spend it discussing solutions rather then re-hashing problems and requirements. I'm sure many folks on this list could probably do a better job summarizing the issues, but I wanted to get this out there to try to enumerate the problems and the different perspectives on the issues that I'm aware of. The document is on LWN here: http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ oh, I had missed that article.. fwiw It was published just moments before I sent out this thread, so I wouldn't have expected anyone to have seen it yet. :) ahh, ok, that would explain it ;-) Another possible solution is to allow dma-buf exporters to not allocate the backing buffers immediately. This would allow multiple drivers to attach to a dma-buf before the allocation occurs. Then, when the buffer is first used, the allocation is done; at that time, the allocator could scan the list of attached drivers and be able to determine the constraints of the attached devices and allocate memory accordingly. This would allow user space to not have to deal with any constraint solving. That is actually how dma-buf works today. And at least with GEM buffers exported as dma-buf's, the allocation is deferred. It does require attaching the buffers in all the devices that will be sharing the buffer up front (but I suppose you need to know the involved devices one way or another with any solution, so this approach seems as good as any). We *do* still need to spiff up dev-dma_parms a bit more, and there might be some room for some helpers to figure out the union of all attached devices constraints, and allocate suitable backing pages... so perhaps this is one thing we should be talking about. Ok. I had gone looking for an example of the deferred allocation, but didn't find it. I'll go look again, but if you have a pointer, that could be useful. for a pure GEM (ie. not TTM) driver, drm_gem_get_pages() is where actual pages get allocated. This is triggered by various things (faulting in page for userspace access, dmabuf map_attachment, etc) BR, -R So yea, I do think this is the most promising approach, but sorting out the next steps for doing a proof of concept is one thing I'd like to discuss (as mentioned in the article, via a ion-like generic allocator, or trying to wire in the constraint solving to some limited set of drivers via generic helper functions). As well as getting a better understanding the Android developers concern about any non-deterministic cost of allocating at mmap time. Thanks for the feedback and thoughts! I'm hopeful some approach to resolving the various issues can be found, but I suspect it will have a few different parts. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi guys, With current git (v3.11-5058-g57d7309) I get the following oops: [5.434312] [ cut here ] [5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390() [5.434321] Info: mapping multiple BARs. Your kernel is fine. [5.434323] Modules linked in: [5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd applesmc input_polldev hwmon microcode bcma snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod xhci_hcd ehci_hcd usbcore usb_common [5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted 3.11.0-TEG-05060-g0312d0c #81 [5.434386] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 07/27/2012 [5.434390] 0009 880168f87898 8145be63 880168f878e0 [5.434394] 880168f878d0 8104b17d c9000c08 a000 [5.434398] c9000c08 c9000c08 1000 880168f87930 [5.434403] Call Trace: [5.434409] [8145be63] dump_stack+0x54/0x8d [5.434413] [8104b17d] warn_slowpath_common+0x7d/0xa0 [5.434417] [8104b1ec] warn_slowpath_fmt+0x4c/0x50 [5.434421] [81051fdc] ? iomem_map_sanity_check+0xac/0xe0 [5.434425] [8103e8b3] __ioremap_caller+0x2e3/0x390 [5.434430] [8103e9f2] ioremap_wc+0x32/0x40 [5.434450] [a043f960] i915_driver_load+0x670/0xf50 [i915] [5.434467] [8131540d] ? drm_get_minor+0x1ad/0x200 [5.434471] [81317509] drm_get_pci_dev+0x129/0x2f0 [5.434487] [a043c63c] i915_pci_probe+0x2c/0x70 [i915] [5.434493] [8127f624] pci_device_probe+0x84/0xe0 [5.434502] [81331977] driver_probe_device+0x87/0x3a0 [5.434509] [81331d63] __driver_attach+0x93/0xa0 [5.434516] [81331cd0] ? __device_attach+0x40/0x40 [5.434521] [8132f813] bus_for_each_dev+0x63/0xa0 [5.434525] [813313ce] driver_attach+0x1e/0x20 [5.434529] [81330f40] bus_add_driver+0x200/0x2d0 [5.434533] [a04dc000] ? 0xa04dbfff [5.434538] [813323e4] driver_register+0x64/0xf0 [5.434541] [a04dc000] ? 0xa04dbfff [5.434545] [8127f45d] __pci_register_driver+0x4d/0x50 [5.434549] [813177e5] drm_pci_init+0x115/0x130 [5.434552] [a04dc000] ? 0xa04dbfff [5.434567] [a04dc066] i915_init+0x66/0x68 [i915] [5.434570] [8100022a] do_one_initcall+0x5a/0x1b0 [5.434575] [81071588] ? __blocking_notifier_call_chain+0x58/0x70 [5.434581] [810af52a] load_module+0x1b0a/0x25a0 [5.434584] [810abf70] ? store_uevent+0x40/0x40 [5.434589] [810b0136] SyS_finit_module+0x86/0xb0 [5.434594] [81463da7] tracesys+0xdd/0xe2 [5.434599] ---[ end trace 4f93e77fcaaac9b7 ]--- This only happens when either simplefb or efifb is enabled. I can not reproduce the problem on v3.11 with efifb enabled so it appears to be new. Let me know if there is any more info I could provide. Cheers, Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Discussion starters for ION session at Linux Plumbers Android+Graphics microconf
On Fri, Sep 6, 2013 at 5:16 AM, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Sep 05, 2013 at 10:06:52PM -0700, John Stultz wrote: On 09/05/2013 08:26 PM, Rob Clark wrote: On Thu, Sep 5, 2013 at 8:49 PM, John Stultz john.stu...@linaro.org wrote: Hey everyone, In preparation for the Plumbers Android+Graphics microconf, I wanted to send out some background documentation to try to get all the context we can out there prior to the discussion, as time will be limited and it would be best to spend it discussing solutions rather then re-hashing problems and requirements. I'm sure many folks on this list could probably do a better job summarizing the issues, but I wanted to get this out there to try to enumerate the problems and the different perspectives on the issues that I'm aware of. The document is on LWN here: http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ oh, I had missed that article.. fwiw It was published just moments before I sent out this thread, so I wouldn't have expected anyone to have seen it yet. :) Another possible solution is to allow dma-buf exporters to not allocate the backing buffers immediately. This would allow multiple drivers to attach to a dma-buf before the allocation occurs. Then, when the buffer is first used, the allocation is done; at that time, the allocator could scan the list of attached drivers and be able to determine the constraints of the attached devices and allocate memory accordingly. This would allow user space to not have to deal with any constraint solving. That is actually how dma-buf works today. And at least with GEM buffers exported as dma-buf's, the allocation is deferred. It does require attaching the buffers in all the devices that will be sharing the buffer up front (but I suppose you need to know the involved devices one way or another with any solution, so this approach seems as good as any). We *do* still need to spiff up dev-dma_parms a bit more, and there might be some room for some helpers to figure out the union of all attached devices constraints, and allocate suitable backing pages... so perhaps this is one thing we should be talking about. Ok. I had gone looking for an example of the deferred allocation, but didn't find it. I'll go look again, but if you have a pointer, that could be useful. So yea, I do think this is the most promising approach, but sorting out the next steps for doing a proof of concept is one thing I'd like to discuss (as mentioned in the article, via a ion-like generic allocator, or trying to wire in the constraint solving to some limited set of drivers via generic helper functions). As well as getting a better understanding the Android developers concern about any non-deterministic cost of allocating at mmap time. Thanks for the feedback and thoughts! I'm hopeful some approach to resolving the various issues can be found, but I suspect it will have a few different parts. My main gripe with ION is that it creates a parallel infrastructure for figuring out allocation constraints of devices. Upstream already has all the knowledge (or at least most of it) for cache flushing, mapping into iommus and allocating from special pools stored in association with the device structure. So imo an upstream ION thing should reuse the information each device and its driver already has available. yeah, we want to make sure that dma-mapping is up to snuff for handling allocations of backing pages meeting the constraints of a set of devices (spiffing up dma_parms, etc, as I mentioned in my first reply). I see a potential upstream ION as just be a sort of convenience wrapper for android userspace rather than an actual allocator of backing pages, etc. Well, maybe some of this is easier to do in userspace/gralloc, but for example to ease jank fears, it could pre-attach to all the involved devices for the use-case, and then do a dummy map_attachment to the ION device to force backing page allocation. BR, -R Now I also see that a central allocator has upsides since reinventing this wheel for every device driver is not a great idea. One idea to get there and keep the benefits of ION with up-front allocations would be. 1) Allcoate the dma-buf handle at the central allocator. No backing storage gets allocated. 2) Import that dma-buf everywhere you want it to be used. That way userspace doesn't need to deal with whatever hw madness is actually used to implement the drm/v4l/whatever devices nodes internally. 3) Ask the central allocator to finalize the buffer allocation placement and grab backing storage. If any further attaching happens that doesn't work out it would simply fail, and userspace gets to keep the pieces. Which is already the case in today's upstream when userspace is unlucky and doesn't pick the most constrained device. This only tackles the make memory allocation predictable issue ION solves, which
Re: [PATCH] DRM: TTM: Fix memory leak issue in ttm_agp_tt_create().
On Wed, Sep 04, 2013 at 11:58:10AM +0530, Manjunath Goudar wrote:
From: Jeyaraman R jeyaraman.rangas...@lge.com
This patch adds kfree() in ttm_agp_tt_create() to avoide the
memory leak, without this there is a chance of memory leak in
ttm_tt_init() fail case.
Signed-off-by: Jeyaraman R jeyaraman.rangas...@lge.com
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: David Airlie airl...@linux.ie
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: David Howells dhowe...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Dave Jones da...@redhat.com
Cc: Dave Airlie airl...@redhat.com
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 3302f99..764be36 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -126,6 +126,7 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device
*bdev,
agp_be-ttm.func = ttm_agp_func;
if (ttm_tt_init(agp_be-ttm, bdev, size, page_flags, dummy_read_page))
{
+ kfree(agp_be);
return NULL;
}
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On Thu, Sep 5, 2013 at 11:37 PM, Rahul Sharma r.sh.o...@gmail.com wrote:
On 5 September 2013 19:20, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt
(https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy
setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by
resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided
by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch
set
should
be rebased on top of Rahul's patch set. Shirish
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 gronius d.tut...@googlemail.com changed: What|Removed |Added Priority|medium |high CC||d.tut...@googlemail.com -- 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 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Attachment #84475|0 |1 is obsolete|| Attachment #84551|0 |1 is obsolete|| Attachment #84880|0 |1 is obsolete|| --- Comment #12 from Tom Stellard tstel...@gmail.com --- Created attachment 85372 -- https://bugs.freedesktop.org/attachment.cgi?id=85372action=edit SGPR register spilling patch v2 Can you try this v2 patch? It fixes the bug Michel found plus another one. -- 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
[libdrm] Stereo 3D
libdrm's support for: http://lists.freedesktop.org/archives/dri-devel/2013-September/044885.html -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm: Make sure every ioctl structure has a typedef
Just for consistency. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- include/uapi/drm/drm.h | 29 + 1 file changed, 29 insertions(+) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index b8604d2..0430fab 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -799,6 +799,11 @@ typedef struct drm_client drm_client_t; typedef enum drm_stat_type drm_stat_type_t; typedef struct drm_stats drm_stats_t; typedef struct drm_set_version drm_set_version_t; +typedef struct drm_modeset_ctl drm_modeset_ctl_t; +typedef struct drm_gem_close drm_gem_close_t; +typedef struct drm_gem_flink drm_gem_flink_t; +typedef struct drm_gem_open drm_gem_open_t; +typedef struct drm_get_cap drm_get_cap_t; typedef struct drm_block drm_block_t; typedef struct drm_control drm_control_t; typedef struct drm_buf_desc drm_buf_desc_t; @@ -815,6 +820,7 @@ typedef struct drm_ctx_res drm_ctx_res_t; typedef struct drm_draw drm_draw_t; typedef enum drm_lock_flags drm_lock_flags_t; typedef struct drm_lock drm_lock_t; +typedef struct drm_prime_handle drm_prime_handle_t; typedef struct drm_agp_mode drm_agp_mode_t; typedef struct drm_agp_info drm_agp_info_t; typedef struct drm_agp_buffer drm_agp_buffer_t; @@ -823,6 +829,29 @@ typedef struct drm_scatter_gather drm_scatter_gather_t; typedef enum drm_vblank_seq_type drm_vblank_seq_type_t; typedef union drm_wait_vblank drm_wait_vblank_t; typedef struct drm_update_draw drm_update_draw_t; +typedef struct drm_mode_card_res drm_mode_card_res_t; +typedef struct drm_mode_crtc drm_mode_crtc_t; +typedef struct drm_mode_cursor drm_mode_cursor_t; +typedef struct drm_mode_crtc_lut drm_mode_crtc_lut_t; +typedef struct drm_mode_get_encoder drm_mode_get_encoder_t; +typedef struct drm_mode_get_connector drm_mode_get_connector_t; +typedef struct drm_mode_mode_cmd drm_mode_mode_cmd_t; +typedef struct drm_mode_get_property drm_mode_get_property_t; +typedef struct drm_mode_connector_set_property drm_mode_connector_set_property_t; +typedef struct drm_mode_get_blob drm_mode_get_blob_t; +typedef struct drm_mode_fb_cmd drm_mode_fb_cmd_t; +typedef struct drm_mode_crtc_page_flip drm_mode_crtc_page_flip_t; +typedef struct drm_mode_fb_dirty_cmd drm_mode_fb_dirty_cmd_t; +typedef struct drm_mode_create_dumb drm_mode_create_dumb_t; +typedef struct drm_mode_map_dumb drm_mode_map_dumb_t; +typedef struct drm_mode_destroy_dumb drm_mode_destroy_dumb_t; +typedef struct drm_mode_get_plane_res drm_mode_get_plane_res_t; +typedef struct drm_mode_get_plane drm_mode_get_plane_t; +typedef struct drm_mode_set_plane drm_mode_set_plane_t; +typedef struct drm_mode_fb_cmd2 drm_mode_fb_cmd2_t; +typedef struct drm_mode_obj_get_properties drm_mode_obj_get_properties_t; +typedef struct drm_mode_obj_set_property drm_mode_obj_set_property_t; +typedef struct drm_mode_cursor2 drm_mode_cursor2_t; typedef struct drm_clip_rect drm_clip_rect_t; typedef struct drm_drawable_info drm_drawable_info_t; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm: Move the GET_CAP macros next to the corresponding ioctl structure
It's a tiny bit more logical to find the different capabilities you can
use with the GET_CAP ioctl next to the structure rather than putting
them at the end of the file.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/uapi/drm/drm.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 272580c..4b683f9 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -611,6 +611,16 @@ struct drm_gem_open {
__u64 size;
};
+#define DRM_CAP_DUMB_BUFFER 0x1
+#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+#define DRM_CAP_PRIME 0x5
+#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
+
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
+
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
__u64 capability;
@@ -774,16 +784,6 @@ struct drm_event_vblank {
__u32 reserved;
};
-#define DRM_CAP_DUMB_BUFFER 0x1
-#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
-#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
-#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
-#define DRM_CAP_PRIME 0x5
-#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
-
-#define DRM_PRIME_CAP_IMPORT 0x1
-#define DRM_PRIME_CAP_EXPORT 0x2
-
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm: Sort userspace typedefs by ioctl number
This way, it's easier to catch ioctl structures that are not yet
typedef'ed and provide a more consistent API.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/uapi/drm/drm.h | 45 -
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 4b683f9..b8604d2 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -786,47 +786,50 @@ struct drm_event_vblank {
/* typedef area */
#ifndef __KERNEL__
-typedef struct drm_clip_rect drm_clip_rect_t;
-typedef struct drm_drawable_info drm_drawable_info_t;
-typedef struct drm_tex_region drm_tex_region_t;
-typedef struct drm_hw_lock drm_hw_lock_t;
+
+/* Please keep this list sorted by ioctl number */
typedef struct drm_version drm_version_t;
typedef struct drm_unique drm_unique_t;
-typedef struct drm_list drm_list_t;
-typedef struct drm_block drm_block_t;
-typedef struct drm_control drm_control_t;
+typedef struct drm_auth drm_auth_t;
+typedef struct drm_irq_busid drm_irq_busid_t;
typedef enum drm_map_type drm_map_type_t;
typedef enum drm_map_flags drm_map_flags_t;
-typedef struct drm_ctx_priv_map drm_ctx_priv_map_t;
typedef struct drm_map drm_map_t;
typedef struct drm_client drm_client_t;
typedef enum drm_stat_type drm_stat_type_t;
typedef struct drm_stats drm_stats_t;
-typedef enum drm_lock_flags drm_lock_flags_t;
-typedef struct drm_lock drm_lock_t;
-typedef enum drm_dma_flags drm_dma_flags_t;
+typedef struct drm_set_version drm_set_version_t;
+typedef struct drm_block drm_block_t;
+typedef struct drm_control drm_control_t;
typedef struct drm_buf_desc drm_buf_desc_t;
typedef struct drm_buf_info drm_buf_info_t;
-typedef struct drm_buf_free drm_buf_free_t;
typedef struct drm_buf_pub drm_buf_pub_t;
typedef struct drm_buf_map drm_buf_map_t;
+typedef struct drm_buf_free drm_buf_free_t;
+typedef enum drm_dma_flags drm_dma_flags_t;
typedef struct drm_dma drm_dma_t;
-typedef union drm_wait_vblank drm_wait_vblank_t;
-typedef struct drm_agp_mode drm_agp_mode_t;
+typedef struct drm_ctx_priv_map drm_ctx_priv_map_t;
typedef enum drm_ctx_flags drm_ctx_flags_t;
typedef struct drm_ctx drm_ctx_t;
typedef struct drm_ctx_res drm_ctx_res_t;
typedef struct drm_draw drm_draw_t;
-typedef struct drm_update_draw drm_update_draw_t;
-typedef struct drm_auth drm_auth_t;
-typedef struct drm_irq_busid drm_irq_busid_t;
-typedef enum drm_vblank_seq_type drm_vblank_seq_type_t;
-
+typedef enum drm_lock_flags drm_lock_flags_t;
+typedef struct drm_lock drm_lock_t;
+typedef struct drm_agp_mode drm_agp_mode_t;
+typedef struct drm_agp_info drm_agp_info_t;
typedef struct drm_agp_buffer drm_agp_buffer_t;
typedef struct drm_agp_binding drm_agp_binding_t;
-typedef struct drm_agp_info drm_agp_info_t;
typedef struct drm_scatter_gather drm_scatter_gather_t;
-typedef struct drm_set_version drm_set_version_t;
+typedef enum drm_vblank_seq_type drm_vblank_seq_type_t;
+typedef union drm_wait_vblank drm_wait_vblank_t;
+typedef struct drm_update_draw drm_update_draw_t;
+
+typedef struct drm_clip_rect drm_clip_rect_t;
+typedef struct drm_drawable_info drm_drawable_info_t;
+typedef struct drm_tex_region drm_tex_region_t;
+typedef struct drm_hw_lock drm_hw_lock_t;
+typedef struct drm_list drm_list_t;
+
#endif
#endif
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/edid: Expose mandatory stereo modes for HDMI sinks
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 75 +-
1 file changed, 68 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a207cc3..9d9881b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2550,13 +2550,60 @@ do_cea_modes(struct drm_connector *connector, const u8
*db, u8 len)
return modes;
}
+struct s3d_mandatory_mode {
+ int width, height, freq;
+ unsigned int interlace_flag, formats;
+};
+
+static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
+ { 1920, 1080, 24, 0,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE,
+ DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+ { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE,
+ DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+ { 1280, 720, 50, 0,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1280, 720, 60, 0,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+};
+
+static bool match_s3d_mandatory_mode(const struct drm_display_mode *mode,
+const struct s3d_mandatory_mode *s3d_mode)
+{
+ unsigned int interlaced = mode-flags DRM_MODE_FLAG_INTERLACE;
+
+ return mode-hdisplay == s3d_mode-width
+ mode-vdisplay == s3d_mode-height
+ interlaced == s3d_mode-interlace_flag
+ drm_mode_vrefresh(mode) == s3d_mode-freq;
+}
+
+static void hdmi_patch_stereo_mode(struct drm_display_mode *mode)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(s3d_mandatory_modes); i++)
+ if (match_s3d_mandatory_mode(mode, s3d_mandatory_modes[i]))
+ mode-flags |= s3d_mandatory_modes[i].formats;
+}
+
+static void hdmi_patch_stereo_modes(struct drm_connector *connector)
+{
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, connector-probed_modes, head)
+ hdmi_patch_stereo_mode(mode);
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
* @db: start of the CEA vendor specific block
* @len: length of the CEA block payload, ie. one can access up to db[len]
*
- * Parses the HDMI VSDB looking for modes to add to @connector.
+ * Parses the HDMI VSDB looking for modes to add to @connector. This function
+ * also adds the stereo 3d flags to already added modes.
*/
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
@@ -2582,10 +2629,15 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
/* the declared length is not long enough for the 2 first bytes
* of additional video format capabilities */
- offset += 2;
- if (len (8 + offset))
+ if (len (8 + offset + 2))
goto out;
+ /* 3D_Present */
+ offset++;
+ if (db[8 + offset] (1 7))
+ hdmi_patch_stereo_modes(connector);
+
+ offset++;
vic_len = db[8 + offset] 5;
for (i = 0; i vic_len len = (9 + offset + i); i++) {
@@ -2665,8 +2717,8 @@ static int
add_cea_modes(struct drm_connector *connector, struct edid *edid)
{
const u8 *cea = drm_find_cea_extension(edid);
- const u8 *db;
- u8 dbl;
+ const u8 *db, *hdmi = NULL;
+ u8 dbl, hdmi_len;
int modes = 0;
if (cea cea_revision(cea) = 3) {
@@ -2681,11 +2733,20 @@ add_cea_modes(struct drm_connector *connector, struct
edid *edid)
if (cea_db_tag(db) == VIDEO_BLOCK)
modes += do_cea_modes(connector, db + 1, dbl);
- else if (cea_db_is_hdmi_vsdb(db))
- modes += do_hdmi_vsdb_modes(connector, db, dbl);
+ else if (cea_db_is_hdmi_vsdb(db)) {
+ hdmi = db;
+ hdmi_len = dbl;
+ }
}
}
+ /*
+* We parse the HDMI VSDB after having added the cea modes as we will
+* be patching their flags when the sink supports stereo 3D.
+*/
+ if (hdmi)
+ modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len);
+
return modes;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm: Add a SET_CAP ioctl
This ioctl can be used to turn some knobs in a DRM driver. This is the
counterpart of GET_CAP and serves a similar role than the various
SETPARAM ioctls that are driver specific, but for DRM core.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_drv.c | 1 +
drivers/gpu/drm/drm_ioctl.c | 8
include/drm/drmP.h | 2 ++
include/uapi/drm/drm.h | 8
4 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 288da3d..7fce2fb 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -69,6 +69,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_CAP, drm_setcap, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index cffc7c0..e471cd9 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -300,6 +300,14 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
}
/**
+ * Set device/driver capabilities
+ */
+int drm_setcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
+{
+ return -EINVAL;
+}
+
+/**
* Setversion ioctl.
*
* \param inode device inode.
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 39911dc..b9c321b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1273,6 +1273,8 @@ extern int drm_getstats(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
extern int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_setcap(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
extern int drm_setversion(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int drm_noop(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 0430fab..d400e6f 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -627,6 +627,12 @@ struct drm_get_cap {
__u64 value;
};
+/** DRM_IOCTL_SET_CAP ioctl argument type */
+struct drm_set_cap {
+ __u64 capability;
+ __u64 value;
+};
+
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
@@ -659,6 +665,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_GEM_FLINKDRM_IOWR(0x0a, struct drm_gem_flink)
#define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
#define DRM_IOCTL_GET_CAP DRM_IOWR(0x0c, struct drm_get_cap)
+#define DRM_IOCTL_SET_CAP DRM_IOW( 0x0d, struct drm_set_cap)
#define DRM_IOCTL_SET_UNIQUE DRM_IOW( 0x10, struct drm_unique)
#define DRM_IOCTL_AUTH_MAGIC DRM_IOW( 0x11, struct drm_auth)
@@ -804,6 +811,7 @@ typedef struct drm_gem_close drm_gem_close_t;
typedef struct drm_gem_flink drm_gem_flink_t;
typedef struct drm_gem_open drm_gem_open_t;
typedef struct drm_get_cap drm_get_cap_t;
+typedef struct drm_set_cap drm_set_cap_t;
typedef struct drm_block drm_block_t;
typedef struct drm_control drm_control_t;
typedef struct drm_buf_desc drm_buf_desc_t;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm: Add HDMI stereo 3D flags to struct drm_mode_modeinfo
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/drm_crtc.h | 9 +
include/uapi/drm/drm_mode.h | 36 ++--
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f660ac5..4e3ce16 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -125,6 +125,15 @@ enum drm_mode_status {
#define CRTC_INTERLACE_HALVE_V 0x1 /* halve V values for interlacing */
+#define DRM_MODE_FLAG_3D_MASK (DRM_MODE_FLAG_3D_FRAME_PACKING | \
+DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE | \
+DRM_MODE_FLAG_3D_LINE_ALTERNATIVE | \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL | \
+DRM_MODE_FLAG_3D_L_DEPTH | \
+DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH | \
+DRM_MODE_FLAG_3D_TOP_AND_BOTTOM| \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
+
struct drm_display_mode {
/* Header */
struct list_head head;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..045046f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -44,20 +44,28 @@
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC (10)
-#define DRM_MODE_FLAG_NHSYNC (11)
-#define DRM_MODE_FLAG_PVSYNC (12)
-#define DRM_MODE_FLAG_NVSYNC (13)
-#define DRM_MODE_FLAG_INTERLACE(14)
-#define DRM_MODE_FLAG_DBLSCAN (15)
-#define DRM_MODE_FLAG_CSYNC(16)
-#define DRM_MODE_FLAG_PCSYNC (17)
-#define DRM_MODE_FLAG_NCSYNC (18)
-#define DRM_MODE_FLAG_HSKEW(19) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(110)
-#define DRM_MODE_FLAG_PIXMUX (111)
-#define DRM_MODE_FLAG_DBLCLK (112)
-#define DRM_MODE_FLAG_CLKDIV2 (113)
+#define DRM_MODE_FLAG_PHSYNC (10)
+#define DRM_MODE_FLAG_NHSYNC (11)
+#define DRM_MODE_FLAG_PVSYNC (12)
+#define DRM_MODE_FLAG_NVSYNC (13)
+#define DRM_MODE_FLAG_INTERLACE(14)
+#define DRM_MODE_FLAG_DBLSCAN (15)
+#define DRM_MODE_FLAG_CSYNC(16)
+#define DRM_MODE_FLAG_PCSYNC (17)
+#define DRM_MODE_FLAG_NCSYNC (18)
+#define DRM_MODE_FLAG_HSKEW(19) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(110)
+#define DRM_MODE_FLAG_PIXMUX (111)
+#define DRM_MODE_FLAG_DBLCLK (112)
+#define DRM_MODE_FLAG_CLKDIV2 (113)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (114)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (115)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (116)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (117)
+#define DRM_MODE_FLAG_3D_L_DEPTH (118)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (119)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(120)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (121)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Stereo 3D v3
Follow up of: http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html Let's try again! This time, intead of a magic connector property to select if we want to return more modeinfo flags to userspace, this series introduces a new SET_CAP ioctl. So the flow goes as following: 1/ the DRM client (limited to the DRM master) can notify it knows about those flags through SET_CAP 2/ we parse the HDMI CEA vendor blog for 3D_Present and patch the mandatory modes with the layouts they support (in -flags) 3/ we can then handle a modeset with one (and only one) of those stereo 3D layout set on the mode. This includes writing a vendor infoframe with the information about the layout we're sending libdrm patches will follow with a new drmSetCap() function and the stereo 3D flags. Testing has been done with intel-gpu-tools' testdisplay that can now compose a left and right image for the top and bottom, side by side half and frame packing stereo 3d layouts (patches posted on intel-gfx). ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo 3D flags from the user mode
modeinfo structure by default, and let them through if we are being told
otherwise.
stereo_allowed is bound to the drm_file structure to make it a
per-client setting, not a global one.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 16 +---
drivers/gpu/drm/drm_ioctl.c | 14 +-
include/drm/drmP.h | 3 +++
include/uapi/drm/drm.h | 9 +
4 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..ff9646f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1257,12 +1257,14 @@ EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
* drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
* @out: drm_mode_modeinfo struct to return to the user
* @in: drm_display_mode to use
+ * @file_priv: drm file from the ioctl call
*
* Convert a drm_display_mode into a drm_mode_modeinfo structure to return to
* the user.
*/
static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out,
- const struct drm_display_mode *in)
+ const struct drm_display_mode *in,
+ const struct drm_file *file_priv)
{
WARN(in-hdisplay USHRT_MAX || in-hsync_start USHRT_MAX ||
in-hsync_end USHRT_MAX || in-htotal USHRT_MAX ||
@@ -1287,6 +1289,13 @@ static void drm_crtc_convert_to_umode(struct
drm_mode_modeinfo *out,
out-type = in-type;
strncpy(out-name, in-name, DRM_DISPLAY_MODE_LEN);
out-name[DRM_DISPLAY_MODE_LEN-1] = 0;
+
+ /*
+* If user-space hasn't configured the driver to expose the stereo 3D
+* flags, clear them.
+*/
+ if (!file_priv-stereo_allowed)
+ out-flags = ~DRM_MODE_FLAG_3D_MASK;
}
/**
@@ -1556,7 +1565,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
if (crtc-enabled) {
- drm_crtc_convert_to_umode(crtc_resp-mode, crtc-mode);
+ drm_crtc_convert_to_umode(crtc_resp-mode, crtc-mode,
+ file_priv);
crtc_resp-mode_valid = 1;
} else {
@@ -1655,7 +1665,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned
long)out_resp-modes_ptr;
list_for_each_entry(mode, connector-modes, head) {
- drm_crtc_convert_to_umode(u_mode, mode);
+ drm_crtc_convert_to_umode(u_mode, mode, file_priv);
if (copy_to_user(mode_ptr + copied,
u_mode, sizeof(u_mode))) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index e471cd9..a716641 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -304,7 +304,19 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
*/
int drm_setcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
{
- return -EINVAL;
+ struct drm_set_cap *req = data;
+
+ switch (req-capability) {
+ case DRM_CAP_STEREO_3D:
+ if (req-value 1)
+ return -EINVAL;
+ file_priv-stereo_allowed = req-value;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
}
/**
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b9c321b..0df654c 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -431,6 +431,9 @@ struct drm_file {
struct drm_master *master; /* master this node is currently associated
with
N.B. not always minor-master */
+ /* true when the client has asked us to expose stereo 3D mode flags */
+ bool stereo_allowed;
+
/**
* fbs - List of framebuffers associated with this file.
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index d400e6f..23922b4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -627,6 +627,15 @@ struct drm_get_cap {
__u64 value;
};
+/**
+ * DRM_CAP_STEREO_3D
+ *
+ * if set to 1, the DRM core will expose the stereo 3D capabilities of the
+ * monitor by advertising the supported 3D layouts in the flags of struct
+ * drm_mode_modeinfo.
+ */
+#define DRM_CAP_STEREO_3D 1
+
/** DRM_IOCTL_SET_CAP ioctl argument type */
struct drm_set_cap {
__u64
[PATCH 9/9] drm: Set the relevant infoframe field when scanning out a 3D mode
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/drm_edid.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9d9881b..8a1ae56 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3325,6 +3325,18 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+static enum hdmi_3d_structure
+s3d_structure_from_display_mode(const struct drm_display_mode *mode)
+{
+ u32 s3d_mode = (mode-flags DRM_MODE_FLAG_3D_MASK) 14;
+ int set = ffs(s3d_mode) - 1;
+
+ if (set == 7)
+ return HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF;
+
+ return set;
+}
+
/**
* drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI infoframe with
* data from a DRM display mode
@@ -3342,20 +3354,29 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
const struct drm_display_mode *mode)
{
int err;
+ u32 s3d_flags;
u8 vic;
if (!frame || !mode)
return -EINVAL;
vic = drm_match_hdmi_mode(mode);
- if (!vic)
+ s3d_flags = mode-flags DRM_MODE_FLAG_3D_MASK;
+
+ if (!vic !s3d_flags)
+ return -EINVAL;
+
+ if (vic s3d_flags)
return -EINVAL;
err = hdmi_vendor_infoframe_init(frame);
if (err 0)
return err;
- frame-vic = vic;
+ if (vic)
+ frame-vic = vic;
+ else
+ frame-s3d_struct = s3d_structure_from_display_mode(mode);
return 0;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm: Reject modes with more than 1 stereo flags set
When setting a stereo 3D mode, there can be only one bit set describing the layout of the frambuffer(s). So reject invalid modes early. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/drm_crtc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index ff9646f..f53d199 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1315,6 +1315,10 @@ static int drm_crtc_convert_umode(struct drm_display_mode *out, if (in-clock INT_MAX || in-vrefresh INT_MAX) return -ERANGE; + /* At most, 1 set bit describing the 3D layout of the mode */ + if (hweight32(in-flags DRM_MODE_FLAG_3D_MASK) 1) + return -EINVAL; + out-clock = in-clock; out-hdisplay = in-hdisplay; out-hsync_start = in-hsync_start; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: pad CS to 8 DW
Aligns the IB to 8 DWs. The aligns the IB to the CP fetch size. r6xx also require at least 4 DW alignment to avoid a hw bug. Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- radeon/radeon_cs_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c index b963140..b87c6b1 100644 --- a/radeon/radeon_cs_gem.c +++ b/radeon/radeon_cs_gem.c @@ -425,6 +425,9 @@ static int cs_gem_emit(struct radeon_cs_int *cs) unsigned i; int r; +while (cs-cdw 7) + radeon_cs_write_dword((struct radeon_cs *)cs, 0x8000); + #if CS_BOF_DUMP cs_gem_dump_bof(cs); #endif -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/3] drm: Synchronize the stereo 3D mode flags from the kernel headers
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/drm_mode.h | 36 ++--
xf86drmMode.h | 36 ++--
2 files changed, 44 insertions(+), 28 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d41d76b..ec2daa9 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -42,20 +42,28 @@
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC (10)
-#define DRM_MODE_FLAG_NHSYNC (11)
-#define DRM_MODE_FLAG_PVSYNC (12)
-#define DRM_MODE_FLAG_NVSYNC (13)
-#define DRM_MODE_FLAG_INTERLACE(14)
-#define DRM_MODE_FLAG_DBLSCAN (15)
-#define DRM_MODE_FLAG_CSYNC(16)
-#define DRM_MODE_FLAG_PCSYNC (17)
-#define DRM_MODE_FLAG_NCSYNC (18)
-#define DRM_MODE_FLAG_HSKEW(19) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(110)
-#define DRM_MODE_FLAG_PIXMUX (111)
-#define DRM_MODE_FLAG_DBLCLK (112)
-#define DRM_MODE_FLAG_CLKDIV2 (113)
+#define DRM_MODE_FLAG_PHSYNC (10)
+#define DRM_MODE_FLAG_NHSYNC (11)
+#define DRM_MODE_FLAG_PVSYNC (12)
+#define DRM_MODE_FLAG_NVSYNC (13)
+#define DRM_MODE_FLAG_INTERLACE(14)
+#define DRM_MODE_FLAG_DBLSCAN (15)
+#define DRM_MODE_FLAG_CSYNC(16)
+#define DRM_MODE_FLAG_PCSYNC (17)
+#define DRM_MODE_FLAG_NCSYNC (18)
+#define DRM_MODE_FLAG_HSKEW(19) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(110)
+#define DRM_MODE_FLAG_PIXMUX (111)
+#define DRM_MODE_FLAG_DBLCLK (112)
+#define DRM_MODE_FLAG_CLKDIV2 (113)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (114)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (115)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (116)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (117)
+#define DRM_MODE_FLAG_3D_L_DEPTH (118)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (119)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(120)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (121)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
diff --git a/xf86drmMode.h b/xf86drmMode.h
index f8a817c..0a65ab1 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -81,20 +81,28 @@ extern C {
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC(10)
-#define DRM_MODE_FLAG_NHSYNC(11)
-#define DRM_MODE_FLAG_PVSYNC(12)
-#define DRM_MODE_FLAG_NVSYNC(13)
-#define DRM_MODE_FLAG_INTERLACE (14)
-#define DRM_MODE_FLAG_DBLSCAN (15)
-#define DRM_MODE_FLAG_CSYNC (16)
-#define DRM_MODE_FLAG_PCSYNC(17)
-#define DRM_MODE_FLAG_NCSYNC(18)
-#define DRM_MODE_FLAG_HSKEW (19) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST (110)
-#define DRM_MODE_FLAG_PIXMUX(111)
-#define DRM_MODE_FLAG_DBLCLK(112)
-#define DRM_MODE_FLAG_CLKDIV2 (113)
+#define DRM_MODE_FLAG_PHSYNC (10)
+#define DRM_MODE_FLAG_NHSYNC (11)
+#define DRM_MODE_FLAG_PVSYNC (12)
+#define DRM_MODE_FLAG_NVSYNC (13)
+#define DRM_MODE_FLAG_INTERLACE(14)
+#define DRM_MODE_FLAG_DBLSCAN (15)
+#define DRM_MODE_FLAG_CSYNC(16)
+#define DRM_MODE_FLAG_PCSYNC (17)
+#define DRM_MODE_FLAG_NCSYNC (18)
+#define DRM_MODE_FLAG_HSKEW(19) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(110)
+#define DRM_MODE_FLAG_PIXMUX (111)
+#define DRM_MODE_FLAG_DBLCLK (112)
+#define DRM_MODE_FLAG_CLKDIV2 (113)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (114)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (115)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (116)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (117)
+#define DRM_MODE_FLAG_3D_L_DEPTH (118)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (119)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(120)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (121)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/3] drm: Sync the DRM_SET_CAP ioctl definition
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 71a2ac1..165231b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -618,6 +618,21 @@ struct drm_get_cap {
__u64 value;
};
+/**
+ * DRM_CAP_STEREO_3D
+ *
+ * if set to 1, the DRM core will expose the stereo 3D capabilities of the
+ * monitor by advertising the supported 3D layouts in the flags of struct
+ * drm_mode_modeinfo.
+ */
+#define DRM_CAP_STEREO_3D 1
+
+/** DRM_IOCTL_SET_CAP ioctl argument type */
+struct drm_set_cap {
+ __u64 capability;
+ __u64 value;
+};
+
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
@@ -650,6 +665,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_GEM_FLINKDRM_IOWR(0x0a, struct drm_gem_flink)
#define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
#define DRM_IOCTL_GET_CAP DRM_IOWR(0x0c, struct drm_get_cap)
+#define DRM_IOCTL_SET_CAP DRM_IOW( 0x0d, struct drm_set_cap)
#define DRM_IOCTL_SET_UNIQUE DRM_IOW( 0x10, struct drm_unique)
#define DRM_IOCTL_AUTH_MAGIC DRM_IOW( 0x11, struct drm_auth)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #13 from Laurent carlier lordhea...@gmail.com --- (In reply to comment #12) Created attachment 85372 [details] [review] SGPR register spilling patch v2 Can you try this v2 patch? It fixes the bug Michel found plus another one. Same result as patch v1, GPU lockup instead of llvm assert; Sanctuary demo gives also a GPU lockup -- 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 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #122 from Bryan Quigley gquigs+b...@gmail.com --- (In reply to comment #116) Does disabling any of the dpm features as per comment 94 help? Nope, still broken. (although I did get distracted by a hang that was fixed by the latest drm pull I thought it was fixed at one point, but it seems I may have mistyped radeon.dpm.. ) -- 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: [PULL] drm-intel-fixes
On Fri, Sep 06, 2013 at 09:49:06AM +0200, Daniel Vetter wrote: Blergh, forgotten to cc: mailing lists ... And then Ville pointed out on irc that I'm actually missing the vgacon-fbcon takeover fix. Fail friday it seems, new pull request below. -Daniel The following changes since commit f33bcab9e816c5bf56b74c3007790f2a256910eb: drm/radeon: support render nodes (2013-09-02 10:51:53 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-09-06 for you to fetch changes up to 6e1b4fdad5157bb9e88777d525704aba24389bee: drm/i915: Delay disabling of VGA memory until vgacon-fbcon handoff is done (2013-09-06 23:27:03 +0200) Alex Williamson (3): vgaarb: Don't disable resources that are not owned vgaarb: Fix VGA decodes changes i915: Update VGA arbiter support for newer devices Chris Wilson (9): drm/i915: Adjust available RPS information through sysfs for vlv drm/i915: Apply the force-detect VGA w/a to Valleyview drm/i915: Report requested frequency alongside current frequency in debugfs drm/i915: Embed the ring-private within the struct intel_ring_buffer drm/i915: Use RCS flips on Ivybridge+ drm/i915: Pin pages whilst mapping the dma-buf drm/i915: Hold an object reference whilst we shrink it drm/i915: Skip stolen region initialisation if none is reserved drm/i915: Confine page flips to BCS on Valleyview Damien Lespiau (1): drm/i915: Don't call sg_free_table() if sg_alloc_table() fails Daniel Vetter (6): drm/i915: tune down hangcheck noise drm/i915: fix up the relocate_entry refactoring drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock drm/i915: handle sdvo input pixel multiplier correctly again drm/i915: fix i9xx_crtc_clock_get for multiplied pixels drm/i915: fix gpu hang vs. flip stall deadlocks Imre Deak (1): drm/i915: fix lvds/dp panel fitter setting Jani Nikula (1): drm/i915: try not to lose backlight CBLV precision Jesse Barnes (2): drm/i915: split PCI IDs out into i915_drm.h v4 x86: add early quirk for reserving Intel graphics stolen memory v5 Joe Perches (1): i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc Mika Kuoppala (2): drm/i915: Don't mask EI UP interrupt on IVB|SNB drm/i915: sanitize forcewake registers on reset Paulo Zanoni (1): drm/i915: enable trickle feed on Haswell Ville Syrjälä (2): drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode drm/i915: Delay disabling of VGA memory until vgacon-fbcon handoff is done arch/x86/kernel/early-quirks.c | 154 + drivers/gpu/drm/i915/i915_debugfs.c| 11 +- drivers/gpu/drm/i915/i915_dma.c| 15 +- drivers/gpu/drm/i915/i915_drv.c| 164 +- drivers/gpu/drm/i915/i915_drv.h| 7 + drivers/gpu/drm/i915/i915_gem.c| 48 +-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 41 +++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 + drivers/gpu/drm/i915/i915_gem_stolen.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_irq.c| 23 +++- drivers/gpu/drm/i915/i915_reg.h| 34 +++-- drivers/gpu/drm/i915/i915_sysfs.c | 36 - drivers/gpu/drm/i915/intel_crt.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 83 ++-- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_lvds.c | 8 +- drivers/gpu/drm/i915/intel_opregion.c | 2 +- drivers/gpu/drm/i915/intel_panel.c | 14 +- drivers/gpu/drm/i915/intel_pm.c| 14 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 99 -- drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +- drivers/gpu/drm/i915/intel_sdvo.c | 17 +-- drivers/gpu/drm/i915/intel_sprite.c| 7 +- drivers/gpu/drm/i915/intel_uncore.c| 9 +- drivers/gpu/vga/vgaarb.c | 51 +++ include/drm/i915_drm.h | 34 + include/drm/i915_pciids.h | 211 + include/linux/vgaarb.h | 7 + 29 files changed, 774 insertions(+), 334 deletions(-) create mode 100644 include/drm/i915_pciids.h -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/3] drm: Introduce a drmSetCap() wrapper
That wraps around the new DRM_SET_CAP ioctl.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
xf86drm.c | 7 +++
xf86drm.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 4791a05..dac6a52 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -823,6 +823,13 @@ int drmGetCap(int fd, uint64_t capability, uint64_t *value)
return 0;
}
+int drmSetCap(int fd, uint64_t capability, uint64_t value)
+{
+ struct drm_set_cap cap = { capability, value };
+
+ return drmIoctl(fd, DRM_IOCTL_SET_CAP, cap);
+}
+
/**
* Free the bus ID information.
*
diff --git a/xf86drm.h b/xf86drm.h
index 5ecb284..053be08 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -609,6 +609,7 @@ extern int drmUpdateDrawableInfo(int fd,
drm_drawable_t handle,
unsigned int num, void *data);
extern int drmCtlInstHandler(int fd, int irq);
extern int drmCtlUninstHandler(int fd);
+extern int drmSetCap(int fd, uint64_t capability, uint64_t value);
/* General user-level programmer's API: authenticated client and/or X */
extern int drmMap(int fd,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Stereo 3D v3
On Fri, Sep 06, 2013 at 07:57:16PM +0100, Damien Lespiau wrote: Follow up of: http://lists.freedesktop.org/archives/dri-devel/2012-September/028278.html Let's try again! This time, intead of a magic connector property to select if we want to return more modeinfo flags to userspace, this series introduces a new SET_CAP ioctl. So the flow goes as following: 1/ the DRM client (limited to the DRM master) can notify it knows about those flags through SET_CAP Is this capability dropped along with a change in master then? -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
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #13 from Alexandre Demers alexandre.f.dem...@gmail.com --- Is there anything else I can do to give a better idea of what is happening and why it crashes? If this can be of any value, my 6950 is of the following model: XFX HD-695X-ZNDC (1GB DDR5, 830MHz Core Clock and 5200MHz Memory Clock) -- 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 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #123 from lucky_beta lucky_b...@126.com --- (In reply to comment #121) Hi lucky_beta, For me it was not 100% fixed. At the moment with Kernel 3.11 it is ~50% chance that system hangs during boot or the windows are slow. It better than it was initially, but the issue is not fully resolved. (Don't have white screen issue even without patches) Thank you for your reply, i will keep an eye on this topic, although i'm a linux beginner, but if i can do some help except for waiting, just with pleasure. -- 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 69062] New: Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 Priority: medium Bug ID: 69062 Assignee: dri-devel@lists.freedesktop.org Summary: Corrupted visuals in Gnome3 (A6-4400M) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lrn1...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 85385 -- https://bugs.freedesktop.org/attachment.cgi?id=85385action=edit Corrupted shell On boot gdm3 looks fine (displays a list of users). When i choose a user from the list, the animation plays out - and that's when the corruption starts (missing text and missing graphics). I can still log in by typing the password. Once logged in, gnome shell looks fine at first. Opening the Activities screen might cause minor corruption (for example, hovering over icons on the left panel might show corrupted selection rectangle fadein). Typing in the Activities screen _always_ causes major corruption in visuals. Only Gnome shell (top bar, Activities, window switcher) is affected. Applications continue to be drawn correctly. Gnome shell reset (Alt+F2, r) cleans up corruption from the shell (completely or almost completely), but it quickly returns. Tried changing radeon.gartsize on boot - no difference. No errors on Xorg.log No errors in dmesg This is a regression (things used to work ~half a year ago) Versions: *Gnome3 3.8 Debian sid/experimental *kernel: git://people.freedesktop.org/~airlied/linux 86a7e1224a68511d3a1ae0b7e11581b9d37723ae (also tried older kernels, as far as 3.8rc4 - same thing, this doesn't seem to be kernel-dependent) *drm git://anongit.freedesktop.org/git/mesa/drm d18cd0c7ccf88c9f6585aaa3cc57f0f064d7310b *mesa git://anongit.freedesktop.org/git/mesa/mesa 505fad04f10eee1efdfcd8986b4d484b49d39986 *xorg (radeon driver, xserver, and its dependencies) git latest versions on 06.09.2013 A screenshot is attached. -- 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 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 --- Comment #1 from LRN lrn1...@gmail.com --- Created attachment 85386 -- https://bugs.freedesktop.org/attachment.cgi?id=85386action=edit dmesg -- 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 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 --- Comment #2 from LRN lrn1...@gmail.com --- Created attachment 85387 -- https://bugs.freedesktop.org/attachment.cgi?id=85387action=edit Xorg log -- 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 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 LRN lrn1...@gmail.com changed: What|Removed |Added Attachment #85385|text/plain |image/png mime type|| -- 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
