[Linaro-mm-sig] CDF discussions at FOSDEM

[Daniel Vetter]

On Tue, Jan 29, 2013 at 08:35:28PM +0100, Marcus Lorentzon wrote:
> On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> >On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter  
> >wrote:
> >Ok, in the interest of pre-heating the discussion a bit I've written down
> >my thoughts about display slave drivers. Adding a few more people and
> >lists to make sure I haven't missed anyone ...
> >
> >Cheers, Daniel
> >--
> >Display Slaves
> >==
> >
> >A highly biased quick analysis from Daniel Vetter.
> And here is my biased version as one of the initiators of the idea of CDF.

Thanks a lot for your detailed answer. Some quick replies, I need to go
through this more carefully and maybe send another mail.

> I work with ARM SoCs (ST-Ericsson) and mobile devices (DSI/DPI
> panels). Of course some of these have the "PC" type of encoder
> devices like HDMI and eDP or even VGA. But from what I have seen
> most of these encoders are used by few different SoCs(GPUs?). And
> using these type of encoders was quite straight forward from DRM
> encoders. My goal was to get some common code of all the "mobile"
> panel encoders or "display module driver IC"s as some call them.
> Instead of tens of drivers (my assumption) you now have hundreds of
> drivers often using MIPI DSI/DPI/DBI or some similar interface. And
> lots of new come each year. There are probably more panel types than
> there are products on the market, since most products use more than
> one type of panel on the same product to secure sourcing for mass
> production (note multiple panels use same driver IC).
> So that was the initial goal, to cover all of these, which most are
> maintained per SoC/CPU out of kernel.org. If HDMI/DP etc fits in
> this framework, then that is just a nice bonus.
> I just wanted to give my history so we are not trying to include to
> many different types of encoders without an actual need. Maybe the
> I2C drm stuff is good enough for that type of encoders. But again,
> it would be nice with one suit that fits all ...
> I also like the idea to start out small. But if no support is added
> initially for the mobile panel types. Then I think it will be hard
> to get all vendors to start pushing those drivers, because the
> benefit of doing so would be small. But maybe the CDF work with
> Linaro and Laurent could just be a second step of adding the
> necessary details to your really simple baseline. And I also favor
> the helpers over framework approach but I miss a big piece which is
> the ops for panel drivers to call back to display controller (the
> video source stuff).

Yeah, I think we have two main goals here for enabling code sharing for
these output devices:
1. Basic panel support, with the panel usually glued onto the board, so
squat runtime configuration required. Aim is to get the gazillion of
out-of-tree drivers merged.
2. Allowing generic output encoder slaves to be used in a bunch of SoCs in.

Summarizing my previous mail I fear that if we start with with the first
point and don't take some of the mad features required to do the 2nd one
right into account, we'll end up at a rather ugly spot.

[cut]

> >- hdmi/dp helpers: HDMI/DP are both standardized output connectors with nice
> >   complexity. DP is mostly about handling dp aux transactions and DPCD
> >   registers, hdmi mostly about infoframes and how to correctly set them up 
> > from
> >   the mode + edid.
> Yes, it is a mess. But we have managed to hide that below a simple
> panel API similar to CDF/omap so far.

Well, my concern is that we need to expose a bunch of special properties
(both to the master driver and ultimately to userspace) which are rather
hard to shovel through a simple panel abstraction. Ime from desktop
graphics there's no limits to the insane usecases and devices people come
up with and want to plug into your machine ;-)

> >- dpms is 4 states in drm, even more in fbdev afaict, but real hw only 
> >supports
> >   on/off nowadays ... how should/do we care?
> Agreed, they should all really go away unless someone find a valid use case.
> >- Fancy modes and how to represent them. Random list of things we need to
> >   represent somehow: broadcast/reduced rbg range for hdmi, yuv modes, 
> > different
> >   bpc modes (and handling how this affects bandwidth/clocks, e.g. i915
> >   auto-dithers to 6bpc on DP if there's not enough), 3D hdmi modes (patches 
> > have
> >   floated on dri-devel for this), overscan compensation. Many of these 
> > things
> >   link in with e.g. the helper libraries for certain outputs, e.g. 
> > discovering
> >   DP sink capabilities or setting up the correct hdmi infoframe.
> Are you saying drm modes doesn't support this as of today? I have
> not used these types of modes in DRM yet. Maybe the common video
> mode patches is a good start.

All the stuff I've mentioned is support in drm/i915 (or at least we have
patches floating around), and on a quick look at the proposed video_mode I
couldn't fit this all in. Some of the 

[Bug 59899] Diagonal rendering artifacts on xbmc

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

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

--- Comment #4 from aeriksson at fastmail.fm ---
Created attachment 73878
  --> https://bugs.freedesktop.org/attachment.cgi?id=73878=edit
Xorg.0.log

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

[Bug 59899] Diagonal rendering artifacts on xbmc

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

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

--- Comment #3 from aeriksson at fastmail.fm ---
Created attachment 73877
  --> https://bugs.freedesktop.org/attachment.cgi?id=73877=edit
glxinfo

-- 
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/20130129/1ef44e6d/attachment.html>

[Bug 59899] Diagonal rendering artifacts on xbmc

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

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

--- Comment #2 from aeriksson at fastmail.fm ---
Created attachment 73876
  --> https://bugs.freedesktop.org/attachment.cgi?id=73876=edit
dmesg

-- 
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/20130129/3ae24f9b/attachment.html>

[PATCH v2] drm/exynos: Get HDMI version from device tree

[Sylwester Nawrocki]

Hi,

On 01/08/2013 11:56 PM, Stephen Warren wrote:
> On 01/08/2013 01:16 PM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>
> I guess this seems OK to me if required, although I'd certainly like to
> see someone familiar with the Exynos HW confirm whether this should be
> driven purely by DT compatible value for the HDMI IP block instead though.

I think the supported HDMI standard is something that could well be derived
from the compatible property. The IP supporting v1.3 and v1.4 will be
significantly different, so this would anyway already need to be reflected
in the compatible property. The only issue I see here is that people tend
to make the compatible string overly generic, so it is hardly usable for
anything but matching an IP with its driver. For instance for exynos5 we
have now (Documentation/devicetree/bindings/drm/exynos/hdmi.txt):

compatible = "samsung,exynos5-hdmi";

For Exynos4 series there were already some patches proposed [1], but I 
believe
this isn't a clean solution. Instead of things like:

compatible = "samsung,exynos4-hdmi13";
compatible = "samsung,exynos4-hdmi14";

I would much more like to see the SoC version embedded in the compatible
string, e.g.

compatible = "samsung,exynos4210-hdmi"; /* among others it carries an
  information this IP supports
  HDMI v1.3 */  

compatible = "samsung,exynos4212-hdmi"; /* HDMI v1.4, IIRC */

[1] http://www.spinics.net/lists/linux-samsung-soc/msg15289.html

--

Thanks,
Sylwester

[Bug 59904] 3DMark2000 crashes: radeon: mmap failed, errno: 12

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

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

--- Comment #10 from maxijac at free.fr ---
OK, it looks like it only happens when I'm on linux 3.8, it's OK when running
linux 3.7.
Also when using 3.8 it does look like a memory leak too ! So I experience the
same symptoms.

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

[Linaro-mm-sig] CDF discussions at FOSDEM

[Marcus Lorentzon]

On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter  
> wrote:
> Ok, in the interest of pre-heating the discussion a bit I've written down
> my thoughts about display slave drivers. Adding a few more people and
> lists to make sure I haven't missed anyone ...
>
> Cheers, Daniel
> --
> Display Slaves
> ==
>
> A highly biased quick analysis from Daniel Vetter.
And here is my biased version as one of the initiators of the idea of CDF.

I work with ARM SoCs (ST-Ericsson) and mobile devices (DSI/DPI panels). 
Of course some of these have the "PC" type of encoder devices like HDMI 
and eDP or even VGA. But from what I have seen most of these encoders 
are used by few different SoCs(GPUs?). And using these type of encoders 
was quite straight forward from DRM encoders. My goal was to get some 
common code of all the "mobile" panel encoders or "display module driver 
IC"s as some call them. Instead of tens of drivers (my assumption) you 
now have hundreds of drivers often using MIPI DSI/DPI/DBI or some 
similar interface. And lots of new come each year. There are probably 
more panel types than there are products on the market, since most 
products use more than one type of panel on the same product to secure 
sourcing for mass production (note multiple panels use same driver IC).
So that was the initial goal, to cover all of these, which most are 
maintained per SoC/CPU out of kernel.org. If HDMI/DP etc fits in this 
framework, then that is just a nice bonus.
I just wanted to give my history so we are not trying to include to many 
different types of encoders without an actual need. Maybe the I2C drm 
stuff is good enough for that type of encoders. But again, it would be 
nice with one suit that fits all ...
I also like the idea to start out small. But if no support is added 
initially for the mobile panel types. Then I think it will be hard to 
get all vendors to start pushing those drivers, because the benefit of 
doing so would be small. But maybe the CDF work with Linaro and Laurent 
could just be a second step of adding the necessary details to your 
really simple baseline. And I also favor the helpers over framework 
approach but I miss a big piece which is the ops for panel drivers to 
call back to display controller (the video source stuff).
Some inline comments below.

>
> A quick discussion about the issues surrounding some common framework for
> display slaves like panels, hdmi/DP/whatever encoders, ... Since these 
> external
> chips are very often reused accross different SoCs, it would be beneficial to
> share slave driver code between different chipset drivers.
>
> Caveat Emperor!
> ---
>
> Current output types and slave encoders already have to deal with a pletoria 
> of
> special cases and strange features. To avoid ending up with something not
> suitable for everyone, we should look at what's all supported already and how 
> we
> could possibly deal with those things:
>
> - audio embedded into the display stream (hdmi/dp). x86 platforms with the HD
>Audio framework rely on ELD and forwarding certain events as interrupts
>through the hw between the display and audio side ...
I would assume any driver handling audio/video/cec like HDMI would hook 
itself up as an mfd device. And one of those exposed functions would be 
the CDF part. Instead of pushing everything into the "display parts". At 
least that is sort of what we do today and it keeps the audio, cec and 
display parts nicely separated.
> - hdmi/dp helpers: HDMI/DP are both standardized output connectors with nice
>complexity. DP is mostly about handling dp aux transactions and DPCD
>registers, hdmi mostly about infoframes and how to correctly set them up 
> from
>the mode + edid.
Yes, it is a mess. But we have managed to hide that below a simple panel 
API similar to CDF/omap so far.
> - dpms is 4 states in drm, even more in fbdev afaict, but real hw only 
> supports
>on/off nowadays ... how should/do we care?
Agreed, they should all really go away unless someone find a valid use case.
> - Fancy modes and how to represent them. Random list of things we need to
>represent somehow: broadcast/reduced rbg range for hdmi, yuv modes, 
> different
>bpc modes (and handling how this affects bandwidth/clocks, e.g. i915
>auto-dithers to 6bpc on DP if there's not enough), 3D hdmi modes (patches 
> have
>floated on dri-devel for this), overscan compensation. Many of these things
>link in with e.g. the helper libraries for certain outputs, e.g. 
> discovering
>DP sink capabilities or setting up the correct hdmi infoframe.
Are you saying drm modes doesn't support this as of today? I have not 
used these types of modes in DRM yet. Maybe the common video mode 
patches is a good start.
> - How to expose random madness as properties, e.g. backlight controllers,
>broadcast mode, enable/disable embedded audio (some screens advertise it, 
> but

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

--- Comment #3 from Andy Furniss  ---
Comment on attachment 73868
  --> https://bugs.freedesktop.org/attachment.cgi?id=73868
worse case from cold boot

Ignore low fps on this compared to other screen - the card was on low.

-- 
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/20130129/076470ae/attachment.html>

radeon modeset crashes on A4-3400 HD6410D

[Mikko Tiihonen]

Hi,

I have a A4-3400 CPU that I bought half a year ago. I've tried once month,
but  Fedora has never succeeded in booting in graphical mode.

Some time ago a finally built some custom kernels to figure out why. I
created a bug to Fedora
bug<https://bugzilla.redhat.com/show_bug.cgi?id=892233>,
but it has not progressed.

Analysis:
The radeon module startup fails with division by zero in
r6xx_remap_render_backend because the first RB is not enabled and the code
assuming that enabled RBs must be all the first ones of the valid range.


Longer version:

In r600.c:r6xx_remap_render_backend

The function contains only one divide:

u32 r6xx_remap_render_backend(struct radeon_device *rdev,
  u32 tiling_pipe_num,
  u32 max_rb_num,
  u32 total_max_rb_num,
  u32 disabled_rb_mask)
{
u32 rendering_pipe_num, rb_num_width, req_rb_num;
...
/* mask out the RBs that don't exist on that asic */
disabled_rb_mask |= (0xff << max_rb_num) & 0xff;

rendering_pipe_num = 1 << tiling_pipe_num;
req_rb_num = total_max_rb_num - r600_count_pipe_bits(disabled_rb_mask);
BUG_ON(rendering_pipe_num < req_rb_num);

pipe_rb_ratio = rendering_pipe_num / req_rb_num;

I added a printk to see what actual parameters are passed in:

tiling_pipe_num=2, max_rb_num=1, total_max_rb_num=8, disabled_rb_mask=253

Using those to calculate the divide by zero comes from:
disabled_rb_mask |= 254; -> 255
req_rb_num = 8 - 8;


Quick fix for stable kernel series:

The attached fix activates only in the division by zero case and instead of
failing uses the given disabled_rb_mask. This is guaranteed to be
regression free and actually allows me to load the radeon driver
successfully. It does help with cards that currently work, but for which
some usable RBs are disabled due to the eager masking.


Proper fix would propably be to find out think why the disabled_rb_mask is
masked the way it is, were there bugs in other places for which it is a
workaround. I can see two possible modifictions:
1) only mask bits exceeding total_max_rb_num instead of the
max_rb_numsince the one enabled RB on A4-3400 can propably be any one
of the 8
possible values.
2) or activate the current code only if there are more than max_rb_num zero
bits in the given disabled_rb_mask


-Mikko
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/c1a632a1/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: r600-division-by-zero.patch
Type: application/octet-stream
Size: 831 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/c1a632a1/attachment-0001.obj>

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

Andy Furniss  changed:

   What|Removed |Added

  Attachment #73869|text/plain  |image/png
  mime type||

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

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

--- Comment #2 from Andy Furniss  ---
Created attachment 73869
  --> https://bugs.freedesktop.org/attachment.cgi?id=73869=edit
best case after repeated runs

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

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

--- Comment #1 from Andy Furniss  ---
Created attachment 73868
  --> https://bugs.freedesktop.org/attachment.cgi?id=73868=edit
worse case from cold boot

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

[Bug 60034] New: rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

  Priority: medium
Bug ID: 60034
  Assignee: dri-devel at lists.freedesktop.org
   Summary: rv790 etqw regression since r600g: add async for
staging buffer upload v2
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: lists at andyfurniss.entadsl.com
  Hardware: x86 (IA32)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Card PCIE HD4890, drm fixes kernel.

Since -

commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
Author: Jerome Glisse 
Date:   Mon Jan 7 17:45:59 2013 -0500

r600g: add async for staging buffer upload v2

v2: Add virtual address to dma src/dst offset for cayman


I can see some reflection rendering errors in etqw.

They are not visible on most maps but looking from high up on island where the
sky is reflected in the sea they are obvious from a cold boot, but far more
subtle after running repeatedly for bisect.

attached screenshots showing both cases.

-- 
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/20130129/3042dc44/attachment.html>

[Bug 53111] vgaswitcheroo not working anymore

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

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





--- Comment #2 from cem.aydin at gmx.ch  2013-01-29 19:10:46 ---
Usually I use the current arch package. Looking at the Arch Rollback Machine
(http://arm.konnichi.com/search/index.php?a=64=^linux=1) shows that
there was made a jump from 3.6.11 to 3.7.3. I was a bit surprised before to get
3.7.4 all of a sudden... I just tried 3.7.3 and the problem appears there
already.

Doing a quick search I found this:
https://bugzilla.novell.com/show_bug.cgi?id=798254 indicating that it's already
broken on 3.7.1 (similar description, and _same_ lspci | grep VGA as mine:

[root at hplaptop cem]# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Caicos
[Radeon HD 6400M/7400M Series]

The old Arch bug mentioned there was mine, but note that it is _not_ related to
this error cause in the meantime vgaswitcheroo was working.

Don't know if it's of interest but maybe see the link there:
http://www.phoronix.com/scan.php?page=news_item=MTE4MDM

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

[PATCH 2/7] mutex: add support for reservation style locks

[Rob Clark]

On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
 wrote:
>

Hi Maarten,

This is a nice looking extension to avoid re-implementing a mutex in
TTM/reservation code..  ofc, probably someone more familiar with mutex
code should probably review, but probably a bit of explanation about
what and why would be helpful.

> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
>   Lock a buffer with a reservation_id set. reservation_id must not be set to 
> 0,
>   since this is a special value that means no reservation_id.
>
>   Normally if reservation_id is not set, or is older than the reservation_id 
> that's
>   currently set on the mutex, the behavior will be to wait normally.
>
>   However, if  the reservation_id is newer than the current reservation_id, 
> -EAGAIN
>   will be returned, and this function must unreserve all other mutexes and 
> then redo
>   a blocking lock with normal mutex calls to prevent a deadlock, then call
>   mutex_locked_set_reservation on successful locking to set the 
> reservation_id inside
>   the lock.

It might be a bit more clear to write up how this works from the
perspective of the user of ticket_mutex, separately from the internal
implementation first, and then how it works internally?  Ie, the
mutex_set_reservation_fastpath() call is internal to the
implementation of ticket_mutex, but -EAGAIN is something the caller of
ticket_mutex shall deal with.  This might give a clearer picture of
how TTM / reservation uses this to prevent deadlock, so those less
familiar with TTM could better understand.

Well, here is an attempt to start a write-up, which should perhaps
eventually be folded into Documentation/ticket-mutex-design.txt.  But
hopefully a better explanation of the problem and the solution will
encourage some review of the ticket_mutex changes.

==
Basic problem statement:
- --- -
GPU's do operations that commonly involve many buffers.  Those buffers
can be shared across contexts/processes, exist in different memory
domains (for example VRAM vs system memory), and so on.  And with
PRIME / dmabuf, they can even be shared across devices.  So there are
a handful of situations where the driver needs to wait for buffers to
become ready.  If you think about this in terms of waiting on a buffer
mutex for it to become available, this presents a problem because
there is no way to guarantee that buffers appear in a execbuf/batch in
the same order in all contexts.  That is directly under control of
userspace, and a result of the sequence of GL calls that an
application makes.  Which results in the potential for deadlock.  The
problem gets more complex when you consider that the kernel may need
to migrate the buffer(s) into VRAM before the GPU operates on the
buffer(s), which main in turn require evicting some other buffers (and
you don't want to evict other buffers which are already queued up to
the GPU), but for a simplified understanding of the problem you can
ignore this.

The algorithm that TTM came up with for dealing with this problem is
quite simple.  For each group of buffers (execbuf) that need to be
locked, the caller would be assigned a unique reservation_id, from a
global counter.  In case of deadlock in the process of locking all the
buffers associated with a execbuf, the one with the lowest
reservation_id wins, and the one with the higher reservation_id
unlocks all of the buffers that it has already locked, and then tries
again.

Originally TTM implemented this algorithm on top of an event-queue and
atomic-ops, but Maarten Lankhorst realized that by merging this with
the mutex code we could take advantage of the existing mutex fast-path
code and result in a simpler solution, and so ticket_mutex was born.
(Well, there where also some additional complexities with the original
implementation when you start adding in cross-device buffer sharing
for PRIME.. Maarten could probably better explain.)

How it is used:
--- -- -- -

A very simplified version:

  int submit_execbuf(execbuf)
  {
  /* acquiring locks, before queuing up to GPU: */
  seqno = assign_global_seqno();
  retry:
  for (buf in execbuf->buffers) {
  ret = mutex_reserve_lock(>lock, seqno);
  switch (ret) {
  case 0:
  /* we got the lock */
  break;
  case -EAGAIN:
  /* someone with a lower seqno, so unreserve and try again: */
  for (buf2 in reverse order starting before buf in
execbuf->buffers)
  mutex_unreserve_unlock(>lock);
  goto retry;
  default:
  goto err;
  }
  }

  /* now everything is good to go, submit job to GPU: */
  ...
  }

  int finish_execbuf(execbuf)
  {
  /* when GPU is finished: */
  for (buf in execbuf->buffers)
  mutex_unreserve_unlock(>lock);
  }
==

anyways, for the rest of the patch, I'm still going through the
mutex/ticket_mutex code in 

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

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

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

--- Comment #7 from Michael Lange  ---
Created attachment 73865
  --> https://bugs.freedesktop.org/attachment.cgi?id=73865=edit
dmesg_debug_1

-- 
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/20130129/690e90ae/attachment.html>

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

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

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

--- Comment #6 from Michael Lange  ---
* today i recompiled mesa from master git (tree   
d276e9294d1f1218e374d43c1320b376ee265ad4) and linux-3.8.0-rc5
* xbmc is starting and working fine again
* the flip errors still appears in /var/log/Xorg.0.log
* with "echo 2 > /sys/module/drm/parameters/debug" nothing special in dmesg
(watched a 40min-video)
* "echo 1 > /sys/module/drm/parameters/debug" gives a bunch of lines (see
attachment dmesg_debug_1 )

-- 
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/20130129/2788b63e/attachment.html>

[Linaro-mm-sig] CDF discussions at FOSDEM

[Ville Syrjälä]

On Tue, Jan 29, 2013 at 03:19:38PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
>  wrote:
> >> DevRooms are also not supposed to open before 11:00 (which is already a
> >> massive improvement over 2011 and the years before, where i was happy
> >> to be able to put the cabling in at 12:00), and i tend to first get a
> >> nod of approval from the on-site devrooms supervisor before i go in and
> >> set up the room.
> >>
> >> So use the hackingroom this year. Things will hopefully be better next
> >> year.
> >
> > Saturday is pretty much out of question, given that most developers 
> > interested
> > in CDF will want to attend the X.org talks. I'll try to get a room for 
> > Sunday
> > then, but I'm not sure yet what time slots will be available. It would be
> > helpful if people interested in CDF discussions could tell me at what time
> > they plan to leave Brussels on Sunday.
> 
> I'll stay till Monday early morning, so requirements from me. Adding a
> bunch of Intel guys who're interested, too.

My return flight isn't until Monday afternoon.

-- 
Ville Syrj?l?
Intel OTC

[PATCH v3 1/3] drm: add prime helpers

[Maarten Lankhorst]

Op 17-01-13 09:40, Daniel Vetter schreef:
> On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner  
> wrote:
>> Can I consider this a Reviewed-by?
> Essentially it was just a drive-by bikeshed ;-) I think it'd be good
> if Maarten takes a look at this and checks whether it complies with
> his massive prime/dma_buf rework to use fences and ticketing
> reservations ...
> -Daniel
Looks ok to me, I just wish there was a unpin being called on dma-buf release 
or if dma_buf_export fails, instead of only implicitly during destruction.
But that's something you couldn't have known, since it seems darktama still 
didn't accept my patch for that. :(

~Maarten

[PATCH] drm/exynos: consider exception case to fb handle creation

[Inki Dae]

GETFB ioctl request creates a new handle to only one gem object
so it should check if the given fb has one gem object.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 294c051..b751c8a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -99,6 +99,10 @@ static int exynos_drm_fb_create_handle(struct 
drm_framebuffer *fb,

DRM_DEBUG_KMS("%s\n", __FILE__);

+   /* This fb should have only one gem object. */
+   if (WARN_ON(exynos_fb->buf_cnt != 1))
+   return -EINVAL;
+
return drm_gem_handle_create(file_priv,
_fb->exynos_gem_obj[0]->base, handle);
 }
-- 
1.7.4.1

[PATCH] x86, efi: remove attribute check from setup_efi_pci

[Matt Fleming]

On Tue, 2013-01-29 at 17:52 +0100, Maarten Lankhorst wrote:
> It looks like the original commit that copied the rom contents from efi 
> always copied
> the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
> ("x86, efi: correct precedence of operators in setup_efi_pci") broke that.
> 
> This resulted in macbook pro's no longer finding the rom images, and thus not 
> being able to use the radeon card any more.
> 
> The solution is to just remove the check for now, and always copy the rom if 
> available.
> 
> Signed-off-by: Maarten Lankhorst 

Applied, thanks!

[PATCH] x86, efi: remove attribute check from setup_efi_pci

[Maarten Lankhorst]

It looks like the original commit that copied the rom contents from efi always 
copied
the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
("x86, efi: correct precedence of operators in setup_efi_pci") broke that.

This resulted in macbook pro's no longer finding the rom images, and thus not 
being able to use the radeon card any more.

The solution is to just remove the check for now, and always copy the rom if 
available.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 18e329c..ce06324 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -302,9 +302,6 @@ static efi_status_t setup_efi_pci(struct boot_params 
*params)
if (status != EFI_SUCCESS)
continue;

-   if (!(attributes & EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM))
-   continue;
-
if (!pci->romimage || !pci->romsize)
continue;

[PATCH] drm: avoid "mono_time_offset may be used uninitialized"

[Stephen Warren]

From: Stephen Warren 

Silence the following:
drivers/gpu/drm/drm_irq.c: In function 'drm_calc_vbltimestamp_from_scanoutpos':
drivers/gpu/drm/drm_irq.c:583:24: warning: 'mono_time_offset.tv64' may be used 
uninitialized in this function

... by always initializing mono_time_offset to zero. In practice, this
warning is false, since mono_time_offset is both set and used under the
condition if (!drm_timestamp_monotonic). However, at least my compiler
can't be coerced into realizing this; almost any code between the if
blocks that set and use the variable causes this warning.

Signed-off-by: Stephen Warren 
---
I'm not sure what the current thinking is re: silencing warnings like this;
IIRC some people may dislike this kind of change. Perhaps if this change
alone is problematic, one could additionally remove the if condition on the
use of mono_time_offset, thus always using the value?
---
 drivers/gpu/drm/drm_irq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 19c01ca..b199818 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -580,7 +580,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
  unsigned flags,
  struct drm_crtc *refcrtc)
 {
-   ktime_t stime, etime, mono_time_offset;
+   ktime_t stime, etime, mono_time_offset = {0};
struct timeval tv_etime;
struct drm_display_mode *mode;
int vbl_status, vtotal, vdisplay;
-- 
1.7.10.4

[PATCH libdrm] tests/dristat: add -C to pretty-print device capabilities

[Aaron Plattner]

Signed-off-by: Aaron Plattner 
---
Example output of dristat -C:
/dev/dri/card0
  Device capabilities:
Dumb framebuffer: yes
VBlank high crtc: yes
Preferred depth: 24
Prefer shadow: yes
Prime: import export

 tests/dristat.c | 69 -
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/tests/dristat.c b/tests/dristat.c
index 900a3e6..d36c3de 100644
--- a/tests/dristat.c
+++ b/tests/dristat.c
@@ -24,9 +24,11 @@
  * DEALINGS IN THE SOFTWARE.
  * 
  * Authors: Rickard E. (Rik) Faith 
+ * Authors: Aaron Plattner 
  * 
  */

+#include 
 #include 
 #include 
 #include 
@@ -35,11 +37,14 @@
 #include "xf86drmHash.c"
 #include "xf86drm.c"

+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
 #define DRM_VERSION 0x0001
 #define DRM_MEMORY  0x0002
 #define DRM_CLIENTS 0x0004
 #define DRM_STATS   0x0008
 #define DRM_BUSID   0x0010
+#define DRM_CAPS0x0020

 static void getversion(int fd)
 {
@@ -228,6 +233,65 @@ static void getstats(int fd, int i)

 }

+enum cap_type {
+CAP_BOOL,
+CAP_UINT,
+CAP_PRIME
+};
+
+static void printcap(enum cap_type type, uint64_t value)
+{
+switch (type) {
+case CAP_BOOL:
+   if (value) printf("yes");
+   else   printf("no");
+   break;
+case CAP_UINT:
+   printf("%" PRIu64, value);
+   break;
+case CAP_PRIME:
+   if (value == 0) printf("none");
+   else {
+   if (value & DRM_PRIME_CAP_IMPORT) printf("import ");
+   if (value & DRM_PRIME_CAP_EXPORT) printf("export");
+   }
+   break;
+}
+}
+
+static void getcaps(int fd)
+{
+const struct {
+   uint64_t capability;
+   enum cap_type type;
+   const char *name;
+} caps[] = {
+   { DRM_CAP_DUMB_BUFFER,  CAP_BOOL,  "Dumb framebuffer" },
+   { DRM_CAP_VBLANK_HIGH_CRTC, CAP_BOOL,  "VBlank high crtc" },
+   { DRM_CAP_DUMB_PREFERRED_DEPTH, CAP_UINT,  "Preferred depth" },
+   { DRM_CAP_DUMB_PREFER_SHADOW,   CAP_BOOL,  "Prefer shadow" },
+   { DRM_CAP_PRIME,CAP_PRIME, "Prime" },
+};
+int i;
+
+printf("  Device capabilities:\n");
+
+for (i = 0; i < ARRAY_SIZE(caps); i++) {
+   uint64_t value;
+   int ret = drmGetCap(fd, caps[i].capability, );
+
+   printf("%s: ", caps[i].name);
+
+   if (ret) {
+   printf("\n");
+   continue;
+   }
+
+   printcap(caps[i].type, value);
+   printf("\n");
+}
+}
+
 int main(int argc, char **argv)
 {
 int  c;
@@ -238,7 +302,7 @@ int main(int argc, char **argv)
 char buf[64];
 int  i;

-while ((c = getopt(argc, argv, "avmcsbM:i:")) != EOF)
+while ((c = getopt(argc, argv, "avmcCsbM:i:")) != EOF)
switch (c) {
case 'a': mask = ~0;  break;
case 'v': mask |= DRM_VERSION;break;
@@ -246,6 +310,7 @@ int main(int argc, char **argv)
case 'c': mask |= DRM_CLIENTS;break;
case 's': mask |= DRM_STATS;  break;
case 'b': mask |= DRM_BUSID;  break;
+   case 'C': mask |= DRM_CAPS;   break;
case 'i': interval = strtol(optarg, NULL, 0); break;
case 'M': minor = strtol(optarg, NULL, 0);break;
default:
@@ -254,6 +319,7 @@ int main(int argc, char **argv)
fprintf( stderr, "  -aShow all available information\n" 
);
fprintf( stderr, "  -bShow DRM bus ID's\n" );
fprintf( stderr, "  -cDisplay information about DRM 
clients\n" );
+   fprintf( stderr, "  -CDisplay DRM device 
capabilities\n" );
fprintf( stderr, "  -i [interval] Continuously display statistics 
every [interval] seconds\n" );
fprintf( stderr, "  -vDisplay DRM module and card 
version information\n" );
fprintf( stderr, "  -mDisplay memory use information\n" 
);
@@ -272,6 +338,7 @@ int main(int argc, char **argv)
if (mask & DRM_MEMORY)  getvm(fd);
if (mask & DRM_CLIENTS) getclients(fd);
if (mask & DRM_STATS)   getstats(fd, interval);
+   if (mask & DRM_CAPS)getcaps(fd);
close(fd);
}
 }
-- 
1.8.1.2

[Linaro-mm-sig] CDF discussions at FOSDEM

[Daniel Vetter]

On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter  
wrote:
> On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
>  wrote:
>>> DevRooms are also not supposed to open before 11:00 (which is already a
>>> massive improvement over 2011 and the years before, where i was happy
>>> to be able to put the cabling in at 12:00), and i tend to first get a
>>> nod of approval from the on-site devrooms supervisor before i go in and
>>> set up the room.
>>>
>>> So use the hackingroom this year. Things will hopefully be better next
>>> year.
>>
>> Saturday is pretty much out of question, given that most developers 
>> interested
>> in CDF will want to attend the X.org talks. I'll try to get a room for Sunday
>> then, but I'm not sure yet what time slots will be available. It would be
>> helpful if people interested in CDF discussions could tell me at what time
>> they plan to leave Brussels on Sunday.
>
> I'll stay till Monday early morning, so requirements from me. Adding a
> bunch of Intel guys who're interested, too.

Ok, in the interest of pre-heating the discussion a bit I've written down
my thoughts about display slave drivers. Adding a few more people and
lists to make sure I haven't missed anyone ...

Cheers, Daniel
--
Display Slaves
==

A highly biased quick analysis from Daniel Vetter.

A quick discussion about the issues surrounding some common framework for
display slaves like panels, hdmi/DP/whatever encoders, ... Since these external
chips are very often reused accross different SoCs, it would be beneficial to
share slave driver code between different chipset drivers.

Caveat Emperor!
---

Current output types and slave encoders already have to deal with a pletoria of
special cases and strange features. To avoid ending up with something not
suitable for everyone, we should look at what's all supported already and how we
could possibly deal with those things:

- audio embedded into the display stream (hdmi/dp). x86 platforms with the HD
  Audio framework rely on ELD and forwarding certain events as interrupts
  through the hw between the display and audio side ...

- hdmi/dp helpers: HDMI/DP are both standardized output connectors with nice
  complexity. DP is mostly about handling dp aux transactions and DPCD
  registers, hdmi mostly about infoframes and how to correctly set them up from
  the mode + edid.

- dpms is 4 states in drm, even more in fbdev afaict, but real hw only supports
  on/off nowadays ... how should/do we care?

- Fancy modes and how to represent them. Random list of things we need to
  represent somehow: broadcast/reduced rbg range for hdmi, yuv modes, different
  bpc modes (and handling how this affects bandwidth/clocks, e.g. i915
  auto-dithers to 6bpc on DP if there's not enough), 3D hdmi modes (patches have
  floated on dri-devel for this), overscan compensation. Many of these things
  link in with e.g. the helper libraries for certain outputs, e.g. discovering
  DP sink capabilities or setting up the correct hdmi infoframe.

- How to expose random madness as properties, e.g. backlight controllers,
  broadcast mode, enable/disable embedded audio (some screens advertise it, but
  don't like it). For additional fun I expect different users of a display slave
  driver to expect different set of "standardized" properties.

- Debug support: Register dumping, exposing random debugfs files, tracing.
  Preferably somewhat unified to keep things sane, since most often slave
  drivers are rather simple, but we expect quite a few different ones.

- Random metadata surrounding a display sink, like output type. Or flags for
  support special modes (h/vsync polarity, interlaced/doublescan, pixel
  doubling, ...).

- mode_fixup: Used a lot in drm-land to allow encoders to change the input mode,
  e.g. for lvds encoders which can do upscaling, or if the encoder supports
  progressive input with interlaced output and similar fancy stuff. See e.g. the
  intel sdvo encoder chip support.

- Handling different control buses like i2c, direct access (not seen that yet),
  DSI, DP aux, some other protocols.

- Handling of different display data standards like dsi (intel invented a few of
  its own, I'm sure we're not the only ones).

- hpd support/polling. Depending upon desing hpd handling needs to be
  cooperative between slave and master, or is a slave only thing (which means
  the slave needs to be able to poke the master when something changes).
  Similarly, masters need to know which slaves require output polling.

- Initializing of slave drivers: of/devicetree based, compiled-in static tables
  in the driver, dynamic discovery by i2c probing, lookup through some
  platform-specific firmware table (ACPI). Related is how to forward random
  platform init values to the drivers from these sources (e.g. the panel fixed
  modes) to the slave driver.

- get_hw_state support. One of the major point in the i915 modeset rewrite which
  landed in 3.7 is that a lot of the hw state can be 

[PATCH] drm/exynos: fix iommu address allocation order

[Inki Dae]

This patch modifies iommu address allocation order from 64k
to 4k. 64k order causes waste of the io space and this was
our mistakes.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_iommu.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.h 
b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
index 53b7dee..598e60f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
@@ -14,7 +14,7 @@

 #define EXYNOS_DEV_ADDR_START  0x2000
 #define EXYNOS_DEV_ADDR_SIZE   0x4000
-#define EXYNOS_DEV_ADDR_ORDER  0x4
+#define EXYNOS_DEV_ADDR_ORDER  0x0

 #ifdef CONFIG_DRM_EXYNOS_IOMMU

-- 
1.7.4.1

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #7 from Michel D?nzer  ---
This is indeed more likely an issue in Mesa than in the kernel. The commit you
bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause the Mesa
code to use different code paths.

Does current Mesa Git still leak?

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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #6 from Dave Witbrodt  ---
I do not know how to interpret these findings.  I am not a developer, and work
with the few tools that I (sort of) know how to use much more slowly than
experienced developers would.  I ran out of time over the weekend, and will
have
to investigate further this coming weekend.

I have been trying to think of possible explanations:

- could a later commit causes a similar (or identical)
  memory leak to the one caused by 4ac0533a?

- is the problem really located somewhere else
  besides in the kernel DRM, such as in Mesa, with
  it being triggered by more than one kind of
  code change in the DRM?

I thought that the bisection would be conclusive, but the failure of the revert
attempts undermined my goal.  If no one demands that I bisect using one of the
drm-airlied branches, then I will try another custom branch which drops the
commit first causing the leak, and see if any later commits also cause a leak. 
(If a developer demands that I bisect an upstream branch, I'll do that
instead.)

Is there anything else I can do to be helpful at this point?

Can any of you confirm/reproduce this memory leak on your own systems?

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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #5 from Dave Witbrodt  ---
Created attachment 73844
  --> https://bugs.freedesktop.org/attachment.cgi?id=73844=edit
diff of attempt to manually revert entire problem commit

Attempt to revert the entire commit

I then decided to manually revert all of the changes in the *.c
files touched by that commit.  (A diff of these changes is
attached.)  The kernel still leaked memory.

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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #4 from Dave Witbrodt  ---
Created attachment 73843
  --> https://bugs.freedesktop.org/attachment.cgi?id=73843=edit
diff of attempt to partially revert problem commit

Naive attempt to revert

My first attempt to revert the patch revealed to be the problem
above did not work.  (A diff of the changes is attached.)  The 
problem commit touched evergreen_cs.c and r600_cs.c, and since I
have Evergreen Juniper hardware I only reverted the code in
evergreen_cs.c.  The kernel built using this approach still
leaked memory.

-- 
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/20130129/9a4d8d9f/attachment.html>

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #3 from Dave Witbrodt  ---
Bisecting

So far, I have only bisected using my local custom kernel branch.  As described
above, I use stable kernel releases to avoid the massive breakage that
frequently occurs in -rc kernels, and I cherry pick commits from drm-fixes and
drm-next.  This is a potential source of error (on my part), so I will not be
offended if anyone objects to me reporting bugs against such kernels.  My
justification is that the HEAD of drm-fixes, which is

3.8.0~rc3 at commit 48367432 of Jan. 26

also leaks memory if I build it and use it on my system.  I bisected using my
custom branch first only to save time:  I add cherry picks in bunches, and keep
separate list files of which commits I have used, so manually bisecting using
those files rapidly led me to the first commit which caused the kernel to leak
memory.

[I will bisect using drm-fixes (or drm-next) if asked, but there are issues
with Mesa not being compatible before a certain point in mid-December, so that
I would have to use an older version of Mesa or patch some of the older
bisection points with later commits in order to use the version of Mesa
I currently have installed.]

For this testing, I started with stable kernel 3.7.4 and applied my lists of
cherry picks that had built up since 3.7-rc7 or so.  I had built up 11 lists of
commits as I added new upstream code to my local branch, so I could perform a
manual bisection by applying an entire list at a time until I found a kernel
which leaked memory.  From that, I would know which list introduce the problem,
and I could build kernels at each commit in that list until I found the first
one that resulted in leaks.  (If anyone is interested in those lists I will be
glad to post them; I have only withheld them for the sake of brevity.)

The manual bisection led me to a last good commit and a first bad commit.  The
cherry picking process causes my branch to have new SHA1 ID numbers, so I
instead of using the 'git log' info from my branch am will use the info
from the drm-airlied/drm-fixes branch.  The first bad commit was:

commit 4ac0533abaec2b83a7f2c675010eedd55664bc26
Author: Jerome Glisse 
Date:   Thu Dec 13 12:08:11 2012 -0500

drm/radeon: fix htile buffer size computation for command stream
checker

Fix the size computation of the htile buffer.

Signed-off-by: Jerome Glisse 
Signed-off-by: Alex Deucher 


The previous commit, which worked fine, was:

commit 9af20792124850369e764965690b99b20623dfc4
Author: Daniel Vetter 
Date:   Tue Dec 11 23:42:24 2012 +0100

drm/radeon: fix fence locking in the pageflip callback

We need to hold bdev->fence_lock while grabbing a reference to
the fence, to prevent concurrent clearing/changing of the
ttm_bo->sync_obj field.

Signed-off-by: Daniel Vetter 
Signed-off-by: Alex Deucher 


This was a time-consuming process, but much shorter than it would have been
using 'git bisect' in drm-fixes.  Later, I made two attempts to revert the
"bad" code on top of the HEAD of my local branch.

-- 
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/20130129/5145f1b3/attachment-0001.html>

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #2 from Dave Witbrodt  ---
Created attachment 73842
  --> https://bugs.freedesktop.org/attachment.cgi?id=73842=edit
Output from successive runs of 'top'

Running 'top' revealed the memory leak.

This attachment is (clipped) output from top.  Running the 'prboom-plus' game
on a kernel that was not leaking, then several snapshots on a kernel that was
leaking.

Eventually the game was taken out by the OOM killer, and system memory usage
was restored to normal.

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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #1 from Dave Witbrodt  ---
Created attachment 73840
  --> https://bugs.freedesktop.org/attachment.cgi?id=73840=edit
Xorg.0.log

-- 
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/20130129/14e5ff70/attachment.html>

[Bug 60028] New: Post-3.7.x memory leak, Radeon Evergreen, bisected

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

here were corruption
problems with 'torcs', but there were also instances of my desktop becoming
unresponsive and programs freezing or suddenly closing without leaving any
errors in logs.

The 'torcs' corruption was solved recently in drm-fixes:

commit 20707874
Revert "drm/radeon: do not move bo to different placement at each cs"

I had assumed that the other issues were related, but when they continued to
occur I started to investigate more seriously, and discovered the memory leak
using 'top'.


[Can a developer rename this bug report for me, using your preferred naming
conventions?]

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

[Linaro-mm-sig] CDF discussions at FOSDEM

[Daniel Vetter]

On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
 wrote:
>> DevRooms are also not supposed to open before 11:00 (which is already a
>> massive improvement over 2011 and the years before, where i was happy
>> to be able to put the cabling in at 12:00), and i tend to first get a
>> nod of approval from the on-site devrooms supervisor before i go in and
>> set up the room.
>>
>> So use the hackingroom this year. Things will hopefully be better next
>> year.
>
> Saturday is pretty much out of question, given that most developers interested
> in CDF will want to attend the X.org talks. I'll try to get a room for Sunday
> then, but I'm not sure yet what time slots will be available. It would be
> helpful if people interested in CDF discussions could tell me at what time
> they plan to leave Brussels on Sunday.

I'll stay till Monday early morning, so requirements from me. Adding a
bunch of Intel guys who're interested, too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

The holiday pull fresh from QA. Not much in in, everyone was on vacation.
Highlights:
- Broadcast RBG improvements and reduced color range fixes from Ville
- Ben is on a "kill legacy gtt code for good" spree, first pile of patches
  included.
- no relocs and lut improvements for faster execbuf from Chris.
- some refactorings from Imre

Big regression caugh by QA was the inbalanced unlock in one of the
load-detect paths - you've merged that one already. Otherwise nothing to
report about.

Cheers, Daniel


The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:

  Merge tag 'drm-intel-next-2012-12-21' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-01-17 
20:34:08 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-01-20

for you to fetch changes up to e5c653777986b40e2986d2c918847fddbcba3a34:

  agp/intel: Add gma_bus_addr (2013-01-20 13:11:12 +0100)


Ben Widawsky (10):
  drm/i915: Kill gtt_end
  drm/i915: Mappable_end can't ever be > end
  drm/i915: Remove gtt_mappable_total
  drm/i915: Create a gtt structure
  drm/i915: Remove use on gma_bus_addr on gen6+
  drm/i915: Remove use of gtt_mappable_entries
  drm/i915: Cut out the infamous ILK w/a from AGP layer
  drm/i915: Remove scratch page from shared
  drm/i915: Needs_dmar, not
  agp/intel: Add gma_bus_addr

Chris Wilson (6):
  drm/i915: Add a debug interface to forcibly evict and shrink our object 
caches
  drm/i915: Bail if we attempt to allocate pages for a purged object
  drm/i915: Mark a temporary allocation for copy-from-user as such
  drm/i915: Take the handle idr spinlock once for looking up the exec 
objects
  drm/i915: Move the execbuffer objects list from the stack into the tracker
  drm/i915: Use the reloc.handle as an index into the execbuffer array

Daniel Vetter (2):
  drm/i915: wake up all pageflip waiters
  drm/i915: Allow userspace to hint that the relocations were known

Egbert Eich (1):
  drm/i915: Remove pch_rq_mask from struct drm_i915_private.

Imre Deak (3):
  drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
  drm/i915: merge {i965, sandybridge}_write_fence_reg()
  drm/i915: use gtt_get_size() instead of open coding it

Ville Syrj?l? (5):
  drm/i915: Fix SPRITE0_FLIP_DONE_INT_EN_VLV and 
SPRITE0_FLIPDONE_INT_STATUS_VLV
  drm/i915: Fix RGB color range property for PCH platforms
  drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
  drm/edid: Add drm_rgb_quant_range_selectable()
  drm/i915: Provide the quantization range in the AVI infoframe

 drivers/char/agp/intel-gtt.c   |   51 ++---
 drivers/gpu/drm/drm_edid.c |   33 
 drivers/gpu/drm/i915/i915_debugfs.c|  109 ++-
 drivers/gpu/drm/i915/i915_dma.c|   35 ++--
 drivers/gpu/drm/i915/i915_drv.h|   48 +++--
 drivers/gpu/drm/i915/i915_gem.c|  120 
 drivers/gpu/drm/i915/i915_gem_evict.c  |2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  280 
 drivers/gpu/drm/i915/i915_gem_gtt.c|  129 +++--
 drivers/gpu/drm/i915/i915_gem_tiling.c |   21 +--
 drivers/gpu/drm/i915/i915_irq.c|   14 +-
 drivers/gpu/drm/i915/i915_reg.h|5 +-
 drivers/gpu/drm/i915/intel_display.c   |   13 +-
 drivers/gpu/drm/i915/intel_dp.c|   39 +++-
 drivers/gpu/drm/i915/intel_drv.h   |   11 ++
 drivers/gpu/drm/i915/intel_fb.c|5 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |   45 -
 drivers/gpu/drm/i915/intel_modes.c |5 +-
 drivers/gpu/drm/i915/intel_overlay.c   |4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   59 +-
 include/drm/drm_crtc.h |1 +
 include/drm/intel-gtt.h|9 -
 include/uapi/drm/i915_drm.h|   20 ++
 24 files changed, 669 insertions(+), 391 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"

[Daniel Vetter]

On Mon, Jan 14, 2013 at 3:37 PM, Paul Menzel
 wrote:
> Am Montag, den 14.01.2013, 11:06 +0100 schrieb Daniel Vetter:
>> This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.
>>
>> The quirk cause a regression, and it looks like the original bug was
>> simply a lack of FIFO bandwidth on the i915G of the reporter. Which
>> should eventually be fixed as soon as we get around to implemented
>> DSPARB FIFO reassignment on gen 3.
>
> Reported-by: Florian Mickler 
>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Daniel Vetter 
>
> Acked-by: Paul Menzel 

Hm, revert hasn't landed anywhere yet :( Dave, Ajax: ping?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: shut up invalid edid messages

[Maarten Lankhorst]

My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam 
every few seconds.

I get it the first time that the entire block is all 0xff..

Signed-off-by: Maarten Lankhorst 
Cc: stable at vger.kernel.org [v3.7]

---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a3770f..4490080 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -357,10 +357,14 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
break;
}
}
-   if (i == 4)
+
+   if (i == 4 && print_bad_edid) {
dev_warn(connector->dev->dev,
 "%s: Ignoring invalid EDID block %d.\n",
 drm_get_connector_name(connector), j);
+
+   connector->bad_edid_counter++;
+   }
}

if (valid_extensions != block[0x7e]) {

[Bug 53111] vgaswitcheroo not working anymore

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

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


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #1 from Alex Deucher   2013-01-29 
13:58:59 ---
Can you bisect?

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

[Linaro-mm-sig] CDF discussions at FOSDEM

[Laurent Pinchart]

Hi Luc,

On Tuesday 29 January 2013 12:47:16 Luc Verhaegen wrote:
> On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote:
> > On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
> > > I've sent a mail to the FOSDEM organizers to request a hacking room for
> > > a couple of hours Sunday. I'll let you know as soon as I get a reply.
> > 
> > Just a quick follow-up. I've received information from the FOSDEM staff,
> > there will be hacking rooms that can be reserved (on-site only) for 1h
> > slots. They unfortunately won't have projectors, as they're not meant for
> > talks.
> > 
> > Another option would be to start early on Saturday, the X.org room is
> > reported as beeing free from 9am to 11am.
> 
> As the organizer of the X.org devroom, i would have to state that the
> latter is impossible. I tend to do a bit of room set-up, like put in
> some power bars (a limited amount this year, as i only have been given
> one day and it simply is not worth putting in the cabling for 100
> sockets, and dragging all that kit over from Nuremberg, for just a
> single day) and some other things. I need one hour at least for that on
> saturday morning.

No worries. It was just an idea.

> DevRooms are also not supposed to open before 11:00 (which is already a
> massive improvement over 2011 and the years before, where i was happy
> to be able to put the cabling in at 12:00), and i tend to first get a
> nod of approval from the on-site devrooms supervisor before i go in and
> set up the room.
> 
> So use the hackingroom this year. Things will hopefully be better next
> year.

Saturday is pretty much out of question, given that most developers interested 
in CDF will want to attend the X.org talks. I'll try to get a room for Sunday 
then, but I'm not sure yet what time slots will be available. It would be 
helpful if people interested in CDF discussions could tell me at what time 
they plan to leave Brussels on Sunday.

-- 
Regards,

Laurent Pinchart

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #4 from Lucas Kannebley Tavares  ---
As a side note, the kernel panic is actually induced by me. It actually means
there was an access to an invalid address.

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

[Linaro-mm-sig] CDF discussions at FOSDEM

[Luc Verhaegen]

On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote:
> Hello,
> 
> On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
> > 
> > I've sent a mail to the FOSDEM organizers to request a hacking room for a
> > couple of hours Sunday. I'll let you know as soon as I get a reply.
> 
> Just a quick follow-up. I've received information from the FOSDEM staff, 
> there 
> will be hacking rooms that can be reserved (on-site only) for 1h slots. They 
> unfortunately won't have projectors, as they're not meant for talks.
> 
> Another option would be to start early on Saturday, the X.org room is 
> reported 
> as beeing free from 9am to 11am.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

As the organizer of the X.org devroom, i would have to state that the 
latter is impossible. I tend to do a bit of room set-up, like put in 
some power bars (a limited amount this year, as i only have been given 
one day and it simply is not worth putting in the cabling for 100 
sockets, and dragging all that kit over from Nuremberg, for just a 
single day) and some other things. I need one hour at least for that on 
saturday morning.

DevRooms are also not supposed to open before 11:00 (which is already a 
massive improvement over 2011 and the years before, where i was happy 
to be able to put the cabling in at 12:00), and i tend to first get a 
nod of approval from the on-site devrooms supervisor before i go in and 
set up the room.

So use the hackingroom this year. Things will hopefully be better next 
year.

Luc Verhaegen.

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #3 from Lucas Kannebley Tavares  ---
Hi Jerome, I attempted the dump without success

[root at localhost ~]# lspci
...
0001:01:00.0 VGA compatible controller: ATI Technologies Inc ...
0001:01:00.1 Audio device: ATI Technologies Inc ...
[root at localhost ~]# cd /sys/bus/pci/devices/0001:01:00.0
[root at localhost 0001:01:00.0]# echo 1 > rom
[root at localhost 0001:01:00.0]# cat rom > ~/bios.rom
[  588.381813] pci 0001:01:00.0: Invalid ROM contents
cat: rom: Input/output error
[root at localhost 0001:01:00.0]# lspci
[  637.187942] Kernel panic - not syncing: FAIL
...
[  637.190672] ===
[  637.190677] [ INFO: suspicious RCU usage. ]
[  637.190683] 3.8.0-rc5-kotd+ #6 Not tainted
[  637.190687] ---
[  637.190692] include/linux/rcupdate.h:468 Illegal context switch in RCU
read-side critical section!
...

I'm investigating what was wrong with the rom dump, but if you have any ideas
what it could be, any help would be appreciated :)

-- 
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/20130129/66b96fa8/attachment-0001.html>

CDF discussions at FOSDEM

[Laurent Pinchart]

Hello,

On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
> On Thursday 17 January 2013 13:29:27 Daniel Vetter wrote:
> > On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote:
> > > On Fri, 11 Jan 2013, Laurent Pinchart wrote:
> > >> Would anyone be interested in meeting at the FOSDEM to discuss the
> > >> Common Display Framework ? There will be a CDF meeting at the ELC at
> > >> the end of February, the FOSDEM would be a good venue for European
> > >> developers.
> > > 
> > > Yes, count me in,
> > 
> > Jesse, Ville and me should also be around. Do we have a slot fixed
> > already?
> 
> I've sent a mail to the FOSDEM organizers to request a hacking room for a
> couple of hours Sunday. I'll let you know as soon as I get a reply.

Just a quick follow-up. I've received information from the FOSDEM staff, there 
will be hacking rooms that can be reserved (on-site only) for 1h slots. They 
unfortunately won't have projectors, as they're not meant for talks.

Another option would be to start early on Saturday, the X.org room is reported 
as beeing free from 9am to 11am.

-- 
Regards,

Laurent Pinchart

[Bug 59899] Diagonal rendering artifacts on xbmc

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

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

--- Comment #1 from Michel D?nzer  ---
This is more likely an issue in Mesa than in the kernel.

Please attach Xorg.0.log and the output of glxinfo and dmesg.

-- 
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/20130129/6e7cf06a/attachment.html>

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

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

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

--- Comment #5 from Michel D?nzer  ---
(In reply to comment #5)
> if i switch with my remote through the xbmc-menu or watch a video the
> xorg-log is spam the whole time with page filp errors

While that is happening, can you write 2 to /sys/module/drm/parameters/debug
and capture some debugging output from dmesg?

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

[PATCH 4/4] drm/tilcdc: add support for LCD panels (v5)

[Rob Clark]

Add an output panel driver for LCD panels.  Tested with LCD3 cape on
beaglebone.

v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Antoniou
v3: add backlight support
v4: rebase to latest of video timing helpers
v5: remove some unneeded fields from panel-info struct, add DT bindings
docs

Signed-off-by: Rob Clark 
Tested-by: Koen Kooi 
---
 .../devicetree/bindings/drm/tilcdc/panel.txt   |  59 +++
 drivers/gpu/drm/tilcdc/Kconfig |   3 +
 drivers/gpu/drm/tilcdc/Makefile|   1 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   3 +
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 436 +
 drivers/gpu/drm/tilcdc/tilcdc_panel.h  |  26 ++
 6 files changed, 528 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
new file mode 100644
index 000..5ff1e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
@@ -0,0 +1,59 @@
+Device-Tree bindings for tilcdc DRM generic panel output driver
+
+Required properties:
+ - compatible: value should be "tilcdc,panel".
+ - panel-info: configuration info to configure LCDC correctly for the panel
+   - ac-bias: AC Bias Pin Frequency
+   - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
+   - dma-burst-sz: DMA burst size
+   - bpp: Bits per pixel
+   - fdd: FIFO DMA Request Delay
+   - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
+   - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
+   - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
+   - fifo-th: DMA FIFO threshold
+ - display-timings: typical videomode of lcd panel.  Multiple video modes
+   can be listed if the panel supports multiple timings, but the 'native-mode'
+   should be the preferred/default resolution.  Refer to
+   Documentation/devicetree/bindings/video/display-timing.txt for display
+   timing binding details.
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+   muxing properly for pins that connect to TFP410 device
+
+Example:
+
+   /* Settings for CDTech_S035Q01 / LCD3 cape: */
+   lcd3 {
+   compatible = "tilcdc,panel";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd3_cape_lcd_pins>;
+   panel-info {
+   ac-bias   = <255>;
+   ac-bias-intrpt= <0>;
+   dma-burst-sz  = <16>;
+   bpp   = <16>;
+   fdd   = <0x80>;
+   sync-edge = <0>;
+   sync-ctrl = <1>;
+   raster-order  = <0>;
+   fifo-th   = <0>;
+   };
+   display-timings {
+   native-mode = <>;
+   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>;
+   hsync-active= <0>;
+   vsync-active= <0>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index ee9b592..ae14fd6 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -4,6 +4,9 @@ config DRM_TILCDC
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+   select OF_VIDEOMODE
+   select OF_DISPLAY_TIMING
+   select BACKLIGHT_CLASS_DEVICE
help
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index aa9097e..deda656 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -4,6 +4,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_slave.o \
+   tilcdc_panel.o \
tilcdc_drv.o

 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 25f3add..c5b592d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ 

[PATCH 3/4] drm/tilcdc: add encoder slave (v2)

[Rob Clark]

Add output panel driver for i2c encoder slaves.

v1: original
v2: add DT bindings docs, and minor updates for review comments

Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Tested-by: Koen Kooi 
---
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  19 ++
 drivers/gpu/drm/tilcdc/Makefile|   1 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 376 +
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 ++
 5 files changed, 426 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
new file mode 100644
index 000..ba51337
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
@@ -0,0 +1,19 @@
+Device-Tree bindings for tilcdc DRM encoder slave output driver
+
+Required properties:
+ - compatible: value should be "tilcdc,slave".
+ - i2c: the phandle for the i2c device the encoder slave is connected to
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+   muxing properly for pins that connect to TFP410 device
+
+Example:
+
+   hdmi {
+   compatible = "tilcdc,slave";
+   i2c = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hdmi_bonelt_pins>;
+   };
+   
\ No newline at end of file
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 1359cc2..aa9097e 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm -Werror
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
+   tilcdc_slave.o \
tilcdc_drv.o

 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index f6defbf..25f3add 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,6 +20,7 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
+#include "tilcdc_slave.h"

 #include "drm_fb_helper.h"

@@ -587,6 +588,7 @@ static int __init tilcdc_drm_init(void)
 {
DBG("init");
tilcdc_tfp410_init();
+   tilcdc_slave_init();
return platform_driver_register(_platform_driver);
 }

@@ -594,10 +596,11 @@ static void __exit tilcdc_drm_fini(void)
 {
DBG("fini");
tilcdc_tfp410_fini();
+   tilcdc_slave_fini();
platform_driver_unregister(_platform_driver);
 }

-module_init(tilcdc_drm_init);
+late_initcall(tilcdc_drm_init);
 module_exit(tilcdc_drm_fini);

 MODULE_AUTHOR("Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tilcdc_drv.h"
+
+struct slave_module {
+   struct tilcdc_module base;
+   struct i2c_adapter *i2c;
+};
+#define to_slave_module(x) container_of(x, struct slave_module, base)
+
+static const struct tilcdc_panel_info slave_info = {
+   .bpp= 16,
+   .ac_bias= 255,
+   .ac_bias_intrpt = 0,
+   .dma_burst_sz   = 16,
+   .fdd= 0x80,
+   .tft_alt_mode   = 0,
+   .sync_edge  = 0,
+   .sync_ctrl  = 1,
+   .raster_order   = 0,
+};
+
+
+/*
+ * Encoder:
+ */
+
+struct slave_encoder {
+   struct drm_encoder_slave base;
+   struct slave_module *mod;
+};
+#define to_slave_encoder(x) container_of(to_encoder_slave(x), struct 
slave_encoder, base)
+
+static inline struct drm_encoder_slave_funcs *
+get_slave_funcs(struct drm_encoder *enc)
+{
+   return to_encoder_slave(enc)->slave_funcs;
+}
+
+static void slave_encoder_destroy(struct drm_encoder *encoder)
+{
+   struct slave_encoder *slave_encoder = to_slave_encoder(encoder);
+   if (get_slave_funcs(encoder))
+   get_slave_funcs(encoder)->destroy(encoder);
+   drm_encoder_cleanup(encoder);
+   kfree(slave_encoder);
+}
+
+static void slave_encoder_prepare(struct drm_encoder *encoder)
+{
+   

[PATCH 2/4] drm/i2c: nxp-tda998x (v3)

[Rob Clark]

Driver for the NXP TDA998X i2c hdmi encoder slave.

v1: original
v2: fix npix/nline programming
v3: add Kconfig, fix dup'd MODULE_DESCRIPTION

Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Tested-by: Koen Kooi 
---
 drivers/gpu/drm/i2c/Kconfig   |   6 +
 drivers/gpu/drm/i2c/Makefile  |   3 +
 drivers/gpu/drm/i2c/tda998x_drv.c | 906 ++
 3 files changed, 915 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 1611836..4d341db 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -19,4 +19,10 @@ config DRM_I2C_SIL164
  when used in pairs) TMDS transmitters, used in some nVidia
  video cards.

+config DRM_I2C_NXP_TDA998X
+   tristate "NXP Semiconductors TDA998X HDMI encoder"
+   default m if DRM_TILCDC
+   help
+ Support for NXP Semiconductors TDA998X HDMI encoders.
+
 endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 9286256..43aa33b 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -5,3 +5,6 @@ obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o

 sil164-y := sil164_drv.o
 obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
+
+tda998x-y := tda998x_drv.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
new file mode 100644
index 000..e68b58a
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -0,0 +1,906 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+
+#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
+
+struct tda998x_priv {
+   struct i2c_client *cec;
+   uint16_t rev;
+   uint8_t current_page;
+   int dpms;
+};
+
+#define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
+
+/* The TDA9988 series of devices use a paged register scheme.. to simplify
+ * things we encode the page # in upper bits of the register #.  To read/
+ * write a given register, we need to make sure CURPAGE register is set
+ * appropriately.  Which implies reads/writes are not atomic.  Fun!
+ */
+
+#define REG(page, addr) (((page) << 8) | (addr))
+#define REG2ADDR(reg)   ((reg) & 0xff)
+#define REG2PAGE(reg)   (((reg) >> 8) & 0xff)
+
+#define REG_CURPAGE   0xff/* write */
+
+
+/* Page 00h: General Control */
+#define REG_VERSION_LSB   REG(0x00, 0x00) /* read */
+#define REG_MAIN_CNTRL0   REG(0x00, 0x01) /* read/write */
+# define MAIN_CNTRL0_SR   (1 << 0)
+# define MAIN_CNTRL0_DECS (1 << 1)
+# define MAIN_CNTRL0_DEHS (1 << 2)
+# define MAIN_CNTRL0_CECS (1 << 3)
+# define MAIN_CNTRL0_CEHS (1 << 4)
+# define MAIN_CNTRL0_SCALER   (1 << 7)
+#define REG_VERSION_MSB   REG(0x00, 0x02) /* read */
+#define REG_SOFTRESET REG(0x00, 0x0a) /* write */
+# define SOFTRESET_AUDIO  (1 << 0)
+# define SOFTRESET_I2C_MASTER (1 << 1)
+#define REG_DDC_DISABLE   REG(0x00, 0x0b) /* read/write */
+#define REG_CCLK_ON   REG(0x00, 0x0c) /* read/write */
+#define REG_I2C_MASTERREG(0x00, 0x0d) /* read/write */
+# define I2C_MASTER_DIS_MM(1 << 0)
+# define I2C_MASTER_DIS_FILT  (1 << 1)
+# define I2C_MASTER_APP_STRT_LAT  (1 << 2)
+#define REG_INT_FLAGS_0   REG(0x00, 0x0f) /* read/write */
+#define REG_INT_FLAGS_1   REG(0x00, 0x10) /* read/write */
+#define REG_INT_FLAGS_2   REG(0x00, 0x11) /* read/write */
+# define INT_FLAGS_2_EDID_BLK_RD  (1 << 1)
+#define REG_ENA_VP_0  REG(0x00, 0x18) /* read/write */
+#define REG_ENA_VP_1  REG(0x00, 0x19) /* read/write */
+#define REG_ENA_VP_2  REG(0x00, 0x1a) /* read/write */
+#define REG_ENA_APREG(0x00, 0x1e) /* read/write */
+#define REG_VIP_CNTRL_0   REG(0x00, 0x20) /* write */
+# define VIP_CNTRL_0_MIRR_A   (1 << 7)
+# define VIP_CNTRL_0_SWAP_A(x)(((x) & 7) << 4)
+# define VIP_CNTRL_0_MIRR_B   (1 << 3)
+# define VIP_CNTRL_0_SWAP_B(x)(((x) & 7) << 0)
+#define REG_VIP_CNTRL_1   REG(0x00, 0x21) /* write */
+# define VIP_CNTRL_1_MIRR_C 

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v4)

[Rob Clark]

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.

v1: original
v2: fix fb refcnting and few other cleanups
v3: get +/- vsync/hsync from timings rather than panel-info, add
option DT max-bandwidth field so driver doesn't attempt to
pick a display mode with too high memory bandwidth, and other
small cleanups
v4: remove some unneeded stuff from panel-info struct, properly
set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs

Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Tested-by: Koen Kooi 
---
 .../devicetree/bindings/drm/tilcdc/tfp410.txt  |  21 +
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  21 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tilcdc/Kconfig |  10 +
 drivers/gpu/drm/tilcdc/Makefile|   8 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 602 
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.h| 150 +
 drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 ++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 ++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 +
 12 files changed, 2019 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
 create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
 create mode 100644 drivers/gpu/drm/tilcdc/Makefile
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
new file mode 100644
index 000..5a79d02
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
@@ -0,0 +1,21 @@
+Device-Tree bindings for tilcdc DRM TFP410 output driver
+
+Required properties:
+ - compatible: value should be "tilcdc,tfp410".
+ - i2c: the phandle for the i2c device to use for DDC
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+   muxing properly for pins that connect to TFP410 device
+ - powerdn-gpio: the powerdown GPIO, pulled low to power down the
+   TFP410 device (for DPMS_OFF)
+
+Example:
+
+   dvicape {
+   compatible = "tilcdc,tfp410";
+   i2c = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_dvi_cape_dvi_00A1_pins>;
+   powerdn-gpio = < 31 0>;
+   };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
new file mode 100644
index 000..e5f1301
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -0,0 +1,21 @@
+Device-Tree bindings for tilcdc DRM driver
+
+Required properties:
+ - compatible: value should be "ti,am33xx-tilcdc".
+ - interrupts: the interrupt number
+ - reg: base address and size of the LCDC device
+
+Recommended properties:
+ - interrupt-parent: the phandle for the interrupt controller that
+   services interrupts for this device.
+ - ti,hwmods: Name of the hwmod associated to the LCDC
+
+Example:
+
+   fb: fb at 4830e000 {
+   compatible = "ti,am33xx-tilcdc";
+   reg = <0x4830e000 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <36>;
+   ti,hwmods = "lcdc";
+   };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 99b09e1..6c322d6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -214,3 +214,5 @@ source "drivers/gpu/drm/cirrus/Kconfig"
 source "drivers/gpu/drm/shmobile/Kconfig"

 source "drivers/gpu/drm/tegra/Kconfig"
+
+source "drivers/gpu/drm/tilcdc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6f58c81..3af934d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -50,4 +50,5 @@ obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/

[PATCH 0/4] TI LCDC DRM driver

[Rob Clark]

One more iteration.. now with more cowbell!

The first patch adds the basic driver and TFP410 DVI output.

The second patch adds support for NXP TDA998x family of i2c connected
HDMI encoders.  It is split out into an i2c encoder-slave in case someone
else has hw with the same HDMI encoder.

The final patch adds support for LCD panels, with timings and panel info
coming from device-tree.

The patch set has dependencies on the following patches that I have sent
earlier (which have not changed since then so I am not resending):

 * drm/cma: add debugfs helpers -
 https://patchwork.kernel.org/patch/1876721/
 * drm: i2c encoder helper wrappers -
 https://patchwork.kernel.org/patch/1950971/
 * drm/i2c: give i2c it's own Kconfig -
 https://patchwork.kernel.org/patch/2037181/

In addition, the LCD panel patch also depends on Steffen Trumtrar's OF
display helper series. I've moved this patch to last so it can be merged
later if needed.  Although I really see no reason not to merge the OF
display helper series for 3.9.

These patches and their dependencies can also be found here:

  git://people.freedesktop.org/~robclark/linux tilcdc-next
  http://cgit.freedesktop.org/~robclark/linux/log/?h=tilcdc-next

Rob Clark (4):
  drm/tilcdc: add TI LCD Controller DRM driver (v4)
  drm/i2c: nxp-tda998x (v3)
  drm/tilcdc: add encoder slave (v2)
  drm/tilcdc: add support for LCD panels (v5)

 .../devicetree/bindings/drm/tilcdc/panel.txt   |  59 ++
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  19 +
 .../devicetree/bindings/drm/tilcdc/tfp410.txt  |  21 +
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  21 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/i2c/Kconfig|   6 +
 drivers/gpu/drm/i2c/Makefile   |   3 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 906 +
 drivers/gpu/drm/tilcdc/Kconfig |  13 +
 drivers/gpu/drm/tilcdc/Makefile|  10 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 602 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 611 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h| 150 
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 436 ++
 drivers/gpu/drm/tilcdc/tilcdc_panel.h  |  26 +
 drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 376 +
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 +
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 ++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 +
 21 files changed, 3887 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
 create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
 create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
 create mode 100644 drivers/gpu/drm/tilcdc/Makefile
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

-- 
1.8.1

[PATCH v2] drm/exynos: Get HDMI version from device tree

[Sean Paul]

On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren  wrote:
> On 01/08/2013 01:16 PM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>
> I guess this seems OK to me if required, although I'd certainly like to
> see someone familiar with the Exynos HW confirm whether this should be
> driven purely by DT compatible value for the HDMI IP block instead though.

+inki

Inki, does this seem reasonable to you?


Sean

[PATCH] drm/cirrus: Add bpp option

[Daniel Vetter]

On Tue, Jan 29, 2013 at 10:57 AM, Takashi Iwai  wrote:
> At Tue, 29 Jan 2013 10:53:50 +0100,
> Daniel Vetter wrote:
>>
>> On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
>> > Add a new option, bpp, to specify the default bpp value.
>> >
>> > Signed-off-by: Takashi Iwai 
>> > ---
>> >
>> > This patch is applied on the top of previous two patches.
>> > I couldn't find an easy way to specify the default bpp, so I cooked
>> > the driver quickly.  If there is any other convenient way to achieve
>> > this, let me know...
>>
>> Well, you can specify the desired bpp with a full mode on the kernel
>> cmdline - the '-bpp' extension. Reading through the parser I think it
>> should work even with just the '-bpp' and not a full mode, but I haven't
>> tested. Look for cmdline_mode->bpp_specified in drm_fb_helper.c and the
>> relevant parsing code in drm_mode_parse_command_line_for_connector in
>> drm_modes.c
>>
>> If that doesn't work for you, I think it's better to extend/fix it than
>> add driver module options.
>
> Well, the fb can be set by that option, but the default modeset
> doesn't seem to honor it.  So if you start X modeset driver, it still
> takes what the driver sets as default.  That was the problem I hit.

Oh, I've missed the preferred_bpp hint for the generic modesetting
driver. Can we fill that in by using the bpp parsed in the fb helper
somehow?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/cirrus: Add bpp option

[Takashi Iwai]

At Tue, 29 Jan 2013 10:53:50 +0100,
Daniel Vetter wrote:
> 
> On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
> > Add a new option, bpp, to specify the default bpp value.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> > 
> > This patch is applied on the top of previous two patches.
> > I couldn't find an easy way to specify the default bpp, so I cooked
> > the driver quickly.  If there is any other convenient way to achieve
> > this, let me know...
> 
> Well, you can specify the desired bpp with a full mode on the kernel
> cmdline - the '-bpp' extension. Reading through the parser I think it
> should work even with just the '-bpp' and not a full mode, but I haven't
> tested. Look for cmdline_mode->bpp_specified in drm_fb_helper.c and the
> relevant parsing code in drm_mode_parse_command_line_for_connector in
> drm_modes.c
> 
> If that doesn't work for you, I think it's better to extend/fix it than
> add driver module options.

Well, the fb can be set by that option, but the default modeset
doesn't seem to honor it.  So if you start X modeset driver, it still
takes what the driver sets as default.  That was the problem I hit.


thanks,

Takashi

[PATCH] drm/cirrus: Add bpp option

[Daniel Vetter]

On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
> Add a new option, bpp, to specify the default bpp value.
> 
> Signed-off-by: Takashi Iwai 
> ---
> 
> This patch is applied on the top of previous two patches.
> I couldn't find an easy way to specify the default bpp, so I cooked
> the driver quickly.  If there is any other convenient way to achieve
> this, let me know...

Well, you can specify the desired bpp with a full mode on the kernel
cmdline - the '-bpp' extension. Reading through the parser I think it
should work even with just the '-bpp' and not a full mode, but I haven't
tested. Look for cmdline_mode->bpp_specified in drm_fb_helper.c and the
relevant parsing code in drm_mode_parse_command_line_for_connector in
drm_modes.c

If that doesn't work for you, I think it's better to extend/fix it than
add driver module options.

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

3.8-rc2: lockdep warning in nouveau driver

[Peter Hurley]

On Wed, 2013-01-09 at 12:45 +0100, Arend van Spriel wrote:
> Maybe this one is already known, but I did not find a post about it. So
> here it is.
> 
> Regards,
> Arend

[snip]

> [9.589986] =
> [9.595365] [ INFO: possible recursive locking detected ]
> [9.600745] 3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1 Not tainted
> [9.607248] -
> [9.612626] modprobe/163 is trying to acquire lock:
> [9.617486]  (>mutex){+.+.+.}, at: []
> nv50_fb_vram_new+0x92/0x230 [nouveau]
> [9.626052]
> [9.626052] but task is already holding lock:
> [9.631865]  (>mutex){+.+.+.}, at: []
> nv50_disp_data_ctor+0x55/0xc0 [nouveau]
> [9.640593]
> [9.640593] other info that might help us debug this:
> [9.647096]  Possible unsafe locking scenario:
> [9.647096]
> [9.652995]CPU0
> [9.655430]
> [9.657867]   lock(>mutex);
> [9.661365]   lock(>mutex);
> [9.664863]
> [9.664863]  *** DEADLOCK ***
> [9.664863]
> [9.670762]  May be due to missing lock nesting notation

Same.

[5.995881] =
[5.995886] [ INFO: possible recursive locking detected ]
[5.995892] 3.8.0-next-20130125+ttypatch-xeon+lockdep #20130125+ttypatch Not 
tainted
[5.995898] -
[5.995904] modprobe/275 is trying to acquire lock:
[5.995909]  (>mutex){+.+.+.}, at: [] 
nouveau_instobj_create_+0x48/0x90 [nouveau]
[5.995955] 
[5.995955] but task is already holding lock:
[5.995961]  (>mutex){+.+.+.}, at: [] 
nv50_disp_data_ctor+0x65/0xd0 [nouveau]
[5.995989] 
[5.995989] other info that might help us debug this:
[5.995995]  Possible unsafe locking scenario:
[5.995995] 
[5.996001]CPU0
[5.996004]
[5.996005]   lock(>mutex);
[5.996005]   lock(>mutex);
[5.996005] 
[5.996005]  *** DEADLOCK ***

Regards,
Peter Hurley

[PATCH] drm/cirrus: Add bpp option

[Takashi Iwai]

Add a new option, bpp, to specify the default bpp value.

Signed-off-by: Takashi Iwai 
---

This patch is applied on the top of previous two patches.
I couldn't find an easy way to specify the default bpp, so I cooked
the driver quickly.  If there is any other convenient way to achieve
this, let me know...

Takashi

===
 drivers/gpu/drm/cirrus/cirrus_drv.c  | 9 +
 drivers/gpu/drm/cirrus/cirrus_drv.h  | 2 ++
 drivers/gpu/drm/cirrus/cirrus_mode.c | 2 +-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 8ecb601..407750fb 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -15,9 +15,12 @@
 #include "cirrus_drv.h"

 int cirrus_modeset = -1;
+int cirrus_bpp = 16;

 MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
 module_param_named(modeset, cirrus_modeset, int, 0400);
+MODULE_PARM_DESC(bpp, "Default bits per pixel");
+module_param_named(bpp, cirrus_bpp, int, 0400);

 /*
  * This is the generic driver code. This binds the driver to the drm core,
@@ -121,6 +124,12 @@ static int __init cirrus_init(void)

if (cirrus_modeset == 0)
return -EINVAL;
+
+   if (cirrus_bpp % 8 || cirrus_bpp < 8 || cirrus_bpp > 24) {
+   pr_err("cirrus: invalid bpp %d, default to 16\n", cirrus_bpp);
+   cirrus_bpp = 16;
+   }
+
return drm_pci_init(, _pci_driver);
 }

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 6e0cc72..45ffdb8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -176,6 +176,8 @@ cirrus_bo(struct ttm_buffer_object *bo)
 #define to_cirrus_obj(x) container_of(x, struct cirrus_gem_object, base)
 #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)

+extern int cirrus_modeset;
+extern int cirrus_bpp;
/* cirrus_mode.c */
 void cirrus_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
 u16 blue, int regno);
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index e259f07..3524081 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -588,7 +588,7 @@ int cirrus_modeset_init(struct cirrus_device *cdev)
cdev->dev->mode_config.max_height = CIRRUS_MAX_FB_HEIGHT;

cdev->dev->mode_config.fb_base = cdev->mc.vram_base;
-   cdev->dev->mode_config.preferred_depth = 16;
+   cdev->dev->mode_config.preferred_depth = cirrus_bpp;
/* don't prefer a shadow on virt GPU */
cdev->dev->mode_config.prefer_shadow = 0;

-- 
1.8.1.1

[PATCH 1/2] drm/cirrus: Correct register values for 16bpp

[Takashi Iwai]

Hi Dave,

any chance to take a look at this problem?


thanks,

Takashi

At Fri, 25 Jan 2013 17:21:54 +0100,
Takashi Iwai wrote:
> 
> When the mode is set with 16bpp on QEMU, the output gets totally
> broken.  The culprit is the bogus register values set for 16bpp,
> which was likely copied from from a wrong place.
> 
> Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=799216
> 
> Cc: 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/cirrus/cirrus_mode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
> b/drivers/gpu/drm/cirrus/cirrus_mode.c
> index 60685b2..379a47e 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> @@ -273,8 +273,8 @@ static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
>   sr07 |= 0x11;
>   break;
>   case 16:
> - sr07 |= 0xc1;
> - hdr = 0xc0;
> + sr07 |= 0x17;
> + hdr = 0xc1;
>   break;
>   case 24:
>   sr07 |= 0x15;
> -- 
> 1.8.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[PATCH] drm: modify pages_to_sg prime helper to create optimized SG table

[Aaron Plattner]

On 01/28/2013 05:38 AM, Rahul Sharma wrote:
> It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
> sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
> creating SG table for the buffers having more than 204 physical pages i.e.
> equal to SG_MAX_SINGLE_ALLOC.
>
> When using sg_alloc_table_from_pages interface, in place of sg_alloc_table,
> page list will be passes to get each contiguous section which is represented
> by a single entry in the table. For a Contiguous Buffer, number of entries
> should be equal to 1.
>
> Following check is causing the failure which is not applicable for Non-Contig
> buffers:
>
>   if (WARN_ON_ONCE(nents > max_ents))
>   return -EINVAL;
>
> Above patch is well tested for EXYNOS4 and EXYNOS5 for with/wihtout IOMMU
> supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
> helper function.
>
> This set is base on "exynos-drm-fixes" branch at
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
> Signed-off-by: Rahul Sharma 

Reviewed-by: Aaron Plattner 

I also verified that this reduces my 2025-entry sg_table to 6 entries, so

Tested-by: Aaron Plattner 

-- 
Aaron

> ---
>   drivers/gpu/drm/drm_prime.c | 8 ++--
>   1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7f12573..072ee08 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -217,21 +217,17 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device 
> *dev, void *data,
>   struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
>   {
>   struct sg_table *sg = NULL;
> - struct scatterlist *iter;
> - int i;
>   int ret;
>
>   sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
>   if (!sg)
>   goto out;
>
> - ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
> + ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> + nr_pages << PAGE_SHIFT, GFP_KERNEL);
>   if (ret)
>   goto out;
>
> - for_each_sg(sg->sgl, iter, nr_pages, i)
> - sg_set_page(iter, pages[i], PAGE_SIZE, 0);
> -
>   return sg;
>   out:
>   kfree(sg);
>

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #2 from Jerome Glisse  ---
cd /sys/bus/pci/devices/:01:05.0
sudo sh -c "echo 1 > rom"
sudo sh -c "cat rom > ~/bios.rom"

Something like that should do the trick, just change the pciid

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

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #1 from Jerome Glisse  ---
Could you please attach your video bios to the bug

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

[PATCH 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function

[Leela Krishna Amudala]

This patch adds display-timing node parsing using video helper function

Signed-off-by: Leela Krishna Amudala 
Tested-by: Vikas Sajjan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..19dc842 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -876,6 +876,8 @@ static int fimd_probe(struct platform_device *pdev)
struct fimd_context *ctx;
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
+   struct fb_videomode *fbmode;
+   struct device *disp_dev = >dev;
struct exynos_drm_panel_info *panel;
struct resource *res;
int win;
@@ -883,10 +885,31 @@ static int fimd_probe(struct platform_device *pdev)

DRM_DEBUG_KMS("%s\n", __FILE__);

-   pdata = pdev->dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, "no platform data specified\n");
-   return -EINVAL;
+   if (pdev->dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR("memory allocation for pdata failed\n");
+   return -ENOMEM;
+   }
+
+   fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+   if (!fbmode) {
+   DRM_ERROR("memory allocation for fbmode failed\n");
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(disp_dev->of_node, fbmode, -1);
+   if (ret) {
+   DRM_ERROR("failed to get fb_videomode\n");
+   return -EINVAL;
+   }
+   pdata->panel.timing = (struct fb_videomode) *fbmode;
+   } else {
+   pdata = pdev->dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR("no platform data specified\n");
+   return -EINVAL;
+   }
}

panel = >panel;
-- 
1.8.0

[PATCH 0/1] Adds display-timing node parsing to exynos drm fimd

[Leela Krishna Amudala]

This patch adds display-timing node parsing to drm fimd, this depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

Patch is based on branch "exynos-drm-next" at
http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/

It is tested on Exynos5250 and Exynos4412 board by applying dependent patches 
available at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

Leela Krishna Amudala (1):
  video: drm: exynos: Adds display-timing node parsing using video
helper function

 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

-- 
1.8.0

[Bug 53111] vgaswitcheroo not working anymore

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

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


Rafael J. Wysocki  changed:

   What|Removed |Added

  Component|Other   |Video(DRI - non Intel)
 AssignedTo|rjw at sisk.pl |drivers_video-dri at 
kernel-bu
   ||gs.osdl.org
Product|Power Management|Drivers




-- 
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 59946] [r600g] WoW crashed with "page allocation failure"

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

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

Chris Rankin  changed:

   What|Removed |Added

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

--- Comment #1 from Chris Rankin  ---
This seems to be fixed by:

commit 87592cff57feef29565150b9203e220b50623f30
Author: Marek Ol??k 
Date:   Mon Jan 28 02:47:24 2013 +0100

gallium/u_upload_mgr: fix a serious memory leak

It can eat all memory and crash in a matter of minutes with r600g.

-- 
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/20130129/39289ecb/attachment.html>

[Bug 58840] rendering error with MSAA on HD6850

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

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

--- Comment #12 from almos  ---
I happened to check out the git exactly at the tag 3.8-rc5 as HEAD. With that
the preformance issues in etqw and nexuiz are gone. The neverball problem is
still there though.

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

Re: [PATCH 1/2] drm/cirrus: Correct register values for 16bpp

[Takashi Iwai]

Hi Dave,

any chance to take a look at this problem?


thanks,

Takashi

At Fri, 25 Jan 2013 17:21:54 +0100,
Takashi Iwai wrote:
 
 When the mode is set with 16bpp on QEMU, the output gets totally
 broken.  The culprit is the bogus register values set for 16bpp,
 which was likely copied from from a wrong place.
 
 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=799216
 
 Cc: sta...@vger.kernel.org
 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
  drivers/gpu/drm/cirrus/cirrus_mode.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
 b/drivers/gpu/drm/cirrus/cirrus_mode.c
 index 60685b2..379a47e 100644
 --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
 +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
 @@ -273,8 +273,8 @@ static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
   sr07 |= 0x11;
   break;
   case 16:
 - sr07 |= 0xc1;
 - hdr = 0xc0;
 + sr07 |= 0x17;
 + hdr = 0xc1;
   break;
   case 24:
   sr07 |= 0x15;
 -- 
 1.8.1.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/cirrus: Add bpp option

[Takashi Iwai]

Add a new option, bpp, to specify the default bpp value.

Signed-off-by: Takashi Iwai ti...@suse.de
---

This patch is applied on the top of previous two patches.
I couldn't find an easy way to specify the default bpp, so I cooked
the driver quickly.  If there is any other convenient way to achieve
this, let me know...

Takashi

===
 drivers/gpu/drm/cirrus/cirrus_drv.c  | 9 +
 drivers/gpu/drm/cirrus/cirrus_drv.h  | 2 ++
 drivers/gpu/drm/cirrus/cirrus_mode.c | 2 +-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 8ecb601..407750fb 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -15,9 +15,12 @@
 #include cirrus_drv.h
 
 int cirrus_modeset = -1;
+int cirrus_bpp = 16;
 
 MODULE_PARM_DESC(modeset, Disable/Enable modesetting);
 module_param_named(modeset, cirrus_modeset, int, 0400);
+MODULE_PARM_DESC(bpp, Default bits per pixel);
+module_param_named(bpp, cirrus_bpp, int, 0400);
 
 /*
  * This is the generic driver code. This binds the driver to the drm core,
@@ -121,6 +124,12 @@ static int __init cirrus_init(void)
 
if (cirrus_modeset == 0)
return -EINVAL;
+
+   if (cirrus_bpp % 8 || cirrus_bpp  8 || cirrus_bpp  24) {
+   pr_err(cirrus: invalid bpp %d, default to 16\n, cirrus_bpp);
+   cirrus_bpp = 16;
+   }
+
return drm_pci_init(driver, cirrus_pci_driver);
 }
 
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 6e0cc72..45ffdb8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -176,6 +176,8 @@ cirrus_bo(struct ttm_buffer_object *bo)
 #define to_cirrus_obj(x) container_of(x, struct cirrus_gem_object, base)
 #define DRM_FILE_PAGE_OFFSET (0x1ULL  PAGE_SHIFT)
 
+extern int cirrus_modeset;
+extern int cirrus_bpp;
/* cirrus_mode.c */
 void cirrus_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
 u16 blue, int regno);
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index e259f07..3524081 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -588,7 +588,7 @@ int cirrus_modeset_init(struct cirrus_device *cdev)
cdev-dev-mode_config.max_height = CIRRUS_MAX_FB_HEIGHT;
 
cdev-dev-mode_config.fb_base = cdev-mc.vram_base;
-   cdev-dev-mode_config.preferred_depth = 16;
+   cdev-dev-mode_config.preferred_depth = cirrus_bpp;
/* don't prefer a shadow on virt GPU */
cdev-dev-mode_config.prefer_shadow = 0;
 
-- 
1.8.1.1

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

[PATCH] drm/exynos: consider exception case to fb handle creation

[Inki Dae]

GETFB ioctl request creates a new handle to only one gem object
so it should check if the given fb has one gem object.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 294c051..b751c8a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -99,6 +99,10 @@ static int exynos_drm_fb_create_handle(struct 
drm_framebuffer *fb,
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
+   /* This fb should have only one gem object. */
+   if (WARN_ON(exynos_fb-buf_cnt != 1))
+   return -EINVAL;
+
return drm_gem_handle_create(file_priv,
exynos_fb-exynos_gem_obj[0]-base, handle);
 }
-- 
1.7.4.1

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

[PATCH] drm: modify pages_to_sg prime helper to create optimized SG table

[Rahul Sharma]

It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
creating SG table for the buffers having more than 204 physical pages i.e.
equal to SG_MAX_SINGLE_ALLOC.

When using sg_alloc_table_from_pages interface, in place of sg_alloc_table,
page list will be passes to get each contiguous section which is represented
by a single entry in the table. For a Contiguous Buffer, number of entries
should be equal to 1.

Following check is causing the failure which is not applicable for Non-Contig
buffers:

if (WARN_ON_ONCE(nents  max_ents))
return -EINVAL;

Above patch is well tested for EXYNOS4 and EXYNOS5 for with/wihtout IOMMU
supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
helper function.

This set is base on exynos-drm-fixes branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 drivers/gpu/drm/drm_prime.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..072ee08 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -217,21 +217,17 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
 struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
 {
struct sg_table *sg = NULL;
-   struct scatterlist *iter;
-   int i;
int ret;
 
sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!sg)
goto out;
 
-   ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
+   ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
+   nr_pages  PAGE_SHIFT, GFP_KERNEL);
if (ret)
goto out;
 
-   for_each_sg(sg-sgl, iter, nr_pages, i)
-   sg_set_page(iter, pages[i], PAGE_SIZE, 0);
-
return sg;
 out:
kfree(sg);
-- 
1.8.0

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

Re: [Intel-gfx] Adding a i915 quirk (here: pipe A force quirk for testing purposes)?

[Sedat Dilek]

On Mon, Jan 28, 2013 at 4:01 PM, Jani Nikula
jani.nik...@linux.intel.com wrote:
 On Mon, 28 Jan 2013, Sedat Dilek sedat.di...@gmail.com wrote:
 ...
 static struct intel_quirk intel_quirks[] = {
   /* HP Mini needs pipe A force quirk (LP: #322104) */
   { 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
 ...
 }

 Triple - which value is what?

 I guess you figured it out, but just a few lines up there's [1]:

 struct intel_quirk {
 int device;
 int subsystem_vendor;
 int subsystem_device;
 void (*hook)(struct drm_device *dev);
 };

 where device, subsystem_vendor, and subsystem_device map to Device,
 SVendor, and SDevice of the gfx controller in 'lspci -vmnn' output.


Oh, cool.
Did not know of these parameters...

Device: 00:02.0
Class:  VGA compatible controller [0300]
Vendor: Intel Corporation [8086]
Device: 2nd Generation Core Processor Family Integrated Graphics
Controller [0116]
SVendor:Samsung Electronics Co Ltd [144d]
SDevice:Device [c0c7]
Rev:09

...together with the pasted code-snippet, it is clear to me!

Thanks for the explanation and hints!

- Sedat -

 HTH,
 Jani.

 [1] 
 http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/intel_display.c?h=drm-intel-nightly#n8574
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/1] Adds display-timing node parsing to exynos drm fimd

[Leela Krishna Amudala]

This patch adds display-timing node parsing to drm fimd, this depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

Patch is based on branch exynos-drm-next at
http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/

It is tested on Exynos5250 and Exynos4412 board by applying dependent patches 
available at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

Leela Krishna Amudala (1):
  video: drm: exynos: Adds display-timing node parsing using video
helper function

 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

-- 
1.8.0

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

[PATCH 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function

[Leela Krishna Amudala]

This patch adds display-timing node parsing using video helper function

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Tested-by: Vikas Sajjan vikas.saj...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..19dc842 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -876,6 +876,8 @@ static int fimd_probe(struct platform_device *pdev)
struct fimd_context *ctx;
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
+   struct fb_videomode *fbmode;
+   struct device *disp_dev = pdev-dev;
struct exynos_drm_panel_info *panel;
struct resource *res;
int win;
@@ -883,10 +885,31 @@ static int fimd_probe(struct platform_device *pdev)
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
-   pdata = pdev-dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, no platform data specified\n);
-   return -EINVAL;
+   if (pdev-dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR(memory allocation for pdata failed\n);
+   return -ENOMEM;
+   }
+
+   fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+   if (!fbmode) {
+   DRM_ERROR(memory allocation for fbmode failed\n);
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(disp_dev-of_node, fbmode, -1);
+   if (ret) {
+   DRM_ERROR(failed to get fb_videomode\n);
+   return -EINVAL;
+   }
+   pdata-panel.timing = (struct fb_videomode) *fbmode;
+   } else {
+   pdata = pdev-dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR(no platform data specified\n);
+   return -EINVAL;
+   }
}
 
panel = pdata-panel;
-- 
1.8.0

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

Re: [PATCH] drm/cirrus: Add bpp option

[Daniel Vetter]

On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
 Add a new option, bpp, to specify the default bpp value.
 
 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
 
 This patch is applied on the top of previous two patches.
 I couldn't find an easy way to specify the default bpp, so I cooked
 the driver quickly.  If there is any other convenient way to achieve
 this, let me know...

Well, you can specify the desired bpp with a full mode on the kernel
cmdline - the '-bpp' extension. Reading through the parser I think it
should work even with just the '-bpp' and not a full mode, but I haven't
tested. Look for cmdline_mode-bpp_specified in drm_fb_helper.c and the
relevant parsing code in drm_mode_parse_command_line_for_connector in
drm_modes.c

If that doesn't work for you, I think it's better to extend/fix it than
add driver module options.

Cheers, 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: [PATCH] drm/cirrus: Add bpp option

[Takashi Iwai]

At Tue, 29 Jan 2013 10:53:50 +0100,
Daniel Vetter wrote:
 
 On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
  Add a new option, bpp, to specify the default bpp value.
  
  Signed-off-by: Takashi Iwai ti...@suse.de
  ---
  
  This patch is applied on the top of previous two patches.
  I couldn't find an easy way to specify the default bpp, so I cooked
  the driver quickly.  If there is any other convenient way to achieve
  this, let me know...
 
 Well, you can specify the desired bpp with a full mode on the kernel
 cmdline - the '-bpp' extension. Reading through the parser I think it
 should work even with just the '-bpp' and not a full mode, but I haven't
 tested. Look for cmdline_mode-bpp_specified in drm_fb_helper.c and the
 relevant parsing code in drm_mode_parse_command_line_for_connector in
 drm_modes.c
 
 If that doesn't work for you, I think it's better to extend/fix it than
 add driver module options.

Well, the fb can be set by that option, but the default modeset
doesn't seem to honor it.  So if you start X modeset driver, it still
takes what the driver sets as default.  That was the problem I hit.


thanks,

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

Re: [PATCH] drm/cirrus: Add bpp option

[Daniel Vetter]

On Tue, Jan 29, 2013 at 10:57 AM, Takashi Iwai ti...@suse.de wrote:
 At Tue, 29 Jan 2013 10:53:50 +0100,
 Daniel Vetter wrote:

 On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
  Add a new option, bpp, to specify the default bpp value.
 
  Signed-off-by: Takashi Iwai ti...@suse.de
  ---
 
  This patch is applied on the top of previous two patches.
  I couldn't find an easy way to specify the default bpp, so I cooked
  the driver quickly.  If there is any other convenient way to achieve
  this, let me know...

 Well, you can specify the desired bpp with a full mode on the kernel
 cmdline - the '-bpp' extension. Reading through the parser I think it
 should work even with just the '-bpp' and not a full mode, but I haven't
 tested. Look for cmdline_mode-bpp_specified in drm_fb_helper.c and the
 relevant parsing code in drm_mode_parse_command_line_for_connector in
 drm_modes.c

 If that doesn't work for you, I think it's better to extend/fix it than
 add driver module options.

 Well, the fb can be set by that option, but the default modeset
 doesn't seem to honor it.  So if you start X modeset driver, it still
 takes what the driver sets as default.  That was the problem I hit.

Oh, I've missed the preferred_bpp hint for the generic modesetting
driver. Can we fill that in by using the bpp parsed in the fb helper
somehow?
-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: CDF discussions at FOSDEM

[Laurent Pinchart]

Hello,

On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
 On Thursday 17 January 2013 13:29:27 Daniel Vetter wrote:
  On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote:
   On Fri, 11 Jan 2013, Laurent Pinchart wrote:
   Would anyone be interested in meeting at the FOSDEM to discuss the
   Common Display Framework ? There will be a CDF meeting at the ELC at
   the end of February, the FOSDEM would be a good venue for European
   developers.
   
   Yes, count me in,
  
  Jesse, Ville and me should also be around. Do we have a slot fixed
  already?
 
 I've sent a mail to the FOSDEM organizers to request a hacking room for a
 couple of hours Sunday. I'll let you know as soon as I get a reply.

Just a quick follow-up. I've received information from the FOSDEM staff, there 
will be hacking rooms that can be reserved (on-site only) for 1h slots. They 
unfortunately won't have projectors, as they're not meant for talks.

Another option would be to start early on Saturday, the X.org room is reported 
as beeing free from 9am to 11am.

-- 
Regards,

Laurent Pinchart

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

Re: [Linaro-mm-sig] CDF discussions at FOSDEM

[Luc Verhaegen]

On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote:
 Hello,
 
 On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
  
  I've sent a mail to the FOSDEM organizers to request a hacking room for a
  couple of hours Sunday. I'll let you know as soon as I get a reply.
 
 Just a quick follow-up. I've received information from the FOSDEM staff, 
 there 
 will be hacking rooms that can be reserved (on-site only) for 1h slots. They 
 unfortunately won't have projectors, as they're not meant for talks.
 
 Another option would be to start early on Saturday, the X.org room is 
 reported 
 as beeing free from 9am to 11am.
 
 -- 
 Regards,
 
 Laurent Pinchart

As the organizer of the X.org devroom, i would have to state that the 
latter is impossible. I tend to do a bit of room set-up, like put in 
some power bars (a limited amount this year, as i only have been given 
one day and it simply is not worth putting in the cabling for 100 
sockets, and dragging all that kit over from Nuremberg, for just a 
single day) and some other things. I need one hour at least for that on 
saturday morning.

DevRooms are also not supposed to open before 11:00 (which is already a 
massive improvement over 2011 and the years before, where i was happy 
to be able to put the cabling in at 12:00), and i tend to first get a 
nod of approval from the on-site devrooms supervisor before i go in and 
set up the room.

So use the hackingroom this year. Things will hopefully be better next 
year.

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

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #5)
 if i switch with my remote through the xbmc-menu or watch a video the
 xorg-log is spam the whole time with page filp errors

While that is happening, can you write 2 to /sys/module/drm/parameters/debug
and capture some debugging output from dmesg?

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

[Bug 59899] Diagonal rendering artifacts on xbmc

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer mic...@daenzer.net ---
This is more likely an issue in Mesa than in the kernel.

Please attach Xorg.0.log and the output of glxinfo and dmesg.

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

Re: [Linaro-mm-sig] CDF discussions at FOSDEM

[Laurent Pinchart]

Hi Luc,

On Tuesday 29 January 2013 12:47:16 Luc Verhaegen wrote:
 On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote:
  On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote:
   I've sent a mail to the FOSDEM organizers to request a hacking room for
   a couple of hours Sunday. I'll let you know as soon as I get a reply.
  
  Just a quick follow-up. I've received information from the FOSDEM staff,
  there will be hacking rooms that can be reserved (on-site only) for 1h
  slots. They unfortunately won't have projectors, as they're not meant for
  talks.
  
  Another option would be to start early on Saturday, the X.org room is
  reported as beeing free from 9am to 11am.
 
 As the organizer of the X.org devroom, i would have to state that the
 latter is impossible. I tend to do a bit of room set-up, like put in
 some power bars (a limited amount this year, as i only have been given
 one day and it simply is not worth putting in the cabling for 100
 sockets, and dragging all that kit over from Nuremberg, for just a
 single day) and some other things. I need one hour at least for that on
 saturday morning.

No worries. It was just an idea.

 DevRooms are also not supposed to open before 11:00 (which is already a
 massive improvement over 2011 and the years before, where i was happy
 to be able to put the cabling in at 12:00), and i tend to first get a
 nod of approval from the on-site devrooms supervisor before i go in and
 set up the room.
 
 So use the hackingroom this year. Things will hopefully be better next
 year.

Saturday is pretty much out of question, given that most developers interested 
in CDF will want to attend the X.org talks. I'll try to get a room for Sunday 
then, but I'm not sure yet what time slots will be available. It would be 
helpful if people interested in CDF discussions could tell me at what time 
they plan to leave Brussels on Sunday.

-- 
Regards,

Laurent Pinchart

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

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

[bugzilla-daemon]

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

--- Comment #3 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
Hi Jerome, I attempted the dump without success

[root@localhost ~]# lspci
...
0001:01:00.0 VGA compatible controller: ATI Technologies Inc ...
0001:01:00.1 Audio device: ATI Technologies Inc ...
[root@localhost ~]# cd /sys/bus/pci/devices/0001:01:00.0
[root@localhost 0001:01:00.0]# echo 1  rom
[root@localhost 0001:01:00.0]# cat rom  ~/bios.rom
[  588.381813] pci 0001:01:00.0: Invalid ROM contents
cat: rom: Input/output error
[root@localhost 0001:01:00.0]# lspci
[  637.187942] Kernel panic - not syncing: FAIL
...
[  637.190672] ===
[  637.190677] [ INFO: suspicious RCU usage. ]
[  637.190683] 3.8.0-rc5-kotd+ #6 Not tainted
[  637.190687] ---
[  637.190692] include/linux/rcupdate.h:468 Illegal context switch in RCU
read-side critical section!
...

I'm investigating what was wrong with the rom dump, but if you have any ideas
what it could be, any help would be appreciated :)

-- 
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 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

[bugzilla-daemon]

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

--- Comment #4 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
As a side note, the kernel panic is actually induced by me. It actually means
there was an access to an invalid address.

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

[PATCH] drm: shut up invalid edid messages

[Maarten Lankhorst]

My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam 
every few seconds.

I get it the first time that the entire block is all 0xff..

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: sta...@vger.kernel.org [v3.7]

---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a3770f..4490080 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -357,10 +357,14 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
break;
}
}
-   if (i == 4)
+
+   if (i == 4  print_bad_edid) {
dev_warn(connector-dev-dev,
 %s: Ignoring invalid EDID block %d.\n,
 drm_get_connector_name(connector), j);
+
+   connector-bad_edid_counter++;
+   }
}
 
if (valid_extensions != block[0x7e]) {

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

[Bug 53111] vgaswitcheroo not working anymore

[bugzilla-daemon]

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


Alex Deucher alexdeuc...@gmail.com changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #1 from Alex Deucher alexdeuc...@gmail.com  2013-01-29 13:58:59 
---
Can you bisect?

-- 
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: [PATCH] Revert drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S

[Daniel Vetter]

On Mon, Jan 14, 2013 at 3:37 PM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Am Montag, den 14.01.2013, 11:06 +0100 schrieb Daniel Vetter:
 This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.

 The quirk cause a regression, and it looks like the original bug was
 simply a lack of FIFO bandwidth on the i915G of the reporter. Which
 should eventually be fixed as soon as we get around to implemented
 DSPARB FIFO reassignment on gen 3.

 Reported-by: Florian Mickler flor...@mickler.org

 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
 Cc: sta...@vger.kernel.org
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

 Acked-by: Paul Menzel paulepan...@users.sourceforge.net

Hm, revert hasn't landed anywhere yet :( Dave, Ajax: ping?
-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

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

The holiday pull fresh from QA. Not much in in, everyone was on vacation.
Highlights:
- Broadcast RBG improvements and reduced color range fixes from Ville
- Ben is on a kill legacy gtt code for good spree, first pile of patches
  included.
- no relocs and lut improvements for faster execbuf from Chris.
- some refactorings from Imre

Big regression caugh by QA was the inbalanced unlock in one of the
load-detect paths - you've merged that one already. Otherwise nothing to
report about.

Cheers, Daniel


The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:

  Merge tag 'drm-intel-next-2012-12-21' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-01-17 
20:34:08 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-01-20

for you to fetch changes up to e5c653777986b40e2986d2c918847fddbcba3a34:

  agp/intel: Add gma_bus_addr (2013-01-20 13:11:12 +0100)


Ben Widawsky (10):
  drm/i915: Kill gtt_end
  drm/i915: Mappable_end can't ever be  end
  drm/i915: Remove gtt_mappable_total
  drm/i915: Create a gtt structure
  drm/i915: Remove use on gma_bus_addr on gen6+
  drm/i915: Remove use of gtt_mappable_entries
  drm/i915: Cut out the infamous ILK w/a from AGP layer
  drm/i915: Remove scratch page from shared
  drm/i915: Needs_dmar, not
  agp/intel: Add gma_bus_addr

Chris Wilson (6):
  drm/i915: Add a debug interface to forcibly evict and shrink our object 
caches
  drm/i915: Bail if we attempt to allocate pages for a purged object
  drm/i915: Mark a temporary allocation for copy-from-user as such
  drm/i915: Take the handle idr spinlock once for looking up the exec 
objects
  drm/i915: Move the execbuffer objects list from the stack into the tracker
  drm/i915: Use the reloc.handle as an index into the execbuffer array

Daniel Vetter (2):
  drm/i915: wake up all pageflip waiters
  drm/i915: Allow userspace to hint that the relocations were known

Egbert Eich (1):
  drm/i915: Remove pch_rq_mask from struct drm_i915_private.

Imre Deak (3):
  drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
  drm/i915: merge {i965, sandybridge}_write_fence_reg()
  drm/i915: use gtt_get_size() instead of open coding it

Ville Syrjälä (5):
  drm/i915: Fix SPRITE0_FLIP_DONE_INT_EN_VLV and 
SPRITE0_FLIPDONE_INT_STATUS_VLV
  drm/i915: Fix RGB color range property for PCH platforms
  drm/i915: Add Automatic mode for the Broadcast RGB property
  drm/edid: Add drm_rgb_quant_range_selectable()
  drm/i915: Provide the quantization range in the AVI infoframe

 drivers/char/agp/intel-gtt.c   |   51 ++---
 drivers/gpu/drm/drm_edid.c |   33 
 drivers/gpu/drm/i915/i915_debugfs.c|  109 ++-
 drivers/gpu/drm/i915/i915_dma.c|   35 ++--
 drivers/gpu/drm/i915/i915_drv.h|   48 +++--
 drivers/gpu/drm/i915/i915_gem.c|  120 
 drivers/gpu/drm/i915/i915_gem_evict.c  |2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  280 
 drivers/gpu/drm/i915/i915_gem_gtt.c|  129 +++--
 drivers/gpu/drm/i915/i915_gem_tiling.c |   21 +--
 drivers/gpu/drm/i915/i915_irq.c|   14 +-
 drivers/gpu/drm/i915/i915_reg.h|5 +-
 drivers/gpu/drm/i915/intel_display.c   |   13 +-
 drivers/gpu/drm/i915/intel_dp.c|   39 +++-
 drivers/gpu/drm/i915/intel_drv.h   |   11 ++
 drivers/gpu/drm/i915/intel_fb.c|5 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |   45 -
 drivers/gpu/drm/i915/intel_modes.c |5 +-
 drivers/gpu/drm/i915/intel_overlay.c   |4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   59 +-
 include/drm/drm_crtc.h |1 +
 include/drm/intel-gtt.h|9 -
 include/uapi/drm/i915_drm.h|   20 ++
 24 files changed, 669 insertions(+), 391 deletions(-)
-- 
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: [Linaro-mm-sig] CDF discussions at FOSDEM

[Daniel Vetter]

On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 DevRooms are also not supposed to open before 11:00 (which is already a
 massive improvement over 2011 and the years before, where i was happy
 to be able to put the cabling in at 12:00), and i tend to first get a
 nod of approval from the on-site devrooms supervisor before i go in and
 set up the room.

 So use the hackingroom this year. Things will hopefully be better next
 year.

 Saturday is pretty much out of question, given that most developers interested
 in CDF will want to attend the X.org talks. I'll try to get a room for Sunday
 then, but I'm not sure yet what time slots will be available. It would be
 helpful if people interested in CDF discussions could tell me at what time
 they plan to leave Brussels on Sunday.

I'll stay till Monday early morning, so requirements from me. Adding a
bunch of Intel guys who're interested, too.
-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: [Linaro-mm-sig] CDF discussions at FOSDEM

[Daniel Vetter]

On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
 DevRooms are also not supposed to open before 11:00 (which is already a
 massive improvement over 2011 and the years before, where i was happy
 to be able to put the cabling in at 12:00), and i tend to first get a
 nod of approval from the on-site devrooms supervisor before i go in and
 set up the room.

 So use the hackingroom this year. Things will hopefully be better next
 year.

 Saturday is pretty much out of question, given that most developers 
 interested
 in CDF will want to attend the X.org talks. I'll try to get a room for Sunday
 then, but I'm not sure yet what time slots will be available. It would be
 helpful if people interested in CDF discussions could tell me at what time
 they plan to leave Brussels on Sunday.

 I'll stay till Monday early morning, so requirements from me. Adding a
 bunch of Intel guys who're interested, too.

Ok, in the interest of pre-heating the discussion a bit I've written down
my thoughts about display slave drivers. Adding a few more people and
lists to make sure I haven't missed anyone ...

Cheers, Daniel
--
Display Slaves
==

A highly biased quick analysis from Daniel Vetter.

A quick discussion about the issues surrounding some common framework for
display slaves like panels, hdmi/DP/whatever encoders, ... Since these external
chips are very often reused accross different SoCs, it would be beneficial to
share slave driver code between different chipset drivers.

Caveat Emperor!
---

Current output types and slave encoders already have to deal with a pletoria of
special cases and strange features. To avoid ending up with something not
suitable for everyone, we should look at what's all supported already and how we
could possibly deal with those things:

- audio embedded into the display stream (hdmi/dp). x86 platforms with the HD
  Audio framework rely on ELD and forwarding certain events as interrupts
  through the hw between the display and audio side ...

- hdmi/dp helpers: HDMI/DP are both standardized output connectors with nice
  complexity. DP is mostly about handling dp aux transactions and DPCD
  registers, hdmi mostly about infoframes and how to correctly set them up from
  the mode + edid.

- dpms is 4 states in drm, even more in fbdev afaict, but real hw only supports
  on/off nowadays ... how should/do we care?

- Fancy modes and how to represent them. Random list of things we need to
  represent somehow: broadcast/reduced rbg range for hdmi, yuv modes, different
  bpc modes (and handling how this affects bandwidth/clocks, e.g. i915
  auto-dithers to 6bpc on DP if there's not enough), 3D hdmi modes (patches have
  floated on dri-devel for this), overscan compensation. Many of these things
  link in with e.g. the helper libraries for certain outputs, e.g. discovering
  DP sink capabilities or setting up the correct hdmi infoframe.

- How to expose random madness as properties, e.g. backlight controllers,
  broadcast mode, enable/disable embedded audio (some screens advertise it, but
  don't like it). For additional fun I expect different users of a display slave
  driver to expect different set of standardized properties.

- Debug support: Register dumping, exposing random debugfs files, tracing.
  Preferably somewhat unified to keep things sane, since most often slave
  drivers are rather simple, but we expect quite a few different ones.

- Random metadata surrounding a display sink, like output type. Or flags for
  support special modes (h/vsync polarity, interlaced/doublescan, pixel
  doubling, ...).

- mode_fixup: Used a lot in drm-land to allow encoders to change the input mode,
  e.g. for lvds encoders which can do upscaling, or if the encoder supports
  progressive input with interlaced output and similar fancy stuff. See e.g. the
  intel sdvo encoder chip support.

- Handling different control buses like i2c, direct access (not seen that yet),
  DSI, DP aux, some other protocols.

- Handling of different display data standards like dsi (intel invented a few of
  its own, I'm sure we're not the only ones).

- hpd support/polling. Depending upon desing hpd handling needs to be
  cooperative between slave and master, or is a slave only thing (which means
  the slave needs to be able to poke the master when something changes).
  Similarly, masters need to know which slaves require output polling.

- Initializing of slave drivers: of/devicetree based, compiled-in static tables
  in the driver, dynamic discovery by i2c probing, lookup through some
  platform-specific firmware table (ACPI). Related is how to forward random
  platform init values to the drivers from these sources (e.g. the panel fixed
  modes) to the slave driver.

- get_hw_state support. One of the major point in the i915 modeset rewrite which
  landed in 3.7 is that a lot of the hw state 

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #1 from Dave Witbrodt dawit...@sbcglobal.net ---
Created attachment 73840
  -- https://bugs.freedesktop.org/attachment.cgi?id=73840action=edit
Xorg.0.log

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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #2 from Dave Witbrodt dawit...@sbcglobal.net ---
Created attachment 73842
  -- https://bugs.freedesktop.org/attachment.cgi?id=73842action=edit
Output from successive runs of 'top'

Running 'top' revealed the memory leak.

This attachment is (clipped) output from top.  Running the 'prboom-plus' game
on a kernel that was not leaking, then several snapshots on a kernel that was
leaking.

Eventually the game was taken out by the OOM killer, and system memory usage
was restored to normal.

-- 
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 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #3 from Dave Witbrodt dawit...@sbcglobal.net ---
Bisecting

So far, I have only bisected using my local custom kernel branch.  As described
above, I use stable kernel releases to avoid the massive breakage that
frequently occurs in -rc kernels, and I cherry pick commits from drm-fixes and
drm-next.  This is a potential source of error (on my part), so I will not be
offended if anyone objects to me reporting bugs against such kernels.  My
justification is that the HEAD of drm-fixes, which is

3.8.0~rc3 at commit 48367432 of Jan. 26

also leaks memory if I build it and use it on my system.  I bisected using my
custom branch first only to save time:  I add cherry picks in bunches, and keep
separate list files of which commits I have used, so manually bisecting using
those files rapidly led me to the first commit which caused the kernel to leak
memory.

[I will bisect using drm-fixes (or drm-next) if asked, but there are issues
with Mesa not being compatible before a certain point in mid-December, so that
I would have to use an older version of Mesa or patch some of the older
bisection points with later commits in order to use the version of Mesa
I currently have installed.]

For this testing, I started with stable kernel 3.7.4 and applied my lists of
cherry picks that had built up since 3.7-rc7 or so.  I had built up 11 lists of
commits as I added new upstream code to my local branch, so I could perform a
manual bisection by applying an entire list at a time until I found a kernel
which leaked memory.  From that, I would know which list introduce the problem,
and I could build kernels at each commit in that list until I found the first
one that resulted in leaks.  (If anyone is interested in those lists I will be
glad to post them; I have only withheld them for the sake of brevity.)

The manual bisection led me to a last good commit and a first bad commit.  The
cherry picking process causes my branch to have new SHA1 ID numbers, so I
instead of using the 'git log' info from my branch am will use the info
from the drm-airlied/drm-fixes branch.  The first bad commit was:

commit 4ac0533abaec2b83a7f2c675010eedd55664bc26
Author: Jerome Glisse jgli...@redhat.com
Date:   Thu Dec 13 12:08:11 2012 -0500

drm/radeon: fix htile buffer size computation for command stream
checker

Fix the size computation of the htile buffer.

Signed-off-by: Jerome Glisse jgli...@redhat.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com


The previous commit, which worked fine, was:

commit 9af20792124850369e764965690b99b20623dfc4
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Tue Dec 11 23:42:24 2012 +0100

drm/radeon: fix fence locking in the pageflip callback

We need to hold bdev-fence_lock while grabbing a reference to
the fence, to prevent concurrent clearing/changing of the
ttm_bo-sync_obj field.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Alex Deucher alexander.deuc...@amd.com


This was a time-consuming process, but much shorter than it would have been
using 'git bisect' in drm-fixes.  Later, I made two attempts to revert the
bad code on top of the HEAD of my local branch.

-- 
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 v2] drm/exynos: Get HDMI version from device tree

[Sean Paul]

On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 01/08/2013 01:16 PM, Sean Paul wrote:
 Add a property to the hdmi node so we can specify the HDMI version in
 the device tree instead of just defaulting to v1.4 with the existence of
 the dt node.

 I guess this seems OK to me if required, although I'd certainly like to
 see someone familiar with the Exynos HW confirm whether this should be
 driven purely by DT compatible value for the HDMI IP block instead though.

+inki

Inki, does this seem reasonable to you?


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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #4 from Dave Witbrodt dawit...@sbcglobal.net ---
Created attachment 73843
  -- https://bugs.freedesktop.org/attachment.cgi?id=73843action=edit
diff of attempt to partially revert problem commit

Naive attempt to revert

My first attempt to revert the patch revealed to be the problem
above did not work.  (A diff of the changes is attached.)  The 
problem commit touched evergreen_cs.c and r600_cs.c, and since I
have Evergreen Juniper hardware I only reverted the code in
evergreen_cs.c.  The kernel built using this approach still
leaked memory.

-- 
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 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #5 from Dave Witbrodt dawit...@sbcglobal.net ---
Created attachment 73844
  -- https://bugs.freedesktop.org/attachment.cgi?id=73844action=edit
diff of attempt to manually revert entire problem commit

Attempt to revert the entire commit

I then decided to manually revert all of the changes in the *.c
files touched by that commit.  (A diff of these changes is
attached.)  The kernel still leaked memory.

-- 
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 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #6 from Dave Witbrodt dawit...@sbcglobal.net ---
I do not know how to interpret these findings.  I am not a developer, and work
with the few tools that I (sort of) know how to use much more slowly than
experienced developers would.  I ran out of time over the weekend, and will
have
to investigate further this coming weekend.

I have been trying to think of possible explanations:

- could a later commit causes a similar (or identical)
  memory leak to the one caused by 4ac0533a?

- is the problem really located somewhere else
  besides in the kernel DRM, such as in Mesa, with
  it being triggered by more than one kind of
  code change in the DRM?

I thought that the bisection would be conclusive, but the failure of the revert
attempts undermined my goal.  If no one demands that I bisect using one of the
drm-airlied branches, then I will try another custom branch which drops the
commit first causing the leak, and see if any later commits also cause a leak. 
(If a developer demands that I bisect an upstream branch, I'll do that
instead.)

Is there anything else I can do to be helpful at this point?

Can any of you confirm/reproduce this memory leak on your own systems?

-- 
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: [Linaro-mm-sig] CDF discussions at FOSDEM

[Ville Syrjälä]

On Tue, Jan 29, 2013 at 03:19:38PM +0100, Daniel Vetter wrote:
 On Tue, Jan 29, 2013 at 1:11 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  DevRooms are also not supposed to open before 11:00 (which is already a
  massive improvement over 2011 and the years before, where i was happy
  to be able to put the cabling in at 12:00), and i tend to first get a
  nod of approval from the on-site devrooms supervisor before i go in and
  set up the room.
 
  So use the hackingroom this year. Things will hopefully be better next
  year.
 
  Saturday is pretty much out of question, given that most developers 
  interested
  in CDF will want to attend the X.org talks. I'll try to get a room for 
  Sunday
  then, but I'm not sure yet what time slots will be available. It would be
  helpful if people interested in CDF discussions could tell me at what time
  they plan to leave Brussels on Sunday.
 
 I'll stay till Monday early morning, so requirements from me. Adding a
 bunch of Intel guys who're interested, too.

My return flight isn't until Monday afternoon.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer mic...@daenzer.net ---
This is indeed more likely an issue in Mesa than in the kernel. The commit you
bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause the Mesa
code to use different code paths.

Does current Mesa Git still leak?

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

[PATCH] x86, efi: remove attribute check from setup_efi_pci

[Maarten Lankhorst]

It looks like the original commit that copied the rom contents from efi always 
copied
the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
(x86, efi: correct precedence of operators in setup_efi_pci) broke that.

This resulted in macbook pro's no longer finding the rom images, and thus not 
being able to use the radeon card any more.

The solution is to just remove the check for now, and always copy the rom if 
available.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 18e329c..ce06324 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -302,9 +302,6 @@ static efi_status_t setup_efi_pci(struct boot_params 
*params)
if (status != EFI_SUCCESS)
continue;
 
-   if (!(attributes  EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM))
-   continue;
-
if (!pci-romimage || !pci-romsize)
continue;
 

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

Re: [PATCH] drm: modify pages_to_sg prime helper to create optimized SG table

[Aaron Plattner]

On 01/28/2013 05:38 AM, Rahul Sharma wrote:

It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
creating SG table for the buffers having more than 204 physical pages i.e.
equal to SG_MAX_SINGLE_ALLOC.

When using sg_alloc_table_from_pages interface, in place of sg_alloc_table,
page list will be passes to get each contiguous section which is represented
by a single entry in the table. For a Contiguous Buffer, number of entries
should be equal to 1.

Following check is causing the failure which is not applicable for Non-Contig
buffers:

if (WARN_ON_ONCE(nents  max_ents))
return -EINVAL;

Above patch is well tested for EXYNOS4 and EXYNOS5 for with/wihtout IOMMU
supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
helper function.

This set is base on exynos-drm-fixes branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com


Reviewed-by: Aaron Plattner aplatt...@nvidia.com

I also verified that this reduces my 2025-entry sg_table to 6 entries, so

Tested-by: Aaron Plattner aplatt...@nvidia.com

--
Aaron


---
  drivers/gpu/drm/drm_prime.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..072ee08 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -217,21 +217,17 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
  struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
  {
struct sg_table *sg = NULL;
-   struct scatterlist *iter;
-   int i;
int ret;

sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!sg)
goto out;

-   ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
+   ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
+   nr_pages  PAGE_SHIFT, GFP_KERNEL);
if (ret)
goto out;

-   for_each_sg(sg-sgl, iter, nr_pages, i)
-   sg_set_page(iter, pages[i], PAGE_SIZE, 0);
-
return sg;
  out:
kfree(sg);



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