ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution

2013-03-04 Thread Toralf Förster 
It is a (small) regression to 3.7.10 with intel integrated graphics i915
- but nevertheless :

With an external VGA display (1680x1050) and a closed internal LVDS1
display (1440x900) the external display starts X11 with 1440x900 - for
kernel 3.7.x.

With 3.8.2 (and .1) now the external display is driven with just 800x600.


-- 
MfG/Sincerely
Toralf F?rster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

nouveau lockdep splat

2013-03-04 Thread Borislav Petkov 
New -rc1, so let the stabilization games begin.

I see the following on rc1, let me know if you need more info.


[0.633617] =
[0.633618] [ INFO: possible recursive locking detected ]
[0.633618] 3.9.0-rc1 #2 Not tainted
[0.633619] -
[0.633619] swapper/0/1 is trying to acquire lock:
[0.633623]  (>lock){+.+...}, at: [] 
evo_wait+0x43/0xf0
[0.633624] 
[0.633624] but task is already holding lock:
[0.633626]  (>lock){+.+...}, at: [] 
evo_wait+0x43/0xf0
[0.633626] 
[0.633626] other info that might help us debug this:
[0.633626]  Possible unsafe locking scenario:
[0.633626] 
[0.633626]CPU0
[0.633627]
[0.633627]   lock(>lock);
[0.633628]   lock(>lock);
[0.633628] 
[0.633628]  *** DEADLOCK ***
[0.633628] 
[0.633628]  May be due to missing lock nesting notation
[0.633628] 
[0.633629] 10 locks held by swapper/0/1:
[0.633632]  #0:  (&__lockdep_no_validate__){..}, at: 
[] __driver_attach+0x5b/0xb0
[0.633633]  #1:  (&__lockdep_no_validate__){..}, at: 
[] __driver_attach+0x69/0xb0
[0.633636]  #2:  (drm_global_mutex){+.+.+.}, at: [] 
drm_get_pci_dev+0xc6/0x2d0
[0.633640]  #3:  (registration_lock){+.+.+.}, at: [] 
register_framebuffer+0x25/0x310
[0.633642]  #4:  (_info->lock){+.+.+.}, at: [] 
lock_fb_info+0x26/0x60
[0.633644]  #5:  (console_lock){+.+.+.}, at: [] 
register_framebuffer+0x1ba/0x310
[0.633646]  #6:  ((fb_notifier_list).rwsem){.+.+.+}, at: 
[] __blocking_notifier_call_chain+0x42/0x80
[0.633648]  #7:  (>mode_config.mutex){+.+.+.}, at: 
[] drm_modeset_lock_all+0x2a/0x70
[0.633650]  #8:  (>mutex){+.+.+.}, at: [] 
drm_modeset_lock_all+0x54/0x70
[0.633652]  #9:  (>lock){+.+...}, at: [] 
evo_wait+0x43/0xf0
[0.633652] 
[0.633652] stack backtrace:
[0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
[0.633654] Call Trace:
[0.633656]  [] __lock_acquire+0x76b/0x1c20
[0.633658]  [] ? dcb_table+0x1ac/0x2a0
[0.633659]  [] ? evo_wait+0x43/0xf0
[0.633660]  [] lock_acquire+0x8a/0x120
[0.633662]  [] ? evo_wait+0x43/0xf0
[0.633664]  [] ? mutex_lock_nested+0x292/0x330
[0.633665]  [] mutex_lock_nested+0x6e/0x330
[0.633667]  [] ? evo_wait+0x43/0xf0
[0.633668]  [] ? __mutex_unlock_slowpath+0xc7/0x150
[0.633669]  [] evo_wait+0x43/0xf0
[0.633671]  [] nv50_display_flip_next+0x749/0x7d0
[0.633672]  [] ? evo_kick+0x37/0x40
[0.633674]  [] nv50_crtc_commit+0x10e/0x230
[0.633676]  [] drm_crtc_helper_set_mode+0x365/0x510
[0.633677]  [] drm_crtc_helper_set_config+0xa4e/0xb70
[0.633679]  [] drm_mode_set_config_internal+0x31/0x70
[0.633680]  [] drm_fb_helper_set_par+0x71/0xf0
[0.633682]  [] fbcon_init+0x514/0x5a0
[0.633683]  [] visual_init+0xbc/0x120
[0.633685]  [] do_bind_con_driver+0x163/0x320
[0.633686]  [] do_take_over_console+0x61/0x70
[0.633687]  [] do_fbcon_takeover+0x63/0xc0
[0.633689]  [] fbcon_event_notify+0x5fd/0x700
[0.633690]  [] notifier_call_chain+0x4d/0x70
[0.633691]  [] __blocking_notifier_call_chain+0x58/0x80
[0.633692]  [] blocking_notifier_call_chain+0x16/0x20
[0.633694]  [] fb_notifier_call_chain+0x1b/0x20
[0.633695]  [] register_framebuffer+0x1c8/0x310
[0.633696]  [] drm_fb_helper_initial_config+0x371/0x520
[0.633697]  [] ? 
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.633700]  [] ? kmem_cache_alloc_trace+0xee/0x150
[0.633701]  [] nouveau_fbcon_init+0x10e/0x160
[0.633703]  [] nouveau_drm_load+0x40a/0x5d0
[0.633705]  [] ? device_register+0x1e/0x30
[0.633706]  [] ? drm_sysfs_device_add+0x86/0xb0
[0.633708]  [] drm_get_pci_dev+0x186/0x2d0
[0.633710]  [] ? __pci_set_master+0x2b/0x90
[0.633711]  [] nouveau_drm_probe+0x26a/0x2c0
[0.633713]  [] ? pci_match_device+0xd5/0xe0
[0.633714]  [] pci_device_probe+0x136/0x150
[0.633715]  [] driver_probe_device+0x76/0x210
[0.633716]  [] __driver_attach+0xab/0xb0
[0.633717]  [] ? driver_probe_device+0x210/0x210
[0.633718]  [] bus_for_each_dev+0x5d/0xa0
[0.633719]  [] driver_attach+0x1e/0x20
[0.633720]  [] bus_add_driver+0x111/0x280
[0.633722]  [] ? ttm_init+0x62/0x62
[0.633724]  [] driver_register+0x77/0x170
[0.633725]  [] ? ttm_init+0x62/0x62
[0.633726]  [] __pci_register_driver+0x64/0x70
[0.633728]  [] drm_pci_init+0x115/0x130
[0.633729]  [] ? ttm_init+0x62/0x62
[0.633730]  [] ? ttm_init+0x62/0x62
[0.633731]  [] nouveau_drm_init+0x4d/0x4f
[0.633732]  [] do_one_initcall+0x122/0x170
[0.633734]  [] kernel_init_freeable+0x108/0x197
[0.633735]  [] ? do_early_param+0x8c/0x8c
[0.633737]  [] ? rest_init+0xe0/0xe0
[0.633738]  [] kernel_init+0xe/0xf0
[0.633740]  [] ret_from_fork+0x7c/0xb0
[0.633741]  [] ? rest_init+0xe0/0xe0

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under

[Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3

2013-03-04 Thread Rodrigo Vivi 
Yeah, I completely agree with you. This is the reason of that
separated 2 lines patch 8/8.

On Mon, Mar 4, 2013 at 8:27 PM, Daniel Vetter  wrote:
> On Thu, Feb 28, 2013 at 08:02:18PM +0200, Ville Syrj?l? wrote:
>> On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote:
>> > Hi
>> >
>> > 2013/2/25 Rodrigo Vivi :
>> > > PSR is an eDP feature that allows power saving even with static image at 
>> > > eDP screen.
>> > >
>> > > v3: Accepted many suggestions that I received at v2 review, fixing, 
>> > > cleaning and improving the code.
>> > >
>> > > v2: Main differences in this v2:
>> > > - Created vbt struct to get i915 dev_priv more organized and to avoid 
>> > > adding more stuff into it.
>> > > - migrated hsw macros to use transcoder instead of pipes than I could 
>> > > address eDP
>> > > - remove patch that was only adding edp psr registers and added them on 
>> > > demand
>> > >
>> > > v1:
>> > > Shobit Kumar has implemented this patch series some time ago, but had no 
>> > > eDP panel with PSR capability to test them.
>> > >
>> > > I could test and verify that this series fully identify PSR capability 
>> > > and enables it at HSW.
>> > > I also verified that it saves from 0.5-1W but only when in blank screen. 
>> > > It seems it is not really entering in sleeping mode with static image at 
>> > > eDP screen yet.
>> >
>> > What do you mean with "blank screen"? It seems we disable PSR before
>> > blanking the screen, so the 0.5-1W saving could be from the backlight.
>> > Did you try masking more bits on the SRD_DEBUG register to see if it
>> > enters PSR more easily? The first test I'd try would be to set 1 to
>> > all those mask regs and see what happens (maybe we'll enter PSR and
>> > never ever leave it again?).
>>
>> One thing I'm wondering if we can even enable PSR w/o implementing the
>> FBC tracking bits. I mean what happens if someone renders to the front
>> buffer while PSR is active?
>
> This is actually my main concern with PSR enabling - our current FBC code
> is broken, and historically the hw is not one iota better :( Worst case we
> need to manually detect frontbuffer rendering and disable PSR ...
>
> Imo this needs to be resolved before we can enable PSR by default
> anywhere.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br

[PATCH] drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

2013-03-04 Thread Marek Olšák 
The MIP_ADDRESS state has 2 meanings. If the texture has one sample
per pixel, it's a pointer to the mipmap chain. If the texture has
multiple samples per pixel, it's a pointer to FMASK, a metadata buffer
needed for reading compressed MSAA textures. AFAIK, the mipmap
alignment rules do not apply to FMASK.

Marek

On Mon, Mar 4, 2013 at 6:50 PM, Paul Menzel
 wrote:
> Am Montag, den 04.03.2013, 11:13 -0500 schrieb Alex Deucher:
>> On Fri, Mar 1, 2013 at 7:40 AM, Marek Ol??k  wrote:
>> > Signed-off-by: Marek Ol??k 
>>
>> Added to my -fixes queue.
>
> Too few information in my opinion as to why this change was made. Please
> be strict with that.
>
>
> Thanks,
>
> Paul

[Bug 53111] vgaswitcheroo not working anymore

2013-03-04 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=53111


Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org




--- Comment #11 from Florian Mickler   2013-03-04 
21:28:06 ---
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit 43a23aa450cc19fe8996caf09e7e21ae5f6e56e8
Author: Alex Deucher 
Date:   Tue Feb 19 12:55:52 2013 -0500

drm/radeon: properly validate the atpx interface

-- 
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 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

2013-03-04 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=44341


Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org




--- Comment #12 from Florian Mickler   2013-03-04 
21:23:54 ---
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit c944b2abb067130542055666f23409fd5e1afc8e
Author: Alex Deucher 
Date:   Tue Feb 12 08:39:10 2013 -0500

drm/radeon: remove overzealous warning in hdmi handling

-- 
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] drm/nouveau/core: fix spelling mistake in comment

2013-03-04 Thread Lijo Antony 
Signed-off-by: Lijo Antony 
---
 drivers/gpu/drm/nouveau/core/core/client.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/client.c 
b/drivers/gpu/drm/nouveau/core/core/client.c
index 295c221..d0f6b9d 100644
--- a/drivers/gpu/drm/nouveau/core/core/client.c
+++ b/drivers/gpu/drm/nouveau/core/core/client.c
@@ -69,7 +69,7 @@ nouveau_client_create_(const char *name, u64 devname, const 
char *cfg,
if (ret)
return ret;

-   /* prevent init/fini being called, os in in charge of this */
+   /* prevent init/fini being called, os is in charge of this */
atomic_set(_object(client)->usecount, 2);

nouveau_object_ref(device, >device);
-- 
1.7.10.4

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

2013-03-04 Thread Martin Peres 
Hi Konrad,

On 04/03/2013 19:40, Konrad Rzeszutek Wilk wrote:> After git merge 
ab7826595e9ec51a51f622c5fc91e2f59440481a
 > (Merge tag 'mfd-3.9-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)
 > the nouveau driver ends up shutting of the machine when booting.
 >
 >
 > I hadn't done a git bisection yet and was wondering if there are some
 > juice commits I ought to look at?

Sure, no need to bisect, it is a new (apparently-broken-for-you) feature.

The code is in /drivers/gpu/drm/nouveau/core/subdev/therm/


 >
 > Here is the serial console:


 > [6.940628] nouveau  [  PTHERM][:00:0d.0] Thermal management: 
disabled
 > [6.957474] nouveau  [  PTHERM][:00:0d.0] programmed 
thresholds [ 90(2), 95(3), 145(2), 135(5) ]
 > [6.966594] nouveau 6.975100] nouveau  [ 
PTHERM][:00:0d.0] Thermal management: automatic
 > [6.982059] nouveau  [  PTHERM][:00:0d.0] temperature (88 C) 
hit the 'downclock' threshold
 > [6.990680] nouveau  [  PTHERM][:00:0d.0] temperature (88 C) 
hit the 'critical' threshold
 > [6.999194] nouveau  [  PTHERM][:00:0d.0] temperature (90 C) 
hit the 'shutdown' threshold

See, this is strange. If I believe the "programmed thresholds" line, the 
fanboost threshold is at 90?C, downclock is at 95?C, critical 
temperature is at 145?C and shutdown is at 135?C.
So, from the BIOS side, things seem to be in fairly good shape (critical 
should be lower than shutdown, but that's OK).

My theory is that your temperature sensor is very variable that would 
set off the shutdown alarm. So, either the sensor needs more settling 
time or the output is genuinely very variable.

In the first case, we could fix that by increasing the settling time (at 
the expense of a longer boot period). We could also for a 10s wait at 
boot time before reading temperature.
If this is the latter case, we only have the solution to average the 
temperature on several samples. I would need statistics on the 
variability in order to calculate a proper low-pass filter that wouldn't 
be too slow or too RAM/wakeup-intensive.

I really hope the problem is the settling time!


Here is what you can do to test the theory:

Change the mdelay at line 41 of 
/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c 
(http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c#n41)
 
from 10 to 1000.
Please also add an mdelay of 1000 between lines 44 and 45.

If it works with this patch, then try decreasing the delay to 20ms.

In any way, I'll send some thermal patches tonight to be more resistant 
to long settling times.

Thanks for reporting!

Martin (mupuf)

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

2013-03-04 Thread Rahul Sharma 
Thanks Sean,

On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul  wrote:
> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma  
> wrote:
>> Right now hdmiphy operations and configs are kept inside hdmi driver. 
>> hdmiphy related
>> code is tightly coupled with hdmi ip driver. Physicaly they are different 
>> devices and
>
> s/Physicaly/Physically/
>
>> should be instantiated independently.
>>
>> In terms of versions/mapping/configurations Hdmi and hdmiphy are independent 
>> of each
>> other. It is preferred to isolate them and maintained independently.
>>
>> This implementations is tested for:
>> 1) Resolutions supported by exynos4 and 5 hdmi.
>> 2) Runtime PM and S2R scenarions for exynos5.
>>
>
> I don't like the idea of spawning off yet another driver in here. It
> adds more globals, more suspend/resume ordering issues, and more
> implicit dependencies. I understand, however, that this is the Chosen
> Way for the exynos driver, so I will save my rant.
>

I agree to it. splitting phy to a new driver will complicate the power related
scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of
config values, mapping (i2c/platform bus) etc. Handling this diversity
inside hdmi driver is complicating it with unrelated changes.

I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock
we should re-factor this by explicitly calling power related callbacks
of mixer, phy,
hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf
device. AFAIR something like this is already in place in chrome-kernel.

> I've made some comments below.
>
>> This patch is dependent on
>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg34733.html
>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg34861.html
>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg34862.html
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>> It is based on exynos-drm-next-todo branch at
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   8 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   6 +
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |  58 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  11 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++--
>>  drivers/gpu/drm/exynos/exynos_hdmi.h |   1 -
>>  drivers/gpu/drm/exynos/exynos_hdmiphy.c  | 586 
>> ++-
>>  drivers/gpu/drm/exynos/regs-hdmiphy.h|  61 
>>  8 files changed, 738 insertions(+), 368 deletions(-)
>>  create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 3da5c2d..03acb6b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -334,6 +334,11 @@ static int __init exynos_drm_init(void)
>> ret = platform_driver_register(_driver);
>> if (ret < 0)
>> goto out_hdmi;
>> +
>> +   ret = exynos_hdmiphy_driver_register();
>
> Not sure why you need to obfuscate the type of driver here. All the
> other ones are directly registered as platform drivers, I don't see
> the harm in just doing the i2c_add_driver directly here.
>

AIMB, Phy is likely to get mapped as a platform device in later soc's.
I want to make driver registration (inside exynos_drm_drv.c) independent
of this changes. We can handle this inside exynos_hdmiphy_driver_register().

>> +   if (ret < 0)
>> +   goto out_hdmiphy;
>> +
>> ret = platform_driver_register(_driver);
>> if (ret < 0)
>> goto out_mixer;
>
>
> I think this ordering is how you plan on enforcing the suspend/resume
> order for hdmi/mixer/hdmiphy. In that case, however, I don't think it
> makes sense to suspend/resume hdmiphy in between mixer and hdmi.
> Ideally, hdmiphy should go down first and come up last.
>

I just wanted to keep, hdmi and hdmiphy things together. But what you said
above makes sense. I will do that change.

>
>> @@ -436,6 +441,8 @@ out_common_hdmi_dev:
>>  out_common_hdmi:
>> platform_driver_unregister(_driver);
>>  out_mixer:
>> +   exynos_hdmiphy_driver_unregister();
>> +out_hdmiphy:
>> platform_driver_unregister(_driver);
>>  out_hdmi:
>>  #endif
>> @@ -479,6 +486,7 @@ static void __exit exynos_drm_exit(void)
>> exynos_platform_device_hdmi_unregister();
>> platform_driver_unregister(_drm_common_hdmi_driver);
>> platform_driver_unregister(_driver);
>> +   exynos_hdmiphy_driver_unregister();
>> platform_driver_unregister(_driver);
>>  #endif
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 4606fac..17c53e3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -325,6 +325,12 @@ void exynos_drm_subdrv_close(struct

[PATCH] drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

2013-03-04 Thread Paul Menzel 
Am Montag, den 04.03.2013, 11:13 -0500 schrieb Alex Deucher:
> On Fri, Mar 1, 2013 at 7:40 AM, Marek Ol??k  wrote:
> > Signed-off-by: Marek Ol??k 
> 
> Added to my -fixes queue.

Too few information in my opinion as to why this change was made. Please
be strict with that.


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130304/184f278d/attachment.pgp>

[PATCH v5 4/9] video: Add generic HDMI infoframe helpers

2013-03-04 Thread Ville Syrjälä 
On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
> Add generic helpers to pack HDMI infoframes into binary buffers.
> 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v2:
> - add support for audio, vendor-specific and SPD infoframes
> - add various validity checks on infoframes
> - factor out checksum computation
> 
> Changes in v3:
> - introduce HDMI_INFOFRAME_HEADER_SIZE
> - fix SPD infoframe SDI field offset
> 
> Changes in v4:
> - remove needless checks for input parameters
> - use memcpy() instead of manual copy loop
> - update SPD SPI enum to include HD-DVD and PMP as per CEA-861-E
> - add audio coding type extension support
> - match audio coding type names to those in CEA-861-E
> 
>  drivers/video/Kconfig  |   3 +
>  drivers/video/Makefile |   1 +
>  drivers/video/hdmi.c   | 308 
> +
>  include/linux/hdmi.h   | 231 +
>  4 files changed, 543 insertions(+)
>  create mode 100644 drivers/video/hdmi.c
>  create mode 100644 include/linux/hdmi.h
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 09f1a18..b11eeab 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -52,6 +52,9 @@ config OF_VIDEOMODE
>   help
> helper to get videomodes from the devicetree
>  
> +config HDMI
> + bool
> +
>  menuconfig FB
>   tristate "Support for frame buffer devices"
>   ---help---
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index f592f3b..0b50082 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -5,6 +5,7 @@
>  # Each configuration option enables a list of files.
>  
>  obj-$(CONFIG_VGASTATE)+= vgastate.o
> +obj-$(CONFIG_HDMI)+= hdmi.o
>  obj-y += fb_notify.o
>  obj-$(CONFIG_FB)  += fb.o
>  fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> new file mode 100644
> index 000..ab23c9b
> --- /dev/null
> +++ b/drivers/video/hdmi.c
> @@ -0,0 +1,308 @@
> +/*
> + * Copyright (C) 2012 Avionic Design GmbH
> + *
> + * 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.
> + */

BTW was there any discussion about the license? drm is generally MIT.
Are people OK with depending on GPL code for infoframe support?

-- 
Ville Syrj?l?
Intel OTC

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

2013-03-04 Thread Konrad Rzeszutek Wilk 
On Mon, Mar 04, 2013 at 08:21:48PM +0100, Martin Peres wrote:
> Hi Konrad,
> 
> On 04/03/2013 19:40, Konrad Rzeszutek Wilk wrote:> After git merge
> ab7826595e9ec51a51f622c5fc91e2f59440481a
> > (Merge tag 'mfd-3.9-1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)
> > the nouveau driver ends up shutting of the machine when booting.
> >
> >
> > I hadn't done a git bisection yet and was wondering if there are some
> > juice commits I ought to look at?
> 
> Sure, no need to bisect, it is a new (apparently-broken-for-you) feature.
> 
> The code is in /drivers/gpu/drm/nouveau/core/subdev/therm/
> 
> 
> >
> > Here is the serial console:
> 
> 
> > [6.940628] nouveau  [  PTHERM][:00:0d.0] Thermal
> management: disabled
> > [6.957474] nouveau  [  PTHERM][:00:0d.0] programmed
> thresholds [ 90(2), 95(3), 145(2), 135(5) ]
> > [6.966594] nouveau 6.975100] nouveau  [
> PTHERM][:00:0d.0] Thermal management: automatic
> > [6.982059] nouveau  [  PTHERM][:00:0d.0] temperature (88
> C) hit the 'downclock' threshold
> > [6.990680] nouveau  [  PTHERM][:00:0d.0] temperature (88
> C) hit the 'critical' threshold
> > [6.999194] nouveau  [  PTHERM][:00:0d.0] temperature (90
> C) hit the 'shutdown' threshold
> 
> See, this is strange. If I believe the "programmed thresholds" line,
> the fanboost threshold is at 90?C, downclock is at 95?C, critical
> temperature is at 145?C and shutdown is at 135?C.
> So, from the BIOS side, things seem to be in fairly good shape
> (critical should be lower than shutdown, but that's OK).
> 
> My theory is that your temperature sensor is very variable that
> would set off the shutdown alarm. So, either the sensor needs more
> settling time or the output is genuinely very variable.

You should see it when I boot it under Xen:

[8.427789] nouveau  [  PTHERM][:00:0d.0] programmed thresholds [ 90(2), 
95(3), 145(2), 135(5) ]^M^M
[8.427855] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'fanboost' threshold^M^M
[8.427919] nouveau  [  PTHERM][:00:0d.0] Thermal management: 
automatic^M^M
[8.427973] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'downclock' threshold^M^M
[8.428036] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'critical' threshold^M^M
[8.428099] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'shutdown' threshold^M^M

> 
> In the first case, we could fix that by increasing the settling time
> (at the expense of a longer boot period). We could also for a 10s
> wait at boot time before reading temperature.
> If this is the latter case, we only have the solution to average the
> temperature on several samples. I would need statistics on the
> variability in order to calculate a proper low-pass filter that
> wouldn't be too slow or too RAM/wakeup-intensive.
> 
> I really hope the problem is the settling time!
> 
> 
> Here is what you can do to test the theory:
> 
> Change the mdelay at line 41 of
> /drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c 
> (http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c#n41)
> from 10 to 1000.
> Please also add an mdelay of 1000 between lines 44 and 45.

Let me do that tomorrow and report my findings.
> 
> If it works with this patch, then try decreasing the delay to 20ms.
> 
> In any way, I'll send some thermal patches tonight to be more
> resistant to long settling times.

Pls CC me in case you would like me also to test them with the
mdelay patch.

> 
> Thanks for reporting!

Of course.
> 
> Martin (mupuf)
> 
>

[PATCH v5 4/9] video: Add generic HDMI infoframe helpers

2013-03-04 Thread Thierry Reding 
On Mon, Mar 04, 2013 at 04:49:46PM +0200, Ville Syrj?l? wrote:
> On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > new file mode 100644
> > index 000..ab23c9b
> > --- /dev/null
> > +++ b/drivers/video/hdmi.c
> > @@ -0,0 +1,308 @@
> > +/*
> > + * Copyright (C) 2012 Avionic Design GmbH
> > + *
> > + * 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.
> > + */
> 
> BTW was there any discussion about the license? drm is generally MIT.
> Are people OK with depending on GPL code for infoframe support?

I wasn't aware of that. I don't know how much of an issue it is really
since all symbols are exported non-GPL.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130304/f10ffb95/attachment.pgp>

3.9-rc1 boot warning at drivers/gpu/drm/i915/intel_dp.c:1121 ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()

2013-03-04 Thread Greg KH 
Hi Daniel,

On 3.9-rc1, I get the following warning on my MacBook Pro Retina.

Graphics still seem to work ok, but I think that's because it's really
using the nouveau driver instead of the intel driver (so David says).

Anything I can do to test to try to fix this?

thanks,

greg k-h



[6.000101] Console: switching to colour frame buffer device 360x112
[6.006662] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[6.006664] nouveau :01:00.0: registered panic notifier
[6.006668] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on 
minor 0
[6.006756] snd_hda_intel :01:00.1: enabling device ( -> 0002)
[6.006838] hda_intel: Disabling MSI
[6.006868] hda-intel :01:00.1: Handle VGA-switcheroo audio client
[6.007848] [drm] Memory usable by graphics device = 2048M
[6.007867] i915 :00:02.0: setting latency timer to 64
[6.031217] usb 2-1.8.1.2: USB disconnect, device number 7
[6.043198] i915 :00:02.0: irq 49 for MSI/MSI-X
[6.043204] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[6.043222] [drm] Driver supports precise vblank timestamp query.
[6.043228] i915 :00:02.0: Invalid ROM contents
[6.043232] [drm] failed to find VBIOS tables
[6.043271] vga_switcheroo: enabled
[6.043307] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none
[6.043314] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[6.070805] [drm] failed to retrieve link info, disabling eDP
[6.070840] [ cut here ]
[6.070870] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1121 
ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()
[6.070878] Hardware name: MacBookPro10,1
[6.070882] Modules linked in: btusb bluetooth nls_cp437 vfat fat arc4 b43 
ssb pcmcia pcmcia_core mac80211 cfg80211 rfkill joydev iTCO_wdt bcm5974 
iTCO_vendor_support applesmc input_polldev snd_hda_codec_cirrus coretemp 
kvm_intel kvm acpi_cpufreq crc32c_intel mperf ghash_clmulni_intel evdev 
aesni_intel xts aes_x86_64 lrw gf128mul ablk_helper cryptd microcode pcspkr 
i2c_i801(+) apple_gmux snd_hda_intel(+) i915(+) sdhci_pci lpc_ich snd_hda_codec 
bcma nouveau sdhci mfd_core snd_hwdep mmc_core mxm_wmi wmi ttm intel_agp 
snd_pcm intel_gtt i2c_algo_bit drm_kms_helper snd_page_alloc snd_timer snd 
soundcore drm video battery apple_bl mei processor ac button
[6.071025] Pid: 123, comm: systemd-udevd Tainted: GW3.9.0-rc1 
#100
[6.071031] Call Trace:
[6.071038]  [] warn_slowpath_common+0x7f/0xc0
[6.071045]  [] warn_slowpath_null+0x1a/0x20
[6.071063]  [] ironlake_panel_vdd_off_sync+0xef/0x100 
[i915]
[6.071079]  [] intel_dp_encoder_destroy+0x64/0x70 [i915]
[6.071095]  [] intel_dp_init_connector+0xa76/0xa90 [i915]
[6.071107]  [] ? drm_modeset_unlock_all+0x52/0x60 [drm]
[6.071122]  [] intel_dp_init+0x106/0x140 [i915]
[6.071138]  [] intel_modeset_init+0xbf9/0xea0 [i915]
[6.071154]  [] i915_driver_load+0xb59/0xde0 [i915]
[6.071176]  [] drm_get_pci_dev+0x186/0x2c0 [drm]
[6.071192]  [] i915_pci_probe+0x3c/0x90 [i915]
[6.071201]  [] local_pci_probe+0x4b/0x80
[6.071211]  [] pci_device_probe+0x111/0x120
[6.071219]  [] driver_probe_device+0x7b/0x240
[6.071225]  [] __driver_attach+0xab/0xb0
[6.071232]  [] ? driver_probe_device+0x240/0x240
[6.071239]  [] bus_for_each_dev+0x5d/0xa0
[6.071246]  [] driver_attach+0x1e/0x20
[6.071253]  [] bus_add_driver+0x10e/0x270
[6.071260]  [] ? 0xa0462fff
[6.071267]  [] driver_register+0x77/0x170
[6.071273]  [] ? tracepoint_module_notify+0x117/0x220
[6.071281]  [] ? 0xa0462fff
[6.071287]  [] __pci_register_driver+0x4b/0x50
[6.071297]  [] drm_pci_init+0x11a/0x130 [drm]
[6.071304]  [] ? 0xa0462fff
[6.071319]  [] i915_init+0x66/0x68 [i915]
[6.071325]  [] do_one_initcall+0x12a/0x180
[6.071334]  [] load_module+0x1a47/0x24b0
[6.071340]  [] ? sys_getegid16+0x50/0x50
[6.071349]  [] sys_init_module+0xa6/0xd0
[6.071356]  [] system_call_fastpath+0x1a/0x1f
[6.071362] ---[ end trace 138aae7ee5fa912d ]---
[6.370967] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[6.371243] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[6.371504] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
[6.644053] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
[6.657295] i915 :00:02.0: No connectors reported connected with modes
[6.657302] [drm] Cannot find any crtc or sizes - going 1024x768
[6.659683] i915 :00:02.0: fb1: inteldrmfb frame buffer device
[6.660364] [Firmware Bug]: ACPI(GFX0) defines _DOD but not _DOS
[6.661371] ACPI: Video Device [GFX0] (multi-head: yes

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel

2013-03-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=61747

--- Comment #7 from Alex Deucher  ---
(In reply to comment #6)
> (In reply to comment #5)
> > Can you bisect mesa?
> 
> I'm not sure that makes sense. The crashes started after Fedora upgraded its
> 3.7.9 kernel to one based on 3.8.1, and so I have no idea if there's even a
> "good" commit in Mesa to start bisecting from.

I'm guessing the kernel update enabled some additional feature in mesa (htile
or async/cp dma support).  Does disabling htile support help?  Set env var
R600_HYPERZ=0

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

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel

2013-03-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=61747

--- Comment #6 from Chris Rankin  ---
(In reply to comment #5)
> Can you bisect mesa?

I'm not sure that makes sense. The crashes started after Fedora upgraded its
3.7.9 kernel to one based on 3.8.1, and so I have no idea if there's even a
"good" commit in Mesa to start bisecting from.

-- 
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/20130304/44ca0890/attachment-0001.html>

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel

2013-03-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=61747

--- Comment #5 from Alex Deucher  ---
Can you bisect mesa?

-- 
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/20130304/88960a70/attachment.html>

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

2013-03-04 Thread Konrad Rzeszutek Wilk 
After git merge ab7826595e9ec51a51f622c5fc91e2f59440481a
(Merge tag 'mfd-3.9-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)
the nouveau driver ends up shutting of the machine when booting.


I hadn't done a git bisection yet and was wondering if there are some
juice commits I ought to look at?

Here is the serial console:


????????
Loading 
latest/initramfs.cpio.gz..ready.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.8.0upstream-10478-g31c7742-dirty (konrad at 
build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 
SMP Sun Mar 3 18:09:03 EST 2013
[0.00] Command line: initrd=latest/initramfs.cpio.gz zcache nofb debug 
selinux=0 console=ttyS0,115200 loglevel=10 apic=debug BOOT_IMAGE=latest/vmlinuz 
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable
[0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xb7ed] usable
[0.00] BIOS-e820: [mem 0xb7ee-0xb7ee2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xb7ee3000-0xb7ee] ACPI data
[0.00] BIOS-e820: [mem 0xb7ef-0xb7ef] reserved
[0.00] BIOS-e820: [mem 0xb800-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: BIOSTAR Group N61PB-M2S/N61PB-M2S, BIOS 6.00 PG 09/03/2009
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C7FFF write-protect
[0.00]   C8000-F uncachable
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask C000 write-back
[0.00]   2 base 0001 mask C000 write-back
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00014000 aka 5120M
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820: update [mem 0xc000-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xb7ee0 max_arch_pfn = 0x4
[0.00] Scan for SMP in [mem 0x-0x03ff]
[0.00] Scan for SMP in [mem 0x0009fc00-0x0009]
[0.00] Scan for SMP in [mem 0x000f-0x000f]
[0.00] found SMP MP-table at [mem 0x000f3a30-0x000f3a3f] mapped at 
[880f3a30]
[0.00]   mpc: f1f44-f2088
[0.00] Scanning 1 areas for low memory corruption
[0.00] ACPI: RSDP 000f7e60 00014 (v00 Nvidia)
[0.00] ACPI: RSDT b7ee3000 00038 (v01 Nvidia NVDAACPI 42302E31 
NVDA )
[0.00] ACPI: FACP b7ee3080 00074 (v01 Nvidia NVDAACPI 42302E31 
NVDA )
[0.00] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has 
zero address or length: 0x/0x1 (20130117/tbfadt-599)
[0.00] ACPI:

[PATCH] ARM: dts: moving dt binding documents for video devices to common place

2013-03-04 Thread Grant Likely 
On Wed, 06 Feb 2013 09:51:39 -0500, Rahul Sharma  
wrote:
> Binding Documents for drm-devices are placed in
> Documentation/devicetree/bindings/drm/*. But these devices are common
> for v4l framework, hence moved to a common place at
> Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to
> associate them with exynos soc series.
> 
> Signed-off-by: Rahul Sharma 

Applied, thanks.

A tip however, if you use the "-M" flag when posting patches it will
show the files as moved instead of delete the old copy and create a new.
It makes my life easier when that is done.

g.

[PATCH] drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

2013-03-04 Thread Alex Deucher 
On Fri, Mar 1, 2013 at 7:40 AM, Marek Ol??k  wrote:
> Signed-off-by: Marek Ol??k 

Added to my -fixes queue.

Alex

> ---
>  drivers/gpu/drm/radeon/evergreen_cs.c |2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c   |3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index d8f5d5f..a759a3d 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -834,7 +834,7 @@ static int evergreen_cs_track_validate_texture(struct 
> radeon_cs_parser *p,
>  __func__, __LINE__, toffset, surf.base_align);
> return -EINVAL;
> }
> -   if (moffset & (surf.base_align - 1)) {
> +   if (surf.nsamples <= 1 && moffset & (surf.base_align - 1)) {
> dev_warn(p->dev, "%s:%d mipmap bo base %ld not aligned with 
> %ld\n",
>  __func__, __LINE__, moffset, surf.base_align);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 1677584..66a7f0f 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -70,9 +70,10 @@
>   *   2.27.0 - r600-SI: Add CS ioctl support for async DMA
>   *   2.28.0 - r600-eg: Add MEM_WRITE packet support
>   *   2.29.0 - R500 FP16 color clear registers
> + *   2.30.0 - fix for FMASK texturing
>   */
>  #define KMS_DRIVER_MAJOR   2
> -#define KMS_DRIVER_MINOR   29
> +#define KMS_DRIVER_MINOR   30
>  #define KMS_DRIVER_PATCHLEVEL  0
>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>  int radeon_driver_unload_kms(struct drm_device *dev);
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2] drm/edid: kernel-doc minimal cleanup

2013-03-04 Thread Nishanth Menon 
On 18:09-20130302, Paul Menzel wrote:
> Am Freitag, den 01.03.2013, 08:00 -0600 schrieb Nishanth Menon:
> > Some basic cleanups for kernel-doc errors or missing documentation
> > parameters.
> 
> Nishanth, thanks for doing that!
glad to be of help.
> 
> > index c194f4e..bd864b5 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -982,14 +982,14 @@ EXPORT_SYMBOL(drm_edid_is_valid);
> >  
> >  #define DDC_SEGMENT_ADDR 0x30
> >  /**
> > - * Get EDID information via I2C.
> > - *
> > - * \param adapter : i2c device adaptor
> > - * \param buf : EDID data buffer to be filled
> > - * \param len : EDID data buffer length
> > - * \return 0 on success or -1 on failure.
> > + * drm_do_probe_ddc_edid() - Get EDID information via I2C.
> 
> Some already existing entries do not use ?()? behind the function name
> in the comment. Not sure what the correct way is though.
I followed the format as in:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-doc-nano-HOWTO.txt#n55

That said, I might suggest someone more knowledgable than I look through
the drm_edid.c - there seems to be code alignment issues etc which I did
not fix up. running Lindent quickly shows:
http://pastebin.com/vaYFQDHv
-- 
Regards,
Nishanth Menon

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

2013-03-04 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=50091





--- Comment #29 from Dzianis Kahanovich   2013-03-04 
09:53:24 ---
(In reply to comment #28)
> That's a separate issue and has nothing to do with this bug.
> See https://bugs.freedesktop.org/show_bug.cgi?id=47182
> In most cases, it is no bug at all.
OK, I just suggested since new DRI code not detect this misalignment - it can
be sources of this bug, this is just visual differences.

-- 
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 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

2013-03-04 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=50091





--- Comment #29 from Dzianis Kahanovich maha...@bspu.unibel.by  2013-03-04 
09:53:24 ---
(In reply to comment #28)
 That's a separate issue and has nothing to do with this bug.
 See https://bugs.freedesktop.org/show_bug.cgi?id=47182
 In most cases, it is no bug at all.
OK, I just suggested since new DRI code not detect this misalignment - it can
be sources of this bug, this is just visual differences.

-- 
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

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel

2013-03-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=61747

--- Comment #5 from Alex Deucher ag...@yahoo.com ---
Can you bisect mesa?

-- 
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 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel

2013-03-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=61747

--- Comment #6 from Chris Rankin ranki...@googlemail.com ---
(In reply to comment #5)
 Can you bisect mesa?

I'm not sure that makes sense. The crashes started after Fedora upgraded its
3.7.9 kernel to one based on 3.8.1, and so I have no idea if there's even a
good commit in Mesa to start bisecting from.

-- 
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 v5 4/9] video: Add generic HDMI infoframe helpers

2013-03-04 Thread Ville Syrjälä 
On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
 Add generic helpers to pack HDMI infoframes into binary buffers.
 
 Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
 ---
 Changes in v2:
 - add support for audio, vendor-specific and SPD infoframes
 - add various validity checks on infoframes
 - factor out checksum computation
 
 Changes in v3:
 - introduce HDMI_INFOFRAME_HEADER_SIZE
 - fix SPD infoframe SDI field offset
 
 Changes in v4:
 - remove needless checks for input parameters
 - use memcpy() instead of manual copy loop
 - update SPD SPI enum to include HD-DVD and PMP as per CEA-861-E
 - add audio coding type extension support
 - match audio coding type names to those in CEA-861-E
 
  drivers/video/Kconfig  |   3 +
  drivers/video/Makefile |   1 +
  drivers/video/hdmi.c   | 308 
 +
  include/linux/hdmi.h   | 231 +
  4 files changed, 543 insertions(+)
  create mode 100644 drivers/video/hdmi.c
  create mode 100644 include/linux/hdmi.h
 
 diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
 index 09f1a18..b11eeab 100644
 --- a/drivers/video/Kconfig
 +++ b/drivers/video/Kconfig
 @@ -52,6 +52,9 @@ config OF_VIDEOMODE
   help
 helper to get videomodes from the devicetree
  
 +config HDMI
 + bool
 +
  menuconfig FB
   tristate Support for frame buffer devices
   ---help---
 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index f592f3b..0b50082 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -5,6 +5,7 @@
  # Each configuration option enables a list of files.
  
  obj-$(CONFIG_VGASTATE)+= vgastate.o
 +obj-$(CONFIG_HDMI)+= hdmi.o
  obj-y += fb_notify.o
  obj-$(CONFIG_FB)  += fb.o
  fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
 diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
 new file mode 100644
 index 000..ab23c9b
 --- /dev/null
 +++ b/drivers/video/hdmi.c
 @@ -0,0 +1,308 @@
 +/*
 + * Copyright (C) 2012 Avionic Design GmbH
 + *
 + * 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.
 + */

BTW was there any discussion about the license? drm is generally MIT.
Are people OK with depending on GPL code for infoframe support?

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

Re: [PATCH v5 4/9] video: Add generic HDMI infoframe helpers

2013-03-04 Thread Thierry Reding 
On Mon, Mar 04, 2013 at 04:49:46PM +0200, Ville Syrjälä wrote:
 On Fri, Feb 22, 2013 at 08:03:26AM +0100, Thierry Reding wrote:
[...]
  diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
  new file mode 100644
  index 000..ab23c9b
  --- /dev/null
  +++ b/drivers/video/hdmi.c
  @@ -0,0 +1,308 @@
  +/*
  + * Copyright (C) 2012 Avionic Design GmbH
  + *
  + * 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.
  + */
 
 BTW was there any discussion about the license? drm is generally MIT.
 Are people OK with depending on GPL code for infoframe support?

I wasn't aware of that. I don't know how much of an issue it is really
since all symbols are exported non-GPL.

Thierry


pgpGPAGsnjlc5.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel

2013-03-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=61747

--- Comment #7 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #6)
 (In reply to comment #5)
  Can you bisect mesa?
 
 I'm not sure that makes sense. The crashes started after Fedora upgraded its
 3.7.9 kernel to one based on 3.8.1, and so I have no idea if there's even a
 good commit in Mesa to start bisecting from.

I'm guessing the kernel update enabled some additional feature in mesa (htile
or async/cp dma support).  Does disabling htile support help?  Set env var
R600_HYPERZ=0

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

Re: [PATCH] drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

2013-03-04 Thread Alex Deucher 
On Fri, Mar 1, 2013 at 7:40 AM, Marek Olšák mar...@gmail.com wrote:
 Signed-off-by: Marek Olšák mar...@gmail.com

Added to my -fixes queue.

Alex

 ---
  drivers/gpu/drm/radeon/evergreen_cs.c |2 +-
  drivers/gpu/drm/radeon/radeon_drv.c   |3 ++-
  2 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index d8f5d5f..a759a3d 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -834,7 +834,7 @@ static int evergreen_cs_track_validate_texture(struct 
 radeon_cs_parser *p,
  __func__, __LINE__, toffset, surf.base_align);
 return -EINVAL;
 }
 -   if (moffset  (surf.base_align - 1)) {
 +   if (surf.nsamples = 1  moffset  (surf.base_align - 1)) {
 dev_warn(p-dev, %s:%d mipmap bo base %ld not aligned with 
 %ld\n,
  __func__, __LINE__, moffset, surf.base_align);
 return -EINVAL;
 diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
 b/drivers/gpu/drm/radeon/radeon_drv.c
 index 1677584..66a7f0f 100644
 --- a/drivers/gpu/drm/radeon/radeon_drv.c
 +++ b/drivers/gpu/drm/radeon/radeon_drv.c
 @@ -70,9 +70,10 @@
   *   2.27.0 - r600-SI: Add CS ioctl support for async DMA
   *   2.28.0 - r600-eg: Add MEM_WRITE packet support
   *   2.29.0 - R500 FP16 color clear registers
 + *   2.30.0 - fix for FMASK texturing
   */
  #define KMS_DRIVER_MAJOR   2
 -#define KMS_DRIVER_MINOR   29
 +#define KMS_DRIVER_MINOR   30
  #define KMS_DRIVER_PATCHLEVEL  0
  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
  int radeon_driver_unload_kms(struct drm_device *dev);
 --
 1.7.10.4

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

[PATCH] drm/nouveau/core: fix spelling mistake in comment

2013-03-04 Thread Lijo Antony 
Signed-off-by: Lijo Antony lijo.ker...@gmail.com
---
 drivers/gpu/drm/nouveau/core/core/client.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/client.c 
b/drivers/gpu/drm/nouveau/core/core/client.c
index 295c221..d0f6b9d 100644
--- a/drivers/gpu/drm/nouveau/core/core/client.c
+++ b/drivers/gpu/drm/nouveau/core/core/client.c
@@ -69,7 +69,7 @@ nouveau_client_create_(const char *name, u64 devname, const 
char *cfg,
if (ret)
return ret;
 
-   /* prevent init/fini being called, os in in charge of this */
+   /* prevent init/fini being called, os is in charge of this */
atomic_set(nv_object(client)-usecount, 2);
 
nouveau_object_ref(device, client-device);
-- 
1.7.10.4

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

Re: [PATCH] drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

2013-03-04 Thread Paul Menzel 
Am Montag, den 04.03.2013, 11:13 -0500 schrieb Alex Deucher:
 On Fri, Mar 1, 2013 at 7:40 AM, Marek Olšák mar...@gmail.com wrote:
  Signed-off-by: Marek Olšák mar...@gmail.com
 
 Added to my -fixes queue.

Too few information in my opinion as to why this change was made. Please
be strict with that.


Thanks,

Paul


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

Re: nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

2013-03-04 Thread Martin Peres 

Hi Konrad,

On 04/03/2013 19:40, Konrad Rzeszutek Wilk wrote: After git merge 
ab7826595e9ec51a51f622c5fc91e2f59440481a
 (Merge tag 'mfd-3.9-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)

 the nouveau driver ends up shutting of the machine when booting.


 I hadn't done a git bisection yet and was wondering if there are some
 juice commits I ought to look at?

Sure, no need to bisect, it is a new (apparently-broken-for-you) feature.

The code is in /drivers/gpu/drm/nouveau/core/subdev/therm/



 Here is the serial console:


 [6.940628] nouveau  [  PTHERM][:00:0d.0] Thermal management: 
disabled
 [6.957474] nouveau  [  PTHERM][:00:0d.0] programmed 
thresholds [ 90(2), 95(3), 145(2), 135(5) ]
 [6.966594] nouveau 6.975100] nouveau  [ 
PTHERM][:00:0d.0] Thermal management: automatic
 [6.982059] nouveau  [  PTHERM][:00:0d.0] temperature (88 C) 
hit the 'downclock' threshold
 [6.990680] nouveau  [  PTHERM][:00:0d.0] temperature (88 C) 
hit the 'critical' threshold
 [6.999194] nouveau  [  PTHERM][:00:0d.0] temperature (90 C) 
hit the 'shutdown' threshold


See, this is strange. If I believe the programmed thresholds line, the 
fanboost threshold is at 90°C, downclock is at 95°C, critical 
temperature is at 145°C and shutdown is at 135°C.
So, from the BIOS side, things seem to be in fairly good shape (critical 
should be lower than shutdown, but that's OK).


My theory is that your temperature sensor is very variable that would 
set off the shutdown alarm. So, either the sensor needs more settling 
time or the output is genuinely very variable.


In the first case, we could fix that by increasing the settling time (at 
the expense of a longer boot period). We could also for a 10s wait at 
boot time before reading temperature.
If this is the latter case, we only have the solution to average the 
temperature on several samples. I would need statistics on the 
variability in order to calculate a proper low-pass filter that wouldn't 
be too slow or too RAM/wakeup-intensive.


I really hope the problem is the settling time!


Here is what you can do to test the theory:

Change the mdelay at line 41 of 
/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c 
(http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c#n41) 
from 10 to 1000.

Please also add an mdelay of 1000 between lines 44 and 45.

If it works with this patch, then try decreasing the delay to 20ms.

In any way, I'll send some thermal patches tonight to be more resistant 
to long settling times.


Thanks for reporting!

Martin (mupuf)


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

Re: [PATCH] drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK

2013-03-04 Thread Marek Olšák 
The MIP_ADDRESS state has 2 meanings. If the texture has one sample
per pixel, it's a pointer to the mipmap chain. If the texture has
multiple samples per pixel, it's a pointer to FMASK, a metadata buffer
needed for reading compressed MSAA textures. AFAIK, the mipmap
alignment rules do not apply to FMASK.

Marek

On Mon, Mar 4, 2013 at 6:50 PM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Am Montag, den 04.03.2013, 11:13 -0500 schrieb Alex Deucher:
 On Fri, Mar 1, 2013 at 7:40 AM, Marek Olšák mar...@gmail.com wrote:
  Signed-off-by: Marek Olšák mar...@gmail.com

 Added to my -fixes queue.

 Too few information in my opinion as to why this change was made. Please
 be strict with that.


 Thanks,

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

nouveau lockdep splat

2013-03-04 Thread Borislav Petkov 
New -rc1, so let the stabilization games begin.

I see the following on rc1, let me know if you need more info.


[0.633617] =
[0.633618] [ INFO: possible recursive locking detected ]
[0.633618] 3.9.0-rc1 #2 Not tainted
[0.633619] -
[0.633619] swapper/0/1 is trying to acquire lock:
[0.633623]  (dmac-lock){+.+...}, at: [8141bb53] 
evo_wait+0x43/0xf0
[0.633624] 
[0.633624] but task is already holding lock:
[0.633626]  (dmac-lock){+.+...}, at: [8141bb53] 
evo_wait+0x43/0xf0
[0.633626] 
[0.633626] other info that might help us debug this:
[0.633626]  Possible unsafe locking scenario:
[0.633626] 
[0.633626]CPU0
[0.633627]
[0.633627]   lock(dmac-lock);
[0.633628]   lock(dmac-lock);
[0.633628] 
[0.633628]  *** DEADLOCK ***
[0.633628] 
[0.633628]  May be due to missing lock nesting notation
[0.633628] 
[0.633629] 10 locks held by swapper/0/1:
[0.633632]  #0:  (__lockdep_no_validate__){..}, at: 
[8143375b] __driver_attach+0x5b/0xb0
[0.633633]  #1:  (__lockdep_no_validate__){..}, at: 
[81433769] __driver_attach+0x69/0xb0
[0.633636]  #2:  (drm_global_mutex){+.+.+.}, at: [8135a8f6] 
drm_get_pci_dev+0xc6/0x2d0
[0.633640]  #3:  (registration_lock){+.+.+.}, at: [812c8e75] 
register_framebuffer+0x25/0x310
[0.633642]  #4:  (fb_info-lock){+.+.+.}, at: [812c7d86] 
lock_fb_info+0x26/0x60
[0.633644]  #5:  (console_lock){+.+.+.}, at: [812c900a] 
register_framebuffer+0x1ba/0x310
[0.633646]  #6:  ((fb_notifier_list).rwsem){.+.+.+}, at: 
[810694d2] __blocking_notifier_call_chain+0x42/0x80
[0.633648]  #7:  (dev-mode_config.mutex){+.+.+.}, at: 
[8135e63a] drm_modeset_lock_all+0x2a/0x70
[0.633650]  #8:  (crtc-mutex){+.+.+.}, at: [8135e664] 
drm_modeset_lock_all+0x54/0x70
[0.633652]  #9:  (dmac-lock){+.+...}, at: [8141bb53] 
evo_wait+0x43/0xf0
[0.633652] 
[0.633652] stack backtrace:
[0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
[0.633654] Call Trace:
[0.633656]  [8109524b] __lock_acquire+0x76b/0x1c20
[0.633658]  [8137f50c] ? dcb_table+0x1ac/0x2a0
[0.633659]  [8141bb53] ? evo_wait+0x43/0xf0
[0.633660]  [81096c6a] lock_acquire+0x8a/0x120
[0.633662]  [8141bb53] ? evo_wait+0x43/0xf0
[0.633664]  [815eaf52] ? mutex_lock_nested+0x292/0x330
[0.633665]  [815ead2e] mutex_lock_nested+0x6e/0x330
[0.633667]  [8141bb53] ? evo_wait+0x43/0xf0
[0.633668]  [815eb0b7] ? __mutex_unlock_slowpath+0xc7/0x150
[0.633669]  [8141bb53] evo_wait+0x43/0xf0
[0.633671]  [8141e569] nv50_display_flip_next+0x749/0x7d0
[0.633672]  [8141bc37] ? evo_kick+0x37/0x40
[0.633674]  [8141e7ee] nv50_crtc_commit+0x10e/0x230
[0.633676]  [8134c2a5] drm_crtc_helper_set_mode+0x365/0x510
[0.633677]  [8134d69e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.633679]  [8135f751] drm_mode_set_config_internal+0x31/0x70
[0.633680]  [8134b7a1] drm_fb_helper_set_par+0x71/0xf0
[0.633682]  [812d40e4] fbcon_init+0x514/0x5a0
[0.633683]  [8132cbdc] visual_init+0xbc/0x120
[0.633685]  [8132f293] do_bind_con_driver+0x163/0x320
[0.633686]  [8132f521] do_take_over_console+0x61/0x70
[0.633687]  [812d2703] do_fbcon_takeover+0x63/0xc0
[0.633689]  [812d63dd] fbcon_event_notify+0x5fd/0x700
[0.633690]  [815f23fd] notifier_call_chain+0x4d/0x70
[0.633691]  [810694e8] __blocking_notifier_call_chain+0x58/0x80
[0.633692]  [81069526] blocking_notifier_call_chain+0x16/0x20
[0.633694]  [812c787b] fb_notifier_call_chain+0x1b/0x20
[0.633695]  [812c9018] register_framebuffer+0x1c8/0x310
[0.633696]  [8134b4d1] drm_fb_helper_initial_config+0x371/0x520
[0.633697]  [8134a607] ? 
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.633700]  [81140a5e] ? kmem_cache_alloc_trace+0xee/0x150
[0.633701]  [8140578e] nouveau_fbcon_init+0x10e/0x160
[0.633703]  [813f5f8a] nouveau_drm_load+0x40a/0x5d0
[0.633705]  [81430cee] ? device_register+0x1e/0x30
[0.633706]  [8135c086] ? drm_sysfs_device_add+0x86/0xb0
[0.633708]  [8135a9b6] drm_get_pci_dev+0x186/0x2d0
[0.633710]  [812b0eab] ? __pci_set_master+0x2b/0x90
[0.633711]  [813f63ba] nouveau_drm_probe+0x26a/0x2c0
[0.633713]  [812b4f15] ? pci_match_device+0xd5/0xe0
[0.633714]  [812b5096] pci_device_probe+0x136/0x150
[0.633715]  [81433566] driver_probe_device+0x76/0x210
[0.633716]  [814337ab] __driver_attach+0xab/0xb0
[0.633717]

[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning

2013-03-04 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=44341


Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org




--- Comment #12 from Florian Mickler flor...@mickler.org  2013-03-04 21:23:54 
---
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit c944b2abb067130542055666f23409fd5e1afc8e
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Tue Feb 12 08:39:10 2013 -0500

drm/radeon: remove overzealous warning in hdmi handling

-- 
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

[Bug 53111] vgaswitcheroo not working anymore

2013-03-04 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=53111


Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org




--- Comment #11 from Florian Mickler flor...@mickler.org  2013-03-04 21:28:06 
---
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit 43a23aa450cc19fe8996caf09e7e21ae5f6e56e8
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Tue Feb 19 12:55:52 2013 -0500

drm/radeon: properly validate the atpx interface

-- 
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: nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

2013-03-04 Thread Konrad Rzeszutek Wilk 
On Mon, Mar 04, 2013 at 08:21:48PM +0100, Martin Peres wrote:
 Hi Konrad,
 
 On 04/03/2013 19:40, Konrad Rzeszutek Wilk wrote: After git merge
 ab7826595e9ec51a51f622c5fc91e2f59440481a
  (Merge tag 'mfd-3.9-1' of
 git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)
  the nouveau driver ends up shutting of the machine when booting.
 
 
  I hadn't done a git bisection yet and was wondering if there are some
  juice commits I ought to look at?
 
 Sure, no need to bisect, it is a new (apparently-broken-for-you) feature.
 
 The code is in /drivers/gpu/drm/nouveau/core/subdev/therm/
 
 
 
  Here is the serial console:
 
 
  [6.940628] nouveau  [  PTHERM][:00:0d.0] Thermal
 management: disabled
  [6.957474] nouveau  [  PTHERM][:00:0d.0] programmed
 thresholds [ 90(2), 95(3), 145(2), 135(5) ]
  [6.966594] nouveau 6.975100] nouveau  [
 PTHERM][:00:0d.0] Thermal management: automatic
  [6.982059] nouveau  [  PTHERM][:00:0d.0] temperature (88
 C) hit the 'downclock' threshold
  [6.990680] nouveau  [  PTHERM][:00:0d.0] temperature (88
 C) hit the 'critical' threshold
  [6.999194] nouveau  [  PTHERM][:00:0d.0] temperature (90
 C) hit the 'shutdown' threshold
 
 See, this is strange. If I believe the programmed thresholds line,
 the fanboost threshold is at 90°C, downclock is at 95°C, critical
 temperature is at 145°C and shutdown is at 135°C.
 So, from the BIOS side, things seem to be in fairly good shape
 (critical should be lower than shutdown, but that's OK).
 
 My theory is that your temperature sensor is very variable that
 would set off the shutdown alarm. So, either the sensor needs more
 settling time or the output is genuinely very variable.

You should see it when I boot it under Xen:

[8.427789] nouveau  [  PTHERM][:00:0d.0] programmed thresholds [ 90(2), 
95(3), 145(2), 135(5) ]^M^M
[8.427855] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'fanboost' threshold^M^M
[8.427919] nouveau  [  PTHERM][:00:0d.0] Thermal management: 
automatic^M^M
[8.427973] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'downclock' threshold^M^M
[8.428036] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'critical' threshold^M^M
[8.428099] nouveau  [  PTHERM][:00:0d.0] temperature (222 C) hit the 
'shutdown' threshold^M^M

 
 In the first case, we could fix that by increasing the settling time
 (at the expense of a longer boot period). We could also for a 10s
 wait at boot time before reading temperature.
 If this is the latter case, we only have the solution to average the
 temperature on several samples. I would need statistics on the
 variability in order to calculate a proper low-pass filter that
 wouldn't be too slow or too RAM/wakeup-intensive.
 
 I really hope the problem is the settling time!
 
 
 Here is what you can do to test the theory:
 
 Change the mdelay at line 41 of
 /drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c 
 (http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c#n41)
 from 10 to 1000.
 Please also add an mdelay of 1000 between lines 44 and 45.

Let me do that tomorrow and report my findings.
 
 If it works with this patch, then try decreasing the delay to 20ms.
 
 In any way, I'll send some thermal patches tonight to be more
 resistant to long settling times.

Pls CC me in case you would like me also to test them with the
mdelay patch.

 
 Thanks for reporting!

Of course.
 
 Martin (mupuf)
 
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution

2013-03-04 Thread Toralf Förster 
It is a (small) regression to 3.7.10 with intel integrated graphics i915
- but nevertheless :

With an external VGA display (1680x1050) and a closed internal LVDS1
display (1440x900) the external display starts X11 with 1440x900 - for
kernel 3.7.x.

With 3.8.2 (and .1) now the external display is driven with just 800x600.


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm-intel tree with Linus' tree

2013-03-04 Thread Stephen Rothwell 
Hi all,

Today's linux-next merge of the drm-intel tree got conflicts in
drivers/gpu/drm/i915/intel_hdmi.c and drivers/gpu/drm/i915/intel_sdvo.c
between commit 18316c8c39a8 (drm: Remove duplicate drm_mode_cea_vic())
from Linus' tree and commit 4f3a8bc7ba6e (drm/i915: rename some HDMI bit
definitions) from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_hdmi.c
index fa8ec4a,4d222ec..000
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@@ -781,8 -777,8 +777,8 @@@ bool intel_hdmi_mode_fixup(struct drm_e
if (intel_hdmi-color_range_auto) {
/* See CEA-861-E - 5.1 Default Encoding Parameters */
if (intel_hdmi-has_hdmi_sink 
 -  drm_mode_cea_vic(adjusted_mode)  1)
 +  drm_match_cea_mode(adjusted_mode)  1)
-   intel_hdmi-color_range = SDVO_COLOR_RANGE_16_235;
+   intel_hdmi-color_range = HDMI_COLOR_RANGE_16_235;
else
intel_hdmi-color_range = 0;
}
diff --cc drivers/gpu/drm/i915/intel_sdvo.c
index d07a8cd,63dcb76..000
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@@ -1076,9 -1076,11 +1076,11 @@@ static bool intel_sdvo_mode_fixup(struc
  
if (intel_sdvo-color_range_auto) {
/* See CEA-861-E - 5.1 Default Encoding Parameters */
+   /* FIXME: This bit is only valid when using TMDS encoding and 8
+* bit per color mode. */
if (intel_sdvo-has_hdmi_monitor 
 -  drm_mode_cea_vic(adjusted_mode)  1)
 +  drm_match_cea_mode(adjusted_mode)  1)
-   intel_sdvo-color_range = SDVO_COLOR_RANGE_16_235;
+   intel_sdvo-color_range = HDMI_COLOR_RANGE_16_235;
else
intel_sdvo-color_range = 0;
}


pgpsz_fPQphbf.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3

2013-03-04 Thread Daniel Vetter 
On Thu, Feb 28, 2013 at 08:02:18PM +0200, Ville Syrjälä wrote:
 On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote:
  Hi
  
  2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com:
   PSR is an eDP feature that allows power saving even with static image at 
   eDP screen.
  
   v3: Accepted many suggestions that I received at v2 review, fixing, 
   cleaning and improving the code.
  
   v2: Main differences in this v2:
   - Created vbt struct to get i915 dev_priv more organized and to avoid 
   adding more stuff into it.
   - migrated hsw macros to use transcoder instead of pipes than I could 
   address eDP
   - remove patch that was only adding edp psr registers and added them on 
   demand
  
   v1:
   Shobit Kumar has implemented this patch series some time ago, but had no 
   eDP panel with PSR capability to test them.
  
   I could test and verify that this series fully identify PSR capability 
   and enables it at HSW.
   I also verified that it saves from 0.5-1W but only when in blank screen. 
   It seems it is not really entering in sleeping mode with static image at 
   eDP screen yet.
  
  What do you mean with blank screen? It seems we disable PSR before
  blanking the screen, so the 0.5-1W saving could be from the backlight.
  Did you try masking more bits on the SRD_DEBUG register to see if it
  enters PSR more easily? The first test I'd try would be to set 1 to
  all those mask regs and see what happens (maybe we'll enter PSR and
  never ever leave it again?).
 
 One thing I'm wondering if we can even enable PSR w/o implementing the
 FBC tracking bits. I mean what happens if someone renders to the front
 buffer while PSR is active?

This is actually my main concern with PSR enabling - our current FBC code
is broken, and historically the hw is not one iota better :( Worst case we
need to manually detect frontbuffer rendering and disable PSR ...

Imo this needs to be resolved before we can enable PSR by default
anywhere.
-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: [Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3

2013-03-04 Thread Rodrigo Vivi 
Yeah, I completely agree with you. This is the reason of that
separated 2 lines patch 8/8.

On Mon, Mar 4, 2013 at 8:27 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Feb 28, 2013 at 08:02:18PM +0200, Ville Syrjälä wrote:
 On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote:
  Hi
 
  2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com:
   PSR is an eDP feature that allows power saving even with static image at 
   eDP screen.
  
   v3: Accepted many suggestions that I received at v2 review, fixing, 
   cleaning and improving the code.
  
   v2: Main differences in this v2:
   - Created vbt struct to get i915 dev_priv more organized and to avoid 
   adding more stuff into it.
   - migrated hsw macros to use transcoder instead of pipes than I could 
   address eDP
   - remove patch that was only adding edp psr registers and added them on 
   demand
  
   v1:
   Shobit Kumar has implemented this patch series some time ago, but had no 
   eDP panel with PSR capability to test them.
  
   I could test and verify that this series fully identify PSR capability 
   and enables it at HSW.
   I also verified that it saves from 0.5-1W but only when in blank screen. 
   It seems it is not really entering in sleeping mode with static image at 
   eDP screen yet.
 
  What do you mean with blank screen? It seems we disable PSR before
  blanking the screen, so the 0.5-1W saving could be from the backlight.
  Did you try masking more bits on the SRD_DEBUG register to see if it
  enters PSR more easily? The first test I'd try would be to set 1 to
  all those mask regs and see what happens (maybe we'll enter PSR and
  never ever leave it again?).

 One thing I'm wondering if we can even enable PSR w/o implementing the
 FBC tracking bits. I mean what happens if someone renders to the front
 buffer while PSR is active?

 This is actually my main concern with PSR enabling - our current FBC code
 is broken, and historically the hw is not one iota better :( Worst case we
 need to manually detect frontbuffer rendering and disable PSR ...

 Imo this needs to be resolved before we can enable PSR by default
 anywhere.
 -Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 ___
 Intel-gfx mailing list
 intel-...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

3.9-rc1 boot warning at drivers/gpu/drm/i915/intel_dp.c:1121 ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()

2013-03-04 Thread Greg KH 
Hi Daniel,

On 3.9-rc1, I get the following warning on my MacBook Pro Retina.

Graphics still seem to work ok, but I think that's because it's really
using the nouveau driver instead of the intel driver (so David says).

Anything I can do to test to try to fix this?

thanks,

greg k-h



[6.000101] Console: switching to colour frame buffer device 360x112
[6.006662] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[6.006664] nouveau :01:00.0: registered panic notifier
[6.006668] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on 
minor 0
[6.006756] snd_hda_intel :01:00.1: enabling device ( - 0002)
[6.006838] hda_intel: Disabling MSI
[6.006868] hda-intel :01:00.1: Handle VGA-switcheroo audio client
[6.007848] [drm] Memory usable by graphics device = 2048M
[6.007867] i915 :00:02.0: setting latency timer to 64
[6.031217] usb 2-1.8.1.2: USB disconnect, device number 7
[6.043198] i915 :00:02.0: irq 49 for MSI/MSI-X
[6.043204] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[6.043222] [drm] Driver supports precise vblank timestamp query.
[6.043228] i915 :00:02.0: Invalid ROM contents
[6.043232] [drm] failed to find VBIOS tables
[6.043271] vga_switcheroo: enabled
[6.043307] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none
[6.043314] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[6.070805] [drm] failed to retrieve link info, disabling eDP
[6.070840] [ cut here ]
[6.070870] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1121 
ironlake_panel_vdd_off_sync+0xef/0x100 [i915]()
[6.070878] Hardware name: MacBookPro10,1
[6.070882] Modules linked in: btusb bluetooth nls_cp437 vfat fat arc4 b43 
ssb pcmcia pcmcia_core mac80211 cfg80211 rfkill joydev iTCO_wdt bcm5974 
iTCO_vendor_support applesmc input_polldev snd_hda_codec_cirrus coretemp 
kvm_intel kvm acpi_cpufreq crc32c_intel mperf ghash_clmulni_intel evdev 
aesni_intel xts aes_x86_64 lrw gf128mul ablk_helper cryptd microcode pcspkr 
i2c_i801(+) apple_gmux snd_hda_intel(+) i915(+) sdhci_pci lpc_ich snd_hda_codec 
bcma nouveau sdhci mfd_core snd_hwdep mmc_core mxm_wmi wmi ttm intel_agp 
snd_pcm intel_gtt i2c_algo_bit drm_kms_helper snd_page_alloc snd_timer snd 
soundcore drm video battery apple_bl mei processor ac button
[6.071025] Pid: 123, comm: systemd-udevd Tainted: GW3.9.0-rc1 
#100
[6.071031] Call Trace:
[6.071038]  [81057dff] warn_slowpath_common+0x7f/0xc0
[6.071045]  [81057e5a] warn_slowpath_null+0x1a/0x20
[6.071063]  [a0402a1f] ironlake_panel_vdd_off_sync+0xef/0x100 
[i915]
[6.071079]  [a0403f44] intel_dp_encoder_destroy+0x64/0x70 [i915]
[6.071095]  [a0406c06] intel_dp_init_connector+0xa76/0xa90 [i915]
[6.071107]  [a00ae6e2] ? drm_modeset_unlock_all+0x52/0x60 [drm]
[6.071122]  [a0406d26] intel_dp_init+0x106/0x140 [i915]
[6.071138]  [a03fb299] intel_modeset_init+0xbf9/0xea0 [i915]
[6.071154]  [a03cb219] i915_driver_load+0xb59/0xde0 [i915]
[6.071176]  [a00aaa96] drm_get_pci_dev+0x186/0x2c0 [drm]
[6.071192]  [a03c650c] i915_pci_probe+0x3c/0x90 [i915]
[6.071201]  [812d3a6b] local_pci_probe+0x4b/0x80
[6.071211]  [812d4341] pci_device_probe+0x111/0x120
[6.071219]  [8138e7eb] driver_probe_device+0x7b/0x240
[6.071225]  [8138ea5b] __driver_attach+0xab/0xb0
[6.071232]  [8138e9b0] ? driver_probe_device+0x240/0x240
[6.071239]  [8138ca6d] bus_for_each_dev+0x5d/0xa0
[6.071246]  [8138e31e] driver_attach+0x1e/0x20
[6.071253]  [8138de1e] bus_add_driver+0x10e/0x270
[6.071260]  [a0463000] ? 0xa0462fff
[6.071267]  [8138f127] driver_register+0x77/0x170
[6.071273]  [810ebdf7] ? tracepoint_module_notify+0x117/0x220
[6.071281]  [a0463000] ? 0xa0462fff
[6.071287]  [812d443b] __pci_register_driver+0x4b/0x50
[6.071297]  [a00aacea] drm_pci_init+0x11a/0x130 [drm]
[6.071304]  [a0463000] ? 0xa0462fff
[6.071319]  [a0463066] i915_init+0x66/0x68 [i915]
[6.071325]  [8100215a] do_one_initcall+0x12a/0x180
[6.071334]  [810be087] load_module+0x1a47/0x24b0
[6.071340]  [810b9300] ? sys_getegid16+0x50/0x50
[6.071349]  [810beb96] sys_init_module+0xa6/0xd0
[6.071356]  [8156411d] system_call_fastpath+0x1a/0x1f
[6.071362] ---[ end trace 138aae7ee5fa912d ]---
[6.370967] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[6.371243] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[6.371504] input: HDA NVidia

Re: [PATCH V2] drm/edid: kernel-doc minimal cleanup

2013-03-04 Thread Nishanth Menon 
On 18:09-20130302, Paul Menzel wrote:
 Am Freitag, den 01.03.2013, 08:00 -0600 schrieb Nishanth Menon:
  Some basic cleanups for kernel-doc errors or missing documentation
  parameters.
 
 Nishanth, thanks for doing that!
glad to be of help.
 
  index c194f4e..bd864b5 100644
  --- a/drivers/gpu/drm/drm_edid.c
  +++ b/drivers/gpu/drm/drm_edid.c
  @@ -982,14 +982,14 @@ EXPORT_SYMBOL(drm_edid_is_valid);
   
   #define DDC_SEGMENT_ADDR 0x30
   /**
  - * Get EDID information via I2C.
  - *
  - * \param adapter : i2c device adaptor
  - * \param buf : EDID data buffer to be filled
  - * \param len : EDID data buffer length
  - * \return 0 on success or -1 on failure.
  + * drm_do_probe_ddc_edid() - Get EDID information via I2C.
 
 Some already existing entries do not use »()« behind the function name
 in the comment. Not sure what the correct way is though.
I followed the format as in:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-doc-nano-HOWTO.txt#n55

That said, I might suggest someone more knowledgable than I look through
the drm_edid.c - there seems to be code alignment issues etc which I did
not fix up. running Lindent quickly shows:
http://pastebin.com/vaYFQDHv
-- 
Regards,
Nishanth Menon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel