ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/0d5ebb1c/attachment.html>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/0c32e185/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Vasco Gervasi changed:
What|Removed |Added
CC||yellowhat46 at gmail.com
--- Comment #52
From: "gioh.kim"
update some descriptions for API arguments and descriptions.
Signed-off-by: Gioh Kim
---
Documentation/dma-buf-sharing.txt | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
in
On 12 May 2014 19:42, Rafa? Mi?ecki wrote:
> On 12 May 2014 17:57, Alex Deucher wrote:
>> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote:
>>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>>> in a slightly different way. Moving support to separated file will
>>> al
On 12 May 2014 17:57, Alex Deucher wrote:
> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote:
>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>> in a slightly different way. Moving support to separated file will
>> allow use to use rv770d.h header in the future and a
On 12 May 2014 16:46, Dave Airlie wrote:
> Hi,
>
> A repost of the current state of the displayport MST support for
> i915, mainly targetted the Lenovo docks.
Also in git at
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support
Dave.
>>
>> If we decide to go for property documentation inside the source code then I
>> believe we'll have to create our own format, as creating a properties table
>> from kerneldoc information extracted from comments is probably not possible.
>
> Can comeone pick up the ball here and figure out what
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #36 from Alex Deucher ---
(In reply to Dieter N?tzel from comment #35)
> (In reply to Alex Deucher from comment #33)
> > I wonder if UVD uses the reference clock directly, or if it uses xclk. If
> > it uses xclk, they may explain the
I
> don't know which kind of omapdss driver you have there, so the mainline
> tfp410 cannot probably be used as an example. Most likely the omapdss
> drivers for your kernel are located in drivers/video/omap2/displays/
> directory.
>
> Tomi
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/c5afa535/attachment.html>
Hi
On Mon, May 12, 2014 at 5:28 PM, Daniel Vetter wrote:
> Those are all just reasons for atomic modeset and maybe an atomic modeget
> ioctl which transfers the entire blob of things. Maybe we should start
> with the atomic modeget to get things rolling. Otoh you can always do that
> in userspace
On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
> > On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>
> If we decide to go for property documentation inside the source code
> then I
> believe we'll have t
he bug.
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/4aa8f562/attachment.html>
Thanks for your time and the comments David.
please find mine inline.
Regards
Shashank
On 5/12/2014 5:20 PM, David Herrmann wrote:
> Hi
>
> On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank
> wrote:
>> Benefits of using color manager:
>>
>> 1. Unique framework fo
On Mon, May 12, 2014 at 05:35:13PM +0530, Sharma, Shashank wrote:
> Thanks for your time and the comments David.
> please find mine inline.
>
> Regards
> Shashank
> On 5/12/2014 5:20 PM, David Herrmann wrote:
> >Hi
> >
> >On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank
> > wrote:
> >>Benefits o
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #35 from Dieter N?tzel ---
(In reply to Alex Deucher from comment #33)
> I wonder if UVD uses the reference clock directly, or if it uses xclk. If
> it uses xclk, they may explain the problems. Can you post your dmesg output
> with t
ow nothing on display.
>>
>> Does the kernel have support for OMAP5 DPI? I remember there were some
>> bits that had to be added to make it work.
>>
>> Tomi
>>
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/941666e7/attachment-0001.html>
On 05/04/2014 03:22 PM, Chris Wilson wrote:
> 32b * 32b = 32b
>
> n = (u64)level * freq; to avoid overflow as you claim.
Updated patch to fix this problem is here, thanks!
>From a0f41a92d949c814c203672ff7efe219a90ca6df Mon Sep 17 00:00:00 2001
From: Aaron Lu
Date: Mon, 28 Apr 2014 11:02:52 +08
From: Dave Airlie
use the mst helper code to dump the topology in debugfs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs
From: Dave Airlie
This adds DP 1.2 MST support on Haswell systems.
Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.
b) it introduces a new MST output type.
c) it
From: Dave Airlie
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drive
From: Dave Airlie
This is the initial import of the helper for displayport multistream.
It consists of a topology manager, init/destroy/set mst state
It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs
connector detect and edid retrieval interface.
It supports i2c device over
From: Dave Airlie
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files chang
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/d
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 10
From: Dave Airlie
This just adds the defines from the DP 1.2 spec, which we
will use later.
Signed-off-by: Dave Airlie
---
include/drm/drm_dp_helper.h | 78 +
1 file changed, 78 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/dr
Hi,
A repost of the current state of the displayport MST support for
i915, mainly targetted the Lenovo docks.
Major changes since last posting:
add a path blob property for userspace to use to track topology
provide reference counting, locking and lookups for branch and port structs.
some DocBook
Return IRQ_NONE if it was not our irq. This is necessary for the case
when qxl is sharing irq line with a device A in a crash kernel. If qxl
is initialized before A and A's irq was raised during this gap,
returning IRQ_HANDLED in this case will cause this irq to be raised
again after EOI since kern
On 12 May 2014 16:19, Christian K?nig wrote:
> Am 12.05.2014 15:54, schrieb Rafa? Mi?ecki:
>
>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>> in a slightly different way. Moving support to separated file will
>> allow use to use rv770d.h header in the future and adjust
Am 12.05.2014 15:54, schrieb Rafa? Mi?ecki:
> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
> in a slightly different way. Moving support to separated file will
> allow use to use rv770d.h header in the future and adjust code as well.
Looks like a valid cleanup to me. Shou
https://bugzilla.kernel.org/show_bug.cgi?id=75841
--- Comment #6 from Darren Salt ---
http://lists.freedesktop.org/archives/dri-devel/2014-May/059365.html
Testing with that patch series applied ? no problems noticed so far. Looks like
we might have a fix for this bug here.
--
You are receiving
Hello Daniel,
Please find the actual problem statement and design overview :
==
1. There are different color correction methods, supported by various
SOCs, across various platforms.
2. These properties vary platform-by-platform, dr
DCE 3.1 and 3.2 have different HDMI registers and should be programmed
in a slightly different way. Moving support to separated file will
allow use to use rv770d.h header in the future and adjust code as well.
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/dce3_1_afmt.c
From: Christian K?nig
Some buffers (UVD/VM page tables) must be placed in VRAM,
but the byte restriction for moving buffers didn't took this
into account.
v2: keep closer to the original code
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
1 file changed, 1 i
From: Christian K?nig
Take padding into account as well.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75651
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/dri
Am 08.05.2014 16:58, schrieb Alex Deucher:
> The i2c and aux buses use the same pads so add
> a mutex to protect access to the pads.
>
> Signed-off-by: Alex Deucher
I've applied this one, "drm/radeon: fix DCE83 check for mullins" and
"drm/radeon: handle non-VGA class pci devices with ATRM" my 3.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #34 from Christian K?nig ---
(In reply to Alex Deucher from comment #33)
> I wonder if UVD uses the reference clock directly, or if it uses xclk. If
> it uses xclk, they may explain the problems.
They can be different? Yeah that woul
On 09/05/2014 16:16, Boris BREZILLON wrote:
> Currently, the only way to add new panel descriptions to the simple panel
> driver is to add new entries in the platform_of_match table.
>
> Add support for panel description retrieval from the DT.
>
> Signed-off-by: Boris BREZILLON
> ---
> drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #33 from Alex Deucher ---
I wonder if UVD uses the reference clock directly, or if it uses xclk. If it
uses xclk, they may explain the problems. Can you post your dmesg output with
this patch applied?
diff --git a/drivers/gpu/drm/ra
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/e8ac1a4c/attachment.sig>
t; Bonaire:
>>>>>> [...]
>>>>>>
>>>>>> The simplest way to reproduce the hangs is to run piglit with these
>>>>>> parameters:
>>>>>> -t texelFetch.fs
>>>>>>
>>>>>> Some of the tests allocate a lot of MSAA textures and the tests also
>>>>>> run in parallel, which creates a lot of memory pressure and probably
>>>>>> causes buffer evictions.
>>>>>>
>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
>>>>> I boot
>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
>>>>> settings.
>>>>> I haven't had a chance to bisect it yet, but it might be a similar
>>>>> problem.
>>>>>
>>>>> Grigori
>>>>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-page-directory-update-size-estimation.patch
Type: text/x-diff
Size: 986 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/35410e95/attachment.patch>
esources:
http://www.freedesktop.org/wiki/Software/xrestop/
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/7d10e9f2/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=74551
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
https://bugzilla.kernel.org/show_bug.cgi?id=75951
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
gt; Does the kernel have support for OMAP5 DPI? I remember there were some
> bits that had to be added to make it work.
>
> Tomi
>
>
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/977f4bf9/attachment-0001.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=74751
--- Comment #19 from William Shuman ---
try the patch mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=75651
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=74751
--- Comment #18 from Tasev Nikola ---
Hi
Just tested now 3.15-rc5, still not working.
--
You are receiving this mail because:
You are watching the assignee of the bug.
mber there were some
> bits that had to be added to make it work.
>
> Tomi
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/6f567d1f/attachment.html>
On Mon, May 12, 2014 at 1:42 PM, Rafa? Mi?ecki wrote:
> On 12 May 2014 17:57, Alex Deucher wrote:
>> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote:
>>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
>>> in a slightly different way. Moving support to separated file
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/d91fb3de/attachment.html>
Hi
On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank
wrote:
> Benefits of using color manager:
>
> 1. Unique framework for all the color correction properties, across all
>DRM drivers, across various platforms.
> 2. Only one set/get call for all kind of prope
https://bugzilla.kernel.org/show_bug.cgi?id=75651
William Shuman changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=75651
--- Comment #9 from Christian K?nig ---
Thanks for the info, so we can close this bug now?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=75651
--- Comment #8 from William Shuman ---
This fixed this issue. Thanks for your work.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=75651
Christian K?nig changed:
What|Removed |Added
Attachment #135731|0 |1
is obsolete|
On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda wrote:
> On 05/09/2014 05:05 PM, Ajay kumar wrote:
>> On Fri, May 9, 2014 at 7:29 PM, Rob Clark wrote:
>>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda
>>> wrote:
On 05/08/2014 08:24 PM, Rob Clark wrote:
> On Thu, May 8, 2014 at 2:41 AM,
On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote:
> DCE 3.1 and 3.2 have different HDMI registers and should be programmed
> in a slightly different way. Moving support to separated file will
> allow use to use rv770d.h header in the future and adjust code as well.
Any reason not to split it
I support approach using docbook to start since there are not lot of
properties. Laurent has ack'ed this one. Can we go ahead with this?
http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html
Adding description of new property is not very complex (assuming table
format is understoo
On Mon, May 12, 2014 at 9:30 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Take padding into account as well.
>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75651
>
> Signed-off-by: Christian K?nig
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/rad
On 05/12/2014 08:54 AM, Daniel Vetter wrote:
> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
>>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>>
>> If we decide to go for property documentation inside the source
On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
> >>
> >> If we decide to go for property documentation inside the source code then I
> >> believe we'll have to create our own format, as creating a properties table
> >> from kerneldoc information extracted from comments is probably not
https://bugzilla.kernel.org/show_bug.cgi?id=66281
--- Comment #7 from Ilia Mirkin ---
(In reply to Gaurav Shukla from comment #6)
> (In reply to Ilia Mirkin from comment #5)
> > (In reply to Gaurav Shukla from comment #4)
> > > (c) How do I check that runtime pm and vga switcheroo are enabled in
Re-adding dri-devel, all drm core stuff must be discussed there.
But on the actual issue at hand I still don't understand what you're
trying to solve. You add a complete new set of properties, using Intel
names (pipes, planes) for some attributes which at first seems
completely redundant to all th
On Fri, May 09, 2014 at 08:14:14AM +0200, Takashi Iwai wrote:
> The recent commit [3ea87855: drm/helper: lock all around force mode
> restore] introduced drm_modeset_lock_all() in
> drm_helper_resume_force_mode() itself, while ast driver still takes
> this lock before calling it. Remove the caller
On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote:
> I support approach using docbook to start since there are not lot of
> properties. Laurent has ack'ed this one. Can we go ahead with this?
> http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html
>
> Adding descri
Hi,
On 05/12/2014 09:32 AM, Hans de Goede wrote:
> acpi_video_backlight_support() is supposed to be called by other (vendor
> specific) firmware backlight controls, not by native / raw backlight controls
> like nv_backlight.
>
> Userspace will normally prefer firmware interfaces over raw interfac
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will us
On 05/09/2014 05:05 PM, Ajay kumar wrote:
> On Fri, May 9, 2014 at 7:29 PM, Rob Clark wrote:
>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda wrote:
>>> On 05/08/2014 08:24 PM, Rob Clark wrote:
On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda
wrote:
> On 05/05/2014 09:52 PM, Ajay Kum
On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda wrote:
> On 05/09/2014 05:05 PM, Ajay kumar wrote:
>> On Fri, May 9, 2014 at 7:29 PM, Rob Clark wrote:
>>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda
>>> wrote:
On 05/08/2014 08:24 PM, Rob Clark wrote:
> On Thu, May 8, 2014 at 2:41 AM,
https://bugzilla.kernel.org/show_bug.cgi?id=66281
--- Comment #6 from Gaurav Shukla ---
(In reply to Ilia Mirkin from comment #5)
> (In reply to Gaurav Shukla from comment #4)
> > (c) How do I check that runtime pm and vga switcheroo are enabled in my
> > kernel. (Sorry, but I am a newbie to Linu
On 05/12/2014 01:58 AM, Daniel Vetter wrote:
> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
If we decide to go for property documentation inside the source code then I
believe we'll have to create our own format, as creating a properties table
from kerneldoc info
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #32 from Christian K?nig ---
(In reply to sdh from comment #30)
> Hi. Any update on this?
I've pushed the workaround upstream. So you should at least have a booting
system. Just don't try to use any accelerated video decoding since th
something like es2gears without X
at all.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/5c7d3646/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #31 from sdh ---
I just noticed I'm getting the following errors during the sleep and wake up
cycle:
[drm:rv730_stop_dpm] *ERROR* Could not force DPM to low
[drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed
Kernel is
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140512/401debf6/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/17279ffe/attachment.html>
s mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/1487537c/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/5af7fcdd/attachment.html>
Hello!
Below is my patch for drm. Here is a photo of kernel output I had:
http://s17.postimg.org/k0301hgf3/Untitled.jpg
to illustrate what I am writing in the description.
---
Subject: [PATCH] drm/crtc-helper: skip locking checks in panicking path
Skip locking checks in drm_helper_*_in_use() if t
81 matches
Mail list logo
