[Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78242

--- Comment #5 from Emil Velikov  ---
(In reply to comment #4)
> > It's a steam bug, not a mesa one
> 
> I disagree: this (na?vely linking LLVM) is a change in mesa that breaks many
> binary software packages, not just Steam. While the steam-runtime will
> likely get a fix for this at some point, some older games may not be so
> lucky.
>
I would say that both parties are to "blame" on this one. AFAICS the topic of
to ship libgcc_s/libstdc++ or not has always been a interesting one.

[snip]
> What you are doing here is introducing additional problems where none
> existed before.
>
I beg to disagree here. Mesa has linked against libgcc_s and libstdc++ since
forever. Whereas the static/shared linking against LLVM has always been a
configure time decision.

> Please reconsider statically linking libLLVM and required
> C++/GCC libs into *_dri.so or finding some other solution to not conflict
> with programs loading libGL. (An even stricter RTLD_LOCAL that completely
> namespaces libs would be nice to have here ?)
> 
Static linking against gcc/c++ seems like a bit of a pain as libtool,
unconditionally appends "-lgcc -lgcc_s -lstdc++" (as defined by postdeps), thus
-Wl,--static.. and/or -static-lib{gcc,stdc++} does not really help.

If you have any solid suggestion please put them forward.

-- 
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/0c32e185/attachment.html>

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60523

Vasco Gervasi  changed:

   What|Removed |Added

 CC||yellowhat46 at gmail.com

--- Comment #52 from Vasco Gervasi  ---
Same problem with a HD6870 and two monitor.
I am using 3.15-rc5.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

[gioh.kim]

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
index 505e711..1ea89b8 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -56,7 +56,7 @@ The dma_buf buffer sharing API usage contains the following 
steps:
 size_t size, int flags,
 const char *exp_name)

-   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
+   If this succeeds, dma_buf_export_named allocates a dma_buf structure, and 
returns a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
@@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following 
steps:

Exporting modules which do not wish to provide any specific name may use the
helper define 'dma_buf_export()', with the same arguments as above, but
-   without the last argument; a __FILE__ pre-processor directive will be
+   without the last argument; a KBUILD_MODNAME pre-processor directive will be
inserted in place of 'exp_name' instead.

 2. Userspace gets a handle to pass around to potential buffer-users
@@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following 
steps:
drivers and/or processes.

Interface:
-  int dma_buf_fd(struct dma_buf *dmabuf)
+  int dma_buf_fd(struct dma_buf *dmabuf, int flags)

This API installs an fd for the anonymous file associated with this buffer;
returns either 'fd', or error.
@@ -157,7 +157,9 @@ to request use of buffer for allocation.
"dma_buf->ops->" indirection from the users of this interface.

In struct dma_buf_ops, unmap_dma_buf is defined as
-  void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
+  void (*unmap_dma_buf)(struct dma_buf_attachment *,
+struct sg_table *,
+enum dma_data_direction);

unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
map_dma_buf, this API also must be implemented by the exporter.
-- 
1.7.9.5

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

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
>>> allow use to use rv770d.h header in the future and adjust code as well.
>>
>> Any reason not to split it at DCE3.2 rather than 3.1?  It seems like
>> most (all?) of the changes are DCE3.2 specific rather than DCE3.1.
>> Otherwise, seems fine to me.
>
> I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed
> in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The
> biggest difference is that DCE 3.1 doesn't seem to have
> AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0.

After looking closer... maybe I have to review it again. It seems
programming order of DCE 3.1 is much more like DCE 3.2, but registers
of DCE 3.1 are more like DCE 2.0/3.0. Maybe we'll need even one more
split.

I'll review it and come back.

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

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 adjust code as well.
>
> Any reason not to split it at DCE3.2 rather than 3.1?  It seems like
> most (all?) of the changes are DCE3.2 specific rather than DCE3.1.
> Otherwise, seems fine to me.

I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed
in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The
biggest difference is that DCE 3.1 doesn't seem to have
AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0.

Take a look at defines for DCE 3.2. Even they are placed in rv770d.h,
which is the DCE 3.1 chipset.

[RFC] DisplayPort MST v0.3

[Dave Airlie]

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.

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Dave Airlie]

>>
>> 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 needs to be done?
>
> The reason why I want a central place for the documentation is to force
> people to collaborate outside their own sandbox when adding properties.
> Whether that's docbook or some text file I don't care so much at this
> point. The fact that it's a central place should mandate that the
> patches changing it will go through dri-devel and so everyone should se
> them, and when adding new properties it would make the patch author more
> likely to look around a bit before adding another slighty incompatible
> version of the same property. If someone has a better suggestion how to
> encforce this I'm all ears.
>
> Of course this idea can still fail if our esteemed maintainer merges
> stuff without checking for violations of this policy. Dave, any thoughts
> on the subject?

Yeah I'm happy to block merging stuff, if we can spot new properties
when stuff is posted on dri-devel, so much the better,

most drivers still send everything via dri-devel anyways, its only
really Intel I have to worry about so far,

But we should definitely add it to the new driver review checklist as well.

I'm also on the side of this patch is ugly and makes my eyes burn,
please please get a plan to use something else ASAP, I'm willing to
merge this but I'm tempted to give it a lifetime of a kernel or two
before I burn it.

Dave.

[Bug 71891] 3.13 fails to boot with the radeon module

[bugzilla-dae...@bugzilla.kernel.org]

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 problems.  Can you post your dmesg output
> > with this patch applied?
> 
> Here is mine (with latest stuff from Christian):
> 
> [   11.159443] [drm] initializing kernel modesetting (RV730 0x1002:0x9495
> 0x174B:0x0028).
> 
> [   11.257005] [drm] ref: 2700, xclk: 2700

On your board (and most boards) they are the same, so your board would not be
affected if this proves to be an issue.

> 
> [   11.263794] radeon :01:00.0: WB disabled   <--- Is this intended?

On AGP cards, WB is disabled.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

OMAPDSS: omap5 SYNC_LOST error with DPI/LCD

[Vikas Patil]

Hi Tomi,

Thank a lot  for your inputs and patch info.

It seems I cannot apply those patches straight away as it is based on
3.6-rc4 and I am using 3.4.25, between these two, it seems significant code
changes for DSS related code.

I am using 3.4.25 kernel from TI for OMAP5 evm, it has been modified as per
our platform requirement which is having OMAP5 ES2.0 revision.

I am trying to use the panel driver for DPI interface(i.e.
Kernel\drivers\video\omap2\displays\panel-generic-dpi.c). So DSS and panel
driver path are as follows

Kernel\drivers\video\omap2\dss\dpi.c,dss.c,display.c,dss_features.c etc
Kernel\drivers\video\omap2\displays\panel-generic-dpi.c

soc specific:
Kernel\arch\arm\mach-omap2\omap5_es2\clkt_clksel.c,
clkt_dpll.c,clock.c,cm44xx_54xx.c etc

omapdrm path:
Kernel\drivers\staging\omapdrm

In case for working HDMI port, we are using:
Kernel\drivers\video\omap2\dss\hdmi.c
Kernel\drivers\video\omap2\dss\hdmi_panel.c

I think this would require considerable amount of understanding on dss
architecture and effort to backport some of the things, write new driver
fro TDF19988 and make DPI interface working for our platform for someone
like me who has just started working on DSS/Display.

Regards,
Vikash

On Mon, May 12, 2014 at 5:28 PM, Tomi Valkeinen wrote:

> On 12/05/14 14:33, Vikas Patil wrote:
> > Hi,
> >
> > Re-posting as previous posting was rejected due to length.
> >
> > Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI
> > conversion.
> > I have build the driver for it from
> >
> https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c
> .
> > Is this the correct driver for it?
>
> That driver cannot be used with omapdrm, which uses omapdss. There's no
> TDF19988 driver for omapdss (at least in the mainline), so you need to
> write one.
>
> > Also I am trying to use the generic-dpi-panel driver for this with
> > OMAP5. It seems I also need to add support for TDF19988 somewhere in
> > omapdrm or lcd/panel driver by calling drm_i2c_encoder_init to
> > initialize it. Can I use somecode from ticldc driver or driver itself?
> > Could you please give some inputs, how should I proceed further to
> > adding support for TDF19988 for which the input is coming from DPI
> > interface?
>
> You need to write a driver for it. Something similar to
> drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c, except tfp410
> is quite simple one.
>
> But I think you said you're based on some old customized kernel, so 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>

[Intel-gfx] Design review request: DRM color manager

[David Herrmann]

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 since we assume there's only one display manager.

DRM_MODE_OBJ_GET_PROPERTIES is already available and allows atomic
retrieval of 'n' properties (as it calls drm_modeset_lock_all()). I
guess that qualifies as what you describe with "atomic modeget"?

> And for modeset we can throw efficiency of the marshalling/de-marshalling
> over board (within some limits of course) since we do about 60*num_pipes
> modeset/pageflip calls per second at most. And the overhead of the
> encoding/decoding of the properties will be completely washed out by all
> the register i/o we need to do to UC pci bars.

Yepp, I fully agree. And if properties turn out to become a
bottleneck, we should optimize them.

Thanks
David

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Daniel Vetter]

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 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 needs to be done?
> >>>
> >>> The reason why I want a central place for the documentation is to force
> >>> people to collaborate outside their own sandbox when adding properties.
> >>> Whether that's docbook or some text file I don't care so much at this
> >>> point. The fact that it's a central place should mandate that the
> >>> patches changing it will go through dri-devel and so everyone should se
> >>> them, and when adding new properties it would make the patch author more
> >>> likely to look around a bit before adding another slighty incompatible
> >>> version of the same property. If someone has a better suggestion how to
> >>> encforce this I'm all ears.
> >>>
> >>> Of course this idea can still fail if our esteemed maintainer merges
> >>> stuff without checking for violations of this policy. Dave, any thoughts
> >>> on the subject?
> >>
> >> Yeah I'm happy to block merging stuff, if we can spot new properties
> >> when stuff is posted on dri-devel, so much the better,
> >>
> >> most drivers still send everything via dri-devel anyways, its only
> >> really Intel I have to worry about so far,
> > 
> > I'll enforce that all prop stuff gets cc: dri-devel and that it has
> > updates for the prop docs.
> > 
> >> But we should definitely add it to the new driver review checklist as well.
> >>
> >> I'm also on the side of this patch is ugly and makes my eyes burn,
> >> please please get a plan to use something else ASAP, I'm willing to
> >> merge this but I'm tempted to give it a lifetime of a kernel or two
> >> before I burn it.
> > 
> > Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
> > find someone to do it for me internally ;-)
> > -Daniel
> > 
> 
> I certainly have no objections to making kerneldoc suck less.
> There was already an attempt to use asciidoc (like git uses) for kernel-doc
> (a few years ago, by Sam Ravnborg).  I support(ed) that effort.

Hm, do you have pointers to those? My google-fu seems lacking ...

Ok, let's move this to the top and start discussions. The past few months
I've written piles of kerneldoc comments for the DRM DocBook (all pulled
in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
sections are really useful to pull all the actual documentation out of the
docbook xml into kerneldoc.

But I've also done piles of docs for intel-gpu-tools, which is using
gtkdoc. And there are some clear deficiencies:

- No markdown for inline coments. Lack of lists and tables is hurting
  especially badly. If we add this (and I don't care one iota whether it's
  markdown or asciidoc or something else as long as it's readable plain
  text in comments) we should be able to move all the existing docbook xml
  paragraphs/lists/tables into kerneldoc comments.

- Automatic cross-referencing of functions. If you place e.g. function()
  or #struct anywhere in a documentation comment gtk-doc automatically
  inserts a hyperlink to the relevant documentation page across the entire
  project. Really powerful and makes overview sections much more useful
  entry points for beginners since they can easily jump back
  betweeen the high-level overview and low-level per-function
  documentation.

- In a really perfect world it would help if kerneldoc could collect
  structure member kerneldoc from per-member comments. Especially for
  large structures with lots of comments this would bring the kerneldoc
  and struct member much closer together.

So that's my wishlist.

> OTOH, I would only want to add another way to do kernel-doc if it can be a
> full replacement for all of our docbook usage, i.e., it should provide a
> way that we can eliminate docbook and stop using it completely.

Hm, I don't mind docbook at all, as long as all the real content is
embedded into source files as kerneldoc and the docbook template just
pulls in all the right bits and pieces. Even gtkdoc allos you to do that
and pull in the different libararies (== header files with declarations
for C) in the order you want. So imo the docbook toolchain is good enough
for my needs.

Or what do you mean by getting rid of all docbook usage?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing)

[bugzilla-dae...@freedesktop.org]

9/libstdc++.so.6
(0x7f37f0e61000)
/usr/lib/mesa/r600g_dri.so: libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1
(0x7f37f059f000)
/usr/lib/mesa/radeon_dri.so:libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6
(0x7f5528868000)
/usr/lib/mesa/radeon_dri.so:libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1
(0x7f5527fa6000)
/usr/lib/mesa/radeonsi_dri.so:  libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6
(0x7f4021a96000)
/usr/lib/mesa/radeonsi_dri.so:  libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1
(0x7f40211d4000)
/usr/lib/mesa/swrast_dri.so:libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6
(0x7f3bf7cc8000)
/usr/lib/mesa/swrast_dri.so:libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1
(0x7f3bf7406000)
/usr/lib/mesa/swrastg_dri.so:   libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6
(0x7fd0b4263000)
/usr/lib/mesa/swrastg_dri.so:   libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1
(0x7fd0b39a1000)

This search includes fglrx's libGL by the way: The proprietary AMD (and I'm
sure NVIDIA) drivers have long used C++ internally, but have taken care not to
pollute the global namespace with the C++ standard library or GCC helper
library. I think this shows even more precedent that these libraries should not
be considered safe to use in base system libraries without additional
precautions.

What you are doing here is introducing additional problems where none existed
before. Please reconsider statically linking libLLVM and required C++/GCC libs
into *_dri.so or finding some other solution to not conflict with programs
loading libGL. (An even stricter RTLD_LOCAL that completely namespaces libs
would be nice to have here ?)

For reference, here are a few more bugs caused by this:
 #30192, #30901, #38182, #38783, #43964, #66955

-- 
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/4aa8f562/attachment.html>

[Intel-gfx] Design review request: DRM color manager

[Sharma, Shashank]

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 for all the color correction properties, across all
>> DRM drivers, across various platforms.
>> 2. Only one set/get call for all kind of properties using the common
>> protocol. One get call can tell what are the color correction capabilities
>> of the SOC, registered by driver.
>
> What's the advantage of that? We should add a
> DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things,
> instead of adding huge payloads.
>
The problem here is a DRM_OBJECT_MODE_SET_PROPERTIES call can pass 
limited value. But there are few properties like gamma correction which 
need a full LUT(256 vals) to be passed according to the correction 
values. The plan here is pretty much aligned to your suggestion, ie to 
use DRM_OBJECT_MODE_SET_BLOB kind of property, and extract the data from 
the blob based on a protocol.
Why do you think its a huge payload ?
> I really think we should define one property for each color-correction
> interface. I cannot see any downside of that except that we should add
> DRM_MODE_OBJ_SET_PROPERTIES.

As I was discussing, if there are 10 color correction properties a SOC 
supports, we have to create 10 properties which doesn't look good, when 
all the properties will do the same (set/reset few registers as 
correction). We already have a case where we expose 6 different type of 
corrections.

One more benefit is, this part is centrally controlled, so you can 
always know what's the state of color correction in single shot at any 
time. This will also provide us to do a lot of common things to do at 
the same place, like floating point arithmetic to register value 
conversion in a supporting userspace library, which might be required 
for many cases.

INHO, its always good to have a controlled interface/ framework to have 
similar things aligned to.

But afaik that's already the plan for
> atomic-modesetting, right?
>
> Thanks
> David
>
AFAIK color management is not a part of atomic modeset, but once we 
create such an interface, it would be really easy to club that in the 
atomic modeset.

[Intel-gfx] Design review request: DRM color manager

[Daniel Vetter]

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 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 properties using the common
> >>protocol. One get call can tell what are the color correction capabilities
> >>of the SOC, registered by driver.
> >
> >What's the advantage of that? We should add a
> >DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things,
> >instead of adding huge payloads.
> >
> The problem here is a DRM_OBJECT_MODE_SET_PROPERTIES call can pass limited
> value. But there are few properties like gamma correction which need a full
> LUT(256 vals) to be passed according to the correction values. The plan here
> is pretty much aligned to your suggestion, ie to use
> DRM_OBJECT_MODE_SET_BLOB kind of property, and extract the data from the
> blob based on a protocol.
> Why do you think its a huge payload ?

Gamma correction lut is already supported. For the other stuff we can use
SET_BLOB (or fix it if it doesn't work).

> >I really think we should define one property for each color-correction
> >interface. I cannot see any downside of that except that we should add
> >DRM_MODE_OBJ_SET_PROPERTIES.
> 
> As I was discussing, if there are 10 color correction properties a SOC
> supports, we have to create 10 properties which doesn't look good, when all
> the properties will do the same (set/reset few registers as correction). We
> already have a case where we expose 6 different type of corrections.
> 
> One more benefit is, this part is centrally controlled, so you can always
> know what's the state of color correction in single shot at any time. This
> will also provide us to do a lot of common things to do at the same place,
> like floating point arithmetic to register value conversion in a supporting
> userspace library, which might be required for many cases.
> 
> INHO, its always good to have a controlled interface/ framework to have
> similar things aligned to.

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 since we assume there's only one display manager.

And we absolutely want color correction to be part of the atomic modeset
stuff (since some hw has e.g. per-plane gamma correction). So adding a new
way to set them despite that the current atomic modeset proposal is fully
centered on properties and that we've added all these properties for just
this reasons is important. I still don't see what you can do with the
color manager that's impossible to do with properties.

And having a large pile of properties imo doesn't count as a good reason,
since with the color manager you still have all these settings. But maybe
just encoded differently, e.g. in a bitfield or something. Changing the
way you set stuff doesn't fundamentally change things at all.

And for modeset we can throw efficiency of the marshalling/de-marshalling
over board (within some limits of course) since we do about 60*num_pipes
modeset/pageflip calls per second at most. And the overhead of the
encoding/decoding of the properties will be completely washed out by all
the register i/o we need to do to UC pci bars.

> But afaik that's already the plan for
> >atomic-modesetting, right?
> >
> >Thanks
> >David
> >
> AFAIK color management is not a part of atomic modeset, but once we create
> such an interface, it would be really easy to club that in the atomic
> modeset.

See above, this is a reason to _not_ add a separate color manager.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 71891] 3.13 fails to boot with the radeon module

[bugzilla-dae...@bugzilla.kernel.org]

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 this patch applied?

Here is mine (with latest stuff from Christian):

[   11.159443] [drm] initializing kernel modesetting (RV730 0x1002:0x9495
0x174B:0x0028).

[   11.257005] [drm] ref: 2700, xclk: 2700

[   11.263794] radeon :01:00.0: WB disabled   <--- Is this intended?

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730
[Radeon HD 4600 AGP Series] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 4650 AGP
DDR2
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
Memory at c000 (32-bit, prefetchable) [size=256M]
I/O ports at a800 [size=256]
Memory at dfdf (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfdc [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] AGP version 3.0
Kernel driver in use: radeon
Kernel modules: radeon

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

OMAPDSS: omap5 SYNC_LOST error with DPI/LCD

[Vikas Patil]

Hi,

Re-posting as previous posting was rejected due to length.

Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI
conversion.
I have build the driver for it from
https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c.
Is this the correct driver for it?

Also I am trying to use the generic-dpi-panel driver for this with OMAP5.
It seems I also need to add support for TDF19988 somewhere in omapdrm or
lcd/panel driver by calling drm_i2c_encoder_init to initialize it. Can I
use somecode from ticldc driver or driver itself? Could you please give
some inputs, how should I proceed further to adding support for TDF19988
for which the input is coming from DPI interface?


Thanks & Regards,
Vikash


On Mon, May 12, 2014 at 2:11 PM, Vikas Patil  wrote:

> Hi Tomi,
>
> How could I confirm for OMAP5 DPI support apart form enabling
> CONFIG_OMAP2_DSS_DPI and CONFIG_PANEL_GENERIC_DPI? Enabling mentioned
> config builds components from Kernel\drivers\video\omap2\dss and
> kernel\drivers\video\omap2\displays only.  Is there any support needs to be
> available under kernel\arch\arm\mach-omap2?
>
> Regards,
> Vikash
>
>
>
> On Fri, May 9, 2014 at 4:49 PM, Tomi Valkeinen  ti.com>wrote:
>
>> On 08/05/14 13:07, Vikas Patil wrote:
>> > Hi,
>> >
>> > I am working on to enable the second display output for customized OMAP5
>> > based platform and linux 3.4.25. First display which is HDMI/tv is
>> > working fine. Second display out is coming via DPI interface. To enable
>> > DPI interface I enabled CONFIG_OMAP2_DSS_DPI and
>> > CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and
>> > omap_dss_board_info and removed the HDMI device and disabled
>> > CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting correctly,
>> > however when I try to run kmscube app and it seems to be running,
>> > noticing following error and till now 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>

[PATCH v3] drm/i915: restore backlight precision when converting from opregion

[Aaron Lu]

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 +0800
Subject: [PATCH] drm/i915: restore backlight precision when converting from
 ACPI

When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.

To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491
Reported-by: Nico Schottelius 
Signed-off-by: Aaron Lu 
---
 drivers/gpu/drm/i915/intel_panel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 0eead16aeda7..cb8cfb7e0974 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -492,6 +492,7 @@ void intel_panel_set_backlight(struct intel_connector 
*connector, u32 level,
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 freq;
unsigned long flags;
+   u64 n;

if (!panel->backlight.present || pipe == INVALID_PIPE)
return;
@@ -502,10 +503,9 @@ void intel_panel_set_backlight(struct intel_connector 
*connector, u32 level,

/* scale to hardware max, but be careful to not overflow */
freq = panel->backlight.max;
-   if (freq < max)
-   level = level * freq / max;
-   else
-   level = freq / max * level;
+   n = (u64)level * freq;
+   do_div(n, max);
+   level = n;

panel->backlight.level = level;
if (panel->backlight.device)
-- 
1.9.0

[PATCH 10/10] i915: mst topology dumper in debugfs

[Dave Airlie]

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.c
index 88e944f..b8a9a51 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2378,6 +2378,31 @@ struct pipe_crc_info {
enum pipe pipe;
 };

+static int i915_dp_mst_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_encoder *encoder;
+   struct intel_encoder *intel_encoder;
+   struct intel_digital_port *intel_dig_port;
+   drm_modeset_lock_all(dev);
+   list_for_each_entry(encoder, >mode_config.encoder_list, head) {
+   intel_encoder = to_intel_encoder(encoder);
+   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
+   continue;
+   intel_dig_port = enc_to_dig_port(encoder);
+   if (!intel_dig_port->dp.can_mst)
+   continue;
+
+   if (!intel_dig_port->dp.is_mst)
+   continue;
+
+   drm_dp_mst_dump_topology(m, _dig_port->dp.mst_mgr);
+   }
+   drm_modeset_unlock_all(dev);
+   return 0;
+}
+
 static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
 {
struct pipe_crc_info *info = inode->i_private;
@@ -3813,6 +3838,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_pc8_status", i915_pc8_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_display_info", i915_display_info, 0},
+   {"i915_dp_mst_info", i915_dp_mst_info, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)

-- 
1.9.0

[PATCH 09/10] i915: add DP 1.2 MST support (v0.3)

[Dave Airlie]

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 really annoys the state checker, as the connector that is
connected at the start, goes into disconnected, and its encoder
it active, and things blow up, need to look into how to solve that.

d) the intel userspace driver needs changes to use this, -modesetting
should work okay.

e) it might contain a race condition big enough to eat you.

f) its hardcoded to 4 lanes 5.4Ghz. - TODO.

Changes since v0.1:
use PORT_PCH_HOTPLUG to detect short vs long pulses
add a workqueue to deal with digital events as they can get blocked on the
main workqueue beyong mode_config mutex
fix a bunch of modeset checker warnings
acks irqs in the driver
cleanup the MST encoders

Changes since v0.3
check irq status again in work handler
move around bring up and tear down to fix DPMS on/off
use path properties.

TODO:
further state checker fixes

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_dma.c   |  10 +
 drivers/gpu/drm/i915/i915_drv.h   |  14 +
 drivers/gpu/drm/i915/i915_irq.c   | 106 ++-
 drivers/gpu/drm/i915/intel_ddi.c  | 111 +--
 drivers/gpu/drm/i915/intel_display.c  |  59 +++-
 drivers/gpu/drm/i915/intel_dp.c   | 213 +-
 drivers/gpu/drm/i915/intel_dp_mst.c   | 530 ++
 drivers/gpu/drm/i915/intel_drv.h  |  42 ++-
 drivers/gpu/drm/i915/intel_opregion.c |   1 +
 10 files changed, 1041 insertions(+), 46 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_mst.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b1445b7..6cf2b95 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -52,6 +52,7 @@ i915-y += dvo_ch7017.o \
  intel_crt.o \
  intel_ddi.o \
  intel_dp.o \
+ intel_dp_mst.o \
  intel_dsi_cmd.o \
  intel_dsi.o \
  intel_dsi_pll.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 58f2c46..3040869 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1677,6 +1677,13 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
goto out_mtrrfree;
}

+   dev_priv->dp_wq = alloc_ordered_workqueue("i915-dp", 0);
+   if (dev_priv->dp_wq == NULL) {
+   DRM_ERROR("Failed to create our dp workqueue.\n");
+   ret = -ENOMEM;
+   goto out_freewq;
+   }
+
intel_irq_init(dev);
intel_uncore_sanitize(dev);

@@ -1752,6 +1759,8 @@ out_gem_unload:
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
pm_qos_remove_request(_priv->pm_qos);
+   destroy_workqueue(dev_priv->dp_wq);
+out_freewq:
destroy_workqueue(dev_priv->wq);
 out_mtrrfree:
arch_phys_wc_del(dev_priv->gtt.mtrr);
@@ -1856,6 +1865,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);

+   destroy_workqueue(dev_priv->dp_wq);
destroy_workqueue(dev_priv->wq);
pm_qos_remove_request(_priv->pm_qos);

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d6acb4..b3b5864c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,6 +1468,18 @@ struct drm_i915_private {

struct i915_runtime_pm pm;

+   struct intel_digital_port *hpd_irq_port[I915_MAX_PORTS];
+   u32 hpd_port;
+   struct work_struct dig_port_work;
+   /*
+* if we get a HPD irq from DP and a HPD irq from non-DP
+* the non-DP HPD could block the workqueue on a mode config
+* mutex getting, that userspace may have taken. However
+* userspace is waiting on the DP workqueue to run which is
+* blocked behind the non-DP one.
+*/
+   struct workqueue_struct *dp_wq;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
 * here! */
struct i915_dri1_state dri1;
@@ -1999,6 +2011,8 @@ i915_disable_pipestat(struct drm_i915_private *dev_priv, 
enum pipe pipe,

 void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv);
 void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv);
+bool intel_hpd_irq_event(struct drm_device *dev,
+struct drm_connector *connector);

 /* i915_gem.c */
 int i915_gem_init_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5852dee..0b16d41 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -963,8 +963,8 @@ 

[PATCH 08/10] drm/i915: check connector->encoder before using it.

[Dave Airlie]

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/intel_display.c | 25 ++---
 3 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..88e944f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2279,13 +2279,15 @@ static void intel_connector_info(struct seq_file *m,
seq_printf(m, "\tCEA rev: %d\n",
   connector->display_info.cea_rev);
}
-   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
-   intel_encoder->type == INTEL_OUTPUT_EDP)
-   intel_dp_info(m, intel_connector);
-   else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
-   intel_hdmi_info(m, intel_connector);
-   else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
-   intel_lvds_info(m, intel_connector);
+   if (intel_encoder) {
+   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_encoder->type == INTEL_OUTPUT_EDP)
+   intel_dp_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
+   intel_hdmi_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
+   intel_lvds_info(m, intel_connector);
+   }

seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, >modes, head)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index afa5519..5852dee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1016,6 +1016,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
dev_priv->hpd_event_bits = 0;
list_for_each_entry(connector, _config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+   if (!intel_connector->encoder)
+   continue;
intel_encoder = intel_connector->encoder;
if (intel_encoder->hpd_pin > HPD_NONE &&
dev_priv->hpd_stats[intel_encoder->hpd_pin].hpd_mark == 
HPD_MARK_DISABLED &&
@@ -1046,6 +1048,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)

list_for_each_entry(connector, _config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+   if (!intel_connector->encoder)
+   continue;
intel_encoder = intel_connector->encoder;
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
if (intel_encoder->hot_plug)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b39d036..75b2aaf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4600,20 +4600,23 @@ static void intel_connector_check_state(struct 
intel_connector *connector)
 "wrong connector dpms state\n");
WARN(connector->base.encoder != >base,
 "active connector not linked to encoder\n");
-   WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");

-   encoder_enabled = encoder->get_hw_state(encoder, );
-   WARN(!encoder_enabled, "encoder not enabled\n");
-   if (WARN_ON(!encoder->base.crtc))
-   return;
+   if (encoder) {
+   WARN(!encoder->connectors_active,
+"encoder->connectors_active not set\n");
+
+   encoder_enabled = encoder->get_hw_state(encoder, );
+   WARN(!encoder_enabled, "encoder not enabled\n");
+   if (WARN_ON(!encoder->base.crtc))
+   return;

-   crtc = encoder->base.crtc;
+   crtc = encoder->base.crtc;

-   WARN(!crtc->enabled, "crtc not enabled\n");
-   WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
-   WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
+   WARN(!crtc->enabled, "crtc not enabled\n");
+   WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
+   WARN(pipe != to_intel_crtc(crtc)->pipe,
+"encoder active on the wrong pipe\n");
+   }
}
 }

-- 
1.9.0

[PATCH 07/10] i915: split some DP modesetting code into a separate function

[Dave Airlie]

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/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e96..a5b8b76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -364,6 +364,18 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR("FDI link training failed!\n");
 }

+void intel_ddi_mode_set_dp(struct intel_encoder *encoder)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(>base);
+
+   intel_dp->DP = intel_dig_port->saved_port_bits |
+   DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
+   intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
+
+}
+
 static void intel_ddi_mode_set(struct intel_encoder *encoder)
 {
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
@@ -378,13 +390,7 @@ static void intel_ddi_mode_set(struct intel_encoder 
*encoder)
crtc->eld_vld = false;
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
-   struct intel_digital_port *intel_dig_port =
-   enc_to_dig_port(>base);
-
-   intel_dp->DP = intel_dig_port->saved_port_bits |
-  DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
-   intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
-
+   intel_ddi_mode_set_dp(encoder);
if (intel_dp->has_audio) {
DRM_DEBUG_DRIVER("DP audio on pipe %c on DDI\n",
 pipe_name(crtc->pipe));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b885df1..8e41cdc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -683,6 +683,7 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_config *pipe_config);

+void intel_ddi_mode_set_dp(struct intel_encoder *encoder);

 /* intel_display.c */
 const char *intel_output_name(int output);
-- 
1.9.0

[PATCH 06/10] drm/helper: add Displayport multi-stream helper (v0.3)

[Dave Airlie]

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 DP 1.2 sideband msg protocol (EDID reads only)

bandwidth manager API via vcpi allocation and payload updating,
along with a helper to check the ACT status.

Objects:
MST topology manager - one per toplevel MST capable GPU port - not sure if this 
should be higher level again
MST branch unit - one instance per plugged branching unit - one at top of 
hierarchy - others hanging from ports
MST port - one port per port reported by branching units, can have MST units 
hanging from them as well.

Changes since initial posting:
a) add a mutex responsbile for the queues, it locks the sideband and msg slots, 
and msgs to transmit state
b) add worker to handle connection state change events, for MST device chaining 
and hotplug
c) add a payload spinlock
d) add path sideband msg support
e) fixup enum path resources transmit
f) reduce max dpcd msg to 16, as per DP1.2 spec.
g) separate tx queue kicking from irq processing and move irq acking back to 
drivers.

Changes since v0.2:
a) reorganise code,
b) drop ACT forcing code
c) add connector naming interface using path property
d) add topology dumper helper
e) proper reference counting and lookup for ports and mstbs.
f) move tx kicking into a workq
g) add aux locking - this should be redone
h) split teardown into two parts
i) start working on documentation on interface.

TODO:
misc features

Signed-off-by: Dave Airlie 
---
 Documentation/DocBook/drm.tmpl|6 +
 drivers/gpu/drm/Makefile  |2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c | 2536 +
 include/drm/drm_dp_mst_helper.h   |  503 +++
 4 files changed, 3046 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dp_mst_topology.c
 create mode 100644 include/drm/drm_dp_mst_helper.h

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 83dd0b0..1883976 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2296,6 +2296,12 @@ void intel_crt_init(struct drm_device *dev)
 !Edrivers/gpu/drm/drm_dp_helper.c
 
 
+  Display Port MST Helper Functions Reference
+!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
+!Iinclude/drm/drm_dp_mst_helper.h
+!Edrivers/gpu/drm/drm_dp_mst_topology.c
+
+
   EDID Helper Functions Reference
 !Edrivers/gpu/drm/drm_edid.c
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 48e38ba..712b73e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o

 drm-usb-y   := drm_usb.o

-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o 
drm_dp_mst_topology.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
new file mode 100644
index 000..ca5c593
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -0,0 +1,2536 @@
+/*
+ * Copyright ? 2014 Red Hat
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/**
+ * DOC: dp mst helper
+ *
+ * These functions contain parts of the DisplayPort 1.2a MultiStream Transport
+ * protocol. The helpers contain a topology manager and bandwidth manager.
+ * The helpers 

[PATCH 05/10] drm: add a path blob property

[Dave Airlie]

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 changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8bf87a6..06b9255 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1165,6 +1165,7 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
 {
struct drm_property *edid;
struct drm_property *dpms;
+   struct drm_property *dev_path;

/*
 * Standard properties (apply to all connectors)
@@ -1179,6 +1180,12 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
   ARRAY_SIZE(drm_dpms_enum_list));
dev->mode_config.dpms_property = dpms;

+   dev_path = drm_property_create(dev,
+  DRM_MODE_PROP_BLOB |
+  DRM_MODE_PROP_IMMUTABLE,
+  "PATH", 0);
+   dev->mode_config.path_property = dev_path;
+
return 0;
 }

@@ -3637,6 +3644,25 @@ done:
return ret;
 }

+int drm_mode_connector_set_path_property(struct drm_connector *connector,
+char *path)
+{
+   struct drm_device *dev = connector->dev;
+   int ret, size;
+   size = strlen(path) + 1;
+
+   connector->path_blob_ptr = drm_property_create_blob(connector->dev,
+   size, path);
+   if (!connector->path_blob_ptr)
+   return -EINVAL;
+
+   ret = drm_object_property_set_value(>base,
+   dev->mode_config.path_property,
+   connector->path_blob_ptr->base.id);
+   return ret;
+}
+EXPORT_SYMBOL(drm_mode_connector_set_path_property);
+
 /**
  * drm_mode_connector_update_edid_property - update the edid property of a 
connector
  * @connector: drm connector
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 55bc523..e33959b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -500,6 +500,8 @@ struct drm_connector {
struct drm_property_blob *edid_blob_ptr;
struct drm_object_properties properties;

+   struct drm_property_blob *path_blob_ptr;
+
uint8_t polled; /* DRM_CONNECTOR_POLL_* */

/* requested DPMS state */
@@ -774,6 +776,7 @@ struct drm_mode_config {
struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
+   struct drm_property *path_property;
struct drm_property *plane_type_property;

/* DVI-I properties */
@@ -926,6 +929,8 @@ extern void drm_mode_config_init(struct drm_device *dev);
 extern void drm_mode_config_reset(struct drm_device *dev);
 extern void drm_mode_config_cleanup(struct drm_device *dev);

+extern int drm_mode_connector_set_path_property(struct drm_connector 
*connector,
+   char *path);
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);
 extern int drm_object_property_set_value(struct drm_mode_object *obj,
-- 
1.9.0

[PATCH 04/10] drm/crtc: add interface to reinitialise the legacy mode group

[Dave Airlie]

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/drivers/gpu/drm/drm_crtc.c
index f1753e6..8bf87a6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1421,6 +1421,15 @@ int drm_mode_group_init_legacy_group(struct drm_device 
*dev,
 }
 EXPORT_SYMBOL(drm_mode_group_init_legacy_group);

+void drm_reinit_primary_mode_group(struct drm_device *dev)
+{
+   drm_modeset_lock_all(dev);
+   drm_mode_group_destroy(>primary->mode_group);
+   drm_mode_group_init_legacy_group(dev, >primary->mode_group);
+   drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_reinit_primary_mode_group);
+
 /**
  * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
  * @out: drm_mode_modeinfo struct to return to the user
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c6b9e8a..55bc523 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -916,6 +916,7 @@ extern const char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
 extern void drm_mode_group_destroy(struct drm_mode_group *group);
+extern void drm_reinit_primary_mode_group(struct drm_device *dev);
 extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
-- 
1.9.0

[PATCH 03/10] drm/i915: add some registers need for displayport MST support.

[Dave Airlie]

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
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5386,6 +5386,7 @@ enum punit_power_well {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_BFI_ENABLE  (1<<4)

 /* DisplayPort Transport Control */
@@ -5395,6 +5396,7 @@ enum punit_power_well {
 #define  DP_TP_CTL_ENABLE  (1<<31)
 #define  DP_TP_CTL_MODE_SST(0<<27)
 #define  DP_TP_CTL_MODE_MST(1<<27)
+#define  DP_TP_CTL_FORCE_ACT   (1<<25)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1<<18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1<<15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7<<8)
@@ -5409,8 +5411,13 @@ enum punit_power_well {
 #define DP_TP_STATUS_A 0x64044
 #define DP_TP_STATUS_B 0x64144
 #define DP_TP_STATUS(port) _PORT(port, DP_TP_STATUS_A, DP_TP_STATUS_B)
-#define  DP_TP_STATUS_IDLE_DONE(1<<25)
-#define  DP_TP_STATUS_AUTOTRAIN_DONE   (1<<12)
+#define  DP_TP_STATUS_IDLE_DONE(1<<25)
+#define  DP_TP_STATUS_ACT_SENT (1<<24)
+#define  DP_TP_STATUS_MODE_STATUS_MST  (1<<23)
+#define  DP_TP_STATUS_AUTOTRAIN_DONE   (1<<12)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC2  (3 << 8)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC1  (3 << 4)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC0  (3 << 0)

 /* DDI Buffer Control */
 #define DDI_BUF_CTL_A  0x64000
-- 
1.9.0

[PATCH 02/10] drm: add DP MST encoder type

[Dave Airlie]

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 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -227,6 +227,7 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
+   { DRM_MODE_ENCODER_DPMST, "DP MST" },
 };

 static const struct drm_prop_enum_list drm_subpixel_enum_list[] =
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f104c26..719add4 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -181,6 +181,7 @@ struct drm_mode_get_plane_res {
 #define DRM_MODE_ENCODER_TVDAC 4
 #define DRM_MODE_ENCODER_VIRTUAL 5
 #define DRM_MODE_ENCODER_DSI   6
+#define DRM_MODE_ENCODER_DPMST 7

 struct drm_mode_get_encoder {
__u32 encoder_id;
-- 
1.9.0

[PATCH 01/10] drm/dp_helper: add defines for DP 1.2 and MST support.

[Dave Airlie]

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/drm_dp_helper.h
index cfcacec..879836d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -37,6 +37,7 @@
  * eDP: Embedded DisplayPort version 1
  * DPI: DisplayPort Interoperability Guideline v1.1a
  * 1.2: DisplayPort 1.2
+ * MST: Multistream Transport - part of DP 1.2a
  *
  * 1.2 formally includes both eDP and DPI definitions.
  */
@@ -103,9 +104,14 @@
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */

 /* Multiple stream transport */
+#define DP_FAUX_CAP0x020   /* 1.2 */
+# define DP_FAUX_CAP_1 (1 << 0)
+
 #define DP_MSTM_CAP0x021   /* 1.2 */
 # define DP_MST_CAP(1 << 0)

+#define DP_GUID0x030   /* 1.2 */
+
 #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
 # define DP_PSR_IS_SUPPORTED1
 #define DP_PSR_CAPS 0x071   /* XXX 1.2? */
@@ -221,6 +227,16 @@
 # define DP_PSR_CRC_VERIFICATION   (1 << 2)
 # define DP_PSR_FRAME_CAPTURE  (1 << 3)

+#define DP_ADAPTER_CTRL0x1a0
+# define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE   (1 << 0)
+
+#define DP_BRANCH_DEVICE_CTRL  0x1a1
+# define DP_BRANCH_DEVICE_IRQ_HPD  (1 << 0)
+
+#define DP_PAYLOAD_ALLOCATE_SET0x1c0
+#define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1
+#define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2
+
 #define DP_SINK_COUNT  0x200
 /* prior to 1.2 bit 7 was reserved mbz */
 # define DP_GET_SINK_COUNT(x)  x) & 0x80) >> 1) | ((x) & 0x3f))
@@ -230,6 +246,9 @@
 # define DP_REMOTE_CONTROL_COMMAND_PENDING  (1 << 0)
 # define DP_AUTOMATED_TEST_REQUEST (1 << 1)
 # define DP_CP_IRQ (1 << 2)
+# define DP_MCCS_IRQ   (1 << 3)
+# define DP_DOWN_REP_MSG_RDY   (1 << 4) /* DP MST */
+# define DP_UP_REQ_MSG_RDY (1 << 5) /* DP MST */
 # define DP_SINK_SPECIFIC_IRQ  (1 << 6)

 #define DP_LANE0_1_STATUS  0x202
@@ -294,6 +313,13 @@
 #define DP_TEST_SINK   0x270
 #define DP_TEST_SINK_START (1 << 0)

+#define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
+# define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
+# define DP_PAYLOAD_ACT_HANDLED (1 << 1)
+
+#define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1   /* 1.2 MST */
+/* up to ID_SLOT_63 at 0x2ff */
+
 #define DP_SOURCE_OUI  0x300
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
@@ -303,6 +329,21 @@
 # define DP_SET_POWER_D30x2
 # define DP_SET_POWER_MASK  0x3

+#define DP_SIDEBAND_MSG_DOWN_REQ_BASE  0x1000   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_UP_REP_BASE0x1200   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_DOWN_REP_BASE  0x1400   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_UP_REQ_BASE0x1600   /* 1.2 MST */
+
+#define DP_SINK_COUNT_ESI  0x2002   /* 1.2 */
+/* 0-5 sink count */
+# define DP_SINK_COUNT_CP_READY (1 << 6)
+
+#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0   0x2003   /* 1.2 */
+
+#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1   0x2004   /* 1.2 */
+
+#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
+
 #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
 # define DP_PSR_LINK_CRC_ERROR  (1 << 0)
 # define DP_PSR_RFB_STORAGE_ERROR   (1 << 1)
@@ -319,6 +360,43 @@
 # define DP_PSR_SINK_INTERNAL_ERROR 7
 # define DP_PSR_SINK_STATE_MASK 0x07

+/* DP 1.2 Sideband message defines */
+/* peer device type - DP 1.2a Table 2-92 */
+#define DP_PEER_DEVICE_NONE0x0
+#define DP_PEER_DEVICE_SOURCE_OR_SST   0x1
+#define DP_PEER_DEVICE_MST_BRANCHING   0x2
+#define DP_PEER_DEVICE_SST_SINK0x3
+#define DP_PEER_DEVICE_DP_LEGACY_CONV  0x4
+
+/* DP 1.2 MST sideband request names DP 1.2a Table 2-80 */
+#define DP_LINK_ADDRESS0x01
+#define DP_CONNECTION_STATUS_NOTIFY0x02
+#define DP_ENUM_PATH_RESOURCES 0x10
+#define DP_ALLOCATE_PAYLOAD0x11
+#define DP_QUERY_PAYLOAD   0x12
+#define DP_RESOURCE_STATUS_NOTIFY  0x13
+#define DP_CLEAR_PAYLOAD_ID_TABLE  0x14
+#define DP_REMOTE_DPCD_READ0x20
+#define DP_REMOTE_DPCD_WRITE   0x21
+#define DP_REMOTE_I2C_READ 0x22
+#define DP_REMOTE_I2C_WRITE0x23
+#define DP_POWER_UP_PHY0x24
+#define DP_POWER_DOWN_PHY  0x25
+#define 

[RFC] DisplayPort MST v0.3

[Dave Airlie]

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!
fix i915 problems with DPMS - ordering of link bring up.
aux channel locking - this should be pushed down I think into the aux helpers,

TODO:
fbcon support:
fix non 4 lane 5.4Ghz.
fix more of state checker harder.

Dave.

[PATCH] drm/qxl: return IRQ_NONE if it was not our irq

[Jason Wang]

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 kernel think it was handled but in fact it was
not.

Cc: Gerd Hoffmann 
Cc: stable at vger.kernel.org
Signed-off-by: Jason Wang 
---
 drivers/gpu/drm/qxl/qxl_irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
index 28f84b4..3485bdc 100644
--- a/drivers/gpu/drm/qxl/qxl_irq.c
+++ b/drivers/gpu/drm/qxl/qxl_irq.c
@@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg)

pending = xchg(>ram_header->int_pending, 0);

+   if (!pending)
+   return IRQ_NONE;
+
atomic_inc(>irq_received);

if (pending & QXL_INTERRUPT_DISPLAY) {
-- 
1.9.1

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Rafał Miłecki]

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 code as well.
>
> Looks like a valid cleanup to me. Should probably go into 3.16.

Thanks for review. Of course it's 3.16 material, no rush.

I'll re-send with Signed-off-by in a bigger patchset, after extra testing.

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Christian König]

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. Should probably go into 3.16.

Christian.

> ---
>   drivers/gpu/drm/radeon/Makefile  |   2 +-
>   drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 
> +++
>   drivers/gpu/drm/radeon/r600_hdmi.c   | 130 +
>   drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
>   drivers/gpu/drm/radeon/radeon_asic.h |   7 ++
>   5 files changed, 235 insertions(+), 127 deletions(-)
>   create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 0943353..dbcbfe8 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
>   radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
>   rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
>   r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
> - radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
> + radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
>   evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
>   evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
>   atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
> diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
> b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> new file mode 100644
> index 000..4e3a8b7
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> @@ -0,0 +1,221 @@
> +#include 
> +#include "radeon.h"
> +#include "radeon_asic.h"
> +#include "r600d.h"
> +
> +static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> +{
> + struct radeon_device *rdev = encoder->dev->dev_private;
> + struct drm_connector *connector;
> + struct radeon_connector *radeon_connector = NULL;
> + u32 tmp;
> + u8 *sadb;
> + int sad_count;
> +
> + list_for_each_entry(connector, 
> >dev->mode_config.connector_list, head) {
> + if (connector->encoder == encoder) {
> + radeon_connector = to_radeon_connector(connector);
> + break;
> + }
> + }
> +
> + if (!radeon_connector) {
> + DRM_ERROR("Couldn't find encoder's connector\n");
> + return;
> + }
> +
> + sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
> );
> + if (sad_count < 0) {
> + DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
> sad_count);
> + return;
> + }
> +
> + /* program the speaker allocation */
> + tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
> + tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
> + /* set HDMI mode */
> + tmp |= HDMI_CONNECTION;
> + if (sad_count)
> + tmp |= SPEAKER_ALLOCATION(sadb[0]);
> + else
> + tmp |= SPEAKER_ALLOCATION(5); /* stereo */
> + WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
> +
> + kfree(sadb);
> +}
> +
> +static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
> +{
> + struct radeon_device *rdev = encoder->dev->dev_private;
> + struct drm_connector *connector;
> + struct radeon_connector *radeon_connector = NULL;
> + struct cea_sad *sads;
> + int i, sad_count;
> +
> + static const u16 eld_reg_to_type[][2] = {
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
> HDMI_AUDIO_CODING_TYPE_PCM },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
> HDMI_AUDIO_CODING_TYPE_AC3 },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
> HDMI_AUDIO_CODING_TYPE_MPEG1 },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
> HDMI_AUDIO_CODING_TYPE_MP3 },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
> HDMI_AUDIO_CODING_TYPE_MPEG2 },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
> HDMI_AUDIO_CODING_TYPE_AAC_LC },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
> HDMI_AUDIO_CODING_TYPE_DTS },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
> HDMI_AUDIO_CODING_TYPE_ATRAC },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
> HDMI_AUDIO_CODING_TYPE_EAC3 },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
> HDMI_AUDIO_CODING_TYPE_DTS_HD },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
> HDMI_AUDIO_CODING_TYPE_MLP },
> + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, 
> HDMI_AUDIO_CODING_TYPE_WMA_PRO },
> + };
> +
> + list_for_each_entry(connector, 
> >dev->mode_config.connector_list, head) {
> + if 

[Bug 75841] radeon (radeonsi): GPU crash and resulting kernel problems (hangs etc.)

[bugzilla-dae...@bugzilla.kernel.org]

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 this mail because:
You are watching the assignee of the bug.

[Intel-gfx] Design review request: DRM color manager

[Sharma, Shashank]

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, driver-to-driver.
  For example, one of the Intel SOC support CSC correction, Gamma
correction, Hue and Saturation correction, Brightness and Contrast 
correction. One other Intel SOC supports two of above mentioned 
properties, and 2 other properties. Hardly any of these properties are 
exposed properly to userspace to be used to its real potential due to 
lack of proper interface.
3. Even if we go for a direct DRM property interface for each of the
correction possible, if some hardware supports 10 color correction
properties, a driver is supposed to create 10 DRM properties 
corresponding to each. But most of the time what these color correction 
properties do is, apply some correction values on some hardware 
registers, and enable / disable the property.
4. Color manager is the one common interface for all such properties
supported by all these drivers, which follows a particular protocol, 
to extract this color correction information from the userspace call, 
call the drivers apply method with all the required Information.

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 properties using the common 
protocol. One get call can tell what are the color correction 
capabilities of the SOC, registered by driver.
3. The corrections value range that can be covered using this can be
single valued to any no. We can apply from single values 
brightness/contrast to full range LUT of a gamma correction using the 
same interface.
4. Hardware specific quirks can be applied on specific corrections.
5. A few of color corrections(like gamma correction) deal with floating 
point values, which is not easy to handle in Kernel. We can always 
delegate this FP conversion work to some userspace library, and get the 
direct register values using the interface. This kind of library can be 
expanded for various facilities to provide color-support.

We have implemented color manager implementation for one of the MCG code 
line, and lot of commercial solutions are using those color properties 
using the simple interface for Brightness, CSC and Gamma correction, and 
fine tuning to the best display experience for their panel. This part 
was not very well used due to lack of proper interface.

I think this design will help us to expose color correction capabilities 
of various SOCs and drivers, and will give an centrally controlled 
interface for ease of access also.

Please let me know if this makes a point.

Regards
Shashank

On 5/12/2014 2:21 PM, Daniel Vetter wrote:
> 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 the properties we already have.
>
> What's the technical reasons for adding this interface? Your proposal
> is only describing how it works, so is lacking this crucial
> information.
> -Daniel
>
> On Wed, May 7, 2014 at 4:22 PM, Sharma, Shashank
>  wrote:
>> Hello all,
>>
>> As per previous discussions, I am sending the drm-color-manager design for
>> review, as inline text. Please have a look and let me know your feedback.
>>
>> (I tried hard to align the inline text diagram in mail, hope you can see the
>> proper picture too)
>>
>> =
>> DRM Color Manager
>> =
>>
>> - Color manager provides a common interface for all color correction /
>>enhancement properties supported by various hardwares.
>> - Color manager will be one Umbrella DRM property (blob type)
>> - Driver can register the color correction properties of its HW during
>>the init time, and all the corrections can be applied using the same
>>interface.
>>
>> How does a driver register color properties with DRM color manager:
>> ---
>>
>> - A DRM driver will call drm_register_color_manager() function with
>> following information:
>>  .prop_set_handler
>>  .prop_get_hanlder
>>  .color_prop_identifier structure
>>  {porp_name, prop_id}
>>  {porp_name, prop_id}
>>  {porp_name, prop_id}
>>
>> For example: I915 driver can register as:
>>  .prop_set_handler = intel_clrmgr_set()
>>  .prop_get_hanlder = intel_clrmgr_get()
>>  .color_prop_identifier structure
>>  {gamma_correction, 0}
>>  

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[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.
---
 drivers/gpu/drm/radeon/Makefile  |   2 +-
 drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 +++
 drivers/gpu/drm/radeon/r600_hdmi.c   | 130 +
 drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
 drivers/gpu/drm/radeon/radeon_asic.h |   7 ++
 5 files changed, 235 insertions(+), 127 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0943353..dbcbfe8 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
-   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
+   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
b/drivers/gpu/drm/radeon/dce3_1_afmt.c
new file mode 100644
index 000..4e3a8b7
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
@@ -0,0 +1,221 @@
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "r600d.h"
+
+static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   u32 tmp;
+   u8 *sadb;
+   int sad_count;
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's connector\n");
+   return;
+   }
+
+   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
);
+   if (sad_count < 0) {
+   DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", 
sad_count);
+   return;
+   }
+
+   /* program the speaker allocation */
+   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
+   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
+   /* set HDMI mode */
+   tmp |= HDMI_CONNECTION;
+   if (sad_count)
+   tmp |= SPEAKER_ALLOCATION(sadb[0]);
+   else
+   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
+   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
+
+   kfree(sadb);
+}
+
+static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct drm_connector *connector;
+   struct radeon_connector *radeon_connector = NULL;
+   struct cea_sad *sads;
+   int i, sad_count;
+
+   static const u16 eld_reg_to_type[][2] = {
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
HDMI_AUDIO_CODING_TYPE_PCM },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
HDMI_AUDIO_CODING_TYPE_AC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
HDMI_AUDIO_CODING_TYPE_MPEG1 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
HDMI_AUDIO_CODING_TYPE_MP3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
HDMI_AUDIO_CODING_TYPE_MPEG2 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
HDMI_AUDIO_CODING_TYPE_AAC_LC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
HDMI_AUDIO_CODING_TYPE_DTS },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
HDMI_AUDIO_CODING_TYPE_ATRAC },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
HDMI_AUDIO_CODING_TYPE_EAC3 },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
HDMI_AUDIO_CODING_TYPE_DTS_HD },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
HDMI_AUDIO_CODING_TYPE_MLP },
+   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, 
HDMI_AUDIO_CODING_TYPE_WMA_PRO },
+   };
+
+   list_for_each_entry(connector, 
>dev->mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   radeon_connector = to_radeon_connector(connector);
+   break;
+   }
+   }
+
+   if (!radeon_connector) {
+   DRM_ERROR("Couldn't find encoder's 

[PATCH 2/2] drm/radeon: fix buffer placement under memory pressure v2

[Christian König]

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 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 72705fb..4faa4d6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -458,7 +458,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
 * into account. We don't want to disallow buffer moves
 * completely.
 */
-   if (current_domain != RADEON_GEM_DOMAIN_CPU &&
+   if ((lobj->alt_domain & current_domain) != 0 &&
(domain & current_domain) == 0 && /* will be moved 
*/
bytes_moved > bytes_moved_threshold) {
/* don't move it */
-- 
1.9.1

[PATCH 1/2] drm/radeon: fix page directory update size estimation

[Christian König]

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/drivers/gpu/drm/radeon/radeon_vm.c
index 2aae6ce..d9ab99f 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -595,7 +595,7 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
ndw = 64;

/* assume the worst case */
-   ndw += vm->max_pde_used * 12;
+   ndw += vm->max_pde_used * 16;

/* update too big for an IB */
if (ndw > 0xf)
-- 
1.9.1

[PATCH] drm/radeon: add a i2c bus mutex

[Christian König]

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.15 queue.

Thanks,
Christian.

> ---
>   drivers/gpu/drm/radeon/atombios_dp.c  | 18 ++
>   drivers/gpu/drm/radeon/atombios_i2c.c | 17 +
>   drivers/gpu/drm/radeon/radeon_i2c.c   |  9 +
>   drivers/gpu/drm/radeon/radeon_mode.h  |  1 +
>   4 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 54e4f52..3bb0933 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -95,9 +95,12 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
> *chan,
>   int index = GetIndexIntoMasterTable(COMMAND, 
> ProcessAuxChannelTransaction);
>   unsigned char *base;
>   int recv_bytes;
> + int r = 0;
>   
>   memset(, 0, sizeof(args));
>   
> + mutex_lock(>mutex);
> +
>   base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1);
>   
>   radeon_atom_copy_swap(base, send, send_bytes, true);
> @@ -117,19 +120,22 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
> *chan,
>   /* timeout */
>   if (args.v1.ucReplyStatus == 1) {
>   DRM_DEBUG_KMS("dp_aux_ch timeout\n");
> - return -ETIMEDOUT;
> + r = -ETIMEDOUT;
> + goto done;
>   }
>   
>   /* flags not zero */
>   if (args.v1.ucReplyStatus == 2) {
>   DRM_DEBUG_KMS("dp_aux_ch flags not zero\n");
> - return -EBUSY;
> + r = -EBUSY;
> + goto done;
>   }
>   
>   /* error */
>   if (args.v1.ucReplyStatus == 3) {
>   DRM_DEBUG_KMS("dp_aux_ch error\n");
> - return -EIO;
> + r = -EIO;
> + goto done;
>   }
>   
>   recv_bytes = args.v1.ucDataOutLen;
> @@ -139,7 +145,11 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
> *chan,
>   if (recv && recv_size)
>   radeon_atom_copy_swap(recv, base + 16, recv_bytes, false);
>   
> - return recv_bytes;
> + r = recv_bytes;
> +done:
> + mutex_unlock(>mutex);
> +
> + return r;
>   }
>   
>   #define BARE_ADDRESS_SIZE 3
> diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c 
> b/drivers/gpu/drm/radeon/atombios_i2c.c
> index b5162c3..9c570fb 100644
> --- a/drivers/gpu/drm/radeon/atombios_i2c.c
> +++ b/drivers/gpu/drm/radeon/atombios_i2c.c
> @@ -43,15 +43,19 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan 
> *chan,
>   int index = GetIndexIntoMasterTable(COMMAND, 
> ProcessI2cChannelTransaction);
>   unsigned char *base;
>   u16 out = cpu_to_le16(0);
> + int r = 0;
>   
>   memset(, 0, sizeof(args));
>   
> + mutex_lock(>mutex);
> +
>   base = (unsigned char *)rdev->mode_info.atom_context->scratch;
>   
>   if (flags & HW_I2C_WRITE) {
>   if (num > ATOM_MAX_HW_I2C_WRITE) {
>   DRM_ERROR("hw i2c: tried to write too many bytes (%d vs 
> 3)\n", num);
> - return -EINVAL;
> + r = -EINVAL;
> + goto done;
>   }
>   if (buf == NULL)
>   args.ucRegIndex = 0;
> @@ -65,7 +69,8 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan 
> *chan,
>   } else {
>   if (num > ATOM_MAX_HW_I2C_READ) {
>   DRM_ERROR("hw i2c: tried to read too many bytes (%d vs 
> 255)\n", num);
> - return -EINVAL;
> + r = -EINVAL;
> + goto done;
>   }
>   args.ucRegIndex = 0;
>   args.lpI2CDataOut = 0;
> @@ -82,13 +87,17 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan 
> *chan,
>   /* error */
>   if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) {
>   DRM_DEBUG_KMS("hw_i2c error\n");
> - return -EIO;
> + r = -EIO;
> + goto done;
>   }
>   
>   if (!(flags & HW_I2C_WRITE))
>   radeon_atom_copy_swap(buf, base, num, false);
>   
> - return 0;
> +done:
> + mutex_unlock(>mutex);
> +
> + return r;
>   }
>   
>   int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap,
> diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c 
> b/drivers/gpu/drm/radeon/radeon_i2c.c
> index 7b94414..427ee4d 100644
> --- a/drivers/gpu/drm/radeon/radeon_i2c.c
> +++ b/drivers/gpu/drm/radeon/radeon_i2c.c
> @@ -94,6 +94,8 @@ static int pre_xfer(struct i2c_adapter *i2c_adap)
>   struct radeon_i2c_bus_rec *rec = >rec;
>   uint32_t temp;
>   
> + mutex_lock(>mutex);
> +
>   /* RV410 appears to have a bug where the hw i2c in reset
>* holds the i2c 

[Bug 71891] 3.13 fails to boot with the radeon module

[bugzilla-dae...@bugzilla.kernel.org]

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 would indeed explain the issue. AFAIK RV730
uses XTALIN directly for the UVD PLLs.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[RFC PATCH 1/2] drm/panel: add support for simple-panel description definition using DT

[Boris BREZILLON]

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/gpu/drm/panel/Kconfig|  1 +
>  drivers/gpu/drm/panel/panel-simple.c | 70 
> 
>  2 files changed, 71 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..4fe3d48 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_PANEL
>   bool
>   depends on DRM
> + select VIDEOMODE_HELPERS
>   help
> Panel registration and lookup framework.
>  
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 309f29e..fcf648d 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -33,6 +33,10 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  struct panel_desc {
>   const struct drm_display_mode *modes;
>   unsigned int num_modes;
> @@ -168,6 +172,61 @@ static const struct drm_panel_funcs panel_simple_funcs = 
> {
>   .get_modes = panel_simple_get_modes,
>  };
>  
> +static struct panel_desc *of_panel_desc_init(struct device *dev)
> +{
> + struct display_timings *timings;
> + struct panel_desc *desc;
> + u32 width, height;
> + int err;
> + int i;
> +
> + err = of_property_read_u32(dev->of_node, "width", );
> + if (err)
> + return ERR_PTR(err);
> +
> + err = of_property_read_u32(dev->of_node, "height", );
> + if (err)
> + return ERR_PTR(err);
> +
> + desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
> + if (!desc)
> + return ERR_PTR(-ENOMEM);
> +
> + timings = of_get_display_timings(dev->of_node);
> + if (timings) {
> + struct drm_display_mode *modes =
> + devm_kzalloc(dev,
> +  timings->num_timings *
> +  sizeof(*desc->modes),
> +  GFP_KERNEL);
> +
> + if (!modes)
> + return ERR_PTR(-ENOMEM);
> +
> + for (i = 0; i < timings->num_timings; i++) {
> + struct videomode vm;
> +
> + if (videomode_from_timings(timings, , i))
> + break;
> +
> + drm_display_mode_from_videomode(, modes + i);
> +
> + modes[i].type = DRM_MODE_TYPE_DRIVER;
> +
> + if (timings->native_mode == i)
> + modes[i].type |= DRM_MODE_TYPE_PREFERRED;
> + desc->num_modes++;
> + }

Oops, I forgot to add:
  desc->modes = modes;

> +
> + kfree(timings);
> + }
> +
> + desc->size.width = width;
> + desc->size.height = height;
> +
> + return desc;
> +}
> +
>  static int panel_simple_probe(struct device *dev, const struct panel_desc 
> *desc)
>  {
>   struct device_node *backlight, *ddc;
> @@ -178,6 +237,17 @@ static int panel_simple_probe(struct device *dev, const 
> struct panel_desc *desc)
>   if (!panel)
>   return -ENOMEM;
>  
> + if (!desc) {
> + desc = of_panel_desc_init(dev);
> + /*
> +  * Do not fail on DT panel desc retrieval error because
> +  * some systems do not need a panel description to work
> +  * properly.
> +  */
> + if (IS_ERR(desc))
> + desc = NULL;
> + }
> +
>   panel->enabled = false;
>   panel->desc = desc;
>  

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Bug 71891] 3.13 fails to boot with the radeon module

[bugzilla-dae...@bugzilla.kernel.org]

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/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index fef3107..bda9137 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1594,6 +1594,9 @@ static void rv770_gpu_init(struct radeon_device *rdev)
WREG32(PA_CL_ENHANCE, (CLIP_VTX_REORDER_ENA |
  NUM_CLIP_SEQ(3)));
WREG32(VC_ENHANCE, 0);
+
+   DRM_INFO("ref: %u, xclk: %u\n",
+rdev->clock.spll.reference_freq, rv770_get_xclk(rdev));
 }

 void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

OMAPDSS: omap5 SYNC_LOST error with DPI/LCD

[Tomi Valkeinen]

On 12/05/14 14:33, Vikas Patil wrote:
> Hi,
> 
> Re-posting as previous posting was rejected due to length.
> 
> Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI
> conversion.
> I have build the driver for it from
> https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c.
> Is this the correct driver for it?

That driver cannot be used with omapdrm, which uses omapdss. There's no
TDF19988 driver for omapdss (at least in the mainline), so you need to
write one.

> Also I am trying to use the generic-dpi-panel driver for this with
> OMAP5. It seems I also need to add support for TDF19988 somewhere in
> omapdrm or lcd/panel driver by calling drm_i2c_encoder_init to
> initialize it. Can I use somecode from ticldc driver or driver itself?
> Could you please give some inputs, how should I proceed further to
> adding support for TDF19988 for which the input is coming from DPI
> interface?

You need to write a driver for it. Something similar to
drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c, except tfp410
is quite simple one.

But I think you said you're based on some old customized kernel, so 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 --
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>

CIK hangs with kernel 3.15, bisected

[Christian König]

I could reproduce the problem with xonotic and I think I've found the issue.

Please test the attached patch.

Thanks,
Christian.

Am 11.05.2014 11:06, schrieb Christian K?nig:
>> I have tested it and it doesn't fix the hangs.
> Yeah, thought so. Well it was just a guess.
>
>> (Also, I don't like the patch, because it reverts the behavior I added
>> for userspace buffers.)
> Actually it shouldn't affect that. The alternative domain always 
> contains GART even when userspace only specified VRAM as placement (as 
> long as it is technical possible to do so).
>
> So what should happen is that TTM sees the current placement, matches 
> that with the desired placement and should find that it doesn't need 
> to move the buffer (we should just test if this behavior really works 
> as expected).
>
> Christian.
>
> Am 10.05.2014 23:38, schrieb Marek Ol??k:
>> Hi Christian,
>>
>> I have tested it and it doesn't fix the hangs.
>>
>> (Also, I don't like the patch, because it reverts the behavior I added
>> for userspace buffers.)
>>
>> Marek
>>
>>
>>
>> On Sat, May 10, 2014 at 6:34 PM, Christian K?nig
>>  wrote:
>>> Couldn't reproduce the issue so far. So the attached patch is just a
>>> complete shoot into the dark found by rereading the code, but it might
>>> actually be the problem.
>>>
>>> Please give it a try.
>>>
>>> Going to keep testing in the meantime,
>>> Christian.
>>>
>>> Am 10.05.2014 10:23, schrieb Christian K?nig:
>>>
>>>>> 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.
>>>> Sounds like the same issue to me. Thx for the good test case.
>>>>
>>>>> Any idea what is wrong with it?
>>>> Actually I already wondered that it went so smooth without any 
>>>> regression
>>>> so far, didn't noticed the bug in bugzilla.kernel.org yet.
>>>>
>>>>> 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.
>>>> Sounds like the underlying problem to me. We probably evict some 
>>>> part of a
>>>> page table without updating the page directory. Going to dig into 
>>>> it today,
>>>> it's probably just a one liner missing somewhere in the VM code.
>>>>
>>>> Christian.
>>>>
>>>> Am 09.05.2014 23:39, schrieb Grigori Goronzy:
>>>>> On 09.05.2014 20:03, Marek Ol??k wrote:
>>>>>>
>>>>>> This commit which first appeared in 3.15-rc1 causes hangs on 
>>>>>> 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>

[Bug 78366] [r600g] Memory leak desktop usage RV770 (HD4850) with 10.1.2 (related to not using LLVM anymore)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78366

--- Comment #3 from Alex Deucher  ---
(In reply to comment #2)
> 
> Apparently, memory is recovered by closing Firefox. Top doesn't show it
> using that much memory, but it somehow does in less traceable ways.

Server side resources:
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>

[Bug 74551] Unable to enable ACPI

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=74551

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #2 from Alex Deucher  ---
(In reply to maxis11 from comment #1)
> acer aspire 5560g has problem with gpt, so I convert using gdisk gpt to mbr,
> and problem seems fixed. But there is another problem, computer freezes
> during boot with radeon.runpm=1. Should I create another bug report?

Is that still and issue with a 3.15 kernel?  I believe that should be fixed now
(with patches destined for stable as well).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75951] Radeon HD, GPU CP Stall on "Octodad - Dadliest catch"

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75951

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
This is a mesa bug rather than a kernel bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75784

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

OMAPDSS: omap5 SYNC_LOST error with DPI/LCD

[Tomi Valkeinen]

Well, there's at least a bit in the dss that needs to be configured for
DPI to be routed correctly. Commit
de09e492986219132b518c3f7834a28823cd in the mainline does that.

Then, if using DSI PLL, the clock routing needs to be fixed for OMAP5,
mainline commit f8ad984ce0372f43006f5c700310c2d6f301085d does that.

I'm not sure if there are any other OMAP5 DPI specific things, those are
the ones I remember.

 Tomi

On 12/05/14 11:41, Vikas Patil wrote:
> Hi Tomi,
> 
> How could I confirm for OMAP5 DPI support apart form enabling
> CONFIG_OMAP2_DSS_DPI and CONFIG_PANEL_GENERIC_DPI? Enabling mentioned
> config builds components from Kernel\drivers\video\omap2\dss and
> kernel\drivers\video\omap2\displays only.  Is there any support needs to
> be available under kernel\arch\arm\mach-omap2?
> 
> Regards,
> Vikash
> 
> 
> On Fri, May 9, 2014 at 4:49 PM, Tomi Valkeinen  <mailto:tomi.valkeinen at ti.com>> wrote:
> 
> On 08/05/14 13:07, Vikas Patil wrote:
> > Hi,
> >
> > I am working on to enable the second display output for customized
> OMAP5
> > based platform and linux 3.4.25. First display which is HDMI/tv is
> > working fine. Second display out is coming via DPI interface. To
> enable
> > DPI interface I enabled CONFIG_OMAP2_DSS_DPI and
> > CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and
> > omap_dss_board_info and removed the HDMI device and disabled
> > CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting correctly,
> > however when I try to run kmscube app and it seems to be running,
> > noticing following error and till now 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 --
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>

[Bug 74751] resume from suspend broken with 3.15-rc1 and rc2 kernels

[bugzilla-dae...@bugzilla.kernel.org]

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.

[Bug 74751] resume from suspend broken with 3.15-rc1 and rc2 kernels

[bugzilla-dae...@bugzilla.kernel.org]

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.

OMAPDSS: omap5 SYNC_LOST error with DPI/LCD

[Vikas Patil]

Hi Tomi,

How could I confirm for OMAP5 DPI support apart form enabling
CONFIG_OMAP2_DSS_DPI and CONFIG_PANEL_GENERIC_DPI? Enabling mentioned
config builds components from Kernel\drivers\video\omap2\dss and
kernel\drivers\video\omap2\displays only.  Is there any support needs to be
available under kernel\arch\arm\mach-omap2?

Regards,
Vikash


On Fri, May 9, 2014 at 4:49 PM, Tomi Valkeinen wrote:

> On 08/05/14 13:07, Vikas Patil wrote:
> > Hi,
> >
> > I am working on to enable the second display output for customized OMAP5
> > based platform and linux 3.4.25. First display which is HDMI/tv is
> > working fine. Second display out is coming via DPI interface. To enable
> > DPI interface I enabled CONFIG_OMAP2_DSS_DPI and
> > CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and
> > omap_dss_board_info and removed the HDMI device and disabled
> > CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting correctly,
> > however when I try to run kmscube app and it seems to be running,
> > noticing following error and till now 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/6f567d1f/attachment.html>

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Alex Deucher]

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 will
>>> allow use to use rv770d.h header in the future and adjust code as well.
>>
>> Any reason not to split it at DCE3.2 rather than 3.1?  It seems like
>> most (all?) of the changes are DCE3.2 specific rather than DCE3.1.
>> Otherwise, seems fine to me.
>
> I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed
> in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The
> biggest difference is that DCE 3.1 doesn't seem to have
> AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0.
>
> Take a look at defines for DCE 3.2. Even they are placed in rv770d.h,
> which is the DCE 3.1 chipset.

Well, they were placed in there since rv770d.h was used by all r7xx
asics which is a mix of DCE3.1 and 3.2.  As far as I recall, 3.1 is
pretty much the same as 3.0 from a programming perspective, but it's
been a while since I looked at it in detail.  The current hdmi code
doesn't seem to have any DCE3.1 specific code at the moment.

Alex

[Bug 78287] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78287

--- Comment #4 from Alex Deucher  ---
In this actually a failure to allocate regular system memory (kalloc or
drm_malloc_ab).

-- 
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/d91fb3de/attachment.html>

[Intel-gfx] Design review request: DRM color manager

[David Herrmann]

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 properties using the common
> protocol. One get call can tell what are the color correction capabilities
> of the SOC, registered by driver.

What's the advantage of that? We should add a
DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things,
instead of adding huge payloads.

I really think we should define one property for each color-correction
interface. I cannot see any downside of that except that we should add
DRM_MODE_OBJ_SET_PROPERTIES. But afaik that's already the plan for
atomic-modesetting, right?

Thanks
David

[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75651

William Shuman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected

[bugzilla-dae...@bugzilla.kernel.org]

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.

[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected

[bugzilla-dae...@bugzilla.kernel.org]

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.

[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75651

Christian K?nig  changed:

   What|Removed |Added

 Attachment #135731|0   |1
is obsolete||

--- Comment #7 from Christian K?nig  ---
Created attachment 135881
  --> https://bugzilla.kernel.org/attachment.cgi?id=135881=edit
Possible fix.

Please try this one instead. It fixes an issue with the commit mentioned, so it
might fix this one as well.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[RFC V2 0/3] drm/bridge: panel and chaining

[Sean Paul]

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, Andrzej Hajda  
> wrote:
>> On 05/05/2014 09:52 PM, Ajay Kumar wrote:
>>> This patchset is based on exynos-drm-next-todo branch of Inki Dae's 
>>> tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have just put up Rob's and Sean's idea of chaining up the bridges
>>> in code, and have implemented basic panel controls as a chained bridge.
>>> This works well with ptn3460 bridge chip on exynos5250-snow board.
>>>
>>> Still need to make use of standard list calls and figure out proper way
>>> of deleting the bridge chain. So, this is just a rough version.
>> As I understand this patchset tries to solve two things:
>> 1. Implement panel as drm_bridge, to ease support for hardware chains:
>> Crtc -> Encoder -> Bridge -> Panel
>> 2. Add support to drm_bridge chaining, to allow software chains:
>> drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel
>>
>> It is done using Russian doll schema, ops from the bridge calls the same
>> ops from the next bridge and the next bridge ops can do the same.
>>
>> This schema means that all the bridges including the last one are seen
>> from the drm core point of view as a one big drm_bridge. Additionally in
>> this particular case, the first bridge (ptn3460) implements connector
>> so it is hard to guess what is the location of the 2nd bridge in video
>> stream chain, sometimes it is after the connector, sometimes before.
>> All this is quite confusing.
>>
>> But if you look at the bridge from upstream video interface point of
>> view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its
>> video input side acts as a panel. On the output side it expects a panel,
>> lvds panel in this case.
> tbh, this is mostly about what we call it.  Perhaps "bridge" isn't the
> best name.. I wouldn't object to changing it.
>
> But my thinking was to leave in drm_panel_funcs things that are just
> needed by the connector (get_modes().. and maybe some day we need
> detect/etc).  Then leave everything else in drm_bridge_funcs.  A panel
> could (if needed) implement both interfaces.
>
> That is basically the same as what you are proposing, but without
> renaming bridge to panel ;-)
 Good to hear that. However there are points which are not clear for me.
 But first lets clarify names, I will use panel and bridge words
 to describe the hardware, and drm_panel, drm_bridge to describe the
 software interfaces.

 What bothers me:
 1. You want to leave connector related callbacks in drm_panel and
 the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460
 must implement connector internally because of this limitation. I guess
 it is quite typical bridge. This problem does not exists in case
 of using drm_panel for ptn3460.

 2. drm_bridge is attached to the encoder, this and the callback order
 suggests the video data flow should be as below:
 drm_crtc -> drm_encoder [-> drm_bridge] -> drm_connector [-> drm_panel]

 ptn3460 implements drm_bridge and drm_connector so it suggests its
 drm_bridge should be the last one, so there should be no place to add
 lvds panel implemented as a drm_bridge after it, as it is done in this
 patchset.

 Additionally it clearly shows that there should be two categories of
 drm_bridges - non-terminal and terminal.

 3. drm_dev uses all-or-nothing approach, ie. it will start only when all
 its components are up. It simplifies synchronization but is quite
 fragile - the whole drm will be down due to error in some of its 
 components.
 For this reason I prefer drm_panel as it is not real drm component
 it can be attached/detached to/from drm_connector anytime. I am not
 really sure but drm_bridge does not allow for that.
>>> So I do think we need to stick to this all-or-nothing approach for
>>> anything that is visible to userspace
>>> (drm_{plane,crtc,encoder,connector}).  We don't currently have a way
>>> to "hotplug" those so I don't see a real smooth upgrade path to add
>>> that in a backwards compatible way that won't cause problems with old
>>> userspace.
>>>
>>> But, that said, we have more flexibility with things not visible to
>>> userspace (drm_{panel,bridge}).  I'm not sure how much we want to
>>> allow things to be completely dynamic (we already have some hard
>>> enough locking fun).  But proposals/rfcs/etc welcome.
>>>
>>> I guess I'm not completely familiar w/ ptn3460, but the fact that it
>>> needs to 

[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw

[Alex Deucher]

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 at DCE3.2 rather than 3.1?  It seems like
most (all?) of the changes are DCE3.2 specific rather than DCE3.1.
Otherwise, seems fine to me.

Alex

> ---
>  drivers/gpu/drm/radeon/Makefile  |   2 +-
>  drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 
> +++
>  drivers/gpu/drm/radeon/r600_hdmi.c   | 130 +
>  drivers/gpu/drm/radeon/radeon_asic.c |   2 +-
>  drivers/gpu/drm/radeon/radeon_asic.h |   7 ++
>  5 files changed, 235 insertions(+), 127 deletions(-)
>  create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 0943353..dbcbfe8 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
> rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
> r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
> -   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
> +   radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \
> evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
> evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
> atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o 
> si.o \
> diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c 
> b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> new file mode 100644
> index 000..4e3a8b7
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> @@ -0,0 +1,221 @@
> +#include 
> +#include "radeon.h"
> +#include "radeon_asic.h"
> +#include "r600d.h"
> +
> +static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> +{
> +   struct radeon_device *rdev = encoder->dev->dev_private;
> +   struct drm_connector *connector;
> +   struct radeon_connector *radeon_connector = NULL;
> +   u32 tmp;
> +   u8 *sadb;
> +   int sad_count;
> +
> +   list_for_each_entry(connector, 
> >dev->mode_config.connector_list, head) {
> +   if (connector->encoder == encoder) {
> +   radeon_connector = to_radeon_connector(connector);
> +   break;
> +   }
> +   }
> +
> +   if (!radeon_connector) {
> +   DRM_ERROR("Couldn't find encoder's connector\n");
> +   return;
> +   }
> +
> +   sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, 
> );
> +   if (sad_count < 0) {
> +   DRM_ERROR("Couldn't read Speaker Allocation Data Block: 
> %d\n", sad_count);
> +   return;
> +   }
> +
> +   /* program the speaker allocation */
> +   tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER);
> +   tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK);
> +   /* set HDMI mode */
> +   tmp |= HDMI_CONNECTION;
> +   if (sad_count)
> +   tmp |= SPEAKER_ALLOCATION(sadb[0]);
> +   else
> +   tmp |= SPEAKER_ALLOCATION(5); /* stereo */
> +   WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp);
> +
> +   kfree(sadb);
> +}
> +
> +static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
> +{
> +   struct radeon_device *rdev = encoder->dev->dev_private;
> +   struct drm_connector *connector;
> +   struct radeon_connector *radeon_connector = NULL;
> +   struct cea_sad *sads;
> +   int i, sad_count;
> +
> +   static const u16 eld_reg_to_type[][2] = {
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, 
> HDMI_AUDIO_CODING_TYPE_PCM },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, 
> HDMI_AUDIO_CODING_TYPE_AC3 },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, 
> HDMI_AUDIO_CODING_TYPE_MPEG1 },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, 
> HDMI_AUDIO_CODING_TYPE_MP3 },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, 
> HDMI_AUDIO_CODING_TYPE_MPEG2 },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, 
> HDMI_AUDIO_CODING_TYPE_AAC_LC },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, 
> HDMI_AUDIO_CODING_TYPE_DTS },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, 
> HDMI_AUDIO_CODING_TYPE_ATRAC },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, 
> HDMI_AUDIO_CODING_TYPE_EAC3 },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, 
> HDMI_AUDIO_CODING_TYPE_DTS_HD },
> +   { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, 
> HDMI_AUDIO_CODING_TYPE_MLP },
> +

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Sagar Arun Kamble]

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 understood and being comfortable with HTML row/table
manipulation).

Adding description of each property in their source might be time
consuming task.

thanks,
Sagar


On Sat, 2014-05-10 at 06:56 -0400, Rob Clark wrote:
> On Sat, May 10, 2014 at 6:39 AM, Ville Syrj?l?
>  wrote:
> > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote:
> >> Hi Sagar,
> >>
> >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote:
> >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote:
> >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote:
> >> > > > On Wed, Mar 5, 2014 at 11:56 AM,   
> >> > > > wrote:
> >> > > > > +
> >> > > > > +
> >> > > > > +
> >> > > > > +Owner Module/Drivers
> >> > > > > +Group
> >> > > > > +Property Object
> >> > > > > +Property Name
> >> > > > > +Type
> >> > > > > +Property Values
> >> > > > > +Object attached
> >> > > > > +Description
> >> > > > > +
> >> > > >
> >> > > > In my opinion this is a horrible way to write property documentations
> >> > > > - explicitly constructing html tables is error prone and really hard
> >> > > > to read in the source. Imo docbook in general is rather horrible,
> >> > > > which is way I write almost all my docs as kerneldoc ;-)
> >> > > >
> >> > > > I think a simple asciidoc/markdown would be much simpler, with a bit
> >> > > > of free-form structure to group properties into relevant groups.
> >> > > > Long-term we might even need to split it up into different spec files
> >> > > > to keep a good overview.
> >> > >
> >> > > Docbook is indeed hard to read and write when it comes to such tables.
> >> > > However I like having the properties documented in the DRM core
> >> > > documentation. Maybe we could come up with a simpler text format that
> >> > > would be transformed into docbook when compiling the documentation ?
> >> >
> >> > Does this mean we need to create comment block with "Doc: drm
> >> > properties" style section in each driver where drm properties are
> >> > instantiated. And then in drm.tmpl collect all these using !P escape
> >> > sequence?
> >> > How do create table out of these across all drivers?
> >>
> >> I don't have a strong preference here. Documenting properties in source 
> >> code
> >> comments would be fine, so would an external central documentation file in 
> >> a
> >> non Docbook format. For the record I'm personally fine with using Docbook 
> >> as
> >> in this patch :-)
> >>
> >> 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 needs to be done?
> >
> > The reason why I want a central place for the documentation is to force
> > people to collaborate outside their own sandbox when adding properties.
> > Whether that's docbook or some text file I don't care so much at this
> > point. The fact that it's a central place should mandate that the
> > patches changing it will go through dri-devel and so everyone should se
> > them, and when adding new properties it would make the patch author more
> > likely to look around a bit before adding another slighty incompatible
> > version of the same property. If someone has a better suggestion how to
> > encforce this I'm all ears.
> >
> > Of course this idea can still fail if our esteemed maintainer merges
> > stuff without checking for violations of this policy. Dave, any thoughts
> > on the subject?
> >
> > Either way I can tell you that I'm not very enthusiastic about reviewing
> > any property patches until some kind of decision about this is reached,
> > be it "docbook", "text", "plan c", or "fuck it, let the world burn!".
> 
> any of the first three options would be vastly superior to what we do now
> 
> tbh, I'd suggest imposing a no-new-properties-without-docs rule even
> if we haven't finished bikeshedding about the docs format.  That might
> motivate someone to hurry up and just pick one.
> 
> We can change the format, figure out some way to get it into docbook,
> etc, later.. it's not such a huge volume of words we have to type here
> that we can't reformat it later.
> 
> BR,
> -R
> 
> 
> >
> > --
> > Ville Syrj?l?
> > Intel OTC
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: fix page directory update size estimation

[Alex Deucher]

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/radeon_vm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index 2aae6ce..d9ab99f 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -595,7 +595,7 @@ int radeon_vm_update_page_directory(struct radeon_device 
> *rdev,
> ndw = 64;
>
> /* assume the worst case */
> -   ndw += vm->max_pde_used * 12;
> +   ndw += vm->max_pde_used * 16;
>
> /* update too big for an IB */
> if (ndw > 0xf)
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Randy Dunlap]

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 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 needs to be done?
>
> The reason why I want a central place for the documentation is to force
> people to collaborate outside their own sandbox when adding properties.
> Whether that's docbook or some text file I don't care so much at this
> point. The fact that it's a central place should mandate that the
> patches changing it will go through dri-devel and so everyone should se
> them, and when adding new properties it would make the patch author more
> likely to look around a bit before adding another slighty incompatible
> version of the same property. If someone has a better suggestion how to
> encforce this I'm all ears.
>
> Of course this idea can still fail if our esteemed maintainer merges
> stuff without checking for violations of this policy. Dave, any thoughts
> on the subject?

 Yeah I'm happy to block merging stuff, if we can spot new properties
 when stuff is posted on dri-devel, so much the better,

 most drivers still send everything via dri-devel anyways, its only
 really Intel I have to worry about so far,
>>>
>>> I'll enforce that all prop stuff gets cc: dri-devel and that it has
>>> updates for the prop docs.
>>>
 But we should definitely add it to the new driver review checklist as well.

 I'm also on the side of this patch is ugly and makes my eyes burn,
 please please get a plan to use something else ASAP, I'm willing to
 merge this but I'm tempted to give it a lifetime of a kernel or two
 before I burn it.
>>>
>>> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
>>> find someone to do it for me internally ;-)
>>> -Daniel
>>>
>>
>> I certainly have no objections to making kerneldoc suck less.
>> There was already an attempt to use asciidoc (like git uses) for kernel-doc
>> (a few years ago, by Sam Ravnborg).  I support(ed) that effort.
> 
> Hm, do you have pointers to those? My google-fu seems lacking ...

I googled for /kernel doc asciidoc ravnborg/ and found several hits for them.

> Ok, let's move this to the top and start discussions. The past few months
> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
> sections are really useful to pull all the actual documentation out of the
> docbook xml into kerneldoc.
> 
> But I've also done piles of docs for intel-gpu-tools, which is using
> gtkdoc. And there are some clear deficiencies:
> 
> - No markdown for inline coments. Lack of lists and tables is hurting
>   especially badly. If we add this (and I don't care one iota whether it's

Yes, I've tried to add lists to kernel-doc notation but have failed so far.

>   markdown or asciidoc or something else as long as it's readable plain
>   text in comments) we should be able to move all the existing docbook xml
>   paragraphs/lists/tables into kerneldoc comments.
> 
> - Automatic cross-referencing of functions. If you place e.g. function()
>   or #struct anywhere in a documentation comment gtk-doc automatically
>   inserts a hyperlink to the relevant documentation page across the entire
>   project. Really powerful and makes overview sections much more useful
>   entry points for beginners since they can easily jump back
>   betweeen the high-level overview and low-level per-function
>   documentation.
> 

That's a nice-to-have IMO, but a really nice one.

> - In a really perfect world it would help if kerneldoc could collect
>   structure member kerneldoc from per-member comments. Especially for
>   large structures with lots of comments this would bring the kerneldoc
>   and struct member much closer together.
> 
> So that's my wishlist.
>  
>> OTOH, I would only want to add another way to do kernel-doc if it can be a
>> full replacement for all of our docbook usage, i.e., it should provide a
>> way that we can eliminate docbook and stop using it completely.
> 
> Hm, I don't mind docbook at all, as long as all the real content is
> embedded into source files as kerneldoc and the docbook template just
> pulls in all the right bits and pieces. Even gtkdoc allos you to do that
> and pull in the different libararies (== header files with declarations
> for C) in the order you want. So imo the docbook toolchain is good enough
> for my needs.
> 
> Or what do you mean by getting rid of all docbook usage?

I meant 

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Daniel Vetter]

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 
> >> possible.
> >
> > Can comeone pick up the ball here and figure out what needs to be done?
> >
> > The reason why I want a central place for the documentation is to force
> > people to collaborate outside their own sandbox when adding properties.
> > Whether that's docbook or some text file I don't care so much at this
> > point. The fact that it's a central place should mandate that the
> > patches changing it will go through dri-devel and so everyone should se
> > them, and when adding new properties it would make the patch author more
> > likely to look around a bit before adding another slighty incompatible
> > version of the same property. If someone has a better suggestion how to
> > encforce this I'm all ears.
> >
> > Of course this idea can still fail if our esteemed maintainer merges
> > stuff without checking for violations of this policy. Dave, any thoughts
> > on the subject?
> 
> Yeah I'm happy to block merging stuff, if we can spot new properties
> when stuff is posted on dri-devel, so much the better,
> 
> most drivers still send everything via dri-devel anyways, its only
> really Intel I have to worry about so far,

I'll enforce that all prop stuff gets cc: dri-devel and that it has
updates for the prop docs.

> But we should definitely add it to the new driver review checklist as well.
> 
> I'm also on the side of this patch is ugly and makes my eyes burn,
> please please get a plan to use something else ASAP, I'm willing to
> merge this but I'm tempted to give it a lifetime of a kernel or two
> before I burn it.

Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
find someone to do it for me internally ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 66281] DRI_PRIME=1 glxinfo crashes and causes session to restart

[bugzilla-dae...@bugzilla.kernel.org]

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 my
> > > kernel. (Sorry, but I am a newbie to Linux).
> > 
> > If you have your .config (which, depending on options, may be visible from
> > /proc/config.gz), you can look for
> > 
> > CONFIG_VGA_SWITCHEROO
> > CONFIG_PM_RUNTIME
> > 
> > Make sure both of those are set to 'y'. (This is only for optimus-type
> > systems, of which I'm assuming yours is one.)
> > 
> 
> There is no config.gz file in my system. I have tried using "locate" as
> well. Is there some other way I can find this out.

http://nouveau.freedesktop.org/wiki/Optimus/

Check

/sys/kernel/debug/vgaswitcheroo/switch
/sys/class/drm/card1/power/runtime_status

If both files are there, that means that you have both of those options.
Further you can check dmesg for references to 'optimus'.

> 
> > 
> > xf86-video-nouveau is the xorg ddx which interacts with the kernel driver.
> > In some distros, for maximal confusion, it is called something else, like
> > xorg-xserver-video-nouveau or something like that (don't have the exact
> > name, sorry).
> 
> Can you please tell me how to find out (or search) if this is the case. Even
> if you can tell me where and how to look for, I will follow.

A quick way to find out the version of xf86-video-nouveau is to look in your
Xorg.0.log file (often located in /var/log). There should be a section like

[ 7.016] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[ 7.019] (II) Module nouveau: vendor="X.Org Foundation"
[ 7.019]compiled for 1.15.0, module version = 1.0.10
[ 7.019]Module class: X.Org Video Driver
[ 7.019]ABI class: X.Org Video Driver, version 15.0

Note the "module version". Make sure yours is 1.0.10. Earlier versions did not
support GK208.

> > 
> > > Actually I am working on some OpenGL/GLSL projects, for which I need GLSL
> > > 4.3, which I believe is still not available in nouveau driver. I was 
> > > looking
> > > forward to be able to install the latest NVIDIA drivers. Will mesa 
> > > 10,2-rcl
> > > solve this issue? Can you please recommend any other solution.
> 
> The latest mesa based DRI drivers through yum is listed as 10.1.1. Will it
> work?

A large number of shader opcode generation issues for GK110/GK208 are fixed in
the 10.2 release. 10.1.x will work enough for like glxgears though. The final
10.2 release should be out on May 30 or so, dunno how long it takes to get into
distros though.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] Design review request: DRM color manager

[Daniel Vetter]

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 the properties we already have.

What's the technical reasons for adding this interface? Your proposal
is only describing how it works, so is lacking this crucial
information.
-Daniel

On Wed, May 7, 2014 at 4:22 PM, Sharma, Shashank
 wrote:
> Hello all,
>
> As per previous discussions, I am sending the drm-color-manager design for
> review, as inline text. Please have a look and let me know your feedback.
>
> (I tried hard to align the inline text diagram in mail, hope you can see the
> proper picture too)
>
> =
> DRM Color Manager
> =
>
> - Color manager provides a common interface for all color correction /
>   enhancement properties supported by various hardwares.
> - Color manager will be one Umbrella DRM property (blob type)
> - Driver can register the color correction properties of its HW during
>   the init time, and all the corrections can be applied using the same
>   interface.
>
> How does a driver register color properties with DRM color manager:
> ---
>
> - A DRM driver will call drm_register_color_manager() function with
> following information:
> .prop_set_handler
> .prop_get_hanlder
> .color_prop_identifier structure
> {porp_name, prop_id}
> {porp_name, prop_id}
> {porp_name, prop_id}
>
> For example: I915 driver can register as:
> .prop_set_handler = intel_clrmgr_set()
> .prop_get_hanlder = intel_clrmgr_get()
> .color_prop_identifier structure
> {gamma_correction, 0}
> {csc_correction, 1}
> {hue_saturation, 2}
>
>
>
> How will color_manager_set/get() functions work:
> -
>
> Color EDID:
>   ==
> || property || Enable/  || Pipe/Plane/  || No of||
> ||  ID  || Disable  || Identifier   || Data bytes   ||data..
> || <1 Byte> || <1 Byte> || <1 Byte> || <1 Byte> ||
> ==
>
> - Color EDID is a protocol to extract the color correction
>   characterictics from a blob, coming from DRM layer
>   as property_set_blob() or loading a blob for property_get_blob()
>
> - Userspace will load this blob with corresponding values and use the
>   drm_set_blob(color-manager) interface.
> - DRM layer of get/set_color_manager() will validate the entry, extract
>   the following information from blob
> - property
> - enable/disable
> - identifier
> - ptr to start of raw data
> - With this information, drm_get/set_color_manager() layer will call
>   driver's .get/set_handler()
>   which will do the correction using those values.
> - Based on the driver's requirement, user space can send any type of
>   values in byte stream, like
>   direct reg values, correction coefficients or any other form of data.
>
> Benefits of this common interface:
> --
> - Single interface for all color properties. No need to create multiple
>   properties.
> - HW agonist. Its in hands of driver to register the properties.
> - Any no of properties can be registered.
> - Can be clubbed with modeset implementations.
>
>
>
>
> Regards
> Shashank
>
> On 5/7/2014 7:41 PM, Sharma, Shashank wrote:
>>
>> FYI
>>
>>
>> -Original Message-
>> From: Sharma, Shashank
>> Sent: Tuesday, April 22, 2014 8:32 PM
>> To: Daniel Vetter
>> Cc: David Herrmann; intel-gfx at lists.freedesktop.org; Cn, Ramakrishnan;
>> Jindal, Sonika; Shankar, Uma
>> Subject: RE: [Intel-gfx] Design review request: DRM color manager
>>
>> David,
>> My apologies for starting a pre-mature design discussion.
>>
>> Daniel,
>> Thanks for pointing out first two things, It was not known to me, I will
>> take care of this in future.
>>
>> First time I presented color-manager design, in internal display design
>> forum, where most of the reviewers were not there.
>> We took the feedback from people who were present, and implemented the
>> design.
>>
>> When we shared color manager implementation, that design was rejected and
>> one of the feedbacks was that it would be better to discuss it on dri-devel
>> where people outside Intel can give their opinion, and that?s the only
>> reason why I added dri-devel for the new design (Please see the attached
>> mail, I replied to all who were in last communication).
>> Please let me know how do we want to proceed now.
>>
>>
>> Regards
>> Shashank
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vetter at 

[PATCH 1/2] drm/ast: Fix double lock at PM resume

[Daniel Vetter]

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 side lock for avoid a
> fatal deadlock.
> 
> Signed-off-by: Takashi Iwai 

Oops, failed to do the audit correctly. Thanks for catching this.

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/ast/ast_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index 5137f15dba19..27e56dda476d 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -94,9 +94,7 @@ static int ast_drm_thaw(struct drm_device *dev)
>   ast_post_gpu(dev);
>  
>   drm_mode_config_reset(dev);
> - drm_modeset_lock_all(dev);
>   drm_helper_resume_force_mode(dev);
> - drm_modeset_unlock_all(dev);
>  
>   console_lock();
>   ast_fbdev_set_suspend(dev, 0);
> -- 
> 1.9.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Daniel Vetter]

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 description of new property is not very complex (assuming table
> format is understood and being comfortable with HTML row/table
> manipulation).
> 
> Adding description of each property in their source might be time
> consuming task.

Yeah I'm ok with docbook for the time being. My long-term plan is to fix
up kerneldoc to support markdown and then we can move such neat tables
into the code. There's lots other places that would benefit from proper
list formatting and tables. So Ack from my side on both the docbook patch
and the no-more-props-without-doc-patch rule (which is kinda what I've
been doing thus far).
-Daniel

> 
> thanks,
> Sagar
> 
> 
> On Sat, 2014-05-10 at 06:56 -0400, Rob Clark wrote:
> > On Sat, May 10, 2014 at 6:39 AM, Ville Syrj?l?
> >  wrote:
> > > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote:
> > >> Hi Sagar,
> > >>
> > >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote:
> > >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote:
> > >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote:
> > >> > > > On Wed, Mar 5, 2014 at 11:56 AM,   
> > >> > > > wrote:
> > >> > > > > +
> > >> > > > > +
> > >> > > > > +
> > >> > > > > +Owner Module/Drivers
> > >> > > > > +Group
> > >> > > > > +Property Object
> > >> > > > > +Property Name
> > >> > > > > +Type
> > >> > > > > +Property Values
> > >> > > > > +Object attached
> > >> > > > > +Description
> > >> > > > > +
> > >> > > >
> > >> > > > In my opinion this is a horrible way to write property 
> > >> > > > documentations
> > >> > > > - explicitly constructing html tables is error prone and really 
> > >> > > > hard
> > >> > > > to read in the source. Imo docbook in general is rather horrible,
> > >> > > > which is way I write almost all my docs as kerneldoc ;-)
> > >> > > >
> > >> > > > I think a simple asciidoc/markdown would be much simpler, with a 
> > >> > > > bit
> > >> > > > of free-form structure to group properties into relevant groups.
> > >> > > > Long-term we might even need to split it up into different spec 
> > >> > > > files
> > >> > > > to keep a good overview.
> > >> > >
> > >> > > Docbook is indeed hard to read and write when it comes to such 
> > >> > > tables.
> > >> > > However I like having the properties documented in the DRM core
> > >> > > documentation. Maybe we could come up with a simpler text format that
> > >> > > would be transformed into docbook when compiling the documentation ?
> > >> >
> > >> > Does this mean we need to create comment block with "Doc: drm
> > >> > properties" style section in each driver where drm properties are
> > >> > instantiated. And then in drm.tmpl collect all these using !P escape
> > >> > sequence?
> > >> > How do create table out of these across all drivers?
> > >>
> > >> I don't have a strong preference here. Documenting properties in source 
> > >> code
> > >> comments would be fine, so would an external central documentation file 
> > >> in a
> > >> non Docbook format. For the record I'm personally fine with using 
> > >> Docbook as
> > >> in this patch :-)
> > >>
> > >> 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 needs to be done?
> > >
> > > The reason why I want a central place for the documentation is to force
> > > people to collaborate outside their own sandbox when adding properties.
> > > Whether that's docbook or some text file I don't care so much at this
> > > point. The fact that it's a central place should mandate that the
> > > patches changing it will go through dri-devel and so everyone should se
> > > them, and when adding new properties it would make the patch author more
> > > likely to look around a bit before adding another slighty incompatible
> > > version of the same property. If someone has a better suggestion how to
> > > encforce this I'm all ears.
> > >
> > > Of course this idea can still fail if our esteemed maintainer merges
> > > stuff without checking for violations of this policy. Dave, any thoughts
> > > on the subject?
> > >
> > > Either way I can tell you that I'm not very enthusiastic about reviewing
> > > any property patches until some kind of decision about this is reached,
> > > be it "docbook", "text", "plan c", or "fuck it, let the world burn!".
> > 
> > any of the first three options would be vastly superior to what we do now
> > 
> > tbh, I'd suggest imposing a no-new-properties-without-docs rule even
> > if we haven't 

[PATCH v2] nouveau: Don't check acpi_video_backlight_support() before registering backlight

[Hans de Goede]

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 interfaces, so
> if acpi_video backlight support is present it will use that even if
> nv_backlight is registered as well.
> 
> Except when video.use_native_backlight is present on the kernel cmdline
> (or enabled through a dmi based quirk). As the name indicates the goal here
> is to make only the raw interface available to userspace so that it will use
> that (it only does this when it sees a win8 compliant bios).
> 
> This is done by:
> 1) Not registering any acpi_video# backlight devices; and
> 2) Making acpi_video_backlight_support() return true so that other firmware
> drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
> own vender specific interfaces.
> 
> Currently nouveau breaks this setup, as when acpi_video_backlight_support()
> returns true, it does not register itself, resulting in no backlight control
> at all.
> 
> This is esp. going to be a problem with 3.16 which will default to
> video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
> will get no backlight control at all.
> 
> This also likely explains why the previous attempt to make
> video.use_native_backlight=1 the default was not a success, as without this
> patch having a default of video.use_native_backlight=1 will cause regressions.
> 
> Note this effectively reverts commit 5bead799
> 
> Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
> 
> Signed-off-by: Hans de Goede 

Ignore the v2 in the subject please it is bogus.

Question should this also go to stable ? I guess that for old / broken userspace
it may lead to userspace doing the wrong thing in some cases. So that goes
against adding it to stable. OTOH the intel driver has been always registering
its native backlight interface for ages, so userspace should know better; and
this fix is needed (together with a quirk to set video.use_native_backlight=1
by default), to get the backlight control to work on the ThinkPad W530.

Regards,

Hans

[PATCH v2] nouveau: Don't check acpi_video_backlight_support() before registering backlight

[Hans de Goede]

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 use that even if
nv_backlight is registered as well.

Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).

This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.

Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.

This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.

This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.

Note this effectively reverts commit 5bead799

Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 630f6e8..2c1e4aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -31,7 +31,6 @@
  */

 #include 
-#include 

 #include "nouveau_drm.h"
 #include "nouveau_reg.h"
@@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev)
struct nouveau_device *device = nv_device(drm->device);
struct drm_connector *connector;

-#ifdef CONFIG_ACPI
-   if (acpi_video_backlight_support()) {
-   NV_INFO(drm, "ACPI backlight interface available, "
-"not registering our own\n");
-   return 0;
-   }
-#endif
-
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
-- 
1.9.0

[RFC V2 0/3] drm/bridge: panel and chaining

[Andrzej Hajda]

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 Kumar wrote:
>> This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree 
>> at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> I have just put up Rob's and Sean's idea of chaining up the bridges
>> in code, and have implemented basic panel controls as a chained bridge.
>> This works well with ptn3460 bridge chip on exynos5250-snow board.
>>
>> Still need to make use of standard list calls and figure out proper way
>> of deleting the bridge chain. So, this is just a rough version.
> As I understand this patchset tries to solve two things:
> 1. Implement panel as drm_bridge, to ease support for hardware chains:
> Crtc -> Encoder -> Bridge -> Panel
> 2. Add support to drm_bridge chaining, to allow software chains:
> drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel
>
> It is done using Russian doll schema, ops from the bridge calls the same
> ops from the next bridge and the next bridge ops can do the same.
>
> This schema means that all the bridges including the last one are seen
> from the drm core point of view as a one big drm_bridge. Additionally in
> this particular case, the first bridge (ptn3460) implements connector
> so it is hard to guess what is the location of the 2nd bridge in video
> stream chain, sometimes it is after the connector, sometimes before.
> All this is quite confusing.
>
> But if you look at the bridge from upstream video interface point of
> view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its
> video input side acts as a panel. On the output side it expects a panel,
> lvds panel in this case.
 tbh, this is mostly about what we call it.  Perhaps "bridge" isn't the
 best name.. I wouldn't object to changing it.

 But my thinking was to leave in drm_panel_funcs things that are just
 needed by the connector (get_modes().. and maybe some day we need
 detect/etc).  Then leave everything else in drm_bridge_funcs.  A panel
 could (if needed) implement both interfaces.

 That is basically the same as what you are proposing, but without
 renaming bridge to panel ;-)
>>> Good to hear that. However there are points which are not clear for me.
>>> But first lets clarify names, I will use panel and bridge words
>>> to describe the hardware, and drm_panel, drm_bridge to describe the
>>> software interfaces.
>>>
>>> What bothers me:
>>> 1. You want to leave connector related callbacks in drm_panel and
>>> the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460
>>> must implement connector internally because of this limitation. I guess
>>> it is quite typical bridge. This problem does not exists in case
>>> of using drm_panel for ptn3460.
>>>
>>> 2. drm_bridge is attached to the encoder, this and the callback order
>>> suggests the video data flow should be as below:
>>> drm_crtc -> drm_encoder [-> drm_bridge] -> drm_connector [-> drm_panel]
>>>
>>> ptn3460 implements drm_bridge and drm_connector so it suggests its
>>> drm_bridge should be the last one, so there should be no place to add
>>> lvds panel implemented as a drm_bridge after it, as it is done in this
>>> patchset.
>>>
>>> Additionally it clearly shows that there should be two categories of
>>> drm_bridges - non-terminal and terminal.
>>>
>>> 3. drm_dev uses all-or-nothing approach, ie. it will start only when all
>>> its components are up. It simplifies synchronization but is quite
>>> fragile - the whole drm will be down due to error in some of its components.
>>> For this reason I prefer drm_panel as it is not real drm component
>>> it can be attached/detached to/from drm_connector anytime. I am not
>>> really sure but drm_bridge does not allow for that.
>> So I do think we need to stick to this all-or-nothing approach for
>> anything that is visible to userspace
>> (drm_{plane,crtc,encoder,connector}).  We don't currently have a way
>> to "hotplug" those so I don't see a real smooth upgrade path to add
>> that in a backwards compatible way that won't cause problems with old
>> userspace.
>>
>> But, that said, we have more flexibility with things not visible to
>> userspace (drm_{panel,bridge}).  I'm not sure how much we want to
>> allow things to be completely dynamic (we already have some hard
>> enough locking fun).  But proposals/rfcs/etc welcome.
>>
>> I guess I'm not completely familiar w/ ptn3460, but the fact that it
>> needs to implement drm_connector makes me a bit suspicious.  Seems
>> like a symptom of missing things in drm_panel_funcs.  It would be
>> better to always create the 

[RFC V2 0/3] drm/bridge: panel and chaining

[Rob Clark]

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, Andrzej Hajda  
> wrote:
>> On 05/05/2014 09:52 PM, Ajay Kumar wrote:
>>> This patchset is based on exynos-drm-next-todo branch of Inki Dae's 
>>> tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have just put up Rob's and Sean's idea of chaining up the bridges
>>> in code, and have implemented basic panel controls as a chained bridge.
>>> This works well with ptn3460 bridge chip on exynos5250-snow board.
>>>
>>> Still need to make use of standard list calls and figure out proper way
>>> of deleting the bridge chain. So, this is just a rough version.
>> As I understand this patchset tries to solve two things:
>> 1. Implement panel as drm_bridge, to ease support for hardware chains:
>> Crtc -> Encoder -> Bridge -> Panel
>> 2. Add support to drm_bridge chaining, to allow software chains:
>> drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel
>>
>> It is done using Russian doll schema, ops from the bridge calls the same
>> ops from the next bridge and the next bridge ops can do the same.
>>
>> This schema means that all the bridges including the last one are seen
>> from the drm core point of view as a one big drm_bridge. Additionally in
>> this particular case, the first bridge (ptn3460) implements connector
>> so it is hard to guess what is the location of the 2nd bridge in video
>> stream chain, sometimes it is after the connector, sometimes before.
>> All this is quite confusing.
>>
>> But if you look at the bridge from upstream video interface point of
>> view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its
>> video input side acts as a panel. On the output side it expects a panel,
>> lvds panel in this case.
> tbh, this is mostly about what we call it.  Perhaps "bridge" isn't the
> best name.. I wouldn't object to changing it.
>
> But my thinking was to leave in drm_panel_funcs things that are just
> needed by the connector (get_modes().. and maybe some day we need
> detect/etc).  Then leave everything else in drm_bridge_funcs.  A panel
> could (if needed) implement both interfaces.
>
> That is basically the same as what you are proposing, but without
> renaming bridge to panel ;-)
 Good to hear that. However there are points which are not clear for me.
 But first lets clarify names, I will use panel and bridge words
 to describe the hardware, and drm_panel, drm_bridge to describe the
 software interfaces.

 What bothers me:
 1. You want to leave connector related callbacks in drm_panel and
 the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460
 must implement connector internally because of this limitation. I guess
 it is quite typical bridge. This problem does not exists in case
 of using drm_panel for ptn3460.

 2. drm_bridge is attached to the encoder, this and the callback order
 suggests the video data flow should be as below:
 drm_crtc -> drm_encoder [-> drm_bridge] -> drm_connector [-> drm_panel]

 ptn3460 implements drm_bridge and drm_connector so it suggests its
 drm_bridge should be the last one, so there should be no place to add
 lvds panel implemented as a drm_bridge after it, as it is done in this
 patchset.

 Additionally it clearly shows that there should be two categories of
 drm_bridges - non-terminal and terminal.

 3. drm_dev uses all-or-nothing approach, ie. it will start only when all
 its components are up. It simplifies synchronization but is quite
 fragile - the whole drm will be down due to error in some of its 
 components.
 For this reason I prefer drm_panel as it is not real drm component
 it can be attached/detached to/from drm_connector anytime. I am not
 really sure but drm_bridge does not allow for that.
>>> So I do think we need to stick to this all-or-nothing approach for
>>> anything that is visible to userspace
>>> (drm_{plane,crtc,encoder,connector}).  We don't currently have a way
>>> to "hotplug" those so I don't see a real smooth upgrade path to add
>>> that in a backwards compatible way that won't cause problems with old
>>> userspace.
>>>
>>> But, that said, we have more flexibility with things not visible to
>>> userspace (drm_{panel,bridge}).  I'm not sure how much we want to
>>> allow things to be completely dynamic (we already have some hard
>>> enough locking fun).  But proposals/rfcs/etc welcome.
>>>
>>> I guess I'm not completely familiar w/ ptn3460, but the fact that it
>>> needs to 

[Bug 66281] DRI_PRIME=1 glxinfo crashes and causes session to restart

[bugzilla-dae...@bugzilla.kernel.org]

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 Linux).
> 
> If you have your .config (which, depending on options, may be visible from
> /proc/config.gz), you can look for
> 
> CONFIG_VGA_SWITCHEROO
> CONFIG_PM_RUNTIME
> 
> Make sure both of those are set to 'y'. (This is only for optimus-type
> systems, of which I'm assuming yours is one.)
> 
> > 
> > (d) I cannot be sure about this as well. AFAIK, the nouveau module is built
> > into the kernel. The modinfo result is as below:

There is no config.gz file in my system. I have tried using "locate" as well.
Is there some other way I can find this out.

> 
> xf86-video-nouveau is the xorg ddx which interacts with the kernel driver.
> In some distros, for maximal confusion, it is called something else, like
> xorg-xserver-video-nouveau or something like that (don't have the exact
> name, sorry).

Can you please tell me how to find out (or search) if this is the case. Even if
you can tell me where and how to look for, I will follow.  
> 
> > Actually I am working on some OpenGL/GLSL projects, for which I need GLSL
> > 4.3, which I believe is still not available in nouveau driver. I was looking
> > forward to be able to install the latest NVIDIA drivers. Will mesa 10,2-rcl
> > solve this issue? Can you please recommend any other solution.

The latest mesa based DRI drivers through yum is listed as 10.1.1. Will it
work?

> 
> Mesa 10.2 will support a few more extensions which are part of GL4+, but
> will not provide all the features required to advertise GL 4.0 support (or
> GL 4.3, obviously). You can see the general progress of things at
> http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt.
> 
> However it's rare to need ALL of the features available in GL 4.3, so
> chances are you could restrict yourself to a lower, supported version + a
> few extensions.
> 
> Also note that GK208, while covered by the nvc0 driver, has en some
> extra-special issues that the GK10x cards (and GF1xx cards) don't have.
> Hopefully they'll be resolved semi-soon, but the hardware is not easily
> available.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Randy Dunlap]

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 information extracted from comments is probably not 
 possible.
>>>
>>> Can comeone pick up the ball here and figure out what needs to be done?
>>>
>>> The reason why I want a central place for the documentation is to force
>>> people to collaborate outside their own sandbox when adding properties.
>>> Whether that's docbook or some text file I don't care so much at this
>>> point. The fact that it's a central place should mandate that the
>>> patches changing it will go through dri-devel and so everyone should se
>>> them, and when adding new properties it would make the patch author more
>>> likely to look around a bit before adding another slighty incompatible
>>> version of the same property. If someone has a better suggestion how to
>>> encforce this I'm all ears.
>>>
>>> Of course this idea can still fail if our esteemed maintainer merges
>>> stuff without checking for violations of this policy. Dave, any thoughts
>>> on the subject?
>>
>> Yeah I'm happy to block merging stuff, if we can spot new properties
>> when stuff is posted on dri-devel, so much the better,
>>
>> most drivers still send everything via dri-devel anyways, its only
>> really Intel I have to worry about so far,
> 
> I'll enforce that all prop stuff gets cc: dri-devel and that it has
> updates for the prop docs.
> 
>> But we should definitely add it to the new driver review checklist as well.
>>
>> I'm also on the side of this patch is ugly and makes my eyes burn,
>> please please get a plan to use something else ASAP, I'm willing to
>> merge this but I'm tempted to give it a lifetime of a kernel or two
>> before I burn it.
> 
> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe
> find someone to do it for me internally ;-)
> -Daniel
> 

I certainly have no objections to making kerneldoc suck less.
There was already an attempt to use asciidoc (like git uses) for kernel-doc
(a few years ago, by Sam Ravnborg).  I support(ed) that effort.

OTOH, I would only want to add another way to do kernel-doc if it can be a
full replacement for all of our docbook usage, i.e., it should provide a
way that we can eliminate docbook and stop using it completely.

thanks,
-- 
~Randy

[Bug 71891] 3.13 fails to boot with the radeon module

[bugzilla-dae...@bugzilla.kernel.org]

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 that would
crash the box again.

My best guess is that the information in the BIOS about the reference frequency
is wrong, but without having the hardware here I can't do much else to get UVD
working properly.

(In reply to sdh from comment #31)
> 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 3.14.2-1-git-dirty with above patch

Sounds like an unrelated DPM problem to me, but who knows.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78453] [HAWAII] Get acceleration working

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #12 from Michel D?nzer  ---
Note that 2D contents use 3D hardware acceleration as well via glamor. For
these tests, it might be best to use as little 2D as possible, e.g. just a bare
X server without -retro and glxgears, or even 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>

[Bug 71891] 3.13 fails to boot with the radeon module

[bugzilla-dae...@bugzilla.kernel.org]

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 3.14.2-1-git-dirty with above patch

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 70569] DOTA2 background and other missing elements on HD4850 GPU

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70569

Roc Vall?s Dom?nech  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Roc Vall?s Dom?nech  ---
Fixed by not using LLVM, which is the case as of Mesa 10.1.2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/401debf6/attachment.html>

[Bug 78366] [r600g] Memory leak desktop usage RV770 (HD4850) with 10.1.2 (related to not using LLVM anymore)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78366

Roc Vall?s Dom?nech  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Roc Vall?s Dom?nech  ---
After trying with older mesa/llvm and experimenting around, I've figured out
it's not the same thing I used to have.

Apparently, memory is recovered by closing Firefox. Top doesn't show it using
that much memory, but it somehow does in less traceable ways.

Damn firefox 29... I'm seriously considering moving to chromium now.

Closing this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/17279ffe/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75112

--- Comment #17 from Michel D?nzer  ---
(In reply to comment #16)
> I browsed bug reports and non of them is APU related, so maybe give a shot for
> these?

Did you test the games referenced in those bug reports?

-- 
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/1487537c/attachment.html>

[Bug 78537] no anisotropic filtering in a native Half-Life 2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78537

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|Mesa
  Component|Driver/Radeon   |Drivers/Gallium/radeonsi

-- 
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/5af7fcdd/attachment.html>

[PATCH] drm/crtc-helper: skip locking checks in panicking path

[Sergei Antonov]

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 they are called in panicking
path. See similar code in drm_warn_on_modeset_not_all_locked().

After panic information has been output, these WARN_ONs go off outputing a lot
of lines and scrolling the panic information out of the screen. Here is a
partial call trace showing how execution reaches them:

? drm_helper_crtc_in_use()
? __drm_helper_disable_unused_functions()
? several *_set_config functions
? drm_fb_helper_restore_fbdev_mode()

Cc: Dave Airlie 
Cc: Daniel Vetter 
Signed-off-by: Sergei Antonov 
---
 drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index df281b5..872ba11 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -29,6 +29,7 @@
  *  Jesse Barnes 
  */

+#include 
 #include 
 #include 

@@ -88,7 +89,13 @@ bool drm_helper_encoder_in_use(struct drm_encoder *encoder)
struct drm_connector *connector;
struct drm_device *dev = encoder->dev;

-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+   /*
+* We can expect this mutex to be locked if we are not panicking.
+* Locking is currently fubar in the panic handler.
+*/
+   if (!oops_in_progress)
+   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+
list_for_each_entry(connector, >mode_config.connector_list, head)
if (connector->encoder == encoder)
return true;
@@ -112,7 +119,13 @@ bool drm_helper_crtc_in_use(struct drm_crtc *crtc)
struct drm_encoder *encoder;
struct drm_device *dev = crtc->dev;

-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+   /*
+* We can expect this mutex to be locked if we are not panicking.
+* Locking is currently fubar in the panic handler.
+*/
+   if (!oops_in_progress)
+   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+
list_for_each_entry(encoder, >mode_config.encoder_list, head)
if (encoder->crtc == crtc && drm_helper_encoder_in_use(encoder))
return true;
-- 
1.9.0