date:20121217


Hi,

Following to my shared talk with krh, danvet and Timothée Ravier @ 
XDC2012, I have
actually taken the time to start fixing some security holes found in the 
graphics stack.


Today, I would like to request your comments on the render node 
patchset. Keep in mind that I am
not asking for inclusion. However, I know this patchset works on my 
nvidia card and I would like

to know if anyone has anything against this architecture.

## DRM
If I'm not mistaken, the idea originated from airlied which got 
simplified later by krh.

Both only provided drm patches.

Here is what I did:
- I took krh's patchset
- rebased it on top on drm 3.7-rc8
- added support for Nouveau
- fixed a few bugs along the way (as stated in the commit logs)

The kernel can be found here: 
https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes
The patches will also be sent in reply, to let you comment on specific 
parts of the patches.


## Libdrm

Here are the two main goals of this patchset:
- Add a new symbol called drmOpenType that allows to open a specific 
type of device (usual node, render node)
- Add a new symbol called drmGetSameDeviceButType to get the path to the 
same drm_device but with a different type


The patches are available here: http://cgit.freedesktop.org/~mperes/drm/

## DRI2Proto

What we want here is to let the ddx send the render node instead of the 
usual one.
However, authentication is not necessary and not shouldn't be done on a 
render node.


This modification to DRI2Proto adds a boolean in the Connection response 
to tell the dri2 client

that no authentication is required.

The patches are available here: 
http://cgit.freedesktop.org/~mperes/dri2proto/


## XServer

The X-Server is responsible for collecting the DRI2 informations from 
the ddx.
In this patch, we provide the way for the ddx to specify whether the 
DRI2 client should authenticate or not.


The patches are available here: http://cgit.freedesktop.org/~mperes/xserver/

## xf86-video-nouveau

In this patch, we simply tell the DRI2 extension to use the render node if
available (using drmGetSameDeviceButType), and if it is the case,
we set the "require_authentication" attribute to 0.

The patches are available here: 
http://cgit.freedesktop.org/~mperes/xf86-video-nouveau/


## Mesa

In this patch, I simply check whether I should authenticate or not using 
the information

from the DRI2 protocol.

The patches are available here: http://cgit.freedesktop.org/~mperes/mesa/

Cheers,

Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

2012-12-17 Thread Sumit Semwal

Hi Maarten,

On 14 December 2012 17:27, Maarten Lankhorst wrote:

> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
> > From: Sumit Semwal 
> >
> > Add debugfs support to make it easier to print debug information
> > about the dma-buf buffers.
> >
> I like the idea, I don't know if it could be done in a free manner, but
> for bonus points
> could we also have the dma-buf fd be obtainable that way from a debugfs
> entry?
>
> Doing so would allow me to 'steal' a dma-buf from an existing mapping
> easily, and test against that.

Also I think the name of the device and process that exported the dma-buf
> would be useful
> to have as well, even if in case of the device that would mean changing
> the api slightly to record it.
>
> I was thinking of having a directory structure like this:
>
> /sys/kernel/debug/dma_buf/stats
>
> and then for each dma-buf:
>
> /sys/kernel/debug/dma-buf/exporting_file.c/-fd
> /sys/kernel/debug/dma-buf/exporting_file.c/-attachments
> /sys/kernel/debug/dma-buf/exporting_file.c/-info
>
> Opening the fd file would give you back the original fd, or fail with -EIO
> if refcount was dropped to 0.
>
> Would something like this be doable? I don't know debugfs that well, but I
> don't see why it wouldn't be,
>
Let me think more about it, but I am inclined to add simple support first,
and then add more features to dma_buf debugfs as it grows.

I still would want to take Daniel's suggestion on dma_buf_export_named()
before I push this patch, so I guess I'll try to work a little more and
prepare it for 3.9?

I quite like your idea of .../dma-buf//...  , which would
need the above as well :)

>
> ~Maarten
>
> Best regards,
~Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: Add debugfs support

2012-12-17 Thread Sumit Semwal

On 14 December 2012 16:04, Daniel Vetter  wrote:
>
> Missed one ...
>
> On Fri, Dec 14, 2012 at 10:36 AM,   wrote:
> > +   list_for_each_entry(attach_obj, &buf_obj->attachments, 
> > node) {
> > +   seq_printf(s, "\t\t");
> > +
> > +   seq_printf(s, "%s\n", attach_obj->dev->init_name);
> > +   attach_count++;
> > +   }
>
> You need to hold dmabuf->lock while walking the attachment list.
> -Daniel


Thanks Daniel!

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



Best regards,

Sumit Semwal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

2012-12-17 Thread Sumit Semwal

On 17 December 2012 14:25, Sumit Semwal  wrote:
Apologies for re-sending, since the gmail ui 'decided' to set some
formatting options by default!
> Hi Maarten,
>
> On 14 December 2012 17:27, Maarten Lankhorst 
> wrote:
>>
>> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>> > From: Sumit Semwal 
>> >
>> > Add debugfs support to make it easier to print debug information
>> > about the dma-buf buffers.
>> >
>> I like the idea, I don't know if it could be done in a free manner, but
>> for bonus points
>> could we also have the dma-buf fd be obtainable that way from a debugfs
>> entry?
>>
>> Doing so would allow me to 'steal' a dma-buf from an existing mapping
>> easily, and test against that.
>>
>> Also I think the name of the device and process that exported the dma-buf
>> would be useful
>> to have as well, even if in case of the device that would mean changing
>> the api slightly to record it.
>>
>> I was thinking of having a directory structure like this:
>>
>> /sys/kernel/debug/dma_buf/stats
>>
>> and then for each dma-buf:
>>
>> /sys/kernel/debug/dma-buf/exporting_file.c/-fd
>> /sys/kernel/debug/dma-buf/exporting_file.c/-attachments
>> /sys/kernel/debug/dma-buf/exporting_file.c/-info
>>
>> Opening the fd file would give you back the original fd, or fail with -EIO
>> if refcount was dropped to 0.
>>
>> Would something like this be doable? I don't know debugfs that well, but I
>> don't see why it wouldn't be,
>
> Let me think more about it, but I am inclined to add simple support first,
> and then add more features to dma_buf debugfs as it grows.
>
> I still would want to take Daniel's suggestion on dma_buf_export_named()
> before I push this patch, so I guess I'll try to work a little more and
> prepare it for 3.9?
>
> I quite like your idea of .../dma-buf//...  , which would
> need the above as well :)
>>
>>
>> ~Maarten
>>
> Best regards,
> ~Sumit.
>



--
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-17 Thread Christian König


On 14.12.2012 21:33, Jerome Glisse wrote:

On Fri, Dec 14, 2012 at 3:13 PM, Christian König
 wrote:

On 14.12.2012 18:39, j.gli...@gmail.com wrote:

From: Jerome Glisse 

After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.

NAK. I changed this on purpose to get partial resets working, please don't
change it back.

The IB test code should reset this to the last synced value anyway, if it
doesn't work then there is something wrong there.

Christian.

There is something wrong 


What symptoms? What exactly is going wrong?

Thinking about it the sequence probably won't get reseted when we 
encounter a unrecoverable GPU lockup. And even when the partial GPU 
reset fails it might be a good idea to reset the fence sequence like 
this


Ok, you're right there is something wrong. Going to write a patch for 
this...


Cheers,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Fan control in nouveau driver with geforce 9600gt

2012-12-17 Thread Ozan Çağlayan

>
> Hi Ozan,
>
> Please have a look at this documentation:
> http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal
> It will tell you how to use fan management on your card :)
>
> Please report back! I am interested in your results!
>
> Martin

Hey this is nice! I'll try it tonight when I'm back home.

Thanks :)

-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-next-queued 120/120] drivers/gpu/drm/i915/intel_fb.c:163:17: sparse: incorrect type in argument 1 (different address spaces)

2012-12-17 Thread kbuild test robot

tree:   git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head:   6ace91e648a327ebf98093b6d971a097c36cd46d
commit: 6ace91e648a327ebf98093b6d971a097c36cd46d [120/120] drm/i915: Clear the 
stolen fb before enabling


sparse warnings:

+ drivers/gpu/drm/i915/intel_fb.c:163:17: sparse: incorrect type in argument 1 
(different address spaces)
drivers/gpu/drm/i915/intel_fb.c:163:17:expected void *
drivers/gpu/drm/i915/intel_fb.c:163:17:got char [noderef] 
*screen_base

vim +163 drivers/gpu/drm/i915/intel_fb.c

79e53945 Jesse Barnes  2008-11-07  147  if (!info->screen_base) {
79e53945 Jesse Barnes  2008-11-07  148  ret = -ENOSPC;
b4476f52 Chris Wilson  2009-02-11  149  goto out_unpin;
79e53945 Jesse Barnes  2008-11-07  150  }
79e53945 Jesse Barnes  2008-11-07  151  info->screen_size = size;
79e53945 Jesse Barnes  2008-11-07  152  
79e53945 Jesse Barnes  2008-11-07  153  //  memset(info->screen_base, 0, 
size);
79e53945 Jesse Barnes  2008-11-07  154  
01f2c773 Ville Syrjälä 2011-12-20  155  drm_fb_helper_fill_fix(info, 
fb->pitches[0], fb->depth);
38651674 Dave Airlie   2010-03-30  156  drm_fb_helper_fill_var(info, 
&ifbdev->helper, sizes->fb_width, sizes->fb_height);
79e53945 Jesse Barnes  2008-11-07  157  
6ace91e6 Chris Wilson  2012-12-16  158  /* If the object is shmemfs 
backed, it will have given us zeroed pages.
6ace91e6 Chris Wilson  2012-12-16  159   * If the object is stolen 
however, it will be full of whatever
6ace91e6 Chris Wilson  2012-12-16  160   * garbage was left in there.
6ace91e6 Chris Wilson  2012-12-16  161   */
6ace91e6 Chris Wilson  2012-12-16  162  if (ifbdev->ifb.obj->stolen)
6ace91e6 Chris Wilson  2012-12-16 @163  
memset(info->screen_base, 0, info->screen_size);
6ace91e6 Chris Wilson  2012-12-16  164  
fb2a99e1 Sascha Hauer  2012-02-06  165  /* Use default scratch pixmap 
(info->pixmap.flags = FB_PIXMAP_SYSTEM) */
79e53945 Jesse Barnes  2008-11-07  166  
28c97730 Zhao Yakui2009-10-09  167  DRM_DEBUG_KMS("allocated %dx%d 
fb: 0x%08x, bo %p\n",
8be48d92 Dave Airlie   2010-03-30  168fb->width, 
fb->height,
05394f39 Chris Wilson  2010-11-08  169obj->gtt_offset, 
obj);
79e53945 Jesse Barnes  2008-11-07  170  
79e53945 Jesse Barnes  2008-11-07  171  

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 4/7] gpu: host1x: Add debug support

2012-12-17 Thread Terje Bergström

On 13.12.2012 17:23, Joe Perches wrote:
> On Thu, 2012-12-13 at 16:04 +0200, Terje Bergstrom wrote:
>> Add support for host1x debugging. Adds debugfs entries, and dumps
>> channel state to UART in case of stuck job.
> 
> trivial note:
> 
> []
> 
>> diff --git a/drivers/gpu/host1x/debug.h b/drivers/gpu/host1x/debug.h
> []
>> +void host1x_debug_output(struct output *o, const char *fmt, ...);
> 
> This should be marked __printf(2, 3)
> so the compiler verifies format and argument types.

Thanks, I didn't know of this "trick". I'll apply it in the next version.

Considering the amount of feedback I've received from the patches, they
must be top notch quality!

Terje

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Tomi,

I finally have time to work on a v3 :-)

On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> On 2012-11-22 23:45, Laurent Pinchart wrote:
> > From: Laurent Pinchart 
> > 
> > Hi everybody,
> > 
> > Here's the second RFC of what was previously known as the Generic Panel
> > Framework.
> 
> Nice work! Thanks for working on this.
> 
> I was doing some testing with the code, seeing how to use it in omapdss.
> Here are some thoughts:
> 
> In your model the DSS gets the panel devices connected to it from
> platform data. After the DSS and the panel drivers are loaded, DSS gets
> a notification and connects DSS and the panel.
> 
> I think it's a bit limited way. First of all, it'll make the DT data a
> bit more complex (although this is not a major problem). With your
> model, you'll need something like:
> 
> soc-base.dtsi:
> 
> dss {
>   dpi0: dpi {
>   };
> };
> 
> board.dts:
> 
> &dpi0 {
>   panel = &dpi-panel;
> };
> 
> / {
>   dpi-panel: dpi-panel {
>   ...panel data...;
>   };
> };
> 
> Second, it'll prevent hotplug, and even if real hotplug would not be
> supported, it'll prevent cases where the connected panel must be found
> dynamically (like reading ID from eeprom).

Hotplug definitely needs to be supported, as the common display framework also 
targets HDMI and DP. The notification mechanism was actually designed to 
support hotplug.

How do you see the proposal preventing hotplug ?

> Third, it kinda creates a cyclical dependency: the DSS needs to know
> about the panel and calls ops in the panel, and the panel calls ops in
> the DSS. I'm not sure if this is an actual problem, but I usually find
> it simpler if calls are done only in one direction.

I don't see any way around that. The panel is not a standalone entity that can 
only receive calls (as it needs to control video streams, per your request 
:-)) or only emit calls (as something needs to control it, userspace doesn't 
control the panel directly).

> What I suggest is take a simpler approach, something alike to how regulators
> or gpios are used, even if slightly more complex than those: the entity that
> has a video output (SoC's DSS, external chips) offers that video output as
> resource. It doesn't know or care who uses it. The user of the video output
> (panel, external chips) will find the video output (to which it is connected
> in the HW) by some means, and will use different operations on that output
> to operate the device.
> 
> This would give us something like the following DT data:
> 
> soc-base.dtsi:
> 
> dss {
>   dpi0: dpi {
>   };
> };
> 
> board.dts:
> 
> / {
>   dpi-panel: dpi-panel {
>   source = <&dpi0>;
>   ...panel data...;
>   };
> };
> 
> The panel driver would do something like this in its probe:
> 
> int dpi_panel_probe()
> {
>   // Find the video source, increase ref
>   src = get_video_source_from_of("source");
> 
>   // Reserve the video source for us. others can still get and
>   // observe it, but cannot use it as video data source.
>   // I think this should cascade upstream, so that after this call
>   // each video entity from the panel to the SoC's CRTC is
>   // reserved and locked for this video pipeline.
>   reserve_video_source(src);
> 
>   // set DPI HW configuration, like DPI data lines. The
>   // configuration would come from panel's platform data
>   set_dpi_config(src, config);
> 
>   // register this panel as a display.
>   register_display(this);
> }
> 
> 
> The DSS's dpi driver would do something like:
> 
> int dss_dpi_probe()
> {
>   // register as a DPI video source
>   register_video_source(this);
> }
> 
> A DSI-2-DPI chip would do something like:
> 
> int dsi2dpi_probe()
> {
>   // get, reserve and config the DSI bus from SoC
>   src = get_video_source_from_of("source");
>   reserve_video_source(src);
>   set_dsi_config(src, config);
> 
>   // register as a DPI video source
>   register_video_source(this);
> }
> 
> 
> Here we wouldn't have similar display_entity as you have, but video sources
> and displays. Video sources are elements in the video pipeline, and a video
> source is used only by the next downstream element. The last element in the
> pipeline would not be a video source, but a display, which would be used by
> the upper layer.

I don't think we should handle pure sources, pure sinks (displays) and mixed 
entities (transceivers) differently. I prefer having abstract entities that 
can have a source and a sink, and expose the corresponding operations. That 
would make pipeline handling much easier, as the code will only need to deal 
with a single type of object. Implementing support for entities with multiple 
sinks and/or sources would also be possible.

> Video source's ops would deal with things related to the video bus in
> question, like configuring data lanes, sending DSI packets, etc. The
> display o

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Mon, Dec 17, 2012 at 7:56 AM, Tomi Valkeinen  wrote:
> On 2012-12-14 02:04, Rob Clark wrote:
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
>> CMA helpers.  Currently only the TFP410 DVI encoder is supported
>> (tested with beaglebone + DVI cape).  There are also various LCD
>> displays, for which support can be added (as I get hw to test on),
>> and an external i2c HDMI encoder found on some boards.
>>
>> The display controller supports a single CRTC.  And the encoder+
>> connector are split out into sub-devices.  Depending on which LCD
>> or external encoder is actually present, the appropriate output
>> module(s) will be loaded.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/Kconfig|   2 +
>>  drivers/gpu/drm/Makefile   |   1 +
>>  drivers/gpu/drm/lcdc/Kconfig   |  11 +
>>  drivers/gpu/drm/lcdc/Makefile  |   8 +
>>  drivers/gpu/drm/lcdc/lcdc_crtc.c   | 544 +
>>  drivers/gpu/drm/lcdc/lcdc_drv.c| 604 
>> +
>>  drivers/gpu/drm/lcdc/lcdc_drv.h| 162 ++
>>  drivers/gpu/drm/lcdc/lcdc_regs.h   | 154 ++
>>  drivers/gpu/drm/lcdc/lcdc_tfp410.c | 424 ++
>>  drivers/gpu/drm/lcdc/lcdc_tfp410.h |  26 ++
>>  10 files changed, 1936 insertions(+)
>>  create mode 100644 drivers/gpu/drm/lcdc/Kconfig
>>  create mode 100644 drivers/gpu/drm/lcdc/Makefile
>>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_crtc.c
>>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.c
>>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.h
>>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_regs.h
>>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.c
>>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.h
>
> "lcdc" is quite a common term. The directory should perhaps be something
> like ti-lcdc?

yeah.. but not one else was using it (other than internally to the
driver).. I guess we could call it tilcdc or ti-lcdc

> Probably not relevant, but I wonder if the same LCDC was used in
> omap1... It'd be nice to get rid of the omap1 fb driver.

would be interesting if you have any idea where to find hw to test
with (museum?)

> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
> drivers. It's not really a big deal if it's only kernel code, but you
> add device-tree bindings also, which is an external API that you need to
> support after adding it.
>
> I'd rather see the energy put to common display framework, and get this
> whole panel/chip driver issue solved in a generic manner.

yeah, I was expecting to migrate to CDF once it exists, but needed
something for now.  I'm using the exercise to get my thoughts straight
on how CDF should fit into KMS.  (One thing I plan to add support for
is an i2c connected hdmi encoder.. which looks like it would fit well
in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
way.)

If you have any suggestions on the DT bindings, I'd like to hear 'em.

BR,
-R

>  Tomi
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Thierry,

On Friday 23 November 2012 20:56:07 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> [...]
> 
> > Display entities are accessed by driver using notifiers. Any driver can
> > register a display entity notifier with the CDF, which then calls the
> > notifier when a matching display entity is registered. The reason for
> > this asynchronous mode of operation, compared to how drivers acquire
> > regulator or clock resources, is that the display entities can use
> > resources provided by the display driver. For instance a panel can be a
> > child of the DBI or DSI bus controlled by the display device, or use a
> > clock provided by that device. We can't defer the display device probe
> > until the panel is registered and also defer the panel device probe until
> > the display is registered. As most display drivers need to handle output
> > devices hotplug (HDMI monitors for instance), handling other display
> > entities through a notification system seemed to be the easiest solution.
> > 
> > Note that this brings a different issue after registration, as display
> > controller and display entity drivers would take a reference to each
> > other. Those circular references would make driver unloading impossible.
> > One possible solution to this problem would be to simulate an unplug event
> > for the display entity, to force the display driver to release the dislay
> > entities it uses. We would need a userspace API for that though. Better
> > solutions would of course be welcome.
> 
> Maybe I don't understand all of the underlying issues correctly, but a
> parent/child model would seem like a better solution to me. We discussed
> this back when designing the DT bindings for Tegra DRM and came to the
> conclusion that the output resource of the display controller (RGB,
> HDMI, DSI or TVO) was the most suitable candidate to be the parent of
> the panel or display attached to it. The reason for that decision was
> that it keeps the flow of data or addressing of nodes consistent. So the
> chain would look something like this (on Tegra):
> 
>   CPU
>   +-host1x
> +-dc
>   +-rgb
>   | +-panel
>   +-hdmi
> +-monitor
> 
> In a natural way this makes the output resource the master of the panel
> or display. From a programming point of view this becomes quite easy to
> implement and is very similar to how other busses like I2C or SPI are
> modelled. In device tree these would be represented as subnodes, while
> with platform data some kind of lookup could be done like for regulators
> or alternatively a board setup registration mechanism like what's in
> place for I2C or SPI.

That works well for panels that have a shared control and video bus (DBI, DSI) 
or only a video bus (DPI), but breaks when you need to support panels with 
separate control and video busses, such as panels with a parallel data bus and 
an I2C or SPI control bus.

Both Linux and DT have a tree-based device model. Devices can have a single 
parent, so you can't represent your panel as a child of both the video source 
and the control bus master. We have the exact same problem in V4L2 with I2C 
camera sensors that output video data on a separate parallel or serial bus, 
and we decided to handle the device as a child of its control bus master. This 
model makes usage of the Linux power management model easier (but not 
straightforward when power management dependencies exist across video busses, 
outside of the kernel device tree).

As the common display framework should handle both panels with common control 
and video busses and panels with separate busses in a similar fashion, DT 
bindings needs to reference the panel through a phandle, even though in some 
cases they could technically just be children of the display controller.

-- 
Regards,

Laurent Pinchart

signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Sascha,

On Friday 23 November 2012 22:41:58 Sascha Hauer wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > From: Laurent Pinchart 
> > 
> > The CDF models this using a Russian doll's model. From the display
> > controller point of view only the first external entity (LVDS to DSI
> > converter) is visible. The display controller thus calls the control
> > operations implemented by the LVDS to DSI transmitter driver (left-most
> > green arrow). The driver is aware of the next entity in the chain,
> 
> I can't find this in the code. I can see the video operations
> propagating upstream using the source field of struct display_entity,
> but how do the control operations propagate downstream? Am I missing
> something?

There's no downstream propagation yet, as there's no display entity driver 
that requires it at the moment. Propagation would be implemented in 
transceiver drivers for instance. I'll have to find one with public 
documentation (and hopefully an existing mainline driver) on one of the boards 
I own.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark  wrote:
>> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
>> drivers. It's not really a big deal if it's only kernel code, but you
>> add device-tree bindings also, which is an external API that you need to
>> support after adding it.
>>
>> I'd rather see the energy put to common display framework, and get this
>> whole panel/chip driver issue solved in a generic manner.
>
> yeah, I was expecting to migrate to CDF once it exists, but needed
> something for now.  I'm using the exercise to get my thoughts straight
> on how CDF should fit into KMS.  (One thing I plan to add support for
> is an i2c connected hdmi encoder.. which looks like it would fit well
> in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
> way.)
>
> If you have any suggestions on the DT bindings, I'd like to hear 'em.

btw, a little bit of-topic, but speaking of DT...

Anybody have any clue about how backlight devices are supposed to work
in this brave new DT world?  In the old days, the board file would
stuff a fxn ptr to control backlight in pdata for the driver.  But we
don't have this any more.  I think I need some way to retrieve the
'struct backlight_device' ptr associated with the panel driver, so
that the appropriate dpms fxn ptrs can enable/disable the backlight.

I'm thinking the dt file should have something that looks roughly like:

/* Settings for CDTech_S035Q01 / LCD3 cape: */
panel {
compatible = "lcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
panel-info {
ac-bias   = <255>;
ac-bias-intrpt= <0>;
dma-burst-sz  = <16>;
bpp   = <16>;
fdd   = <0x80>;
tft-alt-mode  = <0>;
stn-565-mode  = <0>;
mono-8bit-mode= <0>;
invert-line-clock = <1>;
invert-frm-clock  = <1>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order  = <0>;
fifo-th   = <0>;
};
display-timings {
native-mode = <&timing0>;
timing0: 320x240 {
hactive = <320>;
vactive = <240>;
hback-porch = <21>;
hfront-porch= <58>;
hsync-len   = <47>;
vback-porch = <11>;
vfront-porch= <23>;
vsync-len   = <2>;
clock-frequency = <800>;
};
};

backlight {
compatible = "tps65217-backlight";
isel = <1>;
fdim = <200>;

tps = <&tps>;   /* link to the tps */
brightness = <100>;
};
};

display-timings is based on the of-videomode helpers patch..
panel-info probably needs to be made to be something more generic, but
we need something to know how to configure the crtc properly..

but I'm not quite sure what to do with the backlight..

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Alan,

On Monday 26 November 2012 14:47:08 Alan Cox wrote:
> On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote:
> > On 2012-11-23 21:56, Thierry Reding wrote:
> > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > > [...]
> > > 
> > >> Display entities are accessed by driver using notifiers. Any driver can
> > >> register a display entity notifier with the CDF, which then calls the
> > >> notifier when a matching display entity is registered.
> 
> The framebuffer layer has some similar 'anyone can' type notifier
> behaviour and its not a good thing. That kind of "any one can" behaviour
> leads to some really horrible messes unless the connections and the
> locking are well defined IMHO.

I agree with you. I dislike the FBDEV notifier model, and I definitely don't 
intend to duplicate it in the common display framework.

In the CDF model, when the display device driver registers a notifier, it 
tells the core which device it wants to receive events for. This currently 
takes the form of a struct device pointer, and the API will also support 
device nodes in a future version (this is still work in progress). The goal is 
to implement panel discovery in a way that is compatible with (and very 
similar to) hotpluggable display discovery.

Thinking about it now, the API could be cleaner and less subject to abuse if 
the notifier was registered for a given video port instead of a given 
connected device. I'll add that to my TODO list.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

2012-12-17 Thread Jerome Glisse

On Mon, Dec 17, 2012 at 4:11 AM, Christian König
 wrote:
> On 14.12.2012 21:33, Jerome Glisse wrote:
>>
>> On Fri, Dec 14, 2012 at 3:13 PM, Christian König
>>  wrote:
>>>
>>> On 14.12.2012 18:39, j.gli...@gmail.com wrote:

 From: Jerome Glisse 

 After lockup we need to resume fence to last sync sequence and not
 last received sequence so that all thread waiting on command stream
 that lockedup resume. Otherwise GPU reset will be ineffective in most
 cases.
>>>
>>> NAK. I changed this on purpose to get partial resets working, please
>>> don't
>>> change it back.
>>>
>>> The IB test code should reset this to the last synced value anyway, if it
>>> doesn't work then there is something wrong there.
>>>
>>> Christian.
>>
>> There is something wrong 
>
>
> What symptoms? What exactly is going wrong?
>
> Thinking about it the sequence probably won't get reseted when we encounter
> a unrecoverable GPU lockup. And even when the partial GPU reset fails it
> might be a good idea to reset the fence sequence like this
>
> Ok, you're right there is something wrong. Going to write a patch for
> this...
>
> Cheers,
> Christian.

I already sent a patch that fix most of the issue. But for failed GPU
reset we need to write it.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

2012-12-17 Thread j . glisse

From: Jerome Glisse 

Force all fence to signal if GPU reset failed so no process get stuck
on waiting fence.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h|  1 +
 drivers/gpu/drm/radeon/radeon_device.c |  1 +
 drivers/gpu/drm/radeon/radeon_fence.c  | 19 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5d68346..9c7625c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -225,6 +225,7 @@ struct radeon_fence {
 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
 int radeon_fence_driver_init(struct radeon_device *rdev);
 void radeon_fence_driver_fini(struct radeon_device *rdev);
+void radeon_fence_driver_force_completion(struct radeon_device *rdev);
 int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence **fence, 
int ring);
 void radeon_fence_process(struct radeon_device *rdev, int ring);
 bool radeon_fence_signaled(struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e2f5f88..774fae7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1357,6 +1357,7 @@ retry:
}
}
} else {
+   radeon_fence_driver_force_completion(rdev);
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
kfree(ring_data[i]);
}
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 22bd6c2..bf7b20e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -868,6 +868,25 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
mutex_unlock(&rdev->ring_lock);
 }
 
+/**
+ * radeon_fence_driver_force_completion - force all fence waiter to complete
+ *
+ * @rdev: radeon device pointer
+ *
+ * In case of GPU reset failure make sure no process keep waiting on fence
+ * that will never complete.
+ */
+void radeon_fence_driver_force_completion(struct radeon_device *rdev)
+{
+   int ring;
+
+   for (ring = 0; ring < RADEON_NUM_RINGS; ring++) {
+   if (!rdev->fence_drv[ring].initialized)
+   continue;
+   radeon_fence_write(rdev, rdev->fence_drv[ring].sync_seq[ring], 
ring);
+   }
+}
+
 
 /*
  * Fence debugfs
-- 
1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26345] [845G] CPU/GPU incoherency

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

--- Comment #153 from Chris Wilson  ---
Now in kernel form as well:

commit b75e53bac7f4164e1c53a636352faa3d177b4beb
Author: Daniel Vetter 
Date:   Sun Dec 16 18:08:07 2012 +0100

drm/i915: Implement workaround for broken CS tlb on i830/845

Now that Chris Wilson demonstrated that the key for stability on early
gen 2 is to simple _never_ exchange the physical backing storage of
batch buffers I've tried a stab at a kernel solution. Doesn't look too
nefarious imho, now that I don't try to be too clever for my own good
any more.

v2: After discussing the various techniques, we've decided to always blit
batches on the suspect devices, but allow userspace to opt out of the
kernel workaround assume full responsibility for providing coherent
batches. The principal reason is that avoiding the blit does improve
performance in a few key microbenchmarks and also in cairo-trace
replays.

Signed-Off-by: Daniel Vetter 
Signed-off-by: Chris Wilson 

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

2012-12-17 Thread Christian König


On 17.12.2012 16:29, j.gli...@gmail.com wrote:

From: Jerome Glisse 

Force all fence to signal if GPU reset failed so no process get stuck
on waiting fence.

Signed-off-by: Jerome Glisse 


Seems to make sense.

Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon.h|  1 +
  drivers/gpu/drm/radeon/radeon_device.c |  1 +
  drivers/gpu/drm/radeon/radeon_fence.c  | 19 +++
  3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5d68346..9c7625c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -225,6 +225,7 @@ struct radeon_fence {
  int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
  int radeon_fence_driver_init(struct radeon_device *rdev);
  void radeon_fence_driver_fini(struct radeon_device *rdev);
+void radeon_fence_driver_force_completion(struct radeon_device *rdev);
  int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence 
**fence, int ring);
  void radeon_fence_process(struct radeon_device *rdev, int ring);
  bool radeon_fence_signaled(struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e2f5f88..774fae7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1357,6 +1357,7 @@ retry:
}
}
} else {
+   radeon_fence_driver_force_completion(rdev);
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
kfree(ring_data[i]);
}
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 22bd6c2..bf7b20e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -868,6 +868,25 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
mutex_unlock(&rdev->ring_lock);
  }
  
+/**

+ * radeon_fence_driver_force_completion - force all fence waiter to complete
+ *
+ * @rdev: radeon device pointer
+ *
+ * In case of GPU reset failure make sure no process keep waiting on fence
+ * that will never complete.
+ */
+void radeon_fence_driver_force_completion(struct radeon_device *rdev)
+{
+   int ring;
+
+   for (ring = 0; ring < RADEON_NUM_RINGS; ring++) {
+   if (!rdev->fence_drv[ring].initialized)
+   continue;
+   radeon_fence_write(rdev, rdev->fence_drv[ring].sync_seq[ring], 
ring);
+   }
+}
+
  
  /*

   * Fence debugfs


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Two patches for pageflips

Hi all,

So in the course of beating the pageflip paths senseless to test the new locking
scheme I've hunted down some bugs on g33. Sometimes we seemingly time out
waiting for the event - apparently the pageflip irq is lost somewhere. I've
tried to dig in, but lost myself completely in the rather fickle vblank mess in
drm_irq.c.

To not write off the last few days completely, I've figured I'll submit the two
sane patches for inclusion - the first should fix fbcon doing stupid things, the
second is purely paranoia (I hope at least). Imho longterm we need to seriously
look at the current vblank stuff - since it operates on pipe ides instead of
modeset crtc objects it's all rather fiddly and easily falls appart. But keeping
both ums and kms paths working is a challenge ...

Comments highly welcome.

Yours, Daniel

Daniel Vetter (2):
  drm/fb_helper: check whether fbcon is bound
  drm/i915: wake up all pageflip waiters

 drivers/gpu/drm/drm_fb_helper.c  |   39 +-
 drivers/gpu/drm/i915/intel_display.c |2 +-
 2 files changed, 30 insertions(+), 11 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/fb_helper: check whether fbcon is bound

We need to make sure that the fbcon is still bound when touching the
hw, since otherwise we might corrupt the modeset state of kms clients.
X mostly works around that with VT switching and setting the VT into
raw mode, which disables most fbcon events.

Raw kms test programs though don't do that dance, and in the future
we might want to aim to abolish CONFIG_VT anyway. So improve preventive
measures a bit. To do so, extract the existing logic for handling hotplug
events (which X can't block with the current set of tricks) and reuse
it for the fbdev blanking helper.

Long-term we really need to either scrap this all and only have a OOPS
console, or come up with a saner model for device ownership sharing
between fbdev/fbcon and kms userspace.

And for those wondering whether this check can't be added to fb_set_par e.g. to
prevent undue panning - drm initialization locking is too screwed up for that to
work out, I'm sorry :(

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c |   39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index be0f2d6..0c6e25e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -305,6 +305,24 @@ void drm_fb_helper_restore(void)
 }
 EXPORT_SYMBOL(drm_fb_helper_restore);
 
+static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct drm_crtc *crtc;
+   int bound = 0, crtcs_bound = 0;
+
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+   if (crtc->fb)
+   crtcs_bound++;
+   if (crtc->fb == fb_helper->fb)
+   bound++;
+   }
+
+   if (bound < crtcs_bound)
+   return false;
+   return true;
+}
+
 #ifdef CONFIG_MAGIC_SYSRQ
 static void drm_fb_helper_restore_work_fn(struct work_struct *ignored)
 {
@@ -338,6 +356,11 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
 * For each CRTC in this fb, turn the connectors on/off.
 */
drm_modeset_lock_all(dev);
+   if (!drm_fb_helper_is_bound(fb_helper)) {
+   drm_modeset_unlock_all(dev);
+   return;
+   }
+
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;
 
@@ -702,6 +725,11 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
*var,
int i;
 
drm_modeset_lock_all(dev);
+   if (!drm_fb_helper_is_bound(fb_helper)) {
+   drm_modeset_unlock_all(dev);
+   return -EBUSY;
+   }
+
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;
 
@@ -1369,21 +1397,12 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
struct drm_device *dev = fb_helper->dev;
int count = 0;
u32 max_width, max_height, bpp_sel;
-   int bound = 0, crtcs_bound = 0;
-   struct drm_crtc *crtc;
 
if (!fb_helper->fb)
return 0;
 
drm_modeset_lock_all(dev);
-   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
-   if (crtc->fb)
-   crtcs_bound++;
-   if (crtc->fb == fb_helper->fb)
-   bound++;
-   }
-
-   if (bound < crtcs_bound) {
+   if (!drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
drm_modeset_unlock_all(dev);
return 0;
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/i915: wake up all pageflip waiters

Otherwise it seems like we can get stuck with concurrent waiters.
Right now this /shouldn't/ be a problem, since all pending pageflip
waiters are serialized by the one mode_config.mutex, so there's at
most on waiter. But better paranoid than sorry, since this is tricky
code.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6056972..f49fd2a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6788,7 +6788,7 @@ static void do_intel_finish_page_flip(struct drm_device 
*dev,
 
obj = work->old_fb_obj;
 
-   wake_up(&dev_priv->pending_flip_queue);
+   wake_up_all(&dev_priv->pending_flip_queue);
 
queue_work(dev_priv->wq, &work->work);
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

2012-12-17 Thread j . glisse

From: Jerome Glisse 

radeon_fence_wait_empty_locked should not trigger GPU reset as no
place where it's call from would benefit from such thing and it
actually lead to a kernel deadlock in case the reset is triggered
from pm codepath. Instead force ring completion in place where it
makes sense or return early in others.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h|  2 +-
 drivers/gpu/drm/radeon/radeon_device.c | 13 +++--
 drivers/gpu/drm/radeon/radeon_fence.c  | 30 ++
 drivers/gpu/drm/radeon/radeon_pm.c | 15 ---
 4 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9c7625c..071b2d7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -231,7 +231,7 @@ void radeon_fence_process(struct radeon_device *rdev, int 
ring);
 bool radeon_fence_signaled(struct radeon_fence *fence);
 int radeon_fence_wait(struct radeon_fence *fence, bool interruptible);
 int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring);
-void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
+int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
 int radeon_fence_wait_any(struct radeon_device *rdev,
  struct radeon_fence **fences,
  bool intr);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 774fae7..53a9223 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1163,6 +1163,7 @@ int radeon_suspend_kms(struct drm_device *dev, 
pm_message_t state)
struct drm_crtc *crtc;
struct drm_connector *connector;
int i, r;
+   bool force_completion = false;
 
if (dev == NULL || dev->dev_private == NULL) {
return -ENODEV;
@@ -1205,8 +1206,16 @@ int radeon_suspend_kms(struct drm_device *dev, 
pm_message_t state)
 
mutex_lock(&rdev->ring_lock);
/* wait for gpu to finish processing current batch */
-   for (i = 0; i < RADEON_NUM_RINGS; i++)
-   radeon_fence_wait_empty_locked(rdev, i);
+   for (i = 0; i < RADEON_NUM_RINGS; i++) {
+   r = radeon_fence_wait_empty_locked(rdev, i);
+   if (r) {
+   /* delay GPU reset to resume */
+   force_completion = true;
+   }
+   }
+   if (force_completion) {
+   radeon_fence_driver_force_completion(rdev);
+   }
mutex_unlock(&rdev->ring_lock);
 
radeon_save_bios_scratch_regs(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index bf7b20e..28c09b6 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -609,26 +609,20 @@ int radeon_fence_wait_next_locked(struct radeon_device 
*rdev, int ring)
  * Returns 0 if the fences have passed, error for all other cases.
  * Caller must hold ring lock.
  */
-void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
+int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
 {
uint64_t seq = rdev->fence_drv[ring].sync_seq[ring];
+   int r;
 
-   while(1) {
-   int r;
-   r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
+   r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
+   if (r) {
if (r == -EDEADLK) {
-   mutex_unlock(&rdev->ring_lock);
-   r = radeon_gpu_reset(rdev);
-   mutex_lock(&rdev->ring_lock);
-   if (!r)
-   continue;
-   }
-   if (r) {
-   dev_err(rdev->dev, "error waiting for ring to become"
-   " idle (%d)\n", r);
+   return -EDEADLK;
}
-   return;
+   dev_err(rdev->dev, "error waiting for ring[%d] to become idle 
(%d)\n",
+   ring, r);
}
+   return 0;
 }
 
 /**
@@ -854,13 +848,17 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
  */
 void radeon_fence_driver_fini(struct radeon_device *rdev)
 {
-   int ring;
+   int ring, r;
 
mutex_lock(&rdev->ring_lock);
for (ring = 0; ring < RADEON_NUM_RINGS; ring++) {
if (!rdev->fence_drv[ring].initialized)
continue;
-   radeon_fence_wait_empty_locked(rdev, ring);
+   r = radeon_fence_wait_empty_locked(rdev, ring);
+   if (r) {
+   /* no need to trigger GPU reset as we are unloading */
+   radeon_fence_driver_force_completion(rdev);
+   }
wake_up_all(&rdev->fence_queue);
radeon_scratch

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

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





--- Comment #16 from Andre   2012-12-17 16:11:28 ---
Before i could crash X almost instantaneously by switching the kde (openGL)
screensaver back and forth.

Now the system runs for almost two hours without any problems so far.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Mon, Dec 17, 2012 at 9:26 AM, Sekhar Nori  wrote:
> Hi Rob,
>
>
> On Monday, December 17, 2012, Rob Clark wrote:
>>
>> On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark  wrote:
>> >> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
>> >> drivers. It's not really a big deal if it's only kernel code, but you
>> >> add device-tree bindings also, which is an external API that you need
>> >> to
>> >> support after adding it.
>> >>
>> >> I'd rather see the energy put to common display framework, and get this
>> >> whole panel/chip driver issue solved in a generic manner.
>> >
>> > yeah, I was expecting to migrate to CDF once it exists, but needed
>> > something for now.  I'm using the exercise to get my thoughts straight
>> > on how CDF should fit into KMS.  (One thing I plan to add support for
>> > is an i2c connected hdmi encoder.. which looks like it would fit well
>> > in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
>> > way.)
>> >
>> > If you have any suggestions on the DT bindings, I'd like to hear 'em.
>>
>> btw, a little bit of-topic, but speaking of DT...
>>
>> Anybody have any clue about how backlight devices are supposed to work
>> in this brave new DT world?
>
>
> See Runtime interpreted power sequences here:
>  http://lkml.indiana.edu/hypermail/linux/kernel/1208.2/00029.html
>
> It is an attempt to address this need.

hmm, I'm not really sure that is what is needed..  or rather, it might
perhaps make sense to have a generic backlight driver implementation
that could be used where appropriate, but I'm a bit suspicious about
that trying to cover absolutely everything.

>From the drm/display driver we don't even want to care how the
backlight is implemented.  You could have (just making something up
hypothetically) a backlight controlled via a uart or some sort of
other crazy magic.. and eventually the generic interpreter gets out of
hand.

Really I think we just want a way to retrieve a 'struct
backlight_device *' that is created somewhere else.  We don't care how
that backlight driver is implemented.  I don't think we want an
interpreter.. we want a way to lookup backlight device by name or
phandle or something like that.

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

2012-12-17 Thread Christian König


On 17.12.2012 17:04, j.gli...@gmail.com wrote:

From: Jerome Glisse 

radeon_fence_wait_empty_locked should not trigger GPU reset as no
place where it's call from would benefit from such thing and it
actually lead to a kernel deadlock in case the reset is triggered
from pm codepath. Instead force ring completion in place where it
makes sense or return early in others.

Signed-off-by: Jerome Glisse 


I wanted to stop losing GPU reset signals by moving the reset into 
radeon_fence_wait_empty locked, but it's true that in most cases it 
doesn't make much sense (suspend/finish) and I didn't know that it could 
cause a hang in the PM code.


We should probably fix the PM code to properly signal this condition to 
it's caller and reset the GPU when it is possible to do so, but fixing 
the deadlock is of course more important.


Also should probably go into the stable kernel as well, but anyway it is:

Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon.h|  2 +-
  drivers/gpu/drm/radeon/radeon_device.c | 13 +++--
  drivers/gpu/drm/radeon/radeon_fence.c  | 30 ++
  drivers/gpu/drm/radeon/radeon_pm.c | 15 ---
  4 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9c7625c..071b2d7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -231,7 +231,7 @@ void radeon_fence_process(struct radeon_device *rdev, int 
ring);
  bool radeon_fence_signaled(struct radeon_fence *fence);
  int radeon_fence_wait(struct radeon_fence *fence, bool interruptible);
  int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring);
-void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
+int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
  int radeon_fence_wait_any(struct radeon_device *rdev,
  struct radeon_fence **fences,
  bool intr);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 774fae7..53a9223 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1163,6 +1163,7 @@ int radeon_suspend_kms(struct drm_device *dev, 
pm_message_t state)
struct drm_crtc *crtc;
struct drm_connector *connector;
int i, r;
+   bool force_completion = false;
  
  	if (dev == NULL || dev->dev_private == NULL) {

return -ENODEV;
@@ -1205,8 +1206,16 @@ int radeon_suspend_kms(struct drm_device *dev, 
pm_message_t state)
  
  	mutex_lock(&rdev->ring_lock);

/* wait for gpu to finish processing current batch */
-   for (i = 0; i < RADEON_NUM_RINGS; i++)
-   radeon_fence_wait_empty_locked(rdev, i);
+   for (i = 0; i < RADEON_NUM_RINGS; i++) {
+   r = radeon_fence_wait_empty_locked(rdev, i);
+   if (r) {
+   /* delay GPU reset to resume */
+   force_completion = true;
+   }
+   }
+   if (force_completion) {
+   radeon_fence_driver_force_completion(rdev);
+   }
mutex_unlock(&rdev->ring_lock);
  
  	radeon_save_bios_scratch_regs(rdev);

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index bf7b20e..28c09b6 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -609,26 +609,20 @@ int radeon_fence_wait_next_locked(struct radeon_device 
*rdev, int ring)
   * Returns 0 if the fences have passed, error for all other cases.
   * Caller must hold ring lock.
   */
-void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
+int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
  {
uint64_t seq = rdev->fence_drv[ring].sync_seq[ring];
+   int r;
  
-	while(1) {

-   int r;
-   r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
+   r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
+   if (r) {
if (r == -EDEADLK) {
-   mutex_unlock(&rdev->ring_lock);
-   r = radeon_gpu_reset(rdev);
-   mutex_lock(&rdev->ring_lock);
-   if (!r)
-   continue;
-   }
-   if (r) {
-   dev_err(rdev->dev, "error waiting for ring to become"
-   " idle (%d)\n", r);
+   return -EDEADLK;
}
-   return;
+   dev_err(rdev->dev, "error waiting for ring[%d] to become idle 
(%d)\n",
+   ring, r);
}
+   return 0;
  }
  
  /**

@@ -854,13 +848,17 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
   */
  void radeon_fence_driver_fini(struct radeon_device *rdev)
  {
-   int ring;
+

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

2012-12-17 Thread Tomi Valkeinen

On 2012-12-14 02:04, Rob Clark wrote:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
> CMA helpers.  Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape).  There are also various LCD
> displays, for which support can be added (as I get hw to test on),
> and an external i2c HDMI encoder found on some boards.
> 
> The display controller supports a single CRTC.  And the encoder+
> connector are split out into sub-devices.  Depending on which LCD
> or external encoder is actually present, the appropriate output
> module(s) will be loaded.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/lcdc/Kconfig   |  11 +
>  drivers/gpu/drm/lcdc/Makefile  |   8 +
>  drivers/gpu/drm/lcdc/lcdc_crtc.c   | 544 +
>  drivers/gpu/drm/lcdc/lcdc_drv.c| 604 
> +
>  drivers/gpu/drm/lcdc/lcdc_drv.h| 162 ++
>  drivers/gpu/drm/lcdc/lcdc_regs.h   | 154 ++
>  drivers/gpu/drm/lcdc/lcdc_tfp410.c | 424 ++
>  drivers/gpu/drm/lcdc/lcdc_tfp410.h |  26 ++
>  10 files changed, 1936 insertions(+)
>  create mode 100644 drivers/gpu/drm/lcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/lcdc/Makefile
>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.c
>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.h
>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_regs.h
>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.c
>  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.h

"lcdc" is quite a common term. The directory should perhaps be something
like ti-lcdc?

Probably not relevant, but I wonder if the same LCDC was used in
omap1... It'd be nice to get rid of the omap1 fb driver.

I'm not very enthusiastic about adding ti-lcdc specific panel/chip
drivers. It's not really a big deal if it's only kernel code, but you
add device-tree bindings also, which is an external API that you need to
support after adding it.

I'd rather see the energy put to common display framework, and get this
whole panel/chip driver issue solved in a generic manner.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

2012-12-17 Thread Sekhar Nori

Hi Rob,

On Monday, December 17, 2012, Rob Clark wrote:

> On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark >
> wrote:
> >> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
> >> drivers. It's not really a big deal if it's only kernel code, but you
> >> add device-tree bindings also, which is an external API that you need to
> >> support after adding it.
> >>
> >> I'd rather see the energy put to common display framework, and get this
> >> whole panel/chip driver issue solved in a generic manner.
> >
> > yeah, I was expecting to migrate to CDF once it exists, but needed
> > something for now.  I'm using the exercise to get my thoughts straight
> > on how CDF should fit into KMS.  (One thing I plan to add support for
> > is an i2c connected hdmi encoder.. which looks like it would fit well
> > in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
> > way.)
> >
> > If you have any suggestions on the DT bindings, I'd like to hear 'em.
>
> btw, a little bit of-topic, but speaking of DT...
>
> Anybody have any clue about how backlight devices are supposed to work
> in this brave new DT world?


See Runtime interpreted power sequences here:
 http://lkml.indiana.edu/hypermail/linux/kernel/1208.2/00029.html

It is an attempt to address this need.

Thanks,
Sekhar

 In the old days, the board file would
> stuff a fxn ptr to control backlight in pdata for the driver.  But we
> don't have this any more.  I think I need some way to retrieve the
> 'struct backlight_device' ptr associated with the panel driver, so
> that the appropriate dpms fxn ptrs can enable/disable the backlight.
>
> I'm thinking the dt file should have something that looks roughly like:
>
> /* Settings for CDTech_S035Q01 / LCD3 cape: */
> panel {
> compatible = "lcdc,panel";
> pinctrl-names = "default";
> pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
> panel-info {
> ac-bias   = <255>;
> ac-bias-intrpt= <0>;
> dma-burst-sz  = <16>;
> bpp   = <16>;
> fdd   = <0x80>;
> tft-alt-mode  = <0>;
> stn-565-mode  = <0>;
> mono-8bit-mode= <0>;
> invert-line-clock = <1>;
> invert-frm-clock  = <1>;
> sync-edge = <0>;
> sync-ctrl = <1>;
> raster-order  = <0>;
> fifo-th   = <0>;
> };
> display-timings {
> native-mode = <&timing0>;
> timing0: 320x240 {
> hactive = <320>;
> vactive = <240>;
> hback-porch = <21>;
> hfront-porch= <58>;
> hsync-len   = <47>;
> vback-porch = <11>;
> vfront-porch= <23>;
> vsync-len   = <2>;
> clock-frequency = <800>;
> };
> };
>
> backlight {
> compatible = "tps65217-backlight";
> isel = <1>;
> fdim = <200>;
>
> tps = <&tps>;   /* link to the tps */
> brightness = <100>;
> };
> };
>
> display-timings is based on the of-videomode helpers patch..
> panel-info probably needs to be made to be something more generic, but
> we need something to know how to configure the crtc properly..
>
> but I'm not quite sure what to do with the backlight..
>
> BR,
> -R
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org 
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

2012-12-17 Thread Tomi Valkeinen

On 2012-12-17 16:36, Laurent Pinchart wrote:
> Hi Tomi,
> 
> I finally have time to work on a v3 :-)
> 
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>>> From: Laurent Pinchart 
>>>
>>> Hi everybody,
>>>
>>> Here's the second RFC of what was previously known as the Generic Panel
>>> Framework.
>>
>> Nice work! Thanks for working on this.
>>
>> I was doing some testing with the code, seeing how to use it in omapdss.
>> Here are some thoughts:
>>
>> In your model the DSS gets the panel devices connected to it from
>> platform data. After the DSS and the panel drivers are loaded, DSS gets
>> a notification and connects DSS and the panel.
>>
>> I think it's a bit limited way. First of all, it'll make the DT data a
>> bit more complex (although this is not a major problem). With your
>> model, you'll need something like:
>>
>> soc-base.dtsi:
>>
>> dss {
>>  dpi0: dpi {
>>  };
>> };
>>
>> board.dts:
>>
>> &dpi0 {
>>  panel = &dpi-panel;
>> };
>>
>> / {
>>  dpi-panel: dpi-panel {
>>  ...panel data...;
>>  };
>> };
>>
>> Second, it'll prevent hotplug, and even if real hotplug would not be
>> supported, it'll prevent cases where the connected panel must be found
>> dynamically (like reading ID from eeprom).
> 
> Hotplug definitely needs to be supported, as the common display framework 
> also 
> targets HDMI and DP. The notification mechanism was actually designed to 
> support hotplug.

HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a
cable hotplug, handled inside a driver, which doesn't have any effect on
the linux devices.

If we do implement HDMI and DP monitors with real linux drivers, then
yes, we could use real hotplug. But we could as well have the monitor
driver always registered, and just have a driver internal cable-hotplug
system.

To be honest, I'm not sure if implementing real hotplug is easily
possible, as we don't have real, probable (probe-able =) busses. So even
if we'd get a hotplug event of a new display device, what kind of device
would the bus master register? It has no way to know that.

> How do you see the proposal preventing hotplug ?

Well, probably it doesn't prevent. But it doesn't feel right to me.

Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be
probed. In the probe function it should somehow register itself to the
cdf, or perhaps the previous entity in the chain.

This sounds to me that the link is from the panel to the previous
entity, not the other way around as you describe, and also the previous
entity doesn't know of the panel entities.

>> Third, it kinda creates a cyclical dependency: the DSS needs to know
>> about the panel and calls ops in the panel, and the panel calls ops in
>> the DSS. I'm not sure if this is an actual problem, but I usually find
>> it simpler if calls are done only in one direction.
> 
> I don't see any way around that. The panel is not a standalone entity that 
> can 
> only receive calls (as it needs to control video streams, per your request 
> :-)) or only emit calls (as something needs to control it, userspace doesn't 
> control the panel directly).

Right, but as I see it, the destination of the panel's calls, and the
source of the calls to panel are different things. The destination is
the bus layer, dealing with the video signal being transferred. The
source is a bit higher level thing, something that's controlling the
display in general.

>> Here we wouldn't have similar display_entity as you have, but video sources
>> and displays. Video sources are elements in the video pipeline, and a video
>> source is used only by the next downstream element. The last element in the
>> pipeline would not be a video source, but a display, which would be used by
>> the upper layer.
> 
> I don't think we should handle pure sources, pure sinks (displays) and mixed 
> entities (transceivers) differently. I prefer having abstract entities that 
> can have a source and a sink, and expose the corresponding operations. That 
> would make pipeline handling much easier, as the code will only need to deal 
> with a single type of object. Implementing support for entities with multiple 
> sinks and/or sources would also be possible.

Ok. I think having pure sources is simpler model, but it's true that if
we need to iterate and study the pipeline during runtime, it's probably
better to have single entities with multiple sources/sinks.

>> Video source's ops would deal with things related to the video bus in
>> question, like configuring data lanes, sending DSI packets, etc. The
>> display ops would be more high level things, like enable, update, etc.
>> Ac

Re: [RFC v2 0/5] Common Display Framework

2012-12-17 Thread Jani Nikula


Hi Laurent -

On Mon, 17 Dec 2012, Laurent Pinchart  wrote:
> Hi Tomi,
>
> I finally have time to work on a v3 :-)
>
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>> > From: Laurent Pinchart 
>> > 
>> > Hi everybody,
>> > 
>> > Here's the second RFC of what was previously known as the Generic Panel
>> > Framework.
>> 
>> Nice work! Thanks for working on this.
>> 
>> I was doing some testing with the code, seeing how to use it in omapdss.
>> Here are some thoughts:
>> 
>> In your model the DSS gets the panel devices connected to it from
>> platform data. After the DSS and the panel drivers are loaded, DSS gets
>> a notification and connects DSS and the panel.
>> 
>> I think it's a bit limited way. First of all, it'll make the DT data a
>> bit more complex (although this is not a major problem). With your
>> model, you'll need something like:
>> 
>> soc-base.dtsi:
>> 
>> dss {
>>  dpi0: dpi {
>>  };
>> };
>> 
>> board.dts:
>> 
>> &dpi0 {
>>  panel = &dpi-panel;
>> };
>> 
>> / {
>>  dpi-panel: dpi-panel {
>>  ...panel data...;
>>  };
>> };
>> 
>> Second, it'll prevent hotplug, and even if real hotplug would not be
>> supported, it'll prevent cases where the connected panel must be found
>> dynamically (like reading ID from eeprom).
>
> Hotplug definitely needs to be supported, as the common display framework 
> also 
> targets HDMI and DP. The notification mechanism was actually designed to 
> support hotplug.

I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?

BR,
Jani.


>
> How do you see the proposal preventing hotplug ?
>
>> Third, it kinda creates a cyclical dependency: the DSS needs to know
>> about the panel and calls ops in the panel, and the panel calls ops in
>> the DSS. I'm not sure if this is an actual problem, but I usually find
>> it simpler if calls are done only in one direction.
>
> I don't see any way around that. The panel is not a standalone entity that 
> can 
> only receive calls (as it needs to control video streams, per your request 
> :-)) or only emit calls (as something needs to control it, userspace doesn't 
> control the panel directly).
>
>> What I suggest is take a simpler approach, something alike to how regulators
>> or gpios are used, even if slightly more complex than those: the entity that
>> has a video output (SoC's DSS, external chips) offers that video output as
>> resource. It doesn't know or care who uses it. The user of the video output
>> (panel, external chips) will find the video output (to which it is connected
>> in the HW) by some means, and will use different operations on that output
>> to operate the device.
>> 
>> This would give us something like the following DT data:
>> 
>> soc-base.dtsi:
>> 
>> dss {
>>  dpi0: dpi {
>>  };
>> };
>> 
>> board.dts:
>> 
>> / {
>>  dpi-panel: dpi-panel {
>>  source = <&dpi0>;
>>  ...panel data...;
>>  };
>> };
>> 
>> The panel driver would do something like this in its probe:
>> 
>> int dpi_panel_probe()
>> {
>>  // Find the video source, increase ref
>>  src = get_video_source_from_of("source");
>> 
>>  // Reserve the video source for us. others can still get and
>>  // observe it, but cannot use it as video data source.
>>  // I think this should cascade upstream, so that after this call
>>  // each video entity from the panel to the SoC's CRTC is
>>  // reserved and locked for this video pipeline.
>>  reserve_video_source(src);
>> 
>>  // set DPI HW configuration, like DPI data lines. The
>>  // configuration would come from panel's platform data
>>  set_dpi_config(src, config);
>> 
>>  // register this panel as a display.
>>  register_display(this);
>> }
>> 
>> 
>> The DSS's dpi driver would do something like:
>> 
>> int dss_dpi_probe()
>> {
>>  // register as a DPI video source
>>  register_video_source(this);
>> }
>> 
>> A DSI-2-DPI chip would do something like:
>> 
>> int dsi2dpi_probe()
>> {
>>  // get, reserve and config the DSI bus from SoC
>>  src = get_video_source_from_of("source");
>>  reserve_video_source(src);
>>  set_dsi_config(src, config);
>> 
>>  // register as a DPI video source
>>  register_video_source(this);
>> }
>> 
>> 
>> Here we wouldn't have similar display_entity as you have, but video sources
>> and displays. Video sources are elements in the video pipeline, and a video
>> source is used only by the next downstream element. The last element in the
>> pipeline would not be a video source, but a display, which would be used by
>> the upp

Re: [PATCHv3 4/7] gpu: host1x: Add debug support

2012-12-17 Thread Joe Perches

On Mon, 2012-12-17 at 16:01 +0200, Terje Bergström wrote:
> Considering the amount of feedback I've received from the patches, they
> must be top notch quality!

Maybe.
Maybe no one else has the hardware.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

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

--- Comment #2 from Henrique Dias  ---
Today messages from dmesg:

[ 4115.879007] nouveau E[  PGRAPH][:01:00.0] TRAP_MP_EXEC - TP 0 MP 0:
INVALID_OPCODE at 07ff00 warp 0, opcode  
[ 4115.879007] nouveau  [  PGRAPH][:01:00.0]  TRAP
[ 4115.879007] nouveau E[  PGRAPH][:01:00.0] ch 5 [0x00077db000] subc 3
class 0x8297 mthd 0x1694 data 0x00010031

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

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

--- Comment #3 from Henrique Dias  ---
Created attachment 71674
  --> https://bugs.freedesktop.org/attachment.cgi?id=71674&action=edit
my graphics are a mess.

my graphics are a mess.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

GPU lockup CP stall for more than 10000msec on latest vanilla git

As soon as I open the following website:
http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html

my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:


Dec 17 17:41:39 x4 kernel: [drm] Initialized drm 1.1.0 20060810
Dec 17 17:41:39 x4 kernel: [drm] radeon defaulting to kernel modesetting.
Dec 17 17:41:39 x4 kernel: [drm] radeon kernel modesetting enabled.
Dec 17 17:41:39 x4 kernel: [drm] initializing kernel modesetting (RS780 
0x1002:0x9614 0x1043:0x834D).
Dec 17 17:41:39 x4 kernel: [drm] register mmio base: 0xFBEE
Dec 17 17:41:39 x4 kernel: [drm] register mmio size: 65536
Dec 17 17:41:39 x4 kernel: ATOM BIOS: 113
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 - 
0xC7FF (128M used)
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
Dec 17 17:41:39 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Dec 17 17:41:39 x4 kernel: [drm] RAM width 32bits DDR
Dec 17 17:41:39 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
4083532 kiB
Dec 17 17:41:39 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
2097152 kiB
Dec 17 17:41:39 x4 kernel: [TTM] Initializing pool allocator
Dec 17 17:41:39 x4 kernel: [TTM] Initializing DMA pool allocator
Dec 17 17:41:39 x4 kernel: [drm] radeon: 128M of VRAM memory ready
Dec 17 17:41:39 x4 kernel: [drm] radeon: 512M of GTT memory ready.
Dec 17 17:41:39 x4 kernel: [drm] Supports vblank timestamp caching Rev 1 
(10.10.2010).
Dec 17 17:41:39 x4 kernel: [drm] Driver supports precise vblank timestamp query.
Dec 17 17:41:39 x4 kernel: [drm] radeon: irq initialized.
Dec 17 17:41:39 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
131072
Dec 17 17:41:39 x4 kernel: [drm] Loading RS780 Microcode
Dec 17 17:41:39 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
0xC004).
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: WB enabled
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: fence driver on ring 0 use gpu 
addr 0xac00 and cpu addr 0x8802163acc00
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: fence driver on ring 3 use gpu 
addr 0xac0c and cpu addr 0x8802163acc0c
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: setting latency timer to 64
Dec 17 17:41:39 x4 kernel: [drm] ring test on 0 succeeded in 0 usecs
Dec 17 17:41:39 x4 kernel: [drm] ring test on 3 succeeded in 1 usecs
Dec 17 17:41:39 x4 kernel: [drm] ib test on ring 0 succeeded in 0 usecs
Dec 17 17:41:39 x4 kernel: [drm] ib test on ring 3 succeeded in 0 usecs
Dec 17 17:41:39 x4 kernel: [drm] Radeon Display Connectors
Dec 17 17:41:39 x4 kernel: [drm] Connector 0:
Dec 17 17:41:39 x4 kernel: [drm]   VGA-1
Dec 17 17:41:39 x4 kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 
0x7e48 0x7e4c 0x7e4c
Dec 17 17:41:39 x4 kernel: [drm]   Encoders:
Dec 17 17:41:39 x4 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Dec 17 17:41:39 x4 kernel: [drm] Connector 1:
Dec 17 17:41:39 x4 kernel: [drm]   DVI-D-1
Dec 17 17:41:39 x4 kernel: [drm]   HPD3
Dec 17 17:41:39 x4 kernel: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 
0x7e58 0x7e5c 0x7e5c
Dec 17 17:41:39 x4 kernel: [drm]   Encoders:
Dec 17 17:41:39 x4 kernel: [drm] DFP3: INTERNAL_KLDSCP_LVTMA
Dec 17 17:41:39 x4 kernel: [drm] radeon: power management initialized
Dec 17 17:41:39 x4 kernel: [drm] fb mappable at 0xF0142000
Dec 17 17:41:39 x4 kernel: [drm] vram apper at 0xF000
Dec 17 17:41:39 x4 kernel: [drm] size 7299072
Dec 17 17:41:39 x4 kernel: [drm] fb depth is 24
Dec 17 17:41:39 x4 kernel: [drm]pitch is 6912
Dec 17 17:41:39 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
Dec 17 17:41:39 x4 kernel: Console: switching to colour frame buffer device 
131x105
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: fb0: radeondrmfb frame buffer 
device
Dec 17 17:41:39 x4 kernel: radeon :01:05.0: registered panic notifier
Dec 17 17:41:39 x4 kernel: [drm] Initialized radeon 2.27.0 20080528 for 
:01:05.0 on minor 0
...
Dec 17 19:12:33 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more 
than 1msec
Dec 17 19:12:33 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 
0x00022777 last fence id 0x00022774)

after reboot:

Dec 17 19:14:32 x4 kernel: Adding 4194300k swap on /var/cache/swapfile.img.  
Priority:-1 extents:9 across:629080060k 
Dec 17 19:16:44 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more 
than 1msec
Dec 17 19:16:44 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 
0x0954 last fence id 0x0952)
Dec 17 19:16:44 x4 kernel: radeon :01:05.0: Saved 89 dwords of commands on 
ring 0.
Dec 17 19:16:44 x4 kernel: radeon :01:05.0: GPU softreset 
Dec 17 19:16:44 x4 kernel: radeon :01:05.0:   
R_008010_GRBM_STATUS=0xA000B030
Dec 17 19:16:44 x4 kernel: radeon :01:05.0:   
R_008014_GRBM_STATUS2=0x0003
Dec 17 19:16:44 x4 kernel: radeon :01:05.0:   
R_000E50_SRBM_STATUS=0x20005040
Dec 17 19:16:44 x4

Re: [PATCH 0/3] add mie driver for exynos

2012-12-17 Thread Stéphane Marchesin

On Tue, Dec 11, 2012 at 8:01 PM, Inki Dae  wrote:
>
>
> 2012/12/12 Stéphane Marchesin 
>>
>> On Mon, Dec 10, 2012 at 1:27 AM, Inki Dae  wrote:
>> >
>> >
>> > 2012/12/10 Stéphane Marchesin 
>> >>
>> >> On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae  wrote:
>> >> >
>> >> >
>> >> > 2012/12/6 R. Chandrasekar 
>> >> >
>> >> >> From: "R. Chandrasekar" 
>> >> >>
>> >> >> this patch set adds the driver support for the dithering
>> >> >> functionality
>> >> >> of
>> >> >> the
>> >> >> mobile image enhancement (mie) module.
>> >> >>
>> >> >> device tree support is added for mie.
>> >> >>
>> >> >> fimd adds the mie module as plugin and calls the dithering function.
>> >> >> dithere is
>> >> >> required when the panels bpp is less then fimd output.
>> >> >>
>> >> >> though mie mie has other functionalities, current system uses only
>> >> >> dithereing.
>> >> >>
>> >> >
>> >> > Please, move mie module into drivers/video/exynos. The mie is a
>> >> > interface
>> >> > between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be
>> >> > displayed. And it seems like that this doesn't need drm
>> >> > framework-relevant
>> >> > interfaces, such as gem.
>> >>
>> >> Well, if you want to support it from the DRM, it should live in
>> >> drivers/gpu/drm, and I don't think you should add another platform
>> >> driver in the first place. The profusion of platform drivers in exynos
>> >> makes it really difficult to support suspend/resume and initialization
>> >> properly as many devices which operate separately need to sync through
>> >> global variables.
>> >>
>> >
>> > MIE could be used by linux framebuffer-based specific driver(s3c-fb)
>> > also.
>>
>> Yes, but it is a DRM driver we're talking about here. Again it is
>> really difficult to work with it across suspend-resume. I don't think
>
>
> You want to use Exynos drm core framework just for suspend/resume to MIE
> module? as I mentioned before, I think the framework suitable to MIE is
> Common Display Framework. Of course, maybe you should add new features to
> Common Display Framework for it like MIPI DBI bus support framework because
> current Common Display Framework supports only display bus. Logically, MIE
> should be used without dependency of any frameworks such as Linux
> Framebuffer or DRM frameworks. And see the below hardware path,
>
> fimdmie-lcd panel
> fimdmiemipi-dsi--lcd panel
> fimdmieeDP---lcd panel
>
> Thus, the MIE is placed between fimd and lcd panel, mipi dsi or eDP.

But for example the MIE only affects one of the layers. So your
drawing doesn't match reality. You'd need to pass a layer number
somehow which the API doesn't seem to allow...

> And
> fimd, as display controller, could be controlled by linux framebuffer or drm
> framework.
>

I don't think it's a valid point. If the framebuffer is properly done
on top of the DRM, you don't need all of that at all.

Stéphane


>>
>> the DRM was ever meant to be a collection of independent platform
>> drivers.
>>
>>
>> > If linux framebuffer-based driver want to use this mie module, should
>> > the
>> > mie module be placed in drivers/video coping it? I think it's not good
>> > so
>> > it's better way to use this mie module commonly without duplicated
>> > codes.
>> > And mipi-dsi and eDP drivers also have their own platform device/driver
>> > and
>> > are being used by exynos drm driver or s3c-fb driver. Of course, for
>> > some
>> > IPs such as mie between display controller and lcd panel, It seems like
>> > that
>> > there should be proper framework or interfaces in drivers/video/exynos
>> > or
>> > somewhere so that other frameworks can use it commonly. And drm and
>> > linux
>> > framebuffer drivers should call the interfaces.
>>
>> For the short term, I think it's fine to duplicate the code.
>>
>> For the longer term, I think framebuffer support should be provided by
>> the drm framebuffer compat layer, and s3c-fb should disappear. This is
>> what has been done with all the other DRM drivers.
>>
>> Stéphane
>>
>>
>> >
>> > Thanks,
>> > Inki Dae
>> >
>> >> Stéphane
>> >>
>> >>
>> >> >
>> >> > And also, please refer to the below link, Common Display Framework,
>> >> > for
>> >> > more
>> >> > generic way.
>> >> >
>> >> >
>> >> >
>> >> > http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
>> >> >
>> >> > Thanks,
>> >> > Inki Dae
>> >> >
>> >> >>
>> >> >> R. Chandrasekar (3):
>> >> >>   DTS: exynos: add device tree support for exynos mie
>> >> >>   drm: fimd: add mie plugin support for dithering
>> >> >>   drm: mie: add mie driver for exynos
>> >> >>
>> >> >>  arch/arm/boot/dts/exynos5250.dtsi   |7 +-
>> >> >>  drivers/gpu/drm/exynos/Kconfig  |7 +
>> >> >>  drivers/gpu/drm/exynos/Makefile |1 +
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   58 +-
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_fimd_common.h |   20 ++
>> >> >>

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

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

--- Comment #4 from Henrique Dias  ---
more dmesg messages:

[ 1123.476832] nouveau E[  PGRAPH][:01:00.0] TRAP_MP_EXEC - TP 0 MP 0:
INVALID_OPCODE at 07ff00 warp 0, opcode  
[ 1123.476839] nouveau  [  PGRAPH][:01:00.0]  TRAP
[ 1123.476844] nouveau E[  PGRAPH][:01:00.0] ch 6 [0x000765e000] subc 3
class 0x8297 mthd 0x1694 data 0x00010031

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/i915: wake up all pageflip waiters

2012-12-17 Thread Chris Wilson

On Mon, 17 Dec 2012 16:59:00 +0100, Daniel Vetter  
wrote:
> Otherwise it seems like we can get stuck with concurrent waiters.
> Right now this /shouldn't/ be a problem, since all pending pageflip
> waiters are serialized by the one mode_config.mutex, so there's at
> most on waiter. But better paranoid than sorry, since this is tricky
> code.

Hmm.

BUG_ON(waitqueue_active()) before joining the waitqueue?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] add mie driver for exynos

On Mon, Dec 17, 2012 at 7:59 PM, Stéphane Marchesin
 wrote:
>
>> And
>> fimd, as display controller, could be controlled by linux framebuffer or drm
>> framework.
>>
>
> I don't think it's a valid point. If the framebuffer is properly done
> on top of the DRM, you don't need all of that at all.

Imo for hw with full-fledge drm kms drivers the sanest option for
traditional fbdev support is to pimp the fb helpers a bit. Pretty much
the only thing left that a real fbdev driver can do afaics is fb
reallocation - it shouldn't be too hard to (optionally) implement this
in the helpers ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-17 Thread Stephen Warren

On 12/16/2012 09:37 AM, Terje Bergström wrote:
...
> ... Sure we could tell DC to ask its parent
> (host1x), and call host1x driver with platform_device pointer found that
> way, and host1x would return a pointer to tegradrm's data. Hanging the
> data onto host1x driver is just a more complicated way of implementing
> global data

No it's not; at that point, the data is no longer global, but specific
to the driver instance.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset

2012-12-17 Thread Paul Bolle

On an (outdated) laptop the radeon driver (almost always) prints, during
the first resume of each session:
[drm] crtc 1 is connected to a TV

This message is a bit puzzling as, as far as I know, no TV has ever
been connected to this laptop. Anyhow, before v3.5, if that happened the
radeon driver then printed an error during all following resumes:
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!

(-35 is -EDEADLK.) But the resume would succeed and the driver seemed to
run without too much trouble. From v3.5 onwards things changed. If the
(puzzling) message about crtc 1 was printed on first resume the laptop
would simply hang on second resume. Only a manual power off would then
be possible. In that case nothing of interest would be found in the
(truncated) logs.  And, most annoyingly, the hang would never happen if
the laptop was booted with, say, "console=ttyS0,115200n8" added to the
kernel command line.

I bisected the hang to commit 6c6f478370eccfbfafbdc6fc55c0def03e58f124
("drm/radeon: rework recursive gpu reset handling"), which was added in
the v3.5 release cycle. After discovering that and poking at the driver
it turned out that this hang is triggered by radeon_cs_handle_lockup()
returning -EAGAIN after successfully resetting the gpu. Simply returning
0 makes the hang disappear (and makes the drm error reappear).

Nothing in the code or the commit explanation clarifies why -EAGAIN
should be returned on successful gpu reset. So I suggest
radeon_cs_handle_lockup() simply returns what radeon_gpu_reset()
returns, eg 0 (on success) or a negative error code (on failure).

Signed-off-by: Paul Bolle 
---
0) This exact patch is untested (but I run something comparable).

1) Sent as an RFC because I do not understand why this laptop (almost
always) prints the "crtc 1" message on first resume. Note that another
workaround for this hang is simply booting with "radeon.tv=0".

2) Also sent as an RFC because I have no idea whatsoever why returning
-EAGAIN will hang the machine. I guess it's returned to userland by
radeon_cs_ioctl(). What code uses that ioctl? And what does that code do
on -EAGAIN that hangs this laptop?

3) A third reason to send this as an RFC is that I also have no idea why
this hang doesn't happen when booting with "console=ttyS0,115200n8" or
even "console=tty0"! But I guess I'm now allowed to call this hang a
Heisenbug.

 drivers/gpu/drm/radeon/radeon_cs.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 41672cc..a302c00 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -486,11 +486,8 @@ out:
 
 static int radeon_cs_handle_lockup(struct radeon_device *rdev, int r)
 {
-   if (r == -EDEADLK) {
+   if (r == -EDEADLK)
r = radeon_gpu_reset(rdev);
-   if (!r)
-   r = -EAGAIN;
-   }
return r;
 }
 
-- 
1.7.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf
 wrote:
> As soon as I open the following website:
> http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html
>
> my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:

Is this a regression?  Most likely a 3D driver bug unless you are only
seeing it with specific kernels.  What browser are you using and do
you have hw accelerated webgl, etc. enabled?  If so, what version of
mesa are you using?

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44126] [r300g] 0ad: carpet textures "flash" and get hidden by ground texture.

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

Tomasz P.  changed:

   What|Removed |Added

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

--- Comment #1 from Tomasz P.  ---
With current mesa and 0ad a11 all seems to be good.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

Applied to my fixes branch.  Thanks!

2012/12/17 Christian König :
> Reviewed-by: Christian König 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

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

--- Comment #5 from Henrique Dias  ---
Created attachment 71698
  --> https://bugs.freedesktop.org/attachment.cgi?id=71698&action=edit
Another screenshot

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

Added to fixes and stable.  Thanks!

On Mon, Dec 17, 2012 at 11:41 AM, Christian König
 wrote:
> On 17.12.2012 17:04, j.gli...@gmail.com wrote:
>>
>> From: Jerome Glisse 
>>
>> radeon_fence_wait_empty_locked should not trigger GPU reset as no
>> place where it's call from would benefit from such thing and it
>> actually lead to a kernel deadlock in case the reset is triggered
>> from pm codepath. Instead force ring completion in place where it
>> makes sense or return early in others.
>>
>> Signed-off-by: Jerome Glisse 
>
>
> I wanted to stop losing GPU reset signals by moving the reset into
> radeon_fence_wait_empty locked, but it's true that in most cases it doesn't
> make much sense (suspend/finish) and I didn't know that it could cause a
> hang in the PM code.
>
> We should probably fix the PM code to properly signal this condition to it's
> caller and reset the GPU when it is possible to do so, but fixing the
> deadlock is of course more important.
>
> Also should probably go into the stable kernel as well, but anyway it is:
>
> Reviewed-by: Christian König 
>
>
>> ---
>>   drivers/gpu/drm/radeon/radeon.h|  2 +-
>>   drivers/gpu/drm/radeon/radeon_device.c | 13 +++--
>>   drivers/gpu/drm/radeon/radeon_fence.c  | 30
>> ++
>>   drivers/gpu/drm/radeon/radeon_pm.c | 15 ---
>>   4 files changed, 38 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 9c7625c..071b2d7 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -231,7 +231,7 @@ void radeon_fence_process(struct radeon_device *rdev,
>> int ring);
>>   bool radeon_fence_signaled(struct radeon_fence *fence);
>>   int radeon_fence_wait(struct radeon_fence *fence, bool interruptible);
>>   int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring);
>> -void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int
>> ring);
>> +int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring);
>>   int radeon_fence_wait_any(struct radeon_device *rdev,
>>   struct radeon_fence **fences,
>>   bool intr);
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 774fae7..53a9223 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -1163,6 +1163,7 @@ int radeon_suspend_kms(struct drm_device *dev,
>> pm_message_t state)
>> struct drm_crtc *crtc;
>> struct drm_connector *connector;
>> int i, r;
>> +   bool force_completion = false;
>> if (dev == NULL || dev->dev_private == NULL) {
>> return -ENODEV;
>> @@ -1205,8 +1206,16 @@ int radeon_suspend_kms(struct drm_device *dev,
>> pm_message_t state)
>> mutex_lock(&rdev->ring_lock);
>> /* wait for gpu to finish processing current batch */
>> -   for (i = 0; i < RADEON_NUM_RINGS; i++)
>> -   radeon_fence_wait_empty_locked(rdev, i);
>> +   for (i = 0; i < RADEON_NUM_RINGS; i++) {
>> +   r = radeon_fence_wait_empty_locked(rdev, i);
>> +   if (r) {
>> +   /* delay GPU reset to resume */
>> +   force_completion = true;
>> +   }
>> +   }
>> +   if (force_completion) {
>> +   radeon_fence_driver_force_completion(rdev);
>> +   }
>> mutex_unlock(&rdev->ring_lock);
>> radeon_save_bios_scratch_regs(rdev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
>> b/drivers/gpu/drm/radeon/radeon_fence.c
>> index bf7b20e..28c09b6 100644
>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>> @@ -609,26 +609,20 @@ int radeon_fence_wait_next_locked(struct
>> radeon_device *rdev, int ring)
>>* Returns 0 if the fences have passed, error for all other cases.
>>* Caller must hold ring lock.
>>*/
>> -void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
>> +int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring)
>>   {
>> uint64_t seq = rdev->fence_drv[ring].sync_seq[ring];
>> +   int r;
>>   - while(1) {
>> -   int r;
>> -   r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
>> +   r = radeon_fence_wait_seq(rdev, seq, ring, false, false);
>> +   if (r) {
>> if (r == -EDEADLK) {
>> -   mutex_unlock(&rdev->ring_lock);
>> -   r = radeon_gpu_reset(rdev);
>> -   mutex_lock(&rdev->ring_lock);
>> -   if (!r)
>> -   continue;
>> -   }
>> -   if (r) {
>> -   dev_err(rdev->dev, "error waiting for ring to
>> become"
>> -   " idle (%d)\n", r);
>> +

[Bug 57670] segfault with etqw.demo

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

Laurent carlier  changed:

   What|Removed |Added

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

--- Comment #2 from Laurent carlier  ---
Fix applied upstream

https://github.com/divVerent/s2tc/commit/86b61ca2e2906297d972e8a4c1e212e3deac99ef

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 16:32 -0500, Alex Deucher wrote:
> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf
>  wrote:
> > As soon as I open the following website:
> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html
> >
> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:
> 
> Is this a regression?  Most likely a 3D driver bug unless you are only
> seeing it with specific kernels.  What browser are you using and do
> you have hw accelerated webgl, etc. enabled?  If so, what version of
> mesa are you using?

This is a regression, because it is caused by yesterdays merge of
drm-next by Linus. IOW I only see this bug when running a
v3.7-9432-g9360b53 kernel. 

-- 
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

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

--- Comment #6 from Henrique Dias  ---
# lspci -nnvv

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G86 [GeForce 8400M
G] [10de:0428] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. Device [1462:3fe9]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- ___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 22:48 +0100, Markus Trippelsdorf wrote:
> On 2012.12.17 at 16:32 -0500, Alex Deucher wrote:
> > On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf
> >  wrote:
> > > As soon as I open the following website:
> > > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html
> > >
> > > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:
> > 
> > Is this a regression?  Most likely a 3D driver bug unless you are only
> > seeing it with specific kernels.  What browser are you using and do
> > you have hw accelerated webgl, etc. enabled?  If so, what version of
> > mesa are you using?
> 
> This is a regression, because it is caused by yesterdays merge of
> drm-next by Linus. IOW I only see this bug when running a
> v3.7-9432-g9360b53 kernel. 

Forgot to mention that I don't use webgl. Browser is Firefox. And I use
my screen in portrait mode:

 DVI-0 connected 1050x1680+0+0 left (normal left inverted right x axis y axis) 
434mm x 270mm

-- 
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Vikas,

On Friday 14 December 2012 10:27:12 Vikas Sajjan wrote:
> 
> Hi All,
> 
> I was thinking of porting samsung exynos 5250 display driver as per CDF,
> 
> but i had certain doubts and wanted to discuss with you guys,
> 
>  1. Samsung Exynos supports MIPI DSI based display panels, wondering how to
>  accommodate such thing in.  I mean how do I register my MIPI DSI driver
>  with CDF. because the s6e8ax0 AMOLED lcd driver registers itself with MIPI
>  DSI driver, and later the MIPI DSI driver probe calls the probe and init
>  sequence of the LCD driver.
>  Wanted know if anybody about any thoughts on this ?

As explained in my previous mail, MIPI DSI panels should be supported in a 
similar way as MIPI DPI panels. The DSI API is missing, but only because 
nobody has implemented it yet.

> 2.One more thing is, when went through the patchset I coudn't get who
> will register the mipi_dbi_bus_ops?

That's the display controller driver. A sample implementation is available at 
http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel, see 
the "fbdev: sh_mobile_lcdc: Add generic panel support" and "fbdev: 
sh_mobile_lcdc: MIPI DBI bus support" patches.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf
 wrote:
> On 2012.12.17 at 16:32 -0500, Alex Deucher wrote:
>> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf
>>  wrote:
>> > As soon as I open the following website:
>> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html
>> >
>> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:
>>
>> Is this a regression?  Most likely a 3D driver bug unless you are only
>> seeing it with specific kernels.  What browser are you using and do
>> you have hw accelerated webgl, etc. enabled?  If so, what version of
>> mesa are you using?
>
> This is a regression, because it is caused by yesterdays merge of
> drm-next by Linus. IOW I only see this bug when running a
> v3.7-9432-g9360b53 kernel.

Can you bisect?  I'm guessing it may be related to the new DMA rings.  Possibly:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2
or
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4d75658bffea78f0c6f82fd46df1ec983ccacdf0

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

2012-12-17 Thread Thomas Hellström


On 12/14/12 7:50 PM, Daniel Vetter wrote:

Dude, you're seriously overshooting here. This patch isn't required
_at_ _all_ to do cross device sharing/reservations/whatever. We've
simply discussed TTM documentation in the context of Maartens work,
and I've suggested to include all the TTM kerneldoc into a nice
DocBook. That way the kerneldoc stuff gets at least check for correct
parameters and similar trivial stuff (core drm sucked royally in that
regard). So Maarten jabbed around, I and Dave joined in and since
besides vmwgfx nothing else uses it at all I've figured this can't
hurt.


Well I appreciate the effort, but judging from the commit message, the 
idea was to

shovel the ttm lock under the carpet so that nobody else would use it, which
would simplify the cross device reservation work, since it then wouldn't 
have
to take into account a client blocking all other clients from reserving. 
A similar mechanism
(not necessarily the TTM lock) needs to be in place for cross 
reservation for item 3) listed below,
otherwise a TTM driver wouldn't be able to defragment or to guarantee a 
certain amount
of graphics memory for command submission. (This was discussed in the 
phone meeting in Copenhagen).




If you think all the radeon/nouveau/i915/whatever drivers are screwed
up beyond repair and need to have the ttm_lock.c file where it is as a
stern reminder, I don't care one bit. Personally I think the right
solution is to abolish the drm master concept entirely and aim for
CONFIG_VT=n. Insulation is a userspace problem which e.g. policykit or
whatever the latest thing is can do, or which should be solved for
real with per-process address spaces. Everything else smells too fishy
for me. So yeah, I don't think the fact that vmwgfx is the only driver
with a ->set_master and ->drop_master callback is a good sign, but
alas, not my driver and the core impact is negligible.


The fact remains that as long as the current master concept is in place, 
a drm client authenticated by
one master (perhaps already terminated), is authenticated for all 
masters, and IMO that's a pretty nasty

security problem.
That doesn't mean all the non-vmwgfx drivers are screwed up beyond 
repair; it wouldn't be too hard to block clients belonging to other 
masters than the current master in the DRM ioctl dispatcher, which would 
have the additional benefit that the ttm lock can be reduced to a 
read-write semaphore for cross-device reservation purposes.



Finally, I'd like to add that IMHO disussions like

 but seriously, ttm_lock is best left undocumented since
nobody should use that unholy thing..
 agreed ;-)
 imo we should shovel that under drm/vmwgfx ...
 amen
 that thing scares me
 out of sight, out of mind ...

where nobody apparently tried to figure out what purpose the code serves 
and therefore failed to understand it

are pretty unprofessional, and even more so when used as commit messages.



Cheers, Daniel


Cheers,
Thomas






On Fri, Dec 14, 2012 at 4:51 PM, Thomas Hellström  wrote:

Nack,

I'm not against moving the TTM lock away,
when a replacement strategy for the main use case is presented.

but using wording like "unholy", "scares" just because there is a lack of
understanding or because it gets in the way of implementing cross-device
reservation is a really really bad idea, and FWIW I think it's an even
better idea to refrain from such wording unless you completely understand
the problem and have a better solution in place.

No other driver uses it, probably simply because the driver writers probably
aren't aware of the use cases or don't implement parallel command
submission.

And if it weren't for the TTM lock, the cross device work wouldn't have to
consider the case where a client
needs to lock out other reservers, and the cross-device design would suffer.

The main use cases are:

1) If we change master, clients of other masters need to be locked out from
claiming memory resources (particularly VRAM).
2) If we're about to suspend and have cleaned VRAM, client's need to be
stopped from validating VRAM buffer objects.
3) If a client needs access to the complete video memory space or need to
defragment, it needs to lock out other reservers in a parallell command
submission environment

Now, present a better solution to those use cases, and I'll ack this patch
and implement that solution, or
leave the TTM lock in place as a reminder that these things need to be
considered, and that we should have a common solution to them.

/Thomas





On 12/10/12 11:26 AM, Daniel Vetter wrote:

... it's the only user. Also move the header fil there.

 but seriously, ttm_lock is best left undocumented since
nobody should use that unholy thing..
 agreed ;-)
 imo we should shovel that under drm/vmwgfx ...
 amen
 that thing scares me
 out of sight, out of mind ...

Signed-off-by: Daniel Vetter 
---
   drivers/gpu/drm/ttm/Makefile|2 +-
   drivers/gpu/drm/ttm/ttm_lock.c  |  310
---
   dri

Re: [RFC v2 0/5] Common Display Framework

Hi Jani,

On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> On Mon, 17 Dec 2012, Laurent Pinchart wrote:
> > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> >> On 2012-11-22 23:45, Laurent Pinchart wrote:
> >> > From: Laurent Pinchart 
> >> > 
> >> > Hi everybody,
> >> > 
> >> > Here's the second RFC of what was previously known as the Generic Panel
> >> > Framework.
> >> 
> >> Nice work! Thanks for working on this.
> >> 
> >> I was doing some testing with the code, seeing how to use it in omapdss.
> >> Here are some thoughts:
> >> 
> >> In your model the DSS gets the panel devices connected to it from
> >> platform data. After the DSS and the panel drivers are loaded, DSS gets
> >> a notification and connects DSS and the panel.
> >> 
> >> I think it's a bit limited way. First of all, it'll make the DT data a
> >> bit more complex (although this is not a major problem). With your
> >> model, you'll need something like:
> >> 
> >> soc-base.dtsi:
> >> 
> >> dss {
> >>dpi0: dpi {
> >>};
> >> };
> >> 
> >> board.dts:
> >> 
> >> &dpi0 {
> >>panel = &dpi-panel;
> >> };
> >> 
> >> / {
> >>dpi-panel: dpi-panel {
> >>...panel data...;
> >>};
> >> };
> >> 
> >> Second, it'll prevent hotplug, and even if real hotplug would not be
> >> supported, it'll prevent cases where the connected panel must be found
> >> dynamically (like reading ID from eeprom).
> > 
> > Hotplug definitely needs to be supported, as the common display framework
> > also targets HDMI and DP. The notification mechanism was actually
> > designed to support hotplug.
> 
> I can see the need for a framework for DSI panels and such (in fact Tomi
> and I have talked about it like 2-3 years ago already!) but what is the
> story for HDMI and DP? In particular, what's the relationship between
> DRM and CDF here? Is there a world domination plan to switch the DRM
> drivers to use this framework too? ;) Do you have some rough plans how
> DRM and CDF should work together in general?

There's always a world domination plan, isn't there ? :-)

I certainly want CDF to be used by DRM (or more accurately KMS). That's what 
the C stands for, common refers to sharing panel and other display entity 
drivers between FBDEV, KMS and V4L2.

I currently have no plan to expose CDF internals to userspace through the KMS 
API. We might have to do so later if the hardware complexity grows in such a 
way that finer control than what KMS provides needs to be exposed to 
userspace, but I don't think we're there yet. The CDF API will thus only be 
used internally in the kernel by display controller drivers. The KMS core 
might get functions to handle common display entity operations, but the bulk 
of the work will be in the display controller drivers to start with. We will 
then see what can be abstracted in KMS helper functions.

Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF 
API. That's just a thought for now, I haven't tried to implement them, but it 
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.

Do you have thoughts to share on this topic ?

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown

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

--- Comment #5 from maxi...@free.fr ---
Using kernel from linus's repo fixes this issue.
Not sure if it is a "proper" fix, so I'll let you close the repoer if it should
be closed.

(now I'm getting 40 fps in heaven , nice boost if we forget about the 3 fps
thing)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 17:00 -0500, Alex Deucher wrote:
> On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf
>  wrote:
> > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote:
> >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf
> >>  wrote:
> >> > As soon as I open the following website:
> >> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html
> >> >
> >> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:
> >>
> >> Is this a regression?  Most likely a 3D driver bug unless you are only
> >> seeing it with specific kernels.  What browser are you using and do
> >> you have hw accelerated webgl, etc. enabled?  If so, what version of
> >> mesa are you using?
> >
> > This is a regression, because it is caused by yesterdays merge of
> > drm-next by Linus. IOW I only see this bug when running a
> > v3.7-9432-g9360b53 kernel.
> 
> Can you bisect?  I'm guessing it may be related to the new DMA rings.  
> Possibly:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2

Yes, the commit above causes the issue. 

 2d6cc72  GPU lockups
 009ee7a  runs fine

-- 
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915: GPU hang

2012-12-17 Thread Guennadi Liakhovetski

Hi all

Sorry, not sure what information is most appropriate here. GPU hangs from 
time to time on this laptop, typically when running firefox on 
graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6 
(squeeze), lspci

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 011f
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at fc00 (64-bit, non-prefetchable) [size=1M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915

kernel version 3.5.2 (yes, I'll try to upgrade). Sometimes also the 
X-server freezes and restarts with no errors in dmesg. Is it a known 
problem?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
[drm:i915_reset] *ERROR* Failed to reset chip.
[ cut here ]
WARNING: at drivers/gpu/drm/i915/intel_display.c:906 
intel_enable_pipe+0x16c/0x1c0 [i915]()
Hardware name: Extensa 5220   
PLL state assertion failure (expected on, current off)
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat usb_storage tun 
crypto_blkcipher aes_generic mperf cpufreq_powersave cpufreq_userspace 
cpufreq_stats i915 drm_kms_helper bnep rfcomm bluetooth crc16 fuse cryptomgr 
aead arc4 crypto_algapi rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib 
mac80211 cfg80211 uhci_hcd sg ehci_hcd tg3 sr_mod tifm_7xx1 usbcore cdrom 
coretemp snd_hda_codec_realtek pcmcia psmouse tifm_core i2c_i801 yenta_socket 
pcmcia_rsrc snd_hda_intel hwmon libphy snd_hda_codec usb_common pcmcia_core 
sdhci_pci sdhci mmc_core
Pid: 1780, comm: Xorg Not tainted 3.5.2 #32
Call Trace:
[] ? warn_slowpath_common+0x78/0xb0
[] ? intel_enable_pipe+0x16c/0x1c0 [i915]
[] ? intel_enable_pipe+0x16c/0x1c0 [i915]
[] ? warn_slowpath_fmt+0x33/0x40
[] ? intel_enable_pipe+0x16c/0x1c0 [i915]
[] ? i9xx_crtc_mode_set+0x942/0x1070 [i915]
[] ? intel_crtc_mode_set+0x5b/0x90 [i915]
[] ? drm_crtc_helper_set_mode+0x358/0x4a0 [drm_kms_helper]
[] ? intel_get_load_detect_pipe+0x22c/0x3a0 [i915]
[] ? find_get_page+0x63/0xc0
[] ? __find_get_block+0x9a/0x1e0
[] ? __find_get_block_slow+0xfa/0x1b0
[] ? intel_tv_detect+0x9b/0x460 [i915]
[] ? __getblk+0x1b/0x320
[] ? drm_get_connector_name+0x31/0x50
[] ? drm_helper_probe_single_connector_modes+0x258/0x310 
[drm_kms_helper]
[] ? drm_mode_getconnector+0x33f/0x370
[] ? drm_ioctl+0x263/0x4e0
[] ? drm_mode_getencoder+0xb0/0xb0
[] ? drm_version+0x90/0x90
[] ? do_vfs_ioctl+0x8d/0x600
[] ? fsnotify+0x196/0x2c0
[] ? alloc_fd+0xc0/0x110
[] ? vfs_write+0x107/0x150
[] ? sys_ioctl+0x3d/0x70
[] ? sysenter_do_call+0x12/0x22
---[ end trace 81ff939dea1daea3 ]---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Fan control in nouveau driver with geforce 9600gt


On 17/12/2012 13:35, Ozan Çağlayan wrote:

Hi Ozan,

Please have a look at this documentation:
http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal
It will tell you how to use fan management on your card :)

Please report back! I am interested in your results!

Martin

Hey this is nice! I'll try it tonight when I'm back home.

Thanks :)


Here you go :)

I managed to reproduce the issue. Please test this patch!

Thanks for reporting,
Martin
>From 0227e8a93c697c325fb89b31b16aa5fe565c64d5 Mon Sep 17 00:00:00 2001
From: Martin Peres 
Date: Mon, 17 Dec 2012 23:46:22 +0100
Subject: [PATCH] drm/nouveau/fan: handle the cases where we are outside of the
 linear zone

Signed-off-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/core/subdev/therm/base.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/base.c b/drivers/gpu/drm/nouveau/core/subdev/therm/base.c
index b35b4a2..25b7f6a 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/therm/base.c
@@ -71,6 +71,13 @@ nouveau_therm_update_linear(struct nouveau_therm *therm)
 	u8  temp = therm->temp_get(therm);
 	u16 duty;
 
+	/* handle the non-linear part first */
+	if (temp < linear_min_temp)
+		return priv->fan->bios.min_duty;
+	else if (temp > linear_max_temp)
+		return priv->fan->bios.max_duty;
+
+	/* we are in the linear zone */
 	duty  = (temp - linear_min_temp);
 	duty *= (priv->fan->bios.max_duty - priv->fan->bios.min_duty);
 	duty /= (linear_max_temp - linear_min_temp);
-- 
1.8.0.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote:
> On 2012.12.17 at 17:00 -0500, Alex Deucher wrote:
> > On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf
> >  wrote:
> > > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote:
> > >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf
> > >>  wrote:
> > >> > As soon as I open the following website:
> > >> > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html
> > >> >
> > >> > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable:
> > >>
> > >> Is this a regression?  Most likely a 3D driver bug unless you are only
> > >> seeing it with specific kernels.  What browser are you using and do
> > >> you have hw accelerated webgl, etc. enabled?  If so, what version of
> > >> mesa are you using?
> > >
> > > This is a regression, because it is caused by yesterdays merge of
> > > drm-next by Linus. IOW I only see this bug when running a
> > > v3.7-9432-g9360b53 kernel.
> > 
> > Can you bisect?  I'm guessing it may be related to the new DMA rings.  
> > Possibly:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d6cc7296d4ee128ab0fa3b715f0afde511f49c2
> 
> Yes, the commit above causes the issue. 
> 
>  2d6cc72  GPU lockups

With 2d6cc72 reverted I get:

Dec 17 23:09:35 x4 kernel: [ cut here ]
Dec 17 23:09:35 x4 kernel: WARNING: at include/linux/kref.h:42 
radeon_fence_ref+0x2c/0x40()
Dec 17 23:09:35 x4 kernel: Hardware name: System Product Name
Dec 17 23:09:35 x4 kernel: Pid: 182, comm: X Not tainted 3.7.0-09433-ge033059 
#155
Dec 17 23:09:35 x4 kernel: Call Trace:
Dec 17 23:09:35 x4 kernel: [] ? warn_slowpath_common+0x74/0xb0
Dec 17 23:09:35 x4 kernel: [] ? radeon_fence_ref+0x2c/0x40
Dec 17 23:09:35 x4 kernel: [] ? 
ttm_bo_cleanup_refs_and_unlock+0x17c/0x2c0
Dec 17 23:09:35 x4 kernel: [] ? ttm_mem_evict_first+0x94/0x1d0
Dec 17 23:09:35 x4 kernel: [] ? ttm_bo_man_get_node+0x62/0xb0
Dec 17 23:09:35 x4 kernel: [] ? ttm_bo_mem_space+0x271/0x320
Dec 17 23:09:35 x4 kernel: [] ? ttm_bo_move_buffer+0xdd/0x150
Dec 17 23:09:35 x4 kernel: [] ? ttm_bo_validate+0x89/0xf0
Dec 17 23:09:35 x4 kernel: [] ? ttm_bo_init+0x2e9/0x3a0
Dec 17 23:09:35 x4 kernel: [] ? radeon_bo_create+0x18a/0x200
Dec 17 23:09:35 x4 kernel: [] ? radeon_bo_clear_va+0x40/0x40
Dec 17 23:09:35 x4 kernel: [] ? 
radeon_gem_object_create+0x92/0x160
Dec 17 23:09:35 x4 kernel: [] ? 
radeon_gem_create_ioctl+0x6c/0x150
Dec 17 23:09:35 x4 kernel: [] ? drm_ioctl+0x420/0x4f0
Dec 17 23:09:35 x4 kernel: [] ? 
radeon_gem_pwrite_ioctl+0x20/0x20
Dec 17 23:09:35 x4 kernel: [] ? __do_page_fault+0x1a9/0x490
Dec 17 23:09:35 x4 kernel: [] ? mmap_region+0x169/0x560
Dec 17 23:09:35 x4 kernel: [] ? do_vfs_ioctl+0x2e4/0x4e0
Dec 17 23:09:35 x4 kernel: [] ? vm_mmap_pgoff+0x69/0x80
Dec 17 23:09:35 x4 kernel: [] ? sys_ioctl+0x4c/0xa0
Dec 17 23:09:35 x4 kernel: [] ? system_call_fastpath+0x16/0x1b
Dec 17 23:09:35 x4 kernel: ---[ end trace eb6036661a77c177 ]---
Dec 17 23:09:35 x4 kernel: BUG: unable to handle kernel paging request at 
8803d9ee4bd8
Dec 17 23:09:35 x4 kernel: IP: [] 
radeon_fence_wait_seq+0x85/0x440
Dec 17 23:09:35 x4 kernel: PGD 180c063 PUD 0
Dec 17 23:09:35 x4 kernel: Oops:  [#1] SMP
Dec 17 23:09:35 x4 kernel: CPU 3
Dec 17 23:09:35 x4 kernel: Pid: 182, comm: X Tainted: GW
3.7.0-09433-ge033059 #155 System manufacturer System Product Name/M4A78T-E
Dec 17 23:09:35 x4 kernel: RIP: 0010:[]  [] 
radeon_fence_wait_seq+0x85/0x440
Dec 17 23:09:35 x4 kernel: RSP: 0018:880210cc7a38  EFLAGS: 00010282
Dec 17 23:09:35 x4 kernel: RAX: 880210cc7a90 RBX: 88020674c970 RCX: 
0001
Dec 17 23:09:35 x4 kernel: RDX: 0605b580 RSI: 0058 RDI: 
8801c7f7dc80
Dec 17 23:09:35 x4 kernel: RBP: 8803d9ee4bd8 R08: 0001 R09: 
02a9
Dec 17 23:09:35 x4 kernel: R10: 02a8 R11: 0006 R12: 
880210ee6981
Dec 17 23:09:35 x4 kernel: R13: 0605b580 R14: 8801c7f7dc80 R15: 
8802161864f8
Dec 17 23:09:35 x4 kernel: FS:  7f5ee88f4880() 
GS:88021fd8() knlGS:
Dec 17 23:09:35 x4 kernel: CS:  0010 DS:  ES:  CR0: 80050033
Dec 17 23:09:35 x4 kernel: CR2: 8803d9ee4bd8 CR3: 000210c63000 CR4: 
07e0
Dec 17 23:09:35 x4 kernel: DR0:  DR1:  DR2: 

Dec 17 23:09:35 x4 kernel: DR3:  DR6: 0ff0 DR7: 
0400
Dec 17 23:09:35 x4 kernel: Process X (pid: 182, threadinfo 880210cc6000, 
task 880215f45730)
Dec 17 23:09:35 x4 kernel: Stack:
Dec 17 23:09:35 x4 kernel: 8129de0c 0605b580 8803d9ee4080 
0010
Dec 17 23:09:35 x4 kernel: 880210cc7aa8 880201cc7a68 880210cc7a90 
00010177c177
Dec 17 23:09:35 x4 kernel: 00c7 0001 88020674c890 
0286
Dec 17 23:09:35 x4 kernel: Call Trace:
Dec 17 23:09:35 x4 kernel: [] ? radeon_fence_ref+

Re: i915: GPU hang

On Mon, Dec 17, 2012 at 11:36 PM, Guennadi Liakhovetski
 wrote:
> Sorry, not sure what information is most appropriate here. GPU hangs from
> time to time on this laptop, typically when running firefox on
> graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6
> (squeeze), lspci
>
> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
> Subsystem: Acer Incorporated [ALI] Device 011f
> Flags: bus master, fast devsel, latency 0, IRQ 46
> Memory at fc00 (64-bit, non-prefetchable) [size=1M]
> Memory at d000 (64-bit, prefetchable) [size=256M]
> I/O ports at 1800 [size=8]
> Expansion ROM at  [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Capabilities: [d0] Power Management version 3
> Kernel driver in use: i915
>
> kernel version 3.5.2 (yes, I'll try to upgrade). Sometimes also the
> X-server freezes and restarts with no errors in dmesg. Is it a known
> problem?

Upgrading to 3.7 highly recommended, if just to get the recent pile of
gpu reset fixes - those should increase the chances that the reset
works and your system survives. Also worth testing is upgrading
userspace gfx driver components to the latest versions (mesa +
xf86-video-intel). If you still have gpu hangs with all that, please
file a bug report against DRM -> DRI/Intel and please attach the
i915_error_state from debugfs after your gpu hung).

Yours, Daniel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Tomi,

On Monday 17 December 2012 17:29:15 Tomi Valkeinen wrote:
> On 2012-12-17 16:36, Laurent Pinchart wrote:
> > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> >> On 2012-11-22 23:45, Laurent Pinchart wrote:
> >>> From: Laurent Pinchart 
> >>> 
> >>> Hi everybody,
> >>> 
> >>> Here's the second RFC of what was previously known as the Generic Panel
> >>> Framework.
> >> 
> >> Nice work! Thanks for working on this.
> >> 
> >> I was doing some testing with the code, seeing how to use it in omapdss.
> >> Here are some thoughts:
> >> 
> >> In your model the DSS gets the panel devices connected to it from
> >> platform data. After the DSS and the panel drivers are loaded, DSS gets
> >> a notification and connects DSS and the panel.
> >> 
> >> I think it's a bit limited way. First of all, it'll make the DT data a
> >> bit more complex (although this is not a major problem). With your
> >> model, you'll need something like:
> >> 
> >> soc-base.dtsi:
> >> 
> >> dss {
> >>dpi0: dpi {
> >>};
> >> };
> >> 
> >> board.dts:
> >> 
> >> &dpi0 {
> >>panel = &dpi-panel;
> >> };
> >> 
> >> / {
> >>dpi-panel: dpi-panel {
> >>...panel data...;
> >>};
> >> };
> >> 
> >> Second, it'll prevent hotplug, and even if real hotplug would not be
> >> supported, it'll prevent cases where the connected panel must be found
> >> dynamically (like reading ID from eeprom).
> > 
> > Hotplug definitely needs to be supported, as the common display framework
> > also targets HDMI and DP. The notification mechanism was actually
> > designed to support hotplug.
> 
> HDMI or DP hotplug may or may not be a different thing than what I talk
> about here. We may have two kinds of hotplug: real linux device hotplug,
> i.e. a linux device appears or is removed during runtime, or just a cable
> hotplug, handled inside a driver, which doesn't have any effect on the linux
> devices.
> 
> If we do implement HDMI and DP monitors with real linux drivers, then yes,
> we could use real hotplug. But we could as well have the monitor driver
> always registered, and just have a driver internal cable-hotplug system.
>
> To be honest, I'm not sure if implementing real hotplug is easily possible,
> as we don't have real, probable (probe-able =) busses. So even if we'd get a
> hotplug event of a new display device, what kind of device would the bus
> master register? It has no way to know that.

I get your point.

My design goal is to handle both HDMI/DP and panels through a single hotplug 
interface. I believe it would be simpler for display controller drivers to 
handle all display entities with a common API instead of implementing support 
for HDMI/DP and panels separately. This would require real HDMI and DP monitor 
drivers. I share your concern, I don't know whether this can work in the end, 
the only way to find out will be to try it.

> > How do you see the proposal preventing hotplug ?
> 
> Well, probably it doesn't prevent. But it doesn't feel right to me.
> 
> Say, if we have a DPI panel, controlled via foo-bus, which has a probing
> mechanism. When the foo-bus master detects a new hardware device, it'll
> create linux device for it. The driver for this device will then be probed.

That's correct. That's how Linux handles devices, and I don't think we should 
diverge from that model without a very good reason to do so. In my 
understanding you agree with me here, could you please confirm that ?

> In the probe function it should somehow register itself to the cdf, or
> perhaps the previous entity in the chain.

The panel driver would register the panel device to CDF in its probe function. 
>From a panel point of view I think we agree that two sets of operations exist.

- The panel control operations are called by an upper layer component (let's 
call it A) to control the panel (retrieve the list of modes, enable the panel, 
...). That upper layer component will usually call the panel in response to a 
userspace request (that can go through several layers in the kernel before 
reaching the panel), but can also call it in response to a hotplug event, 
without userspace being involved.

- The panel calls video operations of the entity that provides it with a video 
stream (the video source entity, let's call it B) to configure and control the 
video bus.

A and B could be implemented in the same driver or in two separate drivers, 
but at the end of the day I don't think that matters much. A needs a reference 
to the panel, and the panel needs a reference to B, that's all we need to 
provide, regardless of whether A and B come from the same kernel module or 
not.

> This sounds to me that the link is from the panel to the previous entity,
> not the other way around as you describe, and also the previous entity
> doesn't know of the panel entities.

The data flows from the video source to the panel (I'm 100% confident that we 
agree on that :-)), and the video source is controlled by the panel as per 
your reques

Re: i915: GPU hang

On Tue, Dec 18, 2012 at 12:15 AM, Heinz Diehl  wrote:
>> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
>> [drm] capturing error event; look for more information in 
>> /debug/dri/0/i915_error_state
>> [drm:i915_reset] *ERROR* Failed to reset chip.
>
> I have the same problem, are able to reproduce it and have bisected
> it, but the commit which git --bisect identified seems not to be the
> cause.
>
> root@wildsau linux-git]# git bisect good
> 6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
> commit 6c085a728cf000ac1865d66f8c9b52935558b328
> Author: Chris Wilson 
> Date:   Mon Aug 20 11:40:46 2012 +0200
>
> drm/i915: Track unbound pages

Note that Guennadi is running kernel 3.5 which does not contain that
patch - generally there are billions of ways to hang your gpu, so
every gpu hang needs it's own bug (until we've analyzed the
error_state and triaged the bug taking other evidence into account).
Also, this is on a different gpu generation, so even more likely that
it's a different kind of hang.

Thanks, Daniel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.

To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.

Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.

v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.

Cc: Aaron Plattner 
Signed-off-by: Daniel Vetter 
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.

Cheers, Daniel
---
 Documentation/dma-buf-sharing.txt |  6 +-
 drivers/base/dma-buf.c| 42 ++-
 include/linux/dma-buf.h   |  4 +++-
 3 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three 
steps:
   void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 
The vmap call can fail if there is no vmap support in the exporter, or if it
-   runs out of vmalloc space. Fallback to kmap should be implemented.
+   runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+   the dma-buf layer keeps a reference count for all vmap access and calls down
+   into the exporter's vmap function only when no vmapping exists, and only
+   unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+   by taking the dma_buf->lock mutex.
 
 3. Finish access
 
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..36af5de 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 
dmabuf = file->private_data;
 
+   BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
  */
 void *dma_buf_vmap(struct dma_buf *dmabuf)
 {
+   void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
 
-   if (dmabuf->ops->vmap)
-   return dmabuf->ops->vmap(dmabuf);
-   return NULL;
+   if (!dmabuf->ops->vmap)
+   return NULL;
+
+   mutex_lock(&dmabuf->lock);
+   if (dmabuf->vmapping_counter) {
+   dmabuf->vmapping_counter++;
+   BUG_ON(!dmabuf->vmap_ptr);
+   ptr = dmabuf->vmap_ptr;
+   goto out_unlock;
+   }
+
+   BUG_ON(dmabuf->vmap_ptr);
+
+   ptr = dmabuf->ops->vmap(dmabuf);
+   if (IS_ERR_OR_NULL(ptr))
+   goto out_unlock;
+
+   dmabuf->vmap_ptr = ptr;
+   dmabuf->vmapping_counter = 1;
+
+out_unlock:
+   mutex_unlock(&dmabuf->lock);
+   return ptr;
 }
 EXPORT_SYMBOL_GPL(dma_buf_vmap);
 
@@ -501,7 +525,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
 
-   if (dmabuf->ops->vunmap)
-   dmabuf->ops->vunmap(dmabuf, vaddr);
+   BUG_ON(!dmabuf->vmap_ptr);
+   BUG_ON(dmabuf->vmapping_counter > 0);
+
+   mutex_lock(&dmabuf->lock);
+   if (--dmabuf->vmapping_counter == 0) {
+   if (dmabuf->ops->vunmap)
+   dmabuf->ops->vunmap(dmabuf, vaddr);
+   dmabuf->vmap_ptr = NULL;
+   }
+   mutex_unlock(&dmabuf->lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
-   /* mutex to serialize list manipulation and attach/detach */
+   /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+   unsigned vmapping_counter;
+   void *vmap_ptr;
void *priv;
 };
 
-- 
1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH resend] drm: nouveau: Fix build warning seen if HWMON is undefined

2012-12-17 Thread Guenter Roeck

Fix:

nouveau_pm.c: In function ‘nouveau_hwmon_init’:
nouveau_pm.c:703:24: warning: unused variable ‘therm’ [-Wunused-variable]

Signed-off-by: Guenter Roeck 
---
 drivers/gpu/drm/nouveau/nouveau_pm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c 
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index 5566172..a701ff5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_pm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_pm.c
@@ -698,10 +698,10 @@ static int
 nouveau_hwmon_init(struct drm_device *dev)
 {
struct nouveau_pm *pm = nouveau_pm(dev);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nouveau_therm *therm = nouveau_therm(drm->device);
 
 #if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
+   struct nouveau_drm *drm = nouveau_drm(dev);
+   struct nouveau_therm *therm = nouveau_therm(drm->device);
struct device *hwmon_dev;
int ret = 0;
 
-- 
1.7.9.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: GPU hang

2012-12-17 Thread Heinz Diehl

On 17.12.2012, Guennadi Liakhovetski wrote: 

> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm] capturing error event; look for more information in 
> /debug/dri/0/i915_error_state
> [drm:i915_reset] *ERROR* Failed to reset chip.

I have the same problem, are able to reproduce it and have bisected
it, but the commit which git --bisect identified seems not to be the
cause.

root@wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson 
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages

This is a quite nasty (3.7) regression. I have it on all of my three
machines and it drives me mad (3.6.x hangs my USB 3.0 port and 3.7 my
intel graphics).

Try to boot with "i915.i915_enable_rc6=0" and switch to SNA in your
Xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

There are tons of this "GPU hangcheck timer elapsed"
messages on the net...

Good luck!

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.

To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.

Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.

v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.

v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping.  Suggested by Chris Wilson.

Cc: Aaron Plattner 
Signed-off-by: Daniel Vetter 
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.

Cheers, Daniel
---
 Documentation/dma-buf-sharing.txt |  6 +-
 drivers/base/dma-buf.c| 43 ++-
 include/linux/dma-buf.h   |  4 +++-
 3 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three 
steps:
   void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 
The vmap call can fail if there is no vmap support in the exporter, or if it
-   runs out of vmalloc space. Fallback to kmap should be implemented.
+   runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+   the dma-buf layer keeps a reference count for all vmap access and calls down
+   into the exporter's vmap function only when no vmapping exists, and only
+   unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+   by taking the dma_buf->lock mutex.
 
 3. Finish access
 
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..67d3cd5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 
dmabuf = file->private_data;
 
+   BUG_ON(dmabuf->vmapping_counter);
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
  */
 void *dma_buf_vmap(struct dma_buf *dmabuf)
 {
+   void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
 
-   if (dmabuf->ops->vmap)
-   return dmabuf->ops->vmap(dmabuf);
-   return NULL;
+   if (!dmabuf->ops->vmap)
+   return NULL;
+
+   mutex_lock(&dmabuf->lock);
+   if (dmabuf->vmapping_counter) {
+   dmabuf->vmapping_counter++;
+   BUG_ON(!dmabuf->vmap_ptr);
+   ptr = dmabuf->vmap_ptr;
+   goto out_unlock;
+   }
+
+   BUG_ON(dmabuf->vmap_ptr);
+
+   ptr = dmabuf->ops->vmap(dmabuf);
+   if (IS_ERR_OR_NULL(ptr))
+   goto out_unlock;
+
+   dmabuf->vmap_ptr = ptr;
+   dmabuf->vmapping_counter = 1;
+
+out_unlock:
+   mutex_unlock(&dmabuf->lock);
+   return ptr;
 }
 EXPORT_SYMBOL_GPL(dma_buf_vmap);
 
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
 
-   if (dmabuf->ops->vunmap)
-   dmabuf->ops->vunmap(dmabuf, vaddr);
+   BUG_ON(!dmabuf->vmap_ptr);
+   BUG_ON(dmabuf->vmapping_counter > 0);
+   BUG_ON(dmabuf->vmap_ptr != vaddr);
+
+   mutex_lock(&dmabuf->lock);
+   if (--dmabuf->vmapping_counter == 0) {
+   if (dmabuf->ops->vunmap)
+   dmabuf->ops->vunmap(dmabuf, vaddr);
+   dmabuf->vmap_ptr = NULL;
+   }
+   mutex_unlock(&dmabuf->lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
-   /* mutex to serialize list manipulation and attach/detach */
+   /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+   unsigned vmapping_counter;
+   void *vmap_ptr;
void *priv;
 };
 
-- 
1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: Export routines for inserting preallocated nodes into the mm manager

On Fri, Dec 07, 2012 at 08:37:06PM +, Chris Wilson wrote:
> Required by i915 in order to avoid the allocation in the middle of
> manipulating the drm_mm lists.
> 
> Use a pair of stubs to preserve the existing EXPORT_SYMBOLs for
> backporting; to be removed later.
> 
> Cc: Dave Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/drm_mm.c |   42 ++
>  include/drm/drm_mm.h |   27 +++
>  2 files changed, 53 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 0761a03..d93dc05 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -184,19 +184,27 @@ EXPORT_SYMBOL(drm_mm_get_block_generic);
>   * -ENOSPC if no suitable free area is available. The preallocated memory 
> node
>   * must be cleared.
>   */
> -int drm_mm_insert_node(struct drm_mm *mm, struct drm_mm_node *node,
> -unsigned long size, unsigned alignment)
> +int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
> +unsigned long size, unsigned alignment,
> +unsigned long color, int atomic)
>  {
>   struct drm_mm_node *hole_node;
>  
> - hole_node = drm_mm_search_free(mm, size, alignment, false);
> + hole_node = drm_mm_search_free_generic(mm, size, alignment,
> +color, atomic);

The last parameter of search_free_generic is best_match, which isn't used
by any current caller. The only reason it's still there is that I haven't
converted yet all drm_mm.c users to preallocate drm_mm_node's, but as soon
as that's done best_match will die together with search_free_generic as a
public interface.

So what's the atomic doing in here? I've looked through the drm/i915
patches and couldn't see any reason ... Can we just respin the two i915
patches with _generic and atomic = false dropped, or do I miss something
big here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm prime/dma-buf import lifetime issue

So I've gotten back to playing with prime for a day, and found some
old intel/radeon tests I had failing,

Tracked it down to a lifetime issue with the current code and can
think of two fixes,

The problem scenario is

1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object

So we end up at this point, with a imported buffer record for the
dma_buf on the i915 file private.

Now if a subsequent test (without closing the drm fd) reallocates the
dma_buf with the same address, we can end up seeing that.

So why doesn't that reference get cleaned up?

So the reference gets added above at step 2, and when radeon unrefs
the object, i915 gets the dma-buf release callback, however at that
stage
we don't actually have the file priv to remove the pointer from, so it
dangles there.

Possible fixes:

a) take a reference on the dma_buf attached to the gem handle when we
export it, keep it until the gem handle goes away. I'm unsure if this
could create zombie objects, since the dma buf has a reference on the
gem object, but since the gem handle is separate to the object it
might work.

b) don't keep track of dma_buf, keep track of gem objects, when we get
a lookup, check inside the gem object, since currently we NULL out the
export_dma_buf when we hit the release path, apart from the fact I'm
sure the locking is foobar,

c) scan all the file privs for all the devices, no.

Anyone else any better plans?

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

>
> Many developers showed interest in the first RFC, and I've had the opportunity
> to discuss it with most of them. I would like to thank (in no particular
> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
> inviting me to Connect and providing a venue to discuss this topic.
>

So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:

The biggest problem I'm having currently with the whole ARM graphics
and output world is the proliferation of platform drivers for every
little thing. The whole ordering of operations with respect to things
like suspend/resume or dynamic power management is going to be a real
nightmare if there are dependencies between the drivers. How do you
enforce ordering of s/r operations between all the various components?

The other thing I'd like you guys to do is kill the idea of fbdev and
v4l drivers that are "shared" with the drm codebase, really just
implement fbdev and v4l on top of the drm layer, some people might
think this is some sort of maintainer thing, but really nothing else
makes sense, and having these shared display frameworks just to avoid
having using drm/kms drivers seems totally pointless. Fix the drm
fbdev emulation if an fbdev interface is needed. But creating a fourth
framework because our previous 3 frameworks didn't work out doesn't
seem like a situation I want to get behind too much.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/prime: fix lifetime issue with storing dma_buf on import list for exports

From: Dave Airlie 

So when we export an dma buf we store it on the import list for that file
priv, so we can trap later imports of a buffer we exported from ourselves.

However there is nothing to clean that pointer up if the dma-buf gets
released internally, since we don't hold a reference to it. Holding
a reference to it could cause circular references so is probably best
avoided.

However if we store the gem objects in the file priv, and when we clean
up the gem object handles we clean up these references as well, then
it should be safe. We can then search for dma bufs referenced from the
gem objects themselves.

This seems to point out that obj->export_dma_buf and obj->import_attach
may need a bit of a lock safety review.

This fixes some intel/radeon tests from ages ago that started to fail
along with appearing to fix prime on my GM45/r600 laptop in F18.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_gem.c   |  9 +
 drivers/gpu/drm/drm_prime.c | 48 +++--
 include/drm/drmP.h  |  7 ---
 3 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 24efae4..4252f61 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -204,14 +204,7 @@ EXPORT_SYMBOL(drm_gem_object_alloc);
 static void
 drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp)
 {
-   if (obj->import_attach) {
-   drm_prime_remove_imported_buf_handle(&filp->prime,
-   obj->import_attach->dmabuf);
-   }
-   if (obj->export_dma_buf) {
-   drm_prime_remove_imported_buf_handle(&filp->prime,
-   obj->export_dma_buf);
-   }
+   drm_prime_remove_imported_buf_handle(&filp->prime, obj);
 }
 
 /**
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..1f31df1 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -56,10 +56,14 @@
  * from the dma-buf private.
  */
 
+#define PRIME_IMPORT 1
+#define PRIME_EXPORT 2
+
 struct drm_prime_member {
struct list_head entry;
-   struct dma_buf *dma_buf;
+   struct drm_gem_object *obj;
uint32_t handle;
+   int type;
 };
 
 int drm_gem_prime_handle_to_fd(struct drm_device *dev,
@@ -104,8 +108,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
/* if we've exported this buffer the cheat and add it to the import list
 * so we get the correct handle back
 */
-   ret = drm_prime_add_imported_buf_handle(&file_priv->prime,
-   obj->export_dma_buf, handle);
+   ret = drm_prime_add_exported_buf_handle(&file_priv->prime, obj,
+   handle);
if (ret) {
drm_gem_object_unreference_unlocked(obj);
mutex_unlock(&file_priv->prime.lock);
@@ -149,8 +153,8 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
if (ret)
goto out_put;
 
-   ret = drm_prime_add_imported_buf_handle(&file_priv->prime,
-   dma_buf, *handle);
+   ret = drm_prime_add_imported_buf_handle(&file_priv->prime, obj,
+   *handle);
if (ret)
goto fail;
 
@@ -307,7 +311,9 @@ void drm_prime_destroy_file_private(struct 
drm_prime_file_private *prime_fpriv)
 }
 EXPORT_SYMBOL(drm_prime_destroy_file_private);
 
-int drm_prime_add_imported_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle)
+static int drm_prime_add_buf_handle(struct drm_prime_file_private *prime_fpriv,
+   struct drm_gem_object *obj,
+   uint32_t handle, int type)
 {
struct drm_prime_member *member;
 
@@ -315,11 +321,23 @@ int drm_prime_add_imported_buf_handle(struct 
drm_prime_file_private *prime_fpriv
if (!member)
return -ENOMEM;
 
-   member->dma_buf = dma_buf;
+   member->obj = obj;
member->handle = handle;
+   member->type = type;
list_add(&member->entry, &prime_fpriv->head);
return 0;
 }
+
+int drm_prime_add_exported_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct drm_gem_object *obj, uint32_t handle)
+{
+   return drm_prime_add_buf_handle(prime_fpriv, obj, handle, PRIME_EXPORT);
+}
+EXPORT_SYMBOL(drm_prime_add_exported_buf_handle);
+
+int drm_prime_add_imported_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct drm_gem_object *obj, uint32_t handle)
+{
+   return drm_prime_add_buf_handle(prime_fpriv, obj, handle, PRIME_IMPORT);
+}
 EXPORT_SYMBOL(drm_prime_add_imported_buf_handle);
 
 int drm_prime_lookup_imported_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct dma_buf *dma_buf, uint32_t *handle)
@@ -327,7 +345,17 @@ int drm_prime_lookup_imported_buf_handle(struct

Re: drm prime/dma-buf import lifetime issue

>
> b) don't keep track of dma_buf, keep track of gem objects, when we get
> a lookup, check inside the gem object, since currently we NULL out the
> export_dma_buf when we hit the release path, apart from the fact I'm
> sure the locking is foobar,

Okay I've sent and implementation of this option, however it does mean
that prime relies on GEM, which at this point is a tradeoff I'm quite
happy to start making.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/omap: Add PM capabilities

2012-12-17 Thread Andy Gross

Added resume hooks that will be called on resuming from DEVICE_OFF.
The dmm portion of the patch reprograms the LUT to point to the dummy
pages.  The omapdrm portion of the patch repins the buffers into the
DMM.

Signed-off-by: Andy Gross 
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |   34 ++
 drivers/staging/omapdrm/omap_drv.c   |   14 
 drivers/staging/omapdrm/omap_drv.h   |4 +++
 drivers/staging/omapdrm/omap_gem.c   |   28 
 4 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 59bf438..c42c5e5 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -903,12 +903,46 @@ error:
 }
 #endif
 
+#ifdef CONFIG_PM
+static int omap_dmm_resume(struct device *dev)
+{
+   struct tcm_area area;
+   int i;
+
+   if (!omap_dmm)
+   return -ENODEV;
+
+   area = (struct tcm_area) {
+   .is2d = true,
+   .tcm = NULL,
+   .p1.x = omap_dmm->container_width - 1,
+   .p1.y = omap_dmm->container_height - 1,
+   };
+
+   /* initialize all LUTs to dummy page entries */
+   for (i = 0; i < omap_dmm->num_lut; i++) {
+   area.tcm = omap_dmm->tcm[i];
+   if (fill(&area, NULL, 0, 0, true))
+   dev_err(dev, "refill failed");
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops omap_dmm_pm_ops = {
+   .resume = omap_dmm_resume,
+};
+#endif
+
 struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+#ifdef CONFIG_PM
+   .pm = &omap_dmm_pm_ops,
+#endif
},
 };
 
diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index ae5ecc2..d246f85 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -368,6 +368,9 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
/* well, limp along without an fbdev.. maybe X11 will work? */
}
 
+   /* store off drm_device for use in pm ops */
+   dev_set_drvdata(dev->dev, dev);
+
drm_kms_helper_poll_init(dev);
 
return 0;
@@ -393,6 +396,8 @@ static int dev_unload(struct drm_device *dev)
kfree(dev->dev_private);
dev->dev_private = NULL;
 
+   dev_set_drvdata(dev->dev, NULL);
+
return 0;
 }
 
@@ -558,10 +563,19 @@ static int pdev_remove(struct platform_device *device)
return 0;
 }
 
+#ifdef CONFIG_PM
+static const struct dev_pm_ops omapdrm_pm_ops = {
+   .resume = omap_gem_resume,
+};
+#endif
+
 struct platform_driver pdev = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+#ifdef CONFIG_PM
+   .pm = &omapdrm_pm_ops,
+#endif
},
.probe = pdev_probe,
.remove = pdev_remove,
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index cd1f22b..f921027 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -135,6 +135,10 @@ void omap_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m);
 void omap_gem_describe_objects(struct list_head *list, struct seq_file *m);
 #endif
 
+#ifdef CONFIG_PM
+int omap_gem_resume(struct device *dev);
+#endif
+
 int omap_irq_enable_vblank(struct drm_device *dev, int crtc);
 void omap_irq_disable_vblank(struct drm_device *dev, int crtc);
 irqreturn_t omap_irq_handler(DRM_IRQ_ARGS);
diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index c38992b..08f1e292 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -964,6 +964,34 @@ void *omap_gem_vaddr(struct drm_gem_object *obj)
return omap_obj->vaddr;
 }
 
+#ifdef CONFIG_PM
+/* re-pin objects in DMM in resume path: */
+int omap_gem_resume(struct device *dev)
+{
+   struct drm_device *drm_dev = dev_get_drvdata(dev);
+   struct omap_drm_private *priv = drm_dev->dev_private;
+   struct omap_gem_object *omap_obj;
+   int ret = 0;
+
+   list_for_each_entry(omap_obj, &priv->obj_list, mm_list) {
+   if (omap_obj->block) {
+   struct drm_gem_object *obj = &omap_obj->base;
+   uint32_t npages = obj->size >> PAGE_SHIFT;
+   WARN_ON(!omap_obj->pages);  /* this can't happen */
+   ret = tiler_pin(omap_obj->block,
+   omap_obj->pages, npages,
+   omap_obj->roll, true);
+   if (ret) {
+   dev_err(dev, "could not repin: %d\

[PATCH 0/2] drm/omap: Add PM and OMAP5 support

2012-12-17 Thread Andy Gross

First patch adds PM capabilities for omapdrm.  Second patch adds
OMAP5 support to DMM driver component.

Series was build tested and based on linux-next.

Andy Gross (2):
  drm/omap: Add PM capabilities
  drm/omap: Add OMAP5 support

 drivers/staging/omapdrm/omap_dmm_priv.h  |5 +
 drivers/staging/omapdrm/omap_dmm_tiler.c |  159 ++
 drivers/staging/omapdrm/omap_drv.c   |   14 +++
 drivers/staging/omapdrm/omap_drv.h   |4 +
 drivers/staging/omapdrm/omap_gem.c   |   28 +
 drivers/staging/omapdrm/tcm.h|2 +
 6 files changed, 169 insertions(+), 43 deletions(-)

-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/omap: Add OMAP5 support

2012-12-17 Thread Andy Gross

Add support for OMAP5 processor.  The main differences are that the OMAP5
has 2 containers, one for 1D and one for 2D.  Each container is 128MiB in
size.

Signed-off-by: Andy Gross 
---
 drivers/staging/omapdrm/omap_dmm_priv.h  |5 +
 drivers/staging/omapdrm/omap_dmm_tiler.c |  127 +++--
 drivers/staging/omapdrm/tcm.h|2 +
 3 files changed, 90 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h 
b/drivers/staging/omapdrm/omap_dmm_priv.h
index 273ec12..58bcd6a 100644
--- a/drivers/staging/omapdrm/omap_dmm_priv.h
+++ b/drivers/staging/omapdrm/omap_dmm_priv.h
@@ -118,6 +118,11 @@ struct pat {
 #define DESCR_SIZE 128
 #define REFILL_BUFFER_SIZE ((4 * 128 * 256) + (3 * DESCR_SIZE))
 
+/* For OMAP5, a fixed offset is added to all Y coordinates for 1D buffers.
+ * This is used in programming to address the upper portion of the LUT
+*/
+#define OMAP5_LUT_OFFSET   128
+
 struct dmm;
 
 struct dmm_txn {
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index c42c5e5..3910215 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -213,6 +213,11 @@ static void dmm_txn_append(struct dmm_txn *txn, struct 
pat_area *area,
txn->last_pat->next_pa = (uint32_t)pat_pa;
 
pat->area = *area;
+
+   /* adjust Y coordinates based off of container parameters */
+   pat->area.y0 += engine->tcm->y_offset;
+   pat->area.y1 += engine->tcm->y_offset;
+
pat->ctrl = (struct pat_ctrl){
.start = 1,
.lut_id = engine->tcm->lut_id,
@@ -622,6 +627,11 @@ static int omap_dmm_probe(struct platform_device *dev)
omap_dmm->lut_width = ((pat_geom >> 16) & 0xF) << 5;
omap_dmm->lut_height = ((pat_geom >> 24) & 0xF) << 5;
 
+   /* increment LUT by one if on OMAP5 */
+   /* LUT has twice the height, and is split into a separate container */
+   if (omap_dmm->lut_height != omap_dmm->container_height)
+   omap_dmm->num_lut++;
+
/* initialize DMM registers */
writel(0x, omap_dmm->base + DMM_PAT_VIEW__0);
writel(0x, omap_dmm->base + DMM_PAT_VIEW__1);
@@ -701,6 +711,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
 
/* init containers */
+   /* Each LUT is associated with a TCM (container manager).  We use the
+  lut_id to denote the lut_id used to identify the correct LUT for
+  programming during reill operations */
for (i = 0; i < omap_dmm->num_lut; i++) {
omap_dmm->tcm[i] = sita_init(omap_dmm->container_width,
omap_dmm->container_height,
@@ -717,13 +730,23 @@ static int omap_dmm_probe(struct platform_device *dev)
 
/* assign access mode containers to applicable tcm container */
/* OMAP 4 has 1 container for all 4 views */
+   /* OMAP 5 has 2 containers, 1 for 2D and 1 for 1D */
containers[TILFMT_8BIT] = omap_dmm->tcm[0];
containers[TILFMT_16BIT] = omap_dmm->tcm[0];
containers[TILFMT_32BIT] = omap_dmm->tcm[0];
-   containers[TILFMT_PAGE] = omap_dmm->tcm[0];
+
+   if (omap_dmm->container_height != omap_dmm->lut_height) {
+   /* second LUT is used for PAGE mode.  Programming must use
+  y offset that is added to all y coordinates.  LUT id is still
+  0, because it is the same LUT, just the upper 128 lines */
+   containers[TILFMT_PAGE] = omap_dmm->tcm[1];
+   omap_dmm->tcm[1]->y_offset = OMAP5_LUT_OFFSET;
+   omap_dmm->tcm[1]->lut_id = 0;
+   } else {
+   containers[TILFMT_PAGE] = omap_dmm->tcm[0];
+   }
 
area = (struct tcm_area) {
-   .is2d = true,
.tcm = NULL,
.p1.x = omap_dmm->container_width - 1,
.p1.y = omap_dmm->container_height - 1,
@@ -835,64 +858,81 @@ int tiler_map_show(struct seq_file *s, void *arg)
int h_adj;
int w_adj;
unsigned long flags;
+   int lut_idx;
+
 
if (!omap_dmm) {
/* early return if dmm/tiler device is not initialized */
return 0;
}
 
-   h_adj = omap_dmm->lut_height / ydiv;
-   w_adj = omap_dmm->lut_width / xdiv;
+   h_adj = omap_dmm->container_height / ydiv;
+   w_adj = omap_dmm->container_width / xdiv;
 
-   map = kzalloc(h_adj * sizeof(*map), GFP_KERNEL);
-   global_map = kzalloc((w_adj + 1) * h_adj, GFP_KERNEL);
+   map = kmalloc(h_adj * sizeof(*map), GFP_KERNEL);
+   global_map = kmalloc((w_adj + 1) * h_adj, GFP_KERNEL);
 
if (!map || !global_map)
goto error;
 
-   memset(global_map, ' ', (w_adj + 1) * h_adj);
-   for (i = 0; i < omap_dmm->lut_height; i++) {
-   map[i] = global_map + i * (w_adj + 1);
-

Re: [RFC v2 0/5] Common Display Framework

On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie  wrote:
>>
>> Many developers showed interest in the first RFC, and I've had the 
>> opportunity
>> to discuss it with most of them. I would like to thank (in no particular
>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, 
>> Marcus
>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
>> inviting me to Connect and providing a venue to discuss this topic.
>>
>
> So this might be a bit off topic but this whole CDF triggered me
> looking at stuff I generally avoid:
>
> The biggest problem I'm having currently with the whole ARM graphics
> and output world is the proliferation of platform drivers for every
> little thing. The whole ordering of operations with respect to things
> like suspend/resume or dynamic power management is going to be a real
> nightmare if there are dependencies between the drivers. How do you
> enforce ordering of s/r operations between all the various components?

I tend to think that sub-devices are useful just to have a way to
probe hw which may or may not be there, since on ARM we often don't
have any alternative.. but beyond that, suspend/resume, and other
life-cycle aspects, they should really be treated as all one device.
Especially to avoid undefined suspend/resume ordering.

CDF or some sort of mechanism to share panel drivers between drivers
is useful.  Keeping it within drm, is probably a good idea, if nothing
else to simplify re-use of helper fxns (like avi-infoframe stuff, for
example) and avoid dealing with merging changes across multiple trees.
  Treating them more like shared libraries and less like sub-devices
which can be dynamically loaded/unloaded (ie. they should be not built
as separate modules or suspend/resumed or probed/removed independently
of the master driver) is a really good idea to avoid uncovering nasty
synchronization issues later (remove vs modeset or pageflip) or
surprising userspace in bad ways.

> The other thing I'd like you guys to do is kill the idea of fbdev and
> v4l drivers that are "shared" with the drm codebase, really just
> implement fbdev and v4l on top of the drm layer, some people might
> think this is some sort of maintainer thing, but really nothing else
> makes sense, and having these shared display frameworks just to avoid
> having using drm/kms drivers seems totally pointless. Fix the drm
> fbdev emulation if an fbdev interface is needed. But creating a fourth
> framework because our previous 3 frameworks didn't work out doesn't
> seem like a situation I want to get behind too much.

yeah, let's not have multiple frameworks to do the same thing.. For
fbdev, it is pretty clear that it is a dead end.  For v4l2
(subdev+mcf), it is perhaps bit more flexible when it comes to random
arbitrary hw pipelines than kms.  But to take advantage of that, your
userspace isn't going to be portable anyways, so you might as well use
driver specific properties/ioctls.  But I tend to think that is more
useful for cameras.  And from userspace perspective, kms planes are
less painful to use for output than v4l2, so lets stick to drm/kms for
output (and not try to add camera/capture support to kms).. k, thx

BR,
-R

> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|[bisected] r600g locks up   |[bisected] r600g: use DMA
   |in Unigine Tropics with |engine for VM page table
   |drm-next|updates on cayman locks in
   ||Unigine Tropics

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: drop reference on imported dma-buf come from gem

On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim  wrote:
> Increasing ref counts of both dma-buf and gem for imported dma-buf come from 
> gem
> makes memory leak. release function of dma-buf cannot be called because 
> f_count
> of dma-buf increased by importing gem and gem ref count cannot be decrease
> because of exported dma-buf.
>
> So I add dma_buf_put() for imported gem come from its own gem into each 
> drivers
> having prime_import and prime_export capabilities. With this, only gem ref
> count is increased if importing gem exported from gem of same driver.

Okay its taken me a while to circle around and get back to this, but
yes I admit this is needed, but I hate implementing it like this

But I think I'll push it and work out a cleaner solution, I should
also go back and look at the older patches.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

2012-12-17 Thread Terje Bergström

On 17.12.2012 22:55, Stephen Warren wrote:
> On 12/16/2012 09:37 AM, Terje Bergström wrote:
> ...
>> ... Sure we could tell DC to ask its parent
>> (host1x), and call host1x driver with platform_device pointer found that
>> way, and host1x would return a pointer to tegradrm's data. Hanging the
>> data onto host1x driver is just a more complicated way of implementing
>> global data
> 
> No it's not; at that point, the data is no longer global, but specific
> to the driver instance.

We have only one tegradrm, so the advantage is theoretical - the one
driver gets the same pointer in both cases.

If we use static pointer with an accessor function, we can keep the
solution contained to one source code file and the ownership of data is
clear - tegradrm allocates and deallocates the object and is the sole
user. Code is already in the patchset I sent.

Shared responsibility with host1x and tegradrm would work probably
something like this:

tegradrm creates an object, and passes the reference to host1x
(host1x_set_drm_pdata(host1x_platform_dev, object). host1x sets the
pdata to a member in struct host1x. A getter host1x_get_drm_pdata()
allows retrieving the object. DC would call it with
"host1x_get_drm_pdata(to_platform_device(pdev->dev.parent))".

This assumes that tegradrm would keep ownership of the data and free it
before host1x gets unloaded.

To me this sounds like a steep price and I fail to see the advantage.

Dummy device is something that would come then on top of this mechanism.

Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: drop reference on imported dma-buf come from gem

2012-12-17 Thread 김승우

Hi Dave,

On 2012년 12월 18일 15:30, Dave Airlie wrote:
> On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim  wrote:
>> Increasing ref counts of both dma-buf and gem for imported dma-buf come from 
>> gem
>> makes memory leak. release function of dma-buf cannot be called because 
>> f_count
>> of dma-buf increased by importing gem and gem ref count cannot be decrease
>> because of exported dma-buf.
>>
>> So I add dma_buf_put() for imported gem come from its own gem into each 
>> drivers
>> having prime_import and prime_export capabilities. With this, only gem ref
>> count is increased if importing gem exported from gem of same driver.
> 
> Okay its taken me a while to circle around and get back to this, but
> yes I admit this is needed, but I hate implementing it like this
> 
> But I think I'll push it and work out a cleaner solution, I should
> also go back and look at the older patches.

I want to also report some strange thing in dma-buf prime export.

In drm_prime_handle_to_fd_ioctl(), flags is cleared to only support
DRM_CLOEXEC but in gem_prime_export() callbacks of each driver, it uses
0600 as flags for dma_buf_export() like following.

return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, 0600);

Best Regards,
- Seung-Woo Kim

> 
> Dave.
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

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

--- Comment #5 from Alex Deucher  ---
Does your kernel tree have this patch?
http://cgit.freedesktop.org/~airlied/linux/commit/drivers/gpu/drm/radeon/radeon_object.c?h=drm-next&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb

-- 
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/20121217/6eec764e/attachment.html>

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

2012-12-17 Thread bugzilla-dae...@bugzilla.kernel.org

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





--- Comment #15 from Alex Deucher   2012-12-17 
00:34:33 ---
Does this patch fix the issue?
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors

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

--- Comment #4 from David Herrmann  ---
I can provoke this bug with a simple drmModeSetCursor() or drmModeMoveCursor().
The cursor images have a horizontal black stripe (not always). Position varies
on my machine. Using 3D acceleration without cursors works perfectly well
(although starting mplayer caused a deadlock on my machine).

It's also a nv50 card.

I tried bisecting it and it turns out the memory-manager rewrite caused it (as
reported on IRC). I was unable to revert the commit on top of 3.7 as it is
quite complex.

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

[RFC] Complete experimental render node implementation

Hi,

Following to my shared talk with krh, danvet and Timoth?e Ravier @ 
XDC2012, I have
actually taken the time to start fixing some security holes found in the 
graphics stack.

Today, I would like to request your comments on the render node 
patchset. Keep in mind that I am
not asking for inclusion. However, I know this patchset works on my 
nvidia card and I would like
to know if anyone has anything against this architecture.

## DRM
If I'm not mistaken, the idea originated from airlied which got 
simplified later by krh.
Both only provided drm patches.

Here is what I did:
- I took krh's patchset
- rebased it on top on drm 3.7-rc8
- added support for Nouveau
- fixed a few bugs along the way (as stated in the commit logs)

The kernel can be found here: 
https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes
The patches will also be sent in reply, to let you comment on specific 
parts of the patches.

## Libdrm

Here are the two main goals of this patchset:
- Add a new symbol called drmOpenType that allows to open a specific 
type of device (usual node, render node)
- Add a new symbol called drmGetSameDeviceButType to get the path to the 
same drm_device but with a different type

The patches are available here: http://cgit.freedesktop.org/~mperes/drm/

## DRI2Proto

What we want here is to let the ddx send the render node instead of the 
usual one.
However, authentication is not necessary and not shouldn't be done on a 
render node.

This modification to DRI2Proto adds a boolean in the Connection response 
to tell the dri2 client
that no authentication is required.

The patches are available here: 
http://cgit.freedesktop.org/~mperes/dri2proto/

## XServer

The X-Server is responsible for collecting the DRI2 informations from 
the ddx.
In this patch, we provide the way for the ddx to specify whether the 
DRI2 client should authenticate or not.

The patches are available here: http://cgit.freedesktop.org/~mperes/xserver/

## xf86-video-nouveau

In this patch, we simply tell the DRI2 extension to use the render node if
available (using drmGetSameDeviceButType), and if it is the case,
we set the "require_authentication" attribute to 0.

The patches are available here: 
http://cgit.freedesktop.org/~mperes/xf86-video-nouveau/

## Mesa

In this patch, I simply check whether I should authenticate or not using 
the information
from the DRI2 protocol.

The patches are available here: http://cgit.freedesktop.org/~mperes/mesa/

Cheers,

Martin

Fan control in nouveau driver with geforce 9600gt

On 13/12/2012 11:02, Ozan ?a?layan wrote:
> Hi,
>
> I have a geforce 9600gt (nv94) display adapter which has its fan
> running at 100% speed. Yesterday I've compiled and booted with the
> latest nouveau-2.6 tree. sensors from lm_sensors can correctly acquire
> GPU temperature and PWM speed but as far as I understood setting the
> speed is still not supported, am I right?
>
> dmesg lists 3 performance levels with 100% fanspeed all of them.
>
> Are there any other things that I can try? I saw a prlvl_wr module
> parameter which enables setting performance level but it is indicated
> that it is dangerous. Anyway, anything that I can try and help you?
>
> Thanks.
>
Hi Ozan,

Please have a look at this documentation: 
http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal
It will tell you how to use fan management on your card :)

Please report back! I am interested in your results!

Martin
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/e57587cf/attachment-0001.html>

[PATCH 1/4] drm: Fix DRM_MINOR limits for control and render nodes

From: Kristian H?gsberg 

We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.

v2: fix a off-by-one overlap as suggested by ihadzic at research.bell-labs.com

Signed-off-by: Martin Peres 
---
 drivers/gpu/drm/drm_stub.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c236fd2..b56e977 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -107,10 +107,10 @@ static int drm_minor_get_id(struct drm_device *dev, int 
type)

if (type == DRM_MINOR_CONTROL) {
 base += 64;
-limit = base + 127;
+limit = base + 63;
 } else if (type == DRM_MINOR_RENDER) {
 base += 128;
-limit = base + 255;
+limit = base + 63;
 }

 again:
-- 
1.8.0.2

[PATCH 3/4] drm/i915: Support render nodes

From: Kristian H?gsberg 

Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Kristian H?gsberg 
---
 drivers/gpu/drm/i915/i915_dma.c | 36 ++--
 drivers/gpu/drm/i915/i915_drv.c |  3 ++-
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 61ae104..d0554b0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1851,7 +1851,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
@@ -1864,34 +1864,34 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, 
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
-   DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image, 
DRM_MASTER|DRM_CO

[PATCH 4/4] drm/nouveau: Support render nodes

From: Martin Peres 

Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.

Signed-off-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index fdd8813..30def9b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -586,18 +586,18 @@ nouveau_drm_postclose(struct drm_device *dev, struct 
drm_file *fpriv)

 static struct drm_ioctl_desc
 nouveau_ioctls[] = {
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam, 
DRM_UNLOCKED|DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, nouveau_abi16_ioctl_setparam, 
DRM_UNLOCKED|DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC, 
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE, 
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC, 
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC, 
nouveau_abi16_ioctl_channel_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE, 
nouveau_abi16_ioctl_channel_free, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_NOTIFIEROBJ_ALLOC, 
nouveau_abi16_ioctl_notifierobj_alloc, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 };

 static const struct file_operations
@@ -621,7 +621,7 @@ driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
-   DRIVER_MODESET | DRIVER_PRIME,
+   DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,

.load = nouveau_drm_load,
.unload = nouveau_drm_unload,
-- 
1.8.0.2

[PATCH 2/4] drm: Add support for render nodes

From: Kristian H?gsberg 

This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering.  The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only supports rendering
and limited buffer sharing.  A render node can either export a buffer using
the gem flink mechanism, or it can import and export buffers using the
prime fd passing mechanism.

A render node is not associated with any drm master and does not require
the legacy authentication step.  Render nodes can be used without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.

v2: Martin Peres
- Allow render nodes to access DRM_UNLOCKED IOCTLs)

Signed-off-by: Kristian H?gsberg 
Signed-off-by: Martin Peres 
---
 drivers/gpu/drm/drm_drv.c  | 13 +++--
 drivers/gpu/drm/drm_fops.c |  9 ++---
 drivers/gpu/drm/drm_pci.c  |  9 +
 include/drm/drmP.h |  3 +++
 4 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index be174ca..7c74959 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -131,14 +131,14 @@ static struct drm_ioctl_desc drm_ioctls[] = {

DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),

-   DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
DRM_AUTH|DRM_UNLOCKED),

DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),

-   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),

DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -427,9 +427,10 @@ long drm_ioctl(struct file *filp,
DRM_DEBUG("no function\n");
retcode = -EINVAL;
} else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)) 
||
-  ((ioctl->flags & DRM_AUTH) && !file_priv->authenticated) ||
+  ((ioctl->flags & DRM_AUTH) && (file_priv->minor->type != 
DRM_MINOR_RENDER) && !file_priv->authenticated) ||
   ((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
-  (!(ioctl->flags & DRM_CONTROL_ALLOW) && 
(file_priv->minor->type == DRM_MINOR_CONTROL))) {
+  (!(ioctl->flags & DRM_CONTROL_ALLOW) && 
(file_priv->minor->type == DRM_MINOR_CONTROL)) ||
+  (!(ioctl->flags & (DRM_RENDER_ALLOW | DRM_UNLOCKED)) && 
(file_priv->minor->type == DRM_MINOR_RENDER))) {
retcode = -EACCES;
} else {
if (cmd & (IOC_IN | IOC_OUT)) {
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..a27e8a4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -295,7 +295,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,

/* if there is no current master make this fd it */
mutex_lock(&dev->struct_mutex);
-   if (!priv->minor->master) {
+   if (!priv->minor->master && priv->minor->type != DRM_MINOR_RENDER) {
/* create a new master */
priv->minor->master = drm_master_create(priv->minor);
if (!priv->minor->master) {
@@ -334,10 +334,12 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
}
}
mutex_unlock(&dev->struct_mutex);
-   } else {
+   } else if (priv->minor->type != DRM_MINOR_RENDER) {
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
mutex_unlock(&dev->struct_mutex);
+   } else {
+   mutex_unlock(&dev->struct_mutex);
}

mutex_lock(&dev->struct_mutex);
@@ -529,7 +531,8 @@ int drm_release(struct inode *inode, struct file *filp)
iput(container_of(dev->dev_mapping, struct inode, i_data));

/* drop the reference held my the file priv */
-   drm_master_put(&file_priv-

[PATCH 2/5] drm: generate the path of a different device type for the same drm device

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 .gitignore   |  1 +
 tests/Makefile.am|  1 +
 tests/same_device_but_type.c | 52 
 xf86drm.c| 44 +
 xf86drm.h|  1 +
 5 files changed, 99 insertions(+)
 create mode 100644 tests/same_device_but_type.c

diff --git a/.gitignore b/.gitignore
index 28c77c5..318e129 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@ tests/gem_readwrite
 tests/openclose
 tests/setversion
 tests/updatedraw
+tests/same_device_but_type
 tests/modeprint/modeprint
 tests/modetest/modetest
 tests/kmstest/kmstest
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a3a59bd..ddc73ca 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -46,6 +46,7 @@ TESTS =   \
setversion  \
updatedraw  \
name_from_fd\
+   same_device_but_type\
$(NULL)

 SUBDIRS += vbltest $(NULL)
diff --git a/tests/same_device_but_type.c b/tests/same_device_but_type.c
new file mode 100644
index 000..f35951f
--- /dev/null
+++ b/tests/same_device_but_type.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright ? 2012
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Martin Peres 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include "drmtest.h"
+
+/**
+ * Checks drmGetSameDeviceButType
+ */
+int main(int argc, char **argv)
+{
+   int fd, ret;
+   drm_set_version_t sv, version;
+   const char *name = "/dev/dri/card0";
+   char *render;
+   int i;
+
+   render = drmGetSameDeviceButType(name, DRM_NODE_RENDER);
+   assert(strcmp(render, name) == 0);
+   drmFree(render);
+   
+   render = drmGetSameDeviceButType("/no_device", DRM_NODE_RENDER);
+   assert(render == NULL);
+
+   return 0;
+}
diff --git a/xf86drm.c b/xf86drm.c
index eb0549d..cca8d8a 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2602,6 +2602,50 @@ char *drmGetDeviceNameFromFd(int fd)
return NULL;
 }

+/**
+ * Generate the path to a different type (render node, control node, etc...)
+ * but for the same actual drm device.
+ *
+ * \param device a path to an existing drm device type.
+ * \param type the new type that should be returned.
+ * 
+ * \return the path to the same drm device but to a different type if success.
+ * NULL otherwise.
+ */
+char *drmGetSameDeviceButType(const char *device, int type)
+{
+   char base_path[64], name[64], *path, *device_name;
+   struct stat sbuf;
+   int i;
+   
+   /* get the device name (ie /card0) */
+   device_name=strrchr(device, '/');
+   if (!device_name)
+   return NULL;
+   
+   /* get the device's drm folder (ie /sys/class/drm/card0/device/drm */
+   snprintf(base_path, sizeof(base_path), "/sys/class/drm/%s/device/drm",
+device_name + 1);
+   
+   /* search for the type in the base path */
+   device_name = NULL;
+   for (i = 0; i < DRM_MAX_MINOR; i++) {
+   drmDevicePath(name, sizeof(name), base_path, type, i);
+   if (stat(name, &sbuf) == 0) {
+   device_name = strrchr(name, '/');
+   break;
+   }
+   }
+   if (!device_name)
+   return NULL;
+   
+   /* create a more appropriate path for the device (/dev/dri/card0) */
+   path = malloc(64);
+   snprintf(path, 64, "%s/%s", DRM_DIR_NAME, device_name + 1);
+
+   return path;
+}
+
 int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int *prime_fd)
 {
struct drm_prime_handle args;
diff --git a/xf86drm.h b/xf86drm.h
index d727ce1..658dfd7 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -733,6 +733,7 @

[PATCH 3/5] nouveau: Allow opening a specific type of drm device

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 nouveau/nouveau.c | 11 +--
 nouveau/nouveau.h |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 940d933..1402852 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@@ -128,9 +128,10 @@ nouveau_device_wrap(int fd, int close, struct 
nouveau_device **pdev)
 }

 int
-nouveau_device_open(const char *busid, struct nouveau_device **pdev)
+nouveau_device_open_type(const char *busid, struct nouveau_device **pdev, 
+int type)
 {
-   int ret = -ENODEV, fd = drmOpen("nouveau", busid);
+   int ret = -ENODEV, fd = drmOpenType("nouveau", busid, type);
if (fd >= 0) {
ret = nouveau_device_wrap(fd, 1, pdev);
if (ret)
@@ -139,6 +140,12 @@ nouveau_device_open(const char *busid, struct 
nouveau_device **pdev)
return ret;
 }

+int
+nouveau_device_open(const char *busid, struct nouveau_device **pdev)
+{
+   return nouveau_device_open_type(busid, pdev, DRM_NODE_RENDER);
+}
+
 void
 nouveau_device_del(struct nouveau_device **pdev)
 {
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index c42eea7..cbc0dc9 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -66,6 +66,8 @@ struct nouveau_device {
 };

 int  nouveau_device_wrap(int fd, int close, struct nouveau_device **);
+int  nouveau_device_open_type(const char *busid, struct nouveau_device **pdev, 
+ int type);
 int  nouveau_device_open(const char *busid, struct nouveau_device **);
 void nouveau_device_del(struct nouveau_device **);
 int  nouveau_getparam(struct nouveau_device *, uint64_t param, uint64_t 
*value);
-- 
1.8.0.1

[PATCH 1/5] drm: allow opening the drm device by type (control, render or render_only)

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 tests/name_from_fd.c |  19 ++
 xf86drm.c| 105 ---
 xf86drm.h|   7 
 3 files changed, 100 insertions(+), 31 deletions(-)

diff --git a/tests/name_from_fd.c b/tests/name_from_fd.c
index 330c8ff..8e1a197 100644
--- a/tests/name_from_fd.c
+++ b/tests/name_from_fd.c
@@ -41,17 +41,20 @@ int main(int argc, char **argv)
 {
int fd, ret;
drm_set_version_t sv, version;
-   const char *name = "/dev/dri/card0";
+   const char *name[2] = { "/dev/dri/card0", "/dev/dri/renderD128" };
char *v;
+   int i;

-   fd = open("/dev/dri/card0", O_RDWR);
-   if (fd == -1)
-   return 0;
+   for (i = 0; i < 2; i++) {
+   fd = open(name[i], O_RDWR);
+   if (fd > 0) {
+   v = drmGetDeviceNameFromFd(fd);
+   close(fd);
+   assert(v != NULL);
+   assert(strcmp(name[i], v) == 0);
+   }
+   }

-   v = drmGetDeviceNameFromFd(fd);
-   close(fd);
-
-   assert(strcmp(name, v) == 0);
drmFree(v);

return 0;
diff --git a/xf86drm.c b/xf86drm.c
index 2a74c80..eb0549d 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -85,9 +85,6 @@

 #define DRM_MSG_VERBOSITY 3

-#define DRM_NODE_CONTROL 0
-#define DRM_NODE_RENDER 1
-
 static drmServerInfoPtr drm_server_info;

 void drmSetServerInfo(drmServerInfoPtr info)
@@ -286,10 +283,51 @@ static int chown_check_return(const char *path, uid_t 
owner, gid_t group)
 }

 /**
+ * Generate the device name according to its type.
+ *
+ * \param buf buffer that will hold the device path after the call.
+ * \param len length of the buffer.
+ * \param base_dir base directory used to generate the path. If NULL, it
+ *defaults to DRM_DIR_NAME ("/dev/dri").
+ * \param type the type of device (control, render or render_only).
+ * \param minor number of the device.
+ */
+static void drmDevicePath(char *buf, size_t len, const char *base_dir, int 
type, 
+ int minor)
+{
+   const char *dev_name = NULL;
+   
+   switch (type)
+   {
+   case DRM_NODE_CONTROL:
+   dev_name = DRM_CONTROL_DEV_NAME;
+   /* we do not increase minor by 64 not to change the current 
+* behaviour even though I couldn't find who uses this type!
+*/
+   break;
+   case DRM_NODE_RENDER_ONLY:
+   dev_name = DRM_RENDER_ONLY_DEV_NAME;
+   minor += 128;
+   break;
+   default:
+   drmMsg("drmDevicePath: unknown type %d, default to render.\n", 
type);
+   case DRM_NODE_RENDER:
+   dev_name = DRM_DEV_NAME;
+   break;
+   }
+   
+   if (!base_dir)
+   base_dir = DRM_DIR_NAME;
+
+   snprintf(buf, len, dev_name, base_dir, minor);
+}
+
+/**
  * Open the DRM device, creating it if necessary.
  *
  * \param dev major and minor numbers of the device.
  * \param minor minor number of the device.
+ * \param type the type of device we want to open (control, render or 
render_only).
  * 
  * \return a file descriptor on success, or a negative value on error.
  *
@@ -308,7 +346,7 @@ static int drmOpenDevice(long dev, int minor, int type)
 uid_t   user= DRM_DEV_UID;
 gid_t   group   = DRM_DEV_GID, serv_group;

-sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME, 
minor);
+drmDevicePath(buf, sizeof(buf), NULL, type, minor);
 drmMsg("drmOpenDevice: node name is %s\n", buf);

 if (drm_server_info) {
@@ -417,7 +455,7 @@ static int drmOpenMinor(int minor, int create, int type)
 if (create)
return drmOpenDevice(makedev(DRM_MAJOR, minor), minor, type);

-sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME, 
minor);
+drmDevicePath(buf, sizeof(buf), NULL, type, minor);
 if ((fd = open(buf, O_RDWR, 0)) >= 0)
return fd;
 return -errno;
@@ -472,7 +510,7 @@ int drmAvailable(void)
  *
  * \sa drmOpenMinor() and drmGetBusid().
  */
-static int drmOpenByBusid(const char *busid)
+static int drmOpenByBusid(const char *busid, int type)
 {
 inti, pci_domain_ok = 1;
 intfd;
@@ -481,7 +519,7 @@ static int drmOpenByBusid(const char *busid)

 drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
 for (i = 0; i < DRM_MAX_MINOR; i++) {
-   fd = drmOpenMinor(i, 1, DRM_NODE_RENDER);
+   fd = drmOpenMinor(i, 1, type);
drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
if (fd >= 0) {
/* We need to try for 1.4 first for proper PCI domain support
@@ -531,7 +569,7 @@ static int drmOpenByBusid(const char *busid)
  * 
  * \sa drmOpenMinor(), drmGetVersion() and drmGetBusid().
  */
-static int drmOpenByName(const char *name)
+static int drmOpenByName(const cha

[PATCH 4/5] nouveau: bump version to 2.4.34 for release

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 nouveau/libdrm_nouveau.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 6170613..f3b99cf 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@

 Name: libdrm_nouveau
 Description: Userspace interface to nouveau kernel DRM services
-Version: 2.4.33
+Version: 2.4.34
 Libs: -L${libdir} -ldrm_nouveau
 Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/nouveau
 Requires.private: libdrm
-- 
1.8.0.1

[PATCH 5/5] configure.ac: bump version to 2.4.41 for release

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 configure.ac | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0c19929..df56066 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@

 AC_PREREQ([2.63])
 AC_INIT([libdrm],
-[2.4.40],
+[2.4.41],
 [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI],
 [libdrm])

@@ -68,10 +68,6 @@ LT_PREREQ([2.2])
 LT_INIT([disable-static])


-PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)
-AC_SUBST(PTHREADSTUBS_CFLAGS)
-AC_SUBST(PTHREADSTUBS_LIBS)
-
 pkgconfigdir=${libdir}/pkgconfig
 AC_SUBST(pkgconfigdir)
 AC_ARG_ENABLE([udev],
-- 
1.8.0.1

[PATCH] dri2proto: add device_requires_auth in xDRI2ConnectReply to support render nodes

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 dri2proto.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/dri2proto.h b/dri2proto.h
index 128b807..4d11ba7 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -35,7 +35,7 @@

 #define DRI2_NAME  "DRI2"
 #define DRI2_MAJOR 1
-#define DRI2_MINOR 4
+#define DRI2_MINOR 5

 #define DRI2NumberErrors   0
 #define DRI2NumberEvents   2
@@ -109,10 +109,12 @@ typedef struct {
 CARD32  length B32;
 CARD32  driverNameLength B32;
 CARD32  deviceNameLength B32;
-CARD32  pad2 B32;
-CARD32  pad3 B32;
+BYTEdeviceRequiresAuth;
+BYTEpad2;
+CARD16  pad3 B16;
 CARD32  pad4 B32;
 CARD32  pad5 B32;
+CARD32  pad6 B32;
 } xDRI2ConnectReply;
 #define sz_xDRI2ConnectReply   32

-- 
1.8.0.1

[PATCH] dri2: add support for render nodes

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 glx/glxdri2.c |  3 ++-
 hw/xfree86/dri2/dri2.c| 11 ++-
 hw/xfree86/dri2/dri2.h|  8 ++--
 hw/xfree86/dri2/dri2ext.c |  8 ++--
 4 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index bce1bfa..ead24bc 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -929,6 +929,7 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
 __GLXDRIscreen *screen;
 size_t buffer_size;
 ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+unsigned char devReqAuth;

 screen = calloc(1, sizeof *screen);
 if (screen == NULL)
@@ -936,7 +937,7 @@ __glXDRIscreenProbe(ScreenPtr pScreen)

 if (!xf86LoaderCheckSymbol("DRI2Connect") ||
 !DRI2Connect(serverClient, pScreen, DRI2DriverDRI,
- &screen->fd, &driverName, &deviceName)) {
+ &screen->fd, &driverName, &deviceName, &devReqAuth)) {
 LogMessage(X_INFO,
"AIGLX: Screen %d is not DRI2 capable\n", pScreen->myNum);
 return NULL;
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 40963c3..6238caa 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -115,6 +115,7 @@ typedef struct _DRI2Screen {
 int fd;
 unsigned int lastSequence;
 int prime_id;
+unsigned int device_requires_auth;

 DRI2CreateBufferProcPtr CreateBuffer;
 DRI2DestroyBufferProcPtr DestroyBuffer;
@@ -1317,7 +1318,8 @@ DRI2HasSwapControl(ScreenPtr pScreen)
 Bool
 DRI2Connect(ClientPtr client, ScreenPtr pScreen,
 unsigned int driverType, int *fd,
-const char **driverName, const char **deviceName)
+const char **driverName, const char **deviceName,
+   unsigned char *deviceRequiresAuth)
 {
 DRI2ScreenPtr ds;
 uint32_t prime_id = DRI2DriverPrimeId(driverType);
@@ -1503,6 +1505,13 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
 ds->DestroyBuffer2 = info->DestroyBuffer2;
 ds->CopyRegion2 = info->CopyRegion2;
 }
+
+if (info->version >= 10) {
+ds->device_requires_auth = info->device_requires_auth;
+xf86DrvMsg(pScreen->myNum, X_INFO,
+   "[DRI2] The device %s authentication\n",
+  info->device_requires_auth?"requires":"doesn't require");
+}

 /*
  * if the driver doesn't provide an AuthMagic function or the info struct
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1e7afdd..f855565 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -205,7 +205,7 @@ typedef int (*DRI2GetParamProcPtr) (ClientPtr client,
 /**
  * Version of the DRI2InfoRec structure defined in this header
  */
-#define DRI2INFOREC_VERSION 9
+#define DRI2INFOREC_VERSION 10

 typedef struct {
 unsigned int version;   /**< Version of this struct */
@@ -252,6 +252,9 @@ typedef struct {
 DRI2CreateBuffer2ProcPtr CreateBuffer2;
 DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
 DRI2CopyRegion2ProcPtr CopyRegion2;
+
+ /* added in version 10 */
+ unsigned char device_requires_auth;
 } DRI2InfoRec, *DRI2InfoPtr;

 extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
@@ -264,7 +267,8 @@ extern _X_EXPORT Bool DRI2Connect(ClientPtr client, 
ScreenPtr pScreen,
   unsigned int driverType,
   int *fd,
   const char **driverName,
-  const char **deviceName);
+  const char **deviceName,
+ unsigned char *deviceRequiresAuth);

 extern _X_EXPORT Bool DRI2Authenticate(ClientPtr client, ScreenPtr pScreen, 
uint32_t magic);

diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index e1decec..1a78916 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -107,12 +107,14 @@ ProcDRI2Connect(ClientPtr client)
 .sequenceNumber = client->sequence,
 .length = 0,
 .driverNameLength = 0,
-.deviceNameLength = 0
+.deviceNameLength = 0,
+.deviceRequiresAuth = 1
 };
 DrawablePtr pDraw;
 int fd, status;
 const char *driverName;
 const char *deviceName;
+unsigned char deviceRequiresAuth;

 REQUEST_SIZE_MATCH(xDRI2ConnectReq);
 if (!validDrawable(client, stuff->window, DixGetAttrAccess,
@@ -120,11 +122,13 @@ ProcDRI2Connect(ClientPtr client)
 return status;

 if (!DRI2Connect(client, pDraw->pScreen,
- stuff->driverType, &fd, &driverName, &deviceName))
+ stuff->driverType, &fd, &driverName, &deviceName, 
+&deviceRequiresAuth))
 goto fail;

 rep.driverNameLength = strlen(driverName);
 rep.deviceNameLength = strlen(deviceName);
+rep.deviceRequiresAuth = deviceRequiresAuth;
 rep.length = (rep.driverNameLength + 3) / 4 +

[PATCH] add support for render nodes

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 configure.ac   |  2 +-
 src/nouveau_dri2.c | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index ff9c337..61dfb01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,7 +67,7 @@ XORG_DRIVER_CHECK_EXT(XV, videoproto)
 XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)

 # Checks for pkg-config packages
-PKG_CHECK_MODULES(LIBDRM_NOUVEAU, [libdrm_nouveau >= 2.4.25])
+PKG_CHECK_MODULES(LIBDRM_NOUVEAU, [libdrm_nouveau >= 2.4.34])
 AC_SUBST(LIBDRM_NOUVEAU_CFLAGS)
 AC_SUBST(LIBDRM_NOUVEAU_LIBS)

diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 036bcff..f852d8e 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -754,6 +754,7 @@ nouveau_dri2_init(ScreenPtr pScreen)
{ "nouveau", "nouveau" },
{ "nouveau_vieux", "nouveau_vieux" }
};
+   char *device_name = NULL;

if (pNv->Architecture >= NV_ARCH_30)
dri2.driverNames = drivernames[0];
@@ -788,6 +789,16 @@ nouveau_dri2_init(ScreenPtr pScreen)
dri2.DestroyBuffer2 = nouveau_dri2_destroy_buffer2;
dri2.CopyRegion2 = nouveau_dri2_copy_region2;
 #endif
+
+#if DRI2INFOREC_VERSION >= 10
+   dri2.version = 10;
+
+   /* try to use the render node if available */
+   device_name = drmGetSameDeviceButType(pNv->drm_device_name, 
DRM_NODE_RENDER_ONLY);
+   if (device_name)
+   dri2.deviceName = device_name;
+   dri2.device_requires_auth = (device_name == NULL);
+#endif
return DRI2ScreenInit(pScreen, &dri2);
 }

-- 
1.8.0.1

[PATCH] dri2: add support for render nodes

From: Martin Peres 

Signed-off-by: Martin Peres 
---
 src/gallium/state_trackers/egl/x11/x11_screen.c |  2 +-
 src/glx/dri2.c  |  6 +-
 src/glx/dri2.h  |  3 ++-
 src/glx/dri2_glx.c  | 20 +++-
 src/glx/dri_glx.c   |  3 ++-
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/src/gallium/state_trackers/egl/x11/x11_screen.c 
b/src/gallium/state_trackers/egl/x11/x11_screen.c
index effac0e..f648e91 100644
--- a/src/gallium/state_trackers/egl/x11/x11_screen.c
+++ b/src/gallium/state_trackers/egl/x11/x11_screen.c
@@ -234,7 +234,7 @@ x11_screen_probe_dri2(struct x11_screen *xscr, int *major, 
int *minor)
/* get the driver name and the device name */
if (!xscr->dri_driver) {
   if (!DRI2Connect(xscr->dpy, RootWindow(xscr->dpy, xscr->number),
-   &xscr->dri_driver, &xscr->dri_device))
+   &xscr->dri_driver, &xscr->dri_device, NULL))
  xscr->dri_driver = xscr->dri_device = NULL;
}
if (major)
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index bcd1f9c..1c2c91f 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -264,7 +264,8 @@ DRI2QueryVersion(Display * dpy, int *major, int *minor)
 }

 Bool
-DRI2Connect(Display * dpy, XID window, char **driverName, char **deviceName)
+DRI2Connect(Display * dpy, XID window, char **driverName, char **deviceName,
+unsigned char *deviceRequiresAuth)
 {
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
xDRI2ConnectReply rep;
@@ -327,6 +328,9 @@ DRI2Connect(Display * dpy, XID window, char **driverName, 
char **deviceName)
}
_XReadPad(dpy, *deviceName, rep.deviceNameLength);
(*deviceName)[rep.deviceNameLength] = '\0';
+   
+   if (deviceRequiresAuth)
+  *deviceRequiresAuth = rep.deviceRequiresAuth;

UnlockDisplay(dpy);
SyncHandle();
diff --git a/src/glx/dri2.h b/src/glx/dri2.h
index a6fe66e..798cba1 100644
--- a/src/glx/dri2.h
+++ b/src/glx/dri2.h
@@ -53,7 +53,8 @@ DRI2QueryVersion(Display * display, int *major, int *minor);

 extern Bool
 DRI2Connect(Display * display, XID window,
-char **driverName, char **deviceName);
+char **driverName, char **deviceName,
+unsigned char *deviceRequiresAuth);

 extern Bool
 DRI2Authenticate(Display * display, XID window, drm_magic_t magic);
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 1b3cf2b..e6354ef 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1119,6 +1119,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
__GLXDRIscreen *psp;
struct glx_config *configs = NULL, *visuals = NULL;
char *driverName, *deviceName, *tmp;
+   unsigned char deviceRequiresAuth;
drm_magic_t magic;
int i;

@@ -1134,7 +1135,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
}

if (!DRI2Connect(priv->dpy, RootWindow(priv->dpy, screen),
-   &driverName, &deviceName)) {
+   &driverName, &deviceName, &deviceRequiresAuth)) {
   glx_screen_cleanup(&psc->base);
   free(psc);
   InfoMessageF("screen %d does not appear to be DRI2 capable\n", screen);
@@ -1179,16 +1180,17 @@ dri2CreateScreen(int screen, struct glx_display * priv)
   goto handle_error;
}

-   if (drmGetMagic(psc->fd, &magic)) {
-  ErrorMessageF("failed to get magic\n");
-  goto handle_error;
-   }
+   if (deviceRequiresAuth) {
+  if (drmGetMagic(psc->fd, &magic)) {
+ ErrorMessageF("failed to get magic\n");
+ goto handle_error;
+  }

-   if (!DRI2Authenticate(priv->dpy, RootWindow(priv->dpy, screen), magic)) {
-  ErrorMessageF("failed to authenticate magic %d\n", magic);
-  goto handle_error;
+  if (!DRI2Authenticate(priv->dpy, RootWindow(priv->dpy, screen), magic)) {
+ ErrorMessageF("failed to authenticate magic %d\n", magic);
+ goto handle_error;
+  }
}
-

/* If the server does not support the protocol for
 * DRI2GetBuffersWithFormat, don't supply that interface to the driver.
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index ba8fda2..2a03c57 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -133,7 +133,8 @@ driGetDriverName(Display * dpy, int scrNum, char 
**driverName)
}
else if (DRI2QueryExtension(dpy, &event, &error)) {  /* DRI2 */
   char *dev;
-  Bool ret = DRI2Connect(dpy, RootWindow(dpy, scrNum), driverName, &dev);
+  Bool ret = DRI2Connect(dpy, RootWindow(dpy, scrNum), driverName, &dev,
+ NULL);

   if (ret)
  free(dev);
-- 
1.8.0.1

Request for nv40-c0 testing thermal/fan management

Hi Nouveau enthusiasts,

One week ago was merged the thermal/fan management code for most nvidia
cards.

So far, no major issue arose but we would like to have more testing as
soon as possible to deliver a nice and solid support when Linux 3.8 is
released.

Thermal management is split into two parts:

- Temperature monitoring: Making sure your card doesn't overheat
- Fan management: Driving the fan speed according to the temperature

Thermal monitoring should be working on all chipsets that support it
(nv43+). However, some cards use an external (i2c) monitoring chip.
Because of the limitations of the hwmon interface, we cannot access this
information and thus, cannot monitor the temperature of your card
ourselves. However, we should be able to load the right kernel module so
as you can monitor it for us.

As for fan management, the situation is the same as thermal mangement
with the additional limitation that nvc0+ (Fermi+) chipsets are not
supported for fan management. The reason is that nvc0+ chipset use an
internal engine (PDAEMON) that is already set up by the vbios to do fan
management and we didn't feel like getting rid of it just yet even
though some experimental code for its replacement is already available.

What we are trying to avoid is:

VERY IMPORTANT:
- No temperature at all while the blob reports one!
- Inaccurate temperature (we already have a bug report for that on nv4x)

IMPORTANT:
- The fan/card makes a strange noise while driving the fan
- You manage to stop the fan without fiddling with pwm_min
- Non-linear fan speed with PWM value

Please report if one of these issues occur. If you experience something
strange that isn't on the list, please inform us too :)

Complete documentation for thermal management is available at
/Documentation/thermal/nouveau_thermal
(http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal).

Looking forward to your feedback!

Cheers,

Martin (AKA mupuf)

[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

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

--- Comment #6 from Serkan Hosca  ---
(In reply to comment #5)
> Does your kernel tree have this patch?
> http://cgit.freedesktop.org/~airlied/linux/commit/drivers/gpu/drm/radeon/
> radeon_object.c?h=drm-next&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb

Yea i have that commit.

-- 
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/20121217/1909bd31/attachment.html>

[git pull] drm next


Hi Linus,

This is the one and only next pull for 3.8, we had a regression we found 
last week, so I was waiting for that to resolve itself, and I ended up 
with some Intel fixes on top as well.

Highlights:
new driver: nvidia tegra 20/30/hdmi support 
radeon: add support for previously unused DMA engines, more HDMI regs,  
eviction speeds ups and fixes
i915:  HSW support enable, agp removal on GEN6, seqno wrapping
exynos: IPP subsystem support (image post proc), HDMI
nouveau: display class reworking, nv20->40 z compression 
ttm: start of locking fixes, rcu usage for lookups,
core: documentation updates, docbook integration, monotonic clock usage, 
move from connector to object properties

Dave.

The following changes since commit e548a83c34806b8bc2c55f52d3bc481a13a3829e:

  Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux 
(2012-11-28 16:51:10 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to 55bde6b1442fed8af67b92d21acce67db454c9f9:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-12-16 
06:05:03 +)



Adam Jackson (6):
  drm: Export drm_probe_ddc()
  drm/dp: Update DPCD defines
  drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
  drm/i915/dp: Be smarter about connection sense for branch devices
  drm/dp: Document DP spec versions for various DPCD registers
  drm/dp: Make sink count DP 1.2 aware

Akinobu Mita (2):
  drm: use memchr_inv()
  drm/radeon: Use hweight32

Alan Cox (1):
  gma600: Enable HDMI support

Alex Deucher (29):
  drm: fix documentation for drm_crtc_set_mode()
  drm/radeon/dce3.2: add registers for ELD handling
  drm/radeon/dce4/5: add registers for ELD handling
  drm/radeon/dce32+: use fractional fb dividers for high clocks
  drm/radeon: add new INFO ioctl requests
  drm/radeon: fix eDP clk and lane setup for scaled modes
  drm/radeon: bump driver version for new info ioctl requests
  drm/radeon/kms: Add initial support for async DMA on r6xx/r7xx
  drm/radeon/kms: Add initial support for async DMA on evergreen
  drm/radeon/kms: Add initial support for async DMA on cayman/TN
  drm/radeon/kms: Add initial support for async DMA on SI
  drm/radeon/kms: add support for dma rings to radeon_test_moves()
  drm/radeon: use async dma for ttm buffer moves on 6xx-SI
  drm/radeon: add dma engine support for vm pt updates on ni (v5)
  drm/radeon: use DMA engine for VM page table updates on cayman/TN
  drm/radeon: add dma engine support for vm pt updates on si (v2)
  drm/radeon: use DMA engine for VM page table updates on SI
  drm/radeon: improve mc_stop/mc_resume on r5xx-r7xx
  drm/radeon: add register headers for CP DMA on r6xx-SI
  drm/radeon: add support for CP DMA packet to r6xx/r7xx CS checker
  drm/radeon: add support for CP DMA packet to evergreen CS checker
  drm/radeon/cayman: add VM CS checker support for CP DMA
  drm/radeon/si: add VM CS checker support for CP DMA
  drm/radeon/kms: add 6xx/7xx CS parser for async DMA (v2)
  drm/radeon/kms: add evergreen/cayman CS parser for async DMA (v2)
  drm/radeon: add VM CS parser support for async DMA on cayman/TN/SI
  drm/radeon: enable the async DMA rings in the CS ioctl
  drm/radeon: bump version for CS ioctl support for async DMA
  drm/radeon: add more pedantic checks in the CP DMA checker

Ben Skeggs (90):
  drm/nouveau/bios: attempt to fetch entire acpi rom image in one shot
  drm/nouveau/fb: split tile and compression region handling
  drm/nv20/fb: split implementation into nv20/nv25 pieces
  drm/nv30/fb: split implementation into nv34(nv10)/nv30/nv35 pieces
  drm/nv40/fb: split implementation into nv40/nv41/nv44/nv46/nv47/nv49/nv4e 
pieces
  drm/nv20/fb: fix zcomp register calculation on big-endian systems
  drm/nv30-nv40/fb: make use of bankoff for zeta buffers, where supported
  drm/nv40/fb: start bashing zcomp registers on relevant chipsets
  drm/nouveau/fb: read TILE_BASE after writing it to avoid a hardware race
  drm/nouveau: replace some open-coded mm_initialised checks
  drm/nv30/fb: start bashing zcomp registers with 'disabled' (for now)
  drm/nouveau/fb: create tag heap from common code for all relevant chipsets
  drm/nv30-nv40/fb: call zcomp setup hook from tiling setup
  drm/nv30-nv40/graph: poke zcomp regs from tile_prog hook
  drm/nv20/fb: fixup compression tag allocation size
  drm/nv40/fb: enable z compression
  drm/nv30/fb: enable z compression
  drm/nv40/fb: use an actual compressed zeta format
  drm/nouveau: remove newline-only NV_DEBUG calls
  drm/nouveau/gpio: place upper limit on using old-school tvdac bios data
  drm/nouveau: pass add

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version