date:20140617

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

--- Comment #1 from Carlos Gomes  ---
$ glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile 
OpenGL version string: 2.1 Mesa 10.3.0-devel (git-6c2d815 trusty-oibaf-ppa)

$ DRI_PRIME=1 glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel
(git-6c2d815 trusty-oibaf-ppa)
OpenGL version string: 3.0 Mesa 10.3.0-devel (git-6c2d815 trusty-oibaf-ppa)

-- 
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/20140617/45edf783/attachment.html>

[PATCH] drm/nouveau: fix oops in display destructor with headless cards

2014-06-17 Thread Ben Skeggs

On Tue, Jun 17, 2014 at 11:01 PM, Maarten Lankhorst
 wrote:
> If init doesn't run then disp->outp might not be initialized, resulting in an 
> oops.
This can't actually happen (in the very least, it's not supposed
to)... What makes you think it can?

>
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
> index c41f656abe64..9c38c5e40500 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/base.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
> @@ -99,8 +99,10 @@ _nouveau_disp_dtor(struct nouveau_object *object)
>
> nouveau_event_destroy(&disp->vblank);
>
> -   list_for_each_entry_safe(outp, outt, &disp->outp, head) {
> -   nouveau_object_ref(NULL, (struct nouveau_object **)&outp);
> +   if (disp->outp.next) {
> +   list_for_each_entry_safe(outp, outt, &disp->outp, head) {
> +   nouveau_object_ref(NULL, (struct nouveau_object 
> **)&outp);
> +   }
> }
>
> nouveau_engine_destroy(&disp->base);
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 80172] New: Rendering an application with discrete card makes X crash with segfault

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

  Priority: medium
Bug ID: 80172
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Rendering an application with discrete card makes X
crash with segfault
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: cmalvesgomesreg at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 101278
  --> https://bugs.freedesktop.org/attachment.cgi?id=101278&action=edit
Xorg log

Hello, I am using Xubuntu 14.04 with Oibaf's PPA.

Let me know what I can do or if you need further information.

Regards,
Carlos

-- 
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/20140617/7cbfa723/attachment-0001.html>

[Bug 80162] center and lfe channels screwed up on suspend

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

--- Comment #1 from Alex Deucher  ---
AFAIK, video driver doesn't have anything to do with the mappings.  Does
forcing a modeset after resume help?  E.g., change the mode with xrandr and see
if that helps.  Maybe some of the AMD specific verbs in the hda driver need to
be reset?

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/10/AMD_HDA_verbs_v2.pdf

-- 
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/20140617/7596c872/attachment.html>

[Bug 78111] APU turbo core boost not working when radeon.dpm=1

2014-06-17 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #8 from Alex Deucher  ---
Does plugging/unplugging the AC adapter cause any problems with bapm enabled? 
The reason it was disabled on TN/RL parts is because there were hangs on some
systems when switching to/from AC power.

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

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

--- Comment #23 from Collin  ---
Created attachment 101268
  --> https://bugs.freedesktop.org/attachment.cgi?id=101268&action=edit
dmesg output

101191: testing patch fixes the DPM loop

-- 
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/20140617/190997cd/attachment.html>

Radeon drivers on PowerPC (e500)

2014-06-17 Thread Martyn Welch

Hi,

I've been asked to try and get a r600 based (E6460) graphics card 
running on a machine powered by a Freescale p4080 (e500 core). I've run 
into a bit of a problem.

I have the driver built into the kernel at this point. When I boot the 
card is detected and it seems to be finding the fimware (I'm also 
building in the required firmware blobs), but I get the following messages:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (CAICOS 0x1002:0x6763 0x1775:0xC6A7).
[drm] register mmio base: 0x1000
[drm] register mmio size: 131072
ATOM BIOS: GE
[drm] GPU not posted. posting now...
radeon :04:00.0: VRAM: 512M 0x - 0x1FFF 
(512M used)
radeon :04:00.0: GTT: 512M 0x2000 - 0x3FFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 338754 kiB
[TTM] Zone highmem: Available graphics memory: 994110 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :04:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] probing gen 2 caps for device 111d:808a = 2/0
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading CAICOS Microcode
__ioremap_caller(14, 4096, 4194304, c02eab20)__ioremap(): phys addr 
0x14 is RAM lr ttm_bo_kmap
radeon :04:00.0: disabling GPU acceleration
radeon :04:00.0: e957e400 unpin not necessary
radeon :04:00.0: e957e400 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD2
[drm]   HPD3
[drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY1
[drm] Connector 2:
[drm]   DVI-I-1
[drm]   HPD1
[drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[drm]   Encoders:
[drm] DFP3: INTERNAL_UNIPHY
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
__ioremap_caller(141000, 5242880, 4194304, c02eab20)__ioremap(): phys 
addr 0x141000 is RAM lr ttm_bo_kmap
[drm:radeonfb_create] *ERROR* failed to create fbcon object -12
[drm] Initialized radeon 2.29.0 20080528 for :04:00.0 on minor 0

There are failed attempts to ioremap RAM, initially as part of 
r600_vram_scratch_init() and again I guess mapping the GART?

On the e500, overlapping TLBs are not allowed and there is an explict 
check in arch/powerpc/mm/pgtable_32.c __ioremap_caller() to protect 
against ioremapping RAM that's already got TLB entries which is 
resulting in the error messages.

I'm out of ideas, any pointers or suggestions on how I might get this 
working? Has this ever been attempted before?

Martyn

-- 
Martyn Welch (Lead Software Engineer)  | Registered in England and Wales
GE Intelligent Platforms   | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch at ge.com  | VAT:GB 927559189

[Bug 80162] New: center and lfe channels screwed up on suspend

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

  Priority: medium
Bug ID: 80162
  Assignee: dri-devel at lists.freedesktop.org
   Summary: center and lfe channels screwed up on suspend
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pierre-bugzilla at ossman.eu
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Started out in the kernel bugzilla as I figured this was an alsa driver
problem:

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

> AMD HDMI audio output. Works fine until I suspend the machine. After resume, 
> center channel is silent and LFE channel is sent as center.
> 
> Massive issue as the center channel is the most used one of all in 
> multichannel audio sources. :/
> 
> Unloading just snd_hda_intel and reloading it seems to work around the issue.

The verdict there though was that it didn't seem like the audio end was doing
anything wrong, so it must be something in the graphics driver.

Help?

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

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

--- Comment #22 from Alex Deucher  ---
(In reply to comment #21)
> Second patch from Alex Deucher worked like a charm! 60FPS on TF2 and
> currently testing out L4D2 :D

Please attach your dmesg output.

-- 
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/20140617/54e4d46a/attachment.html>

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

2014-06-17 Thread Mikko Perttunen

On 06/17/2014 07:15 PM, Stephen Warren wrote:
> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>
>>> This binding looks quite anaemic vs.
>>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
>>> would expect that this binding needs all the EMC register data from the
>>> tegra20-emc binding too. Can the two bindings be identical?
>>
>> There's even less stuff needed right now, as all what ultimately the EMC
>> driver does is call clk_set_rate on the EMC clock. As the T124 EMC
>> driver gains more features, they should get more similar.
>
> IIRC, even changing the EMC clock rate requires modifying the memory
> controller's programming (e.g. delays/taps/tuning etc.). That's exactly
> what the more complex stuff in the nvidia,tegra20-emc.txt is all about.
> I not convinced that a driver that just modifies the clock rate without
> adjusting the EMC programming will work reliably.

Indeed, changing the EMC clock rate is a somewhat complicated sequence 
of ~10 steps. The kernel even won't let one the rate be change directly, 
as the change would be propagated to PLL_M which cannot have its rate 
changed while it is enabled. I suppose the sequence should be hidden in 
the EMC clk's set_rate implementation, which I guess would leave just 
the rate policy to this driver.

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

--- Comment #21 from Collin  ---
Second patch from Alex Deucher worked like a charm! 60FPS on TF2 and currently
testing out L4D2 :D

-- 
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/20140617/082d9e3a/attachment.html>

[PATCH 2/2] drm/radeon: Fix radeon_irq_kms_pflip_irq_get/put() imbalance

2014-06-17 Thread Michel Dänzer

From: Michel D?nzer 

Fixes a regression in 3.16-rc1 compared to 3.15.

The unbalanced calls would presumably result in the page flip interrupts
never getting disabled once they are enabled.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 97d7a80..8b575a4 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -359,7 +359,7 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
int crtc_id)

drm_vblank_put(rdev->ddev, radeon_crtc->crtc_id);
radeon_fence_unref(&work->fence);
-   radeon_irq_kms_pflip_irq_get(rdev, work->crtc_id);
+   radeon_irq_kms_pflip_irq_put(rdev, work->crtc_id);
queue_work(radeon_crtc->flip_queue, &work->unpin_work);
 }

-- 
2.0.0

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

2014-06-17 Thread Michel Dänzer

From: Michel D?nzer 

This reverts commit 75f36d861957cb05b7889af24c8cd4a789398304.

drm_vblank_get() is necessary to ensure the DRM vblank counter value is
up to date in drm_send_vblank_event().

Seems to fix weston hangs waiting for page flips to complete.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_display.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 2a8b9f1..97d7a80 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -357,6 +357,7 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
int crtc_id)

spin_unlock_irqrestore(&rdev->ddev->event_lock, flags);

+   drm_vblank_put(rdev->ddev, radeon_crtc->crtc_id);
radeon_fence_unref(&work->fence);
radeon_irq_kms_pflip_irq_get(rdev, work->crtc_id);
queue_work(radeon_crtc->flip_queue, &work->unpin_work);
@@ -459,6 +460,12 @@ static void radeon_flip_work_func(struct work_struct 
*__work)
base &= ~7;
}

+   r = drm_vblank_get(crtc->dev, radeon_crtc->crtc_id);
+   if (r) {
+   DRM_ERROR("failed to get vblank before flip\n");
+   goto pflip_cleanup;
+   }
+
/* We borrow the event spin lock for protecting flip_work */
spin_lock_irqsave(&crtc->dev->event_lock, flags);

@@ -473,6 +480,16 @@ static void radeon_flip_work_func(struct work_struct 
*__work)

return;

+pflip_cleanup:
+   if (unlikely(radeon_bo_reserve(work->new_rbo, false) != 0)) {
+   DRM_ERROR("failed to reserve new rbo in error path\n");
+   goto cleanup;
+   }
+   if (unlikely(radeon_bo_unpin(work->new_rbo) != 0)) {
+   DRM_ERROR("failed to unpin new rbo in error path\n");
+   }
+   radeon_bo_unreserve(work->new_rbo);
+
 cleanup:
drm_gem_object_unreference_unlocked(&work->old_rbo->gem_base);
radeon_fence_unref(&work->fence);
-- 
2.0.0

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

--- Comment #3 from Aaron B  ---
Created attachment 101259
  --> https://bugs.freedesktop.org/attachment.cgi?id=101259&action=edit
Dmesg output.

I'm adding it for 3.15, currently trying to get this kernel to crash. Give me
time I'll test down to 3.13 and see if it's in all of them, but I'll need time
to find out which crash. I believe this has been a problem since 3.13 IIRC.
Before 3.13, the card was basically unusable, though, so I'm not going to test
down below that.

-- 
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/20140617/6358d646/attachment-0001.html>

[PATCH 1/1] drm/exynos: Fix de-registration ordering

2014-06-17 Thread Sachin Kamat

'exynos_drm_pdev' was not getting unregistered if platform_driver_register()
failed. Fix the ordering to allow this. This also fixes the below warning by
moving the #endif macro. While at it also fix the ordering in the exit function
so that de-registration happens in opposite order of registration.
drivers/gpu/drm/exynos/exynos_drm_drv.c:768:1: warning: label 
?err_unregister_pd? defined but not used [-Wunused-label]

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5d225dd5..f72ca0c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -765,24 +765,24 @@ static int exynos_drm_init(void)

return 0;

-err_unregister_pd:
-   platform_device_unregister(exynos_drm_pdev);
-
 err_remove_vidi:
 #ifdef CONFIG_DRM_EXYNOS_VIDI
exynos_drm_remove_vidi();
+
+err_unregister_pd:
 #endif
+   platform_device_unregister(exynos_drm_pdev);

return ret;
 }

 static void exynos_drm_exit(void)
 {
+   platform_driver_unregister(&exynos_drm_platform_driver);
 #ifdef CONFIG_DRM_EXYNOS_VIDI
exynos_drm_remove_vidi();
 #endif
platform_device_unregister(exynos_drm_pdev);
-   platform_driver_unregister(&exynos_drm_platform_driver);
 }

 module_init(exynos_drm_init);
-- 
1.7.9.5

[REGRESSION] drm/g94/i2c: add aux channel interrupt driver

2014-06-17 Thread Maarten Lankhorst

Hey,

This patch causes a regression on my display-less nvd7.
Commenting out the aux, aux_stat and aux_mask members in nvd0_i2c_oclass fixes 
boot, and makes things work normally again.

broken dmesg:

[   40.314470] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - 
Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)
[   40.314729] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - 
Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)
[   40.314963] i915 :00:02.0: optimus capabilities: enabled, status dynamic 
power, 
[   40.315001] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)
[   40.315198] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)
[   40.315386] pci :01:00.0: optimus capabilities: enabled, status dynamic 
power, 
[   40.315392] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP 
handle
[   40.315652] nouveau D[ DRM] hdmi device not found 1 0 1
[   40.315695] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0d7000a2
[   40.315698] nouveau  [  DEVICE][:01:00.0] Chipset: GF117 (NVD7)
[   40.315700] nouveau  [  DEVICE][:01:00.0] Family : NVD0
[   40.315703] nouveau D[  DEVICE][:01:00.0] crystal freq: 27000KHz
[   40.315724] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[   40.315728] nouveau  [   VBIOS][:01:00.0] ... signature not found
[   40.315730] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[   40.315787] nouveau  [   VBIOS][:01:00.0] ... signature not found
[   40.315788] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[   40.361066] init: Failed to obtain startpar-bridge instance: Unknown 
parameter: INSTANCE
[   40.505222] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   41.547821] snd_hda_intel :00:1b.0: irq 47 for MSI/MSI-X
[   41.695435] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[   41.695441] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[   41.695539] nouveau  [   VBIOS][:01:00.0] BIT signature found
[   41.695543] nouveau  [   VBIOS][:01:00.0] version 75.17.53.00.12
[   41.695746] nouveau D[   VBIOS][:01:00.0] reset
[   41.695751] nouveau D[ DEVINIT][:01:00.0] reset
[   41.695753] nouveau  [   VBIOS][:01:00.0] running init tables
[   41.695884] nouveau D[ I2C][:01:00.0] PAD:X:03: -> PORT:03
[   41.697027] nouveau D[ I2C][:01:00.0] PAD:X:03: -> NULL
[   41.697030] nouveau D[ I2C][:01:00.0] PAD:X:03: -> PORT:03
[   41.698124] nouveau D[ I2C][:01:00.0] PAD:X:03: -> NULL
[   41.698126] nouveau D[ I2C][:01:00.0] PAD:X:03: -> PORT:03
[   41.699239] nouveau D[ I2C][:01:00.0] PAD:X:03: -> NULL
[   41.699242] nouveau D[ I2C][:01:00.0] PAD:X:03: -> PORT:03
[   41.700337] nouveau D[ I2C][:01:00.0] PAD:X:03: -> NULL
[   41.704845] sound hdaudioC0D0: autoconfig: line_outs=1 
(0x14/0x0/0x0/0x0/0x0) type:speaker
[   41.704848] sound hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   41.704850] sound hdaudioC0D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
[   41.704851] sound hdaudioC0D0:mono: mono_out=0x0
[   41.704852] sound hdaudioC0D0:inputs:
[   41.704854] sound hdaudioC0D0:  Mic=0x1a
[   41.704856] sound hdaudioC0D0:  Internal Mic=0x19
[   41.783610] nouveau D[GPIO][:01:00.0] reset
[   41.783616] nouveau D[ I2C][:01:00.0] PAD:X:03: -> NULL
[   41.783618] nouveau D[ I2C][:01:00.0] PAD:X:05: -> NULL
[   41.784591] nouveau D[ I2C][:01:00.0] reset
[   41.784596] nouveau D[ MXM][:01:00.0] no VBIOS data, nothing to do
[   41.784599] nouveau D[ MXM][:01:00.0] reset
[   41.784619] nouveau :01:00.0: irq 48 for MSI/MSI-X
[   41.784634] nouveau  [ PMC][:01:00.0] MSI interrupts enabled
[   41.784655] nouveau D[ PMC][:01:00.0] reset
[   41.784658] nouveau D[PBUS][:01:00.0] reset
[   41.784660] nouveau D[  PTIMER][:01:00.0] reset
[   41.784662] nouveau D[  PTIMER][:01:00.0] input frequency : 27000Hz
[   41.784663] nouveau D[  PTIMER][:01:00.0] input multiplier: 3
[   41.784665] nouveau D[  PTIMER][:01:00.0] numerator   : 0x0144
[   41.784666] nouveau D[  PTIMER][:01:00.0] denominator : 0x007d
[   41.784668] nouveau D[  PTIMER][:01:00.0] timer frequency : 31250Hz
[   41.784669] nouveau D[  PTIMER][:01:00.0] time low: 0x
[   41.784670] nouveau D[  PTIMER][:01:00.0] time high   : 0x
[   41.786060] nouveau D[ PFB][:01:00.0] 0x100800: 0x0001
[   41.786062] nouveau D[ PFB][:01:00.0] parts 0x mask 
0x
[   41.786074] nouveau W[ PFB][:01:00.0][0x][8800028d1000] 
reclocking of this ram type unsupported
[   41.786076] nouveau  [ PFB][:01:00.0] RAM type:

[Bug 78111] APU turbo core boost not working when radeon.dpm=1

2014-06-17 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #7 from Alex Deucher  ---
We can probably enable it by default on KV/KB systems at some point.  It had
some stability issues on trinity APUs so I disabled it across the board, so it
remains to be seen if there are any problems with newer APUs.

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

[PATCH 1/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

2014-06-17 Thread Bjorn Helgaas

On Mon, Jun 02, 2014 at 08:19:26PM +0200, Bruno Pr?mont wrote:
> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> systems that do not load shadow VBIOS or setup VGA get proper value for
> boot_vga PCI sysfs attribute on the corresponding PCI device.
> 
> Xorg is refusing to detect devices when boot_vga=0 which is the case on
> some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> the dri device but then bails out with "no devices detected".
> 
> Note: When vga_default_device() is set boot_vga PCI sysfs attribute
> reflects its state. When unset this attribute is 1 whenever
> IORESOURCE_ROM_SHADOW flag is set.
> 
> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting
> sysfb/efifb optional.
> 
> Remove the efifb implementation of vga_default_device() and initialize
> vgaarb's vga_default_device() with the PCI GPU that matches boot
> screen_info in pci_fixup_video().
> 
> Signed-off-by: Bruno Pr?mont 
> ---
>  arch/ia64/pci/fixup.c   | 21 +
>  arch/x86/include/asm/vga.h  |  6 --
>  arch/x86/pci/fixup.c| 21 +
>  drivers/video/fbdev/efifb.c | 38 --
>  4 files changed, 42 insertions(+), 44 deletions(-)

Something went wrong here.  It seems like the [2/2] patch should have
been [1/2], and this one should be [2/2].  And this one modifies both
arch/ia64/pci/fixup.c and arch/x86/pci/fixup.c, but the other patch
mostly combines them, so I don't see how this one applies.

And there were unrelated (trivial) changes to these files, so they
need to be rebased to v3.16-rc1.  I'd take care of the rebase, but
I don't understand the other stuff I mentioned.

Bjorn

> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
> index eee069a..9ed5bef 100644
> --- a/arch/ia64/pci/fixup.c
> +++ b/arch/ia64/pci/fixup.c
> @@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
>   return;
>   /* Maybe, this machine supports legacy memory map. */
>  
> + if (!vga_default_device()) {
> + resource_size_t start, end;
> + int i;
> +
> + /* Does firmware framebuffer belong to us? */
> + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> + continue;
> +
> + start = pci_resource_start(pdev, i);
> + end  = pci_resource_end(pdev, i);
> +
> + if (!start || !end)
> + continue;
> +
> + if (screen_info.lfb_base >= start &&
> + (screen_info.lfb_base + screen_info.lfb_size) < 
> end)
> + vga_set_default_device(pdev);
> + }
> + }
> +
>   /* Is VGA routed to us? */
>   bus = pdev->bus;
>   while (bus) {
> diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
> index 44282fb..c4b9dc2 100644
> --- a/arch/x86/include/asm/vga.h
> +++ b/arch/x86/include/asm/vga.h
> @@ -17,10 +17,4 @@
>  #define vga_readb(x) (*(x))
>  #define vga_writeb(x, y) (*(y) = (x))
>  
> -#ifdef CONFIG_FB_EFI
> -#define __ARCH_HAS_VGA_DEFAULT_DEVICE
> -extern struct pci_dev *vga_default_device(void);
> -extern void vga_set_default_device(struct pci_dev *pdev);
> -#endif
> -
>  #endif /* _ASM_X86_VGA_H */
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 94ae9ae..7246cf2 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -325,6 +325,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
>   struct pci_bus *bus;
>   u16 config;
>  
> + if (!vga_default_device()) {
> + resource_size_t start, end;
> + int i;
> +
> + /* Does firmware framebuffer belong to us? */
> + for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> + continue;
> +
> + start = pci_resource_start(pdev, i);
> + end  = pci_resource_end(pdev, i);
> +
> + if (!start || !end)
> + continue;
> +
> + if (screen_info.lfb_base >= start &&
> + (screen_info.lfb_base + screen_info.lfb_size) < 
> end)
> + vga_set_default_device(pdev);
> + }
> + }
> +
>   /* Is VGA routed to us? */
>   bus = pdev->bus;
>   while (bus) {
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index ae9618f..a033180 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -19,8 +19,6 @@
>  
>  static bool request_mem_succeeded = false;
>  
> -static struct pci_dev

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

--- Comment #2 from Alex Deucher  ---
Please attach your dmesg output.  What was the last kernel that was working
without problems?

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

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

Aaron B  changed:

   What|Removed |Added

Summary|Fails to page flip  |Fails to page flip multiple
   |multiple, queue overflows   |time, queue overflows
   |waiting for one to finish   |waiting for one to finish
   |that never does crashing|that never does crashing
   |entire system.  |entire system.

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

[Bug 76223] [radeonsi] luxmark segfault

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

--- Comment #8 from Aaron Watry  ---
Created attachment 101243
  --> https://bugs.freedesktop.org/attachment.cgi?id=101243&action=edit
Test Case for SLG InitFrameBuffer Kernel

I've tracked down where slg4 is segfaulting on my machine currently. The
InitFrameBuffer Kernel is not being compiled/invoked correctly. It's a very
simple kernel that works fine IF you split the kernel out on its own, but when
you embed the kernel within a large source file (~8600 lines), the compilation
process seems to break.

There's an #if 0 at line 44 of this test case that will, when flipped, show how
the kernel itself is fine, but the other non-invoked code causes it to break.

I'm assuming that we've got some buffer/iterator in clover or LLVM which is
breaking on large CL source files.

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

[PATCH v14 09/10] ARM: dts: mbimx51sd: Add display support.

2014-06-17 Thread Denis Carikli

On 06/16/2014 02:29 PM, Denis Carikli wrote:
[...]
> Which result at the lcd regulator being physically powered on at boot.
> I didn't see that because powering it on at boot is what I want.
I fixed that in imx-drm's parallel-display with another patch I just 
sent separately.

Denis.

[PATCH RESEND RESEND] drm/ttm: remove declaration of ttm_tt_cache_flush

2014-06-17 Thread Alexandre Courbot

ttm_tt_cache_flush's implementation was removed in 2009 by commit
c9c97b8c, but its declaration has been hiding in ttm_bo_driver.h since
then.

It has been surviving in the dark for too long now ; give it the mercy
blow.

Signed-off-by: Alexandre Courbot 
Reviewed-by: Thierry Reding 
Reviewed-by: David Herrmann 
---
 include/drm/ttm/ttm_bo_driver.h | 12 
 1 file changed, 12 deletions(-)

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 52fb709568fc..1cf69cbb1789 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -654,18 +654,6 @@ extern void ttm_tt_unbind(struct ttm_tt *ttm);
 extern int ttm_tt_swapin(struct ttm_tt *ttm);

 /**
- * ttm_tt_cache_flush:
- *
- * @pages: An array of pointers to struct page:s to flush.
- * @num_pages: Number of pages to flush.
- *
- * Flush the data of the indicated pages from the cpu caches.
- * This is used when changing caching attributes of the pages from
- * cache-coherent.
- */
-extern void ttm_tt_cache_flush(struct page *pages[], unsigned long num_pages);
-
-/**
  * ttm_tt_set_placement_caching:
  *
  * @ttm A struct ttm_tt the backing pages of which will change caching policy.
-- 
2.0.0

[PATCH] imx-drm: parallel-display: Fix DPMS default state.

2014-06-17 Thread Denis Carikli

If connector->dpms is left untouched, it defaults
to DRM_MODE_DPMS_ON (0).

As a result, drm_helper_connector_dpms will exit when
it will be asked to set the state to DRM_MODE_DPMS_ON,
because it is already set.

That issue prevented displays from turning on at boot.

Signed-off-by: Denis Carikli 
---
 drivers/staging/imx-drm/parallel-display.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index b567832..4ca61af 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -173,6 +173,13 @@ static int imx_pd_register(struct drm_device *drm,
if (ret)
return ret;

+   /* set the connector's dpms to OFF so that
+* drm_helper_connector_dpms() won't return
+* immediately since the current state is ON
+* at this point.
+*/
+   imxpd->connector.dpms = DRM_MODE_DPMS_OFF;
+
drm_encoder_helper_add(&imxpd->encoder, &imx_pd_encoder_helper_funcs);
drm_encoder_init(drm, &imxpd->encoder, &imx_pd_encoder_funcs,
 DRM_MODE_ENCODER_NONE);
-- 
1.7.9.5

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

--- Comment #20 from Collin  ---
(In reply to comment #19)
> Created attachment 101191 [details] [review]
> testing patch
> 
> Here's another kernel patch to try.  Please try this independent of any
> other patches on this bug.

First patch failed, gonna try out the second as soon as I start compiling a new
kernel.

-- 
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/20140617/9a4f8f12/attachment.html>

[Bug 80141] Fails to page flip multiple, queue overflows waiting for one to finish that never does crashing entire system.

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

--- Comment #1 from Aaron B  ---
Created attachment 101237
  --> https://bugs.freedesktop.org/attachment.cgi?id=101237&action=edit
My hardware info.

-- 
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/20140617/093f4705/attachment.html>

[Bug 80141] New: Fails to page flip multiple, queue overflows waiting for one to finish that never does crashing entire system.

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

Priority: medium
Bug ID: 80141
Assignee: dri-devel at lists.freedesktop.org
Summary: Fails to page flip multiple, queue overflows waiting
for one to finish that never does crashing entire
system.
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: aaronbottegal at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: unspecified
Component: DRM/Radeon
Product: DRI

Created attachment 101236
--> https://bugs.freedesktop.org/attachment.cgi?id=101236&action=edit
Xorg crash log of the system.

We have events pile up in the queue when the card becomes unresponsive. The
only place I've seen this happen besides one time in Counter Strike Source, are
youtube in Chromium running HTML5 video. More so when switching tabs to or from
the video when a lot of pixels on the screen changing. It does not have to be
rendering to crash, though, it happens off screen too. Otherwise no other
software triggers this bug nearly as consistently. I am attaching the XOrg
failure log. I'm on Mesa and firmware from the Oibaf PPA. 3.16-rc1 kernel, and
this is in every kernel for a while as far as I remember. From the log, you can
see the errors and how it says the queue overflows and the device is waiting
for something to happen, it more than likely is DRM related. The screen usually
goes out and stops rendering on the HDMI channel that I use, but sometimes
comes back with very badly botched video if it does, both cases result in a
100% unresponsive system, besides audio will usually continue to play until the
end of the video.

Hardware is an R9 270X Radeon card. I only use HDMI video output. I am using
the mc2 files even though they are not officially with any firmware package, I
added them when using the 3.15+ kernels. Any more info or anything else needed
just ask, I'll supply it.

--
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/20140617/462477e3/attachment.html>

[Bug 77876] Performance degredation shown when running glmark2

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

Aaron B  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |DRI CVS
  Component|Drivers/Gallium/radeonsi|DRM/Radeon

-- 
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/20140617/5d0f9312/attachment-0001.html>

[PATCH] drm/nouveau: fix oops in display destructor with headless cards

2014-06-17 Thread Maarten Lankhorst

If init doesn't run then disp->outp might not be initialized, resulting in an 
oops.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
index c41f656abe64..9c38c5e40500 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/base.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/base.c
@@ -99,8 +99,10 @@ _nouveau_disp_dtor(struct nouveau_object *object)

nouveau_event_destroy(&disp->vblank);

-   list_for_each_entry_safe(outp, outt, &disp->outp, head) {
-   nouveau_object_ref(NULL, (struct nouveau_object **)&outp);
+   if (disp->outp.next) {
+   list_for_each_entry_safe(outp, outt, &disp->outp, head) {
+   nouveau_object_ref(NULL, (struct nouveau_object 
**)&outp);
+   }
}

nouveau_engine_destroy(&disp->base);

[PULL] drm-intel-fixes

2014-06-17 Thread Daniel Vetter

On Tue, Jun 17, 2014 at 02:09:41PM +0300, Jani Nikula wrote:
> 
> Hi Dave -
> 
> First round of fixes for 3.16-rc, mostly cc: stable, and the vt/vgacon
> fixes from Daniel [1] to avoid hangs and unclaimed register errors on
> module load/reload.

Aside: The vt/vgacon stuff also seems to fix some rare hard-hangs on
driver load, hence why I want this in -fixes. The rare module reload issue
is imo not -fixes material since users never run into that.
-Daniel

> 
> BR,
> Jani.
> 
> [1] http://lkml.kernel.org/r/1401980308-5116-1-git-send-email-daniel.vetter 
> at ffwll.ch
> 
> The following changes since commit bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b:
> 
>   Merge branch 'drm-nouveau-next' of 
> git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-06-11 
> 16:28:10 +1000)
> 
> are available in the git repository at:
> 
> 
>   git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-06-17
> 
> for you to fetch changes up to 223a6f2b975ab35d93270ea1d4fb6e0ac6b27fe6:
> 
>   drm/i915/bdw: remove erroneous chv specific workarounds from bdw code 
> (2014-06-13 11:33:16 +0300)
> 
> 
> Chris Wilson (3):
>   drm/i915: Disable FBC by default also on Haswell and later
>   drm/i95: Initialize active ring->pid to -1
>   drm/i915: Reorder semaphore deadlock check
> 
> Daniel Vetter (5):
>   vt: Fix replacement console check when unbinding
>   vt: Fix up unregistration of vt drivers
>   vt: Don't ignore unbind errors in vt_unbind
>   drm/i915: Fixup global gtt cleanup
>   drm/i915: Kick out vga console
> 
> Imre Deak (1):
>   drm/i915: fix possible refcount leak when resetting forcewake
> 
> Jani Nikula (2):
>   drm/i915: set backlight duty cycle after backlight enable for gen4
>   Merge remote-tracking branch 'drm-intel/topic/kicking-dogs-and-vgacon' 
> into drm-intel-fixes
> 
> Tom O'Rourke (1):
>   drm/i915/bdw: remove erroneous chv specific workarounds from bdw code
> 
> Ville Syrj?l? (1):
>   drm/i915: Avoid div-by-zero when pixel_multiplier is zero
> 
>  drivers/gpu/drm/i915/i915_dma.c | 47 
> +
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  9 ++-
>  drivers/gpu/drm/i915/i915_gpu_error.c   |  3 ++-
>  drivers/gpu/drm/i915/i915_irq.c | 18 ++---
>  drivers/gpu/drm/i915/intel_panel.c  |  5 ++--
>  drivers/gpu/drm/i915/intel_pm.c |  9 ++-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c   |  4 ++-
>  drivers/gpu/drm/i915/intel_uncore.c |  3 ++-
>  drivers/tty/vt/vt.c | 24 ++---
>  drivers/video/console/dummycon.c|  1 +
>  drivers/video/console/vgacon.c  |  1 +
>  12 files changed, 92 insertions(+), 34 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center



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

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

2014-06-17 Thread Tomeu Vizoso

On 06/16/2014 10:02 PM, Stephen Warren wrote:
> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>> +
>> +Child device nodes describe the memory settings for different 
>> configurations and
>> +clock rates.
>
> How do the child nodes do that? The binding needs to specify the format
> of the child node.

Sorry, that file was sent before I had finished removing the bits from 
downstream that aren't needed yet. There's no current need for any child 
nodes.

> This binding looks quite anaemic vs.
> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
> would expect that this binding needs all the EMC register data from the
> tegra20-emc binding too. Can the two bindings be identical?

There's even less stuff needed right now, as all what ultimately the EMC 
driver does is call clk_set_rate on the EMC clock. As the T124 EMC 
driver gains more features, they should get more similar.

> Can you explain what the nvidia,mc and nvidia,pmc references are needed
> for? Hopefully, this driver isn't going to reach into those devices and
> touch their registers directly.

Not really needed, see above.

>> diff --git a/include/linux/platform_data/tegra_emc.h 
>> b/include/linux/platform_data/tegra_emc.h
>
> A header file that defines platform data format isn't the correct place
> to put the definitions of public APIs. I'd expect something more like
> .

Sounds better indeed, thanks.

>> +#ifdef CONFIG_TEGRA124_EMC
>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned long 
>> rate);
>> +void tegra124_emc_set_floor(unsigned long freq);
>> +void tegra124_emc_set_ceiling(unsigned long freq);
>> +#else
>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned long 
>> rate)
>> +{ return -ENODEV; }
>> +void tegra124_emc_set_floor(unsigned long freq)
>> +{ return; }
>> +void tegra124_emc_set_ceiling(unsigned long freq)
>> +{ return; }
>> +#endif
>
> I'll repeat what I said off-list so that we can have the whole
> conversation on the list:
>
> That looks like a custom Tegra-specific API. I think it'd be much better
> to integrate this into the common clock framework as a standard clock
> constraints API. There are other use-cases for clock constraints besides
> EMC scaling (e.g. some in audio on Tegra, and I'm sure many on other
> SoCs too).

Yes, I wrote a bit in the cover letter about our requirements and how 
they map to the CCF. Could you please comment on that?

Thanks,

Tomeu

> See https://lkml.org/lkml/2014/5/16/569 for some previous discussion on
> this topic.

[PULL] drm-intel-fixes

2014-06-17 Thread Jani Nikula


Hi Dave -

First round of fixes for 3.16-rc, mostly cc: stable, and the vt/vgacon
fixes from Daniel [1] to avoid hangs and unclaimed register errors on
module load/reload.

BR,
Jani.

[1] http://lkml.kernel.org/r/1401980308-5116-1-git-send-email-daniel.vetter at 
ffwll.ch

The following changes since commit bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b:

  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-06-11 
16:28:10 +1000)

are available in the git repository at:


  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-06-17

for you to fetch changes up to 223a6f2b975ab35d93270ea1d4fb6e0ac6b27fe6:

  drm/i915/bdw: remove erroneous chv specific workarounds from bdw code 
(2014-06-13 11:33:16 +0300)


Chris Wilson (3):
  drm/i915: Disable FBC by default also on Haswell and later
  drm/i95: Initialize active ring->pid to -1
  drm/i915: Reorder semaphore deadlock check

Daniel Vetter (5):
  vt: Fix replacement console check when unbinding
  vt: Fix up unregistration of vt drivers
  vt: Don't ignore unbind errors in vt_unbind
  drm/i915: Fixup global gtt cleanup
  drm/i915: Kick out vga console

Imre Deak (1):
  drm/i915: fix possible refcount leak when resetting forcewake

Jani Nikula (2):
  drm/i915: set backlight duty cycle after backlight enable for gen4
  Merge remote-tracking branch 'drm-intel/topic/kicking-dogs-and-vgacon' 
into drm-intel-fixes

Tom O'Rourke (1):
  drm/i915/bdw: remove erroneous chv specific workarounds from bdw code

Ville Syrj?l? (1):
  drm/i915: Avoid div-by-zero when pixel_multiplier is zero

 drivers/gpu/drm/i915/i915_dma.c | 47 +
 drivers/gpu/drm/i915/i915_gem_gtt.c |  9 ++-
 drivers/gpu/drm/i915/i915_gpu_error.c   |  3 ++-
 drivers/gpu/drm/i915/i915_irq.c | 18 ++---
 drivers/gpu/drm/i915/intel_panel.c  |  5 ++--
 drivers/gpu/drm/i915/intel_pm.c |  9 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |  4 ++-
 drivers/gpu/drm/i915/intel_uncore.c |  3 ++-
 drivers/tty/vt/vt.c | 24 ++---
 drivers/video/console/dummycon.c|  1 +
 drivers/video/console/vgacon.c  |  1 +
 12 files changed, 92 insertions(+), 34 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/f698fc55/attachment-0001.sig>

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

2014-06-17 Thread Christian König

Am 17.06.2014 12:12, schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> This reverts commit 75f36d861957cb05b7889af24c8cd4a789398304.
>
> drm_vblank_get() is necessary to ensure the DRM vblank counter value is
> up to date in drm_send_vblank_event().
>
> Seems to fix weston hangs waiting for page flips to complete.
>
> Signed-off-by: Michel D?nzer 

Both patches are: Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/radeon_display.c | 17 +
>   1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 2a8b9f1..97d7a80 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -357,6 +357,7 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
> int crtc_id)
>   
>   spin_unlock_irqrestore(&rdev->ddev->event_lock, flags);
>   
> + drm_vblank_put(rdev->ddev, radeon_crtc->crtc_id);
>   radeon_fence_unref(&work->fence);
>   radeon_irq_kms_pflip_irq_get(rdev, work->crtc_id);
>   queue_work(radeon_crtc->flip_queue, &work->unpin_work);
> @@ -459,6 +460,12 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
>   base &= ~7;
>   }
>   
> + r = drm_vblank_get(crtc->dev, radeon_crtc->crtc_id);
> + if (r) {
> + DRM_ERROR("failed to get vblank before flip\n");
> + goto pflip_cleanup;
> + }
> +
>   /* We borrow the event spin lock for protecting flip_work */
>   spin_lock_irqsave(&crtc->dev->event_lock, flags);
>   
> @@ -473,6 +480,16 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
>   
>   return;
>   
> +pflip_cleanup:
> + if (unlikely(radeon_bo_reserve(work->new_rbo, false) != 0)) {
> + DRM_ERROR("failed to reserve new rbo in error path\n");
> + goto cleanup;
> + }
> + if (unlikely(radeon_bo_unpin(work->new_rbo) != 0)) {
> + DRM_ERROR("failed to unpin new rbo in error path\n");
> + }
> + radeon_bo_unreserve(work->new_rbo);
> +
>   cleanup:
>   drm_gem_object_unreference_unlocked(&work->old_rbo->gem_base);
>   radeon_fence_unref(&work->fence);

[Bug 79980] Random radeonsi crashes

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

--- Comment #14 from Andy Furniss  ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> 
> > > optimize SI VM handling + use lower_32_bits where appropriate reverted - 
> > > the
> > > latter just so I could revert the former.
> > > 
> > > I'll see if I am stable over the next couple of days like this.
> > 
> > I am stable so far with the above reverted.
> 
> Spoke too soon, I just locked. Wasn't quite the same as before in that
> screen stayed on displaying normal rather that off/on + junk.
> 
> Wasn't doing anything GPU related (accepting I always am with glamor), was
> doing a big compile, so memory pressure I guess.
> 
> Also just add to the mix, after thinking I was stable yesterday I upgraded
> gcc and updated llvm and mesa so they were different in several ways, though
> I haven't rebuilt kernel.

I got another lock last thing, this one was "typical" happened when closing
seamonkey, this is the third time closing it has locked. Of course it doesn't
do it if I try. I must be using gl someway/sometimes, as the last thing I see
is the xterm from where it was started and there is a mesa message about
default setting for s3tc being overridden by env (and that's not by me - I
don't have drirc anywhere).

I think this is going to be a pain to find - I just tried reset --hard onto 

 add large PTE support for NI, SI and CIK v5

that failed to resume from mem 1st try, though it wasn't locked. just corrupt
(mouse cursor large block of junk, fluxbox desktop black, but toolbar still
visible) so maybe a different issue fixed by a later commit. I could SysRq -
the log was 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/20140617/987281e8/attachment-0001.html>

[Bug 79980] Random radeonsi crashes

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

--- Comment #13 from darkbasic  ---
> Wasn't doing anything GPU related (accepting I always am with glamor), was
> doing a big compile, so memory pressure I guess.

You're right, i was compiling too when it crashed. Nothing GPU related anyway.

-- 
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/20140617/089859d1/attachment.html>

[Bug 79980] Random radeonsi crashes

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

agapito  changed:

   What|Removed |Added

   Priority|medium  |high

--- Comment #12 from agapito  ---
First of all: excuse my bad english.

I have the same problem with my HD 7950; using hangouts, playing Left for Dead
2, or watching a flash video my screen goes crazy with vertical lines or grey
fog. Started when i upgraded to testing repo (Archlinux) and downloaded the
newest linux-firmware package, who includes TAHITI_mc2.bin. I suffered this bug
on kernels 3.14 and 3.15. For now, i am using 3.15.1 kernel, and the old Tahiti
firmware, and it seems stable.

-- 
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/20140617/4797f46b/attachment.html>

[Bug 79980] Random radeonsi crashes

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

--- Comment #11 from darkbasic  ---
Created attachment 101226
  --> https://bugs.freedesktop.org/attachment.cgi?id=101226&action=edit
gray screen

This is what I often get, I was simply syncing my portage tree while it
happened.

-- 
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/20140617/5418cf20/attachment.html>

[PATCH 0/6] File Sealing & memfd_create()

2014-06-17 Thread Florian Weimer

On 04/10/2014 10:37 PM, Andy Lutomirski wrote:

> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only.  That may be enough for the file sealing thing.

Increasing privilege on O_PATH descriptors via access through 
/proc/self/fd is part of the userspace API.  The same thing might be 
true for O_RDONLY descriptors, but it's a bit less likely that there are 
any users out there.  In any case, I'm not sure it makes sense to plug 
the O_RDONLY hole while leaving the O_PATH hole open.

-- 
Florian Weimer / Red Hat Product Security Team

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

Use module_init instead of late_initcall, as is the norm for modular
drivers.

module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
but it does not explain why. Tests show it's working properly with
module_init.

Signed-off-by: Guido Mart?nez 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 2c860c4..6be623b 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -629,7 +629,7 @@ static void __exit tilcdc_drm_fini(void)
tilcdc_tfp410_fini();
 }

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

 MODULE_AUTHOR("Rob Clark

[PATCH/RESEND 8/9] drm/tilcdc: remove submodule destroy calls

The TI tilcdc driver is designed with a notion of submodules. Currently,
at unload time, these submodules are iterated and destroyed.

Now that the tilcdc remove order is fixed, this can be handled perfectly
by the kernel using the device infrastructure, since each submodule
is a kernel driver itself, and they are only destroy()'ed at unload
time. Therefore we move the destroy() functionality to each submodule's
remove().

Also, remove some checks in the unloading process since the new code
guarantees the resources are allocated and need a release.

Signed-off-by: Guido Mart?nez 
---
 drivers/gpu/drm/tilcdc/Module.symvers  |  0
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  6 --
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 36 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 26 +---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 34 
 6 files changed, 50 insertions(+), 53 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers

diff --git a/drivers/gpu/drm/tilcdc/Module.symvers 
b/drivers/gpu/drm/tilcdc/Module.symvers
new file mode 100644
index 000..e69de29
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 006a30e..2c860c4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -120,7 +120,6 @@ static int cpufreq_transition(struct notifier_block *nb,
 static int tilcdc_unload(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
-   struct tilcdc_module *mod, *cur;

drm_fbdev_cma_fini(priv->fbdev);
drm_kms_helper_poll_fini(dev);
@@ -149,11 +148,6 @@ static int tilcdc_unload(struct drm_device *dev)

pm_runtime_disable(dev->dev);

-   list_for_each_entry_safe(mod, cur, &module_list, list) {
-   DBG("destroying module: %s", mod->name);
-   mod->funcs->destroy(mod);
-   }
-
kfree(priv);

return 0;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0938036..7596c14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -98,7 +98,6 @@ struct tilcdc_module;
 struct tilcdc_module_ops {
/* create appropriate encoders/connectors: */
int (*modeset_init)(struct tilcdc_module *mod, struct drm_device *dev);
-   void (*destroy)(struct tilcdc_module *mod);
 #ifdef CONFIG_DEBUG_FS
/* create debugfs nodes (can be NULL): */
int (*debugfs_init)(struct tilcdc_module *mod, struct drm_minor *minor);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index b085dcc..2f6efae 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -282,21 +282,8 @@ static int panel_modeset_init(struct tilcdc_module *mod, 
struct drm_device *dev)
return 0;
 }

-static void panel_destroy(struct tilcdc_module *mod)
-{
-   struct panel_module *panel_mod = to_panel_module(mod);
-
-   if (panel_mod->timings)
-   display_timings_release(panel_mod->timings);
-
-   tilcdc_module_cleanup(mod);
-   kfree(panel_mod->info);
-   kfree(panel_mod);
-}
-
 static const struct tilcdc_module_ops panel_module_ops = {
.modeset_init = panel_modeset_init,
-   .destroy = panel_destroy,
 };

 /*
@@ -372,6 +359,7 @@ static int panel_probe(struct platform_device *pdev)
return -ENOMEM;

mod = &panel_mod->base;
+   pdev->dev.platform_data = mod;

tilcdc_module_init(mod, "panel", &panel_module_ops);

@@ -379,17 +367,16 @@ static int panel_probe(struct platform_device *pdev)
if (IS_ERR(pinctrl))
dev_warn(&pdev->dev, "pins are not configured\n");

-
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
dev_err(&pdev->dev, "could not get panel timings\n");
-   goto fail;
+   goto fail_free;
}

panel_mod->info = of_get_panel_info(node);
if (!panel_mod->info) {
dev_err(&pdev->dev, "could not get panel info\n");
-   goto fail;
+   goto fail_timings;
}

mod->preferred_bpp = panel_mod->info->bpp;
@@ -400,13 +387,26 @@ static int panel_probe(struct platform_device *pdev)

return 0;

-fail:
-   panel_destroy(mod);
+fail_timings:
+   display_timings_release(panel_mod->timings);
+
+fail_free:
+   kfree(panel_mod);
+   tilcdc_module_cleanup(mod);
return ret;
 }

 static int panel_remove(struct platform_device *pdev)
 {
+   struct tilcdc_module *mod = dev_get_platdata(&pdev->dev);
+   struct panel_module *panel_mod = to_panel_module(mod);
+
+   display_timings_release(panel_mod->timings);
+
+   tilcdc_module_cleanup(mod);
+   kfree(panel_mod-

[PATCH/RESEND 7/9] drm/tilcdc: fix double kfree

display_timings_release calls kfree on the display_timings object passed
to it. Calling kfree after it is wrong. SLUB debug showed the following
warning:


=
BUG kmalloc-64 (Tainted: GW): Object already free

-

Disabling lock debugging due to kernel taint
INFO: Allocated in of_get_display_timings+0x2c/0x214 age=601 cpu=0
pid=884
 __slab_alloc.constprop.79+0x2e0/0x33c
 kmem_cache_alloc+0xac/0xdc
 of_get_display_timings+0x2c/0x214
 panel_probe+0x7c/0x314 [tilcdc]
 platform_drv_probe+0x18/0x48
 [..snip..]
INFO: Freed in panel_destroy+0x18/0x3c [tilcdc] age=0 cpu=0 pid=907
 __slab_free+0x34/0x330
 panel_destroy+0x18/0x3c [tilcdc]
 tilcdc_unload+0xd0/0x118 [tilcdc]
 drm_dev_unregister+0x24/0x98
 [..snip..]

Signed-off-by: Guido Mart?nez 
Cc:  #v3.9+
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 1943b2f..b085dcc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -286,10 +286,8 @@ static void panel_destroy(struct tilcdc_module *mod)
 {
struct panel_module *panel_mod = to_panel_module(mod);

-   if (panel_mod->timings) {
+   if (panel_mod->timings)
display_timings_release(panel_mod->timings);
-   kfree(panel_mod->timings);
-   }

tilcdc_module_cleanup(mod);
kfree(panel_mod->info);
-- 
2.0.0

[PATCH/RESEND 6/9] drm/tilcdc: fix release order on exit

Unregister resources in the correct order on tilcdc_drm_fini, which is
the reverse order they were registered during tilcdc_drm_init.

This also means unregistering the driver before releasing its resources.

Signed-off-by: Guido Mart?nez 
Cc:  #v3.9+
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 490aee7..006a30e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -629,10 +629,10 @@ static int __init tilcdc_drm_init(void)
 static void __exit tilcdc_drm_fini(void)
 {
DBG("fini");
-   tilcdc_tfp410_fini();
-   tilcdc_slave_fini();
-   tilcdc_panel_fini();
platform_driver_unregister(&tilcdc_platform_driver);
+   tilcdc_panel_fini();
+   tilcdc_slave_fini();
+   tilcdc_tfp410_fini();
 }

 late_initcall(tilcdc_drm_init);
-- 
2.0.0

[PATCH/RESEND 5/9] drm/tilcdc: panel: fix leak when unloading the module

The driver did not unregister the allocated framebuffer, which caused
memory leaks (and memory manager WARNs) when unloading. Also, the
framebuffer device under /dev still existed after unloading.

Add a call to drm_fbdev_cma_fini when unloading the module to prevent
both issues.

Signed-off-by: Guido Mart?nez 
Cc:  #v3.9+
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index b20b694..490aee7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -122,6 +122,7 @@ static int tilcdc_unload(struct drm_device *dev)
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_module *mod, *cur;

+   drm_fbdev_cma_fini(priv->fbdev);
drm_kms_helper_poll_fini(dev);
drm_mode_config_cleanup(dev);
drm_vblank_cleanup(dev);
-- 
2.0.0

[PATCH/RESEND 4/9] drm/tilcdc: tfp410: fix dangling sysfs connector node

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver, otherwise
we will get a warning about a duplicate filename in sysfs.

Signed-off-by: Guido Mart?nez 
Cc:  #v3.9+
---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index c38b56b..ce75ac8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -167,6 +167,7 @@ struct tfp410_connector {
 static void tfp410_connector_destroy(struct drm_connector *connector)
 {
struct tfp410_connector *tfp410_connector = 
to_tfp410_connector(connector);
+   drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(tfp410_connector);
 }
-- 
2.0.0

[PATCH/RESEND 3/9] drm/tilcdc: slave: fix dangling sysfs connector node

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:

   tda998x 0-0070: found TDA19988
   [ cut here ]
   WARNING: CPU: 0 PID: 825 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74()
   sysfs: cannot create duplicate filename '/class/drm/card0-HDMI-A-1'
   Modules linked in: [..]
   CPU: 0 PID: 825 Comm: modprobe Not tainted 3.15.0-rc4-00027-g9dcdef4 #82
   [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
   [] (show_stack) from [] (warn_slowpath_common+0x68/0x88)
   [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
   [] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x54/0x74)
   [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd.isra.2+0xb0/0xb8)
   [] (sysfs_do_create_link_sd.isra.2) from [] 
(device_add+0x338/0x520)
   [] (device_add) from [] 
(device_create_groups_vargs+0xa0/0xc4)
   [] (device_create_groups_vargs) from [] 
(device_create+0x24/0x2c)
   [] (device_create) from [] 
(drm_sysfs_connector_add+0x64/0x204)
   [] (drm_sysfs_connector_add) from [] 
(slave_modeset_init+0x120/0x1bc [tilcdc])
   [] (slave_modeset_init [tilcdc]) from [] 
(tilcdc_load+0x214/0x4c0 [tilcdc])
   [] (tilcdc_load [tilcdc]) from [] 
(drm_dev_register+0xa4/0x104)
  [..snip..]
   ---[ end trace 4df8d614936ebdee ]---
   [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: 
-17

Signed-off-by: Guido Mart?nez 
Cc:  #v3.9+
---
 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 595068b..2f83ffb 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -166,6 +166,7 @@ struct slave_connector {
 static void slave_connector_destroy(struct drm_connector *connector)
 {
struct slave_connector *slave_connector = to_slave_connector(connector);
+   drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(slave_connector);
 }
-- 
2.0.0

[PATCH/RESEND 2/9] drm/tilcdc: panel: fix dangling sysfs connector node

Add a drm_sysfs_connector_remove call when we destroy the panel to make
sure the connector node in sysfs gets deleted.

This is required for proper unload and re-load of this driver as a
module. Without this, we would get a warning at re-load time like so:

   [ cut here ]
   WARNING: CPU: 0 PID: 824 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74()
   sysfs: cannot create duplicate filename '/class/drm/card0-LVDS-1'
   Modules linked in: [...]
   CPU: 0 PID: 824 Comm: modprobe Not tainted 3.15.0-rc4-00027-g6484f96-dirty 
#81
   [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
   [] (show_stack) from [] (warn_slowpath_common+0x68/0x88)
   [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
   [] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x54/0x74)
   [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd.isra.2+0xb0/0xb8)
   [] (sysfs_do_create_link_sd.isra.2) from [] 
(device_add+0x338/0x520)
   [] (device_add) from [] 
(device_create_groups_vargs+0xa0/0xc4)
   [] (device_create_groups_vargs) from [] 
(device_create+0x24/0x2c)
   [] (device_create) from [] 
(drm_sysfs_connector_add+0x64/0x204)
   [] (drm_sysfs_connector_add) from [] 
(panel_modeset_init+0xb8/0x134 [tilcdc])
   [] (panel_modeset_init [tilcdc]) from [] 
(tilcdc_load+0x214/0x4c0 [tilcdc])
   [] (tilcdc_load [tilcdc]) from [] 
(drm_dev_register+0xa4/0x104)
  [ .. snip .. ]
   ---[ end trace b2d09cd9578b0497 ]---
   [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: 
-17

Signed-off-by: Guido Mart?nez 
Cc:  #v3.9+
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 86c6732..1943b2f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -151,6 +151,7 @@ struct panel_connector {
 static void panel_connector_destroy(struct drm_connector *connector)
 {
struct panel_connector *panel_connector = to_panel_connector(connector);
+   drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(panel_connector);
 }
-- 
2.0.0

[PATCH/RESEND 1/9] drm/i2c: tda998x: move drm_i2c_encoder_destroy call

Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.

This commit moves the latter so it's done afterwards.

Signed-off-by: Guido Mart?nez 
Signed-off-by: Ezequiel Garc?a 
Cc:  #v3.9+
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 240c331..db9515f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1183,7 +1183,6 @@ static void
 tda998x_encoder_destroy(struct drm_encoder *encoder)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   drm_i2c_encoder_destroy(encoder);

/* disable all IRQs and free the IRQ handler */
cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
@@ -1193,6 +1192,7 @@ tda998x_encoder_destroy(struct drm_encoder *encoder)

if (priv->cec)
i2c_unregister_device(priv->cec);
+   drm_i2c_encoder_destroy(encoder);
kfree(priv);
 }

-- 
2.0.0

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

The tilcdc driver could be compiled as a module, but was severely broken
and could not be used as such. This patchset attempts to fix the issues
preventing a proper load/unload of the module.

Issues included dangling sysfs nodes, dangling devices, memory leaks and
a double kfree.

It now seems to be working ok. We have tested this by loading and
unloading the driver repeteadly, with both panel and slave connectors
and found no flaws.

There is still one warning left on tilcdc_crtc_destroy, caused by
destroying the connector while still in an ON status. We don't know why
this happens or why it's an issue, so we did not fix it.

The first 7 patches are bug fixes which and should probably be applied
in the stable trees. The last two are clean-ups.


Resending this since I got no replies.


Guido Mart?nez (9):
  drm/i2c: tda998x: move drm_i2c_encoder_destroy call
  drm/tilcdc: panel: fix dangling sysfs connector node
  drm/tilcdc: slave: fix dangling sysfs connector node
  drm/tilcdc: tfp410: fix dangling sysfs connector node
  drm/tilcdc: panel: fix leak when unloading the module
  drm/tilcdc: fix release order on exit
  drm/tilcdc: fix double kfree
  drm/tilcdc: remove submodule destroy calls
  drm/tilcdc: replace late_initcall with module_init

 drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
 drivers/gpu/drm/tilcdc/Module.symvers  |  0
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
 7 files changed, 59 insertions(+), 60 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers

-- 
2.0.0

[PATCH 1/1] drivers/gpu/drm/msm/msm_iommu.c: use PAGE_ALIGNED instead of IS_ALIGNED(PAGE_SIZE

2014-06-17 Thread Rob Clark

On Sat, Jun 14, 2014 at 6:24 PM, Fabian Frederick  wrote:
> use mm.h definition
>
> Cc: David Airlie 
> Cc: Rob Clark 
> Signed-off-by: Fabian Frederick 

Thanks, I've got this queued up

BR,
-R

> ---
>  drivers/gpu/drm/msm/msm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 92b7459..198ed84 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -110,7 +110,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint32_t 
> iova,
>
> VERB("unmap[%d]: %08x(%x)", i, iova, bytes);
>
> -   BUG_ON(!IS_ALIGNED(bytes, PAGE_SIZE));
> +   BUG_ON(!PAGE_ALIGNED(bytes));
>
> da += bytes;
> }
> --
> 1.8.4.5
>

[PATCH v2 3/7] drm: add Atmel HLCDC Display Controller support

2014-06-17 Thread Boris BREZILLON


On 09/06/2014 18:04, Boris BREZILLON wrote:
> The Atmel HLCDC (High LCD Controller) IP available on some Atmel SoCs (i.e.
> at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> controller device.
>
> This display controller support at least one primary plane and might
> provide several overlays and an hardware cursor depending on the IP
> version.
>
> Signed-off-by: Boris BREZILLON 
> ---
>  .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  59 ++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
>  drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 529 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 477 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 178 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 701 
> +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 417 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c| 351 +++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 658 +++

>  drivers/gpu/drm/atmel_hlcdc/Kconfig|  11 +
>  drivers/gpu/drm/atmel_hlcdc/Makefile   |   8 +

These two files should not be part of the driver. I'll fix that.

>  14 files changed, 3410 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/Makefile
>
> diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt 
> b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
> new file mode 100644
> index 000..594bdb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
> @@ -0,0 +1,59 @@
> +Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
> +
> +The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
> +See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
> +
> +Required properties:
> + - compatible: value should be one of the following:
> +   "atmel,hlcdc-dc"
> + - interrupts: the HLCDC interrupt definition
> + - pinctrl-names: the pin control state names. Should contain "default",
> +   "rgb-444", "rgb-565", "rgb-666" and "rgb-888".
> + - pinctrl-[0-4]: should contain the pinctrl states described by pinctrl
> +   names.
> + - atmel,panel: Should contain a phandle with 2 parameters.
> +   The first cell is a phandle to a DRM panel device
> +   The second cell encodes the RGB mode, which can take the following values:
> +   * 0: RGB444
> +   * 1: RGB565
> +   * 2: RGB666
> +   * 3: RGB888
> +   The third cell encodes specific flags describing LCD signals configuration
> +   (see Atmel's datasheet for a full description of these fields):
> +   * bit 0: HSPOL: Horizontal Synchronization Pulse Polarity
> +   * bit 1: VSPOL: Vertical Synchronization Pulse Polarity
> +   * bit 2: VSPDLYS: Vertical Synchronization Pulse Start
> +   * bit 3: VSPDLYE: Vertical Synchronization Pulse End
> +   * bit 4: DISPPOL: Display Signal Polarity
> +   * bit 7: DISPDLY: LCD Controller Display Power Signal Synchronization
> +   * bit 12: VSPSU: LCD Controller Vertical synchronization Pulse Setup 
> Configuration
> +   * bit 13: VSPHO: LCD Controller Vertical synchronization Pulse Hold 
> Configuration
> +   * bit 16-20: GUARDTIME: LCD DISPLAY Guard Time
> +
> +Example:
> +
> + hlcdc: hlcdc at f003 {
> + compatible = "atmel,sama5d3-hlcdc";
> + reg = <0xf003 0x2000>;
> + clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
> + clock-names = "periph_clk","sys_clk", "slow_clk";
> + status = "disabled";
> +
> + hlcdc-display-controller {
> + compatible = "atmel,hlcdc-dc";
> + interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
> + pinctrl-names = "default", "rgb-444", "rgb-565", 
> "rgb-666", "rgb-888";
> + pinctrl-0 = <&pinctrl_lcd_base>;
> + pinctrl-1 = <&pinctrl_lcd_base &pinctrl_lcd_rgb444>;
> + pinctrl-2 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
> +

[PATCH 2/2] drm/msm: activate iommu support

2014-06-17 Thread Stephane Viau

This changes activates the iommu support for MDP5, through the
platform config structure.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 47b3eb0..ee30f1e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -358,5 +358,11 @@ static struct mdp5_platform_config *mdp5_get_config(struct 
platform_device *dev)
 #ifdef CONFIG_OF
/* TODO */
 #endif
+   config.iommu = iommu_domain_alloc(&platform_bus_type, 0);
+   /* TODO hard-coded in downstream mdss, but should it be? */
+   config.max_clk = 2;
+   /* TODO get from DT: */
+   config.smp_blk_cnt = 22;
+
return &config;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/2] drm/msm: update iommu support

2014-06-17 Thread Stephane Viau

Iommu support is slightly modified in order to make sure
that MDP iommu is properly cleaned up if a probe deferral is
requested. Before this change, IOMMU faults would occur if the
probe failed (-EPROBE_DEFER).

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 22 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  1 +
 drivers/gpu/drm/msm/msm_gem.c   |  6 ++
 drivers/gpu/drm/msm/msm_iommu.c | 21 +++--
 drivers/gpu/drm/msm/msm_mmu.h   |  1 +
 5 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index ee8446c..47b3eb0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -20,6 +20,10 @@
 #include "msm_mmu.h"
 #include "mdp5_kms.h"

+static const char *iommu_ports[] = {
+   "mdp_0",
+};
+
 static struct mdp5_platform_config *mdp5_get_config(struct platform_device 
*dev);

 static int mdp5_hw_init(struct msm_kms *kms)
@@ -104,6 +108,12 @@ static void mdp5_preclose(struct msm_kms *kms, struct 
drm_file *file)
 static void mdp5_destroy(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   struct msm_mmu *mmu = mdp5_kms->mmu;
+
+   if (mmu) {
+   mmu->funcs->detach(mmu, iommu_ports, ARRAY_SIZE(iommu_ports));
+   mmu->funcs->destroy(mmu);
+   }
kfree(mdp5_kms);
 }

@@ -216,10 +226,6 @@ fail:
return ret;
 }

-static const char *iommu_ports[] = {
-   "mdp_0",
-};
-
 static int get_clk(struct platform_device *pdev, struct clk **clkp,
const char *name)
 {
@@ -307,17 +313,23 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
mmu = msm_iommu_new(dev, config->iommu);
if (IS_ERR(mmu)) {
ret = PTR_ERR(mmu);
+   dev_err(dev->dev, "failed to init iommu: %d\n", ret);
goto fail;
}
+
ret = mmu->funcs->attach(mmu, iommu_ports,
ARRAY_SIZE(iommu_ports));
-   if (ret)
+   if (ret) {
+   dev_err(dev->dev, "failed to attach iommu: %d\n", ret);
+   mmu->funcs->destroy(mmu);
goto fail;
+   }
} else {
dev_info(dev->dev, "no iommu, fallback to phys "
"contig buffers for scanout\n");
mmu = NULL;
}
+   mdp5_kms->mmu = mmu;

mdp5_kms->id = msm_register_mmu(dev, mmu);
if (mdp5_kms->id < 0) {
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index c8b1a25..6e981b6 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -33,6 +33,7 @@ struct mdp5_kms {

/* mapper-id used to request GEM buffer mapped for scanout: */
int id;
+   struct msm_mmu *mmu;

/* for tracking smp allocation amongst pipes: */
mdp5_smp_state_t smp_state;
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index bb8026d..690d7e7 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -278,6 +278,7 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj, int 
id,
uint32_t *iova)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   struct drm_device *dev = obj->dev;
int ret = 0;

if (!msm_obj->domain[id].iova) {
@@ -285,6 +286,11 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj, 
int id,
struct msm_mmu *mmu = priv->mmus[id];
struct page **pages = get_pages(obj);

+   if (!mmu) {
+   dev_err(dev->dev, "null MMU pointer\n");
+   return -EINVAL;
+   }
+
if (IS_ERR(pages))
return PTR_ERR(pages);

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 92b7459..198b2fe 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -28,7 +28,7 @@ static int msm_fault_handler(struct iommu_domain *iommu, 
struct device *dev,
unsigned long iova, int flags, void *arg)
 {
DBG("*** fault: iova=%08lx, flags=%d", iova, flags);
-   return 0;
+   return -ENOSYS;
 }

 static int msm_iommu_attach(struct msm_mmu *mmu, const char **names, int cnt)
@@ -40,8 +40,10 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char 
**names, int cnt)
for (i = 0; i < cnt; i++) {
struct device *msm_iommu_get_ctx(const char *ctx_name);
struct device *ctx = msm_iommu_get_ctx(names[i]);
-   if (IS_ERR_OR_NULL(ctx))
+   if (IS_ERR_OR_NULL(ctx)) {
+   dev_warn(dev-

[PATCH v2 0/2] drm/msm: update and activate iommu support

2014-06-17 Thread Stephane Viau

I am resending these patches after splitting them into two:
1) to update the IOMMU support
2) to activate the IOMMU

Stephane Viau (2):
  drm/msm: update iommu support
  drm/msm: activate iommu support

 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 28 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  1 +
 drivers/gpu/drm/msm/msm_gem.c   |  6 ++
 drivers/gpu/drm/msm/msm_iommu.c | 21 +++--
 drivers/gpu/drm/msm/msm_mmu.h   |  1 +
 5 files changed, 50 insertions(+), 7 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver

2014-06-17 Thread Stephen Warren

On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:

>> This binding looks quite anaemic vs.
>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
>> would expect that this binding needs all the EMC register data from the
>> tegra20-emc binding too. Can the two bindings be identical?
> 
> There's even less stuff needed right now, as all what ultimately the EMC
> driver does is call clk_set_rate on the EMC clock. As the T124 EMC
> driver gains more features, they should get more similar.

IIRC, even changing the EMC clock rate requires modifying the memory
controller's programming (e.g. delays/taps/tuning etc.). That's exactly
what the more complex stuff in the nvidia,tegra20-emc.txt is all about.
I not convinced that a driver that just modifies the clock rate without
adjusting the EMC programming will work reliably.

>>> +#ifdef CONFIG_TEGRA124_EMC
>>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned
>>> long rate);
>>> +void tegra124_emc_set_floor(unsigned long freq);
>>> +void tegra124_emc_set_ceiling(unsigned long freq);
>>> +#else
>>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned
>>> long rate)
>>> +{ return -ENODEV; }
>>> +void tegra124_emc_set_floor(unsigned long freq)
>>> +{ return; }
>>> +void tegra124_emc_set_ceiling(unsigned long freq)
>>> +{ return; }
>>> +#endif
>>
>> I'll repeat what I said off-list so that we can have the whole
>> conversation on the list:
>>
>> That looks like a custom Tegra-specific API. I think it'd be much better
>> to integrate this into the common clock framework as a standard clock
>> constraints API. There are other use-cases for clock constraints besides
>> EMC scaling (e.g. some in audio on Tegra, and I'm sure many on other
>> SoCs too).
> 
> Yes, I wrote a bit in the cover letter about our requirements and how
> they map to the CCF. Could you please comment on that?

My comments remain the same. I believe this is something that belongs in
the clock driver, or at the least, some API that takes a struct clock as
its parameter, so that drivers can use the existing DT clock lookup
mechanism.

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

2014-06-17 Thread Alex Deucher

On Tue, Jun 17, 2014 at 7:41 AM, Christian K?nig
 wrote:
> Am 17.06.2014 12:12, schrieb Michel D?nzer:
>
>> From: Michel D?nzer 
>>
>> This reverts commit 75f36d861957cb05b7889af24c8cd4a789398304.
>>
>> drm_vblank_get() is necessary to ensure the DRM vblank counter value is
>> up to date in drm_send_vblank_event().
>>
>> Seems to fix weston hangs waiting for page flips to complete.
>>
>> Signed-off-by: Michel D?nzer 
>
>
> Both patches are: Reviewed-by: Christian K?nig 

Both applied to my fixes tree.

Alex

>
>
>> ---
>>   drivers/gpu/drm/radeon/radeon_display.c | 17 +
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
>> b/drivers/gpu/drm/radeon/radeon_display.c
>> index 2a8b9f1..97d7a80 100644
>> --- a/drivers/gpu/drm/radeon/radeon_display.c
>> +++ b/drivers/gpu/drm/radeon/radeon_display.c
>> @@ -357,6 +357,7 @@ void radeon_crtc_handle_flip(struct radeon_device
>> *rdev, int crtc_id)
>> spin_unlock_irqrestore(&rdev->ddev->event_lock, flags);
>>   + drm_vblank_put(rdev->ddev, radeon_crtc->crtc_id);
>> radeon_fence_unref(&work->fence);
>> radeon_irq_kms_pflip_irq_get(rdev, work->crtc_id);
>> queue_work(radeon_crtc->flip_queue, &work->unpin_work);
>> @@ -459,6 +460,12 @@ static void radeon_flip_work_func(struct work_struct
>> *__work)
>> base &= ~7;
>> }
>>   + r = drm_vblank_get(crtc->dev, radeon_crtc->crtc_id);
>> +   if (r) {
>> +   DRM_ERROR("failed to get vblank before flip\n");
>> +   goto pflip_cleanup;
>> +   }
>> +
>> /* We borrow the event spin lock for protecting flip_work */
>> spin_lock_irqsave(&crtc->dev->event_lock, flags);
>>   @@ -473,6 +480,16 @@ static void radeon_flip_work_func(struct
>> work_struct *__work)
>> return;
>>   +pflip_cleanup:
>> +   if (unlikely(radeon_bo_reserve(work->new_rbo, false) != 0)) {
>> +   DRM_ERROR("failed to reserve new rbo in error path\n");
>> +   goto cleanup;
>> +   }
>> +   if (unlikely(radeon_bo_unpin(work->new_rbo) != 0)) {
>> +   DRM_ERROR("failed to unpin new rbo in error path\n");
>> +   }
>> +   radeon_bo_unreserve(work->new_rbo);
>> +
>>   cleanup:
>> drm_gem_object_unreference_unlocked(&work->old_rbo->gem_base);
>> radeon_fence_unref(&work->fence);
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/6] File Sealing & memfd_create()

2014-06-17 Thread Andy Lutomirski

On Jun 17, 2014 2:48 AM, "Florian Weimer"  wrote:
>
> On 04/10/2014 10:37 PM, Andy Lutomirski wrote:
>
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
>> read-only.  That may be enough for the file sealing thing.
>
>
> Increasing privilege on O_PATH descriptors via access through
/proc/self/fd is part of the userspace API.  The same thing might be true
for O_RDONLY descriptors, but it's a bit less likely that there are any
users out there.  In any case, I'm not sure it makes sense to plug the
O_RDONLY hole while leaving the O_PATH hole open.

Do you mean O_PATH fds for the directory or O_PATH fds for the file
itself?  In any event, I'm much less concerned about passing O_PATH memfds
around than O_RDONLY memfds.

I have incomplete patches for this stuff.  I need to fix them so they work
and get past Al Viro.


--Andy
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/30d2d605/attachment.html>

[Intel-gfx] [PATCH 09/11] drm/i915: check connector->encoder before using it.

erging 
> initially,
>
> Since the last set, it makes fbcon and suspend/resume work a lot better,
>
> I've also fixed a couple of bugs in -intel that make things work a lot
> better.
>
> I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked
> to add 3 monitor support.
>
> It still generates a fair few i915 state checker backtraces, and some
> of them are fairly hard to work out, it might be we should just tone
> down the state checker for encoders/connectors with no actual hw backing
> them.
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sent using Postbox:
http://www.getpostbox.com
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/9117312f/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1291 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/9117312f/attachment-0001.jpg>

[PATCH 08/11] i915: split some DP modesetting code into a separate function


Looks good to me.

Reviewed-by: Todd Previte 

> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, May 20, 2014 7:55 PM
> From: Dave Airlie 
>
> this is just prep work for mst support.
>
> Signed-off-by: Dave Airlie 
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 20 +---
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0ad4e96..a5b8b76 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -364,6 +364,18 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
> DRM_ERROR("FDI link training failed!\n");
> }
>
> +void intel_ddi_mode_set_dp(struct intel_encoder *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> + struct intel_digital_port *intel_dig_port =
> + enc_to_dig_port(&encoder->base);
> +
> + intel_dp->DP = intel_dig_port->saved_port_bits |
> + DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
> + intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
> +
> +}
> +
> static void intel_ddi_mode_set(struct intel_encoder *encoder)
> {
> struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> @@ -378,13 +390,7 @@ static void intel_ddi_mode_set(struct 
> intel_encoder *encoder)
> crtc->eld_vld = false;
> if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> - struct intel_digital_port *intel_dig_port =
> - enc_to_dig_port(&encoder->base);
> -
> - intel_dp->DP = intel_dig_port->saved_port_bits |
> - DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
> - intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
> -
> + intel_ddi_mode_set_dp(encoder);
> if (intel_dp->has_audio) {
> DRM_DEBUG_DRIVER("DP audio on pipe %c on DDI\n",
> pipe_name(crtc->pipe));
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index b885df1..8e41cdc 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -683,6 +683,7 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc);
> void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_config *pipe_config);
>
> +void intel_ddi_mode_set_dp(struct intel_encoder *encoder);
>
> /* intel_display.c */
> const char *intel_output_name(int output);
> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, May 20, 2014 7:54 PM
> Hey,
>
> So this set is pretty close to what I think we should be merging 
> initially,
>
> Since the last set, it makes fbcon and suspend/resume work a lot better,
>
> I've also fixed a couple of bugs in -intel that make things work a lot
> better.
>
> I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked
> to add 3 monitor support.
>
> It still generates a fair few i915 state checker backtraces, and some
> of them are fairly hard to work out, it might be we should just tone
> down the state checker for encoders/connectors with no actual hw backing
> them.
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sent using Postbox:
http://www.getpostbox.com
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/93973305/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1291 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/93973305/attachment.jpg>

[Intel-gfx] [PATCH 07/11] drm/helper: add Displayport multi-stream helper (v0.5)


This patch is a monster, but that's to be expected with MST, I suppose. 
:) It has some formatting issues (lines over 80 characters in length) 
but that can be cleaned up later (as far as I'm concerned). Otherwise I 
don't see anything glaring here, so...

Reviewed-by: Todd Previte 

> Dave Airlie 
> Tuesday, May 20, 2014 7:55 PM
> From: Dave Airlie 
>
> This is the initial import of the helper for displayport multistream.
>
> It consists of a topology manager, init/destroy/set mst state
>
> It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs
>
> connector detect and edid retrieval interface.
>
> It supports i2c device over DP 1.2 sideband msg protocol (EDID reads only)
>
> bandwidth manager API via vcpi allocation and payload updating,
> along with a helper to check the ACT status.
>
> Objects:
> MST topology manager - one per toplevel MST capable GPU port - not 
> sure if this should be higher level again
> MST branch unit - one instance per plugged branching unit - one at top 
> of hierarchy - others hanging from ports
> MST port - one port per port reported by branching units, can have MST 
> units hanging from them as well.
>
> Changes since initial posting:
> a) add a mutex responsbile for the queues, it locks the sideband and 
> msg slots, and msgs to transmit state
> b) add worker to handle connection state change events, for MST device 
> chaining and hotplug
> c) add a payload spinlock
> d) add path sideband msg support
> e) fixup enum path resources transmit
> f) reduce max dpcd msg to 16, as per DP1.2 spec.
> g) separate tx queue kicking from irq processing and move irq acking 
> back to drivers.
>
> Changes since v0.2:
> a) reorganise code,
> b) drop ACT forcing code
> c) add connector naming interface using path property
> d) add topology dumper helper
> e) proper reference counting and lookup for ports and mstbs.
> f) move tx kicking into a workq
> g) add aux locking - this should be redone
> h) split teardown into two parts
> i) start working on documentation on interface.
>
> Changes since v0.3:
> a) vc payload locking and tracking fixes
> b) add hotplug callback into driver - replaces crazy return 1 scheme
> c) txmsg + mst branch device refcount fixes
> d) don't bail on mst shutdown if device is gone
> e) change irq handler to take all 4 bytes of SINK_COUNT + ESI vectors
> f) make DP payload updates timeout longer - observed on docking 
> station redock
> g) add more info to debugfs dumper
>
> Changes since v0.4:
> a) suspend/resume support
> b) more debugging in debugfs
>
> TODO:
> misc features
>
> Signed-off-by: Dave Airlie 
> ---
> Documentation/DocBook/drm.tmpl | 6 +
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c | 2739 
> +
> include/drm/drm_dp_mst_helper.h | 507 ++
> 4 files changed, 3253 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_dp_mst_topology.c
> create mode 100644 include/drm/drm_dp_mst_helper.h
>
> diff --git a/Documentation/DocBook/drm.tmpl 
> b/Documentation/DocBook/drm.tmpl
> index 83dd0b0..1883976 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2296,6 +2296,12 @@ void intel_crt_init(struct drm_device *dev)
> !Edrivers/gpu/drm/drm_dp_helper.c
> 
> 
> + Display Port MST Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
> +!Iinclude/drm/drm_dp_mst_helper.h
> +!Edrivers/gpu/drm/drm_dp_mst_topology.c
> + 
> + 
> EDID Helper Functions Reference
> !Edrivers/gpu/drm/drm_edid.c
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 48e38ba..712b73e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -23,7 +23,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>
> drm-usb-y := drm_usb.o
>
> -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
> +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> drm_probe_helper.o drm_dp_mst_topology.o
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> new file mode 100644
> index 000..ebd9292
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -0,0 +1,2739 @@
> +/*
> + * Copyright ? 2014 Red Hat
> + *
> + * Permission to use, copy, modify, distribute, and sell this 
> software and its
> + * documentation for any purpose is hereby granted without fee, 
> provided that
> + * the above copyright notice appear in all copies and that both that 
> copyright
> + * notice and this permission notice appear in supporting 
> documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permis

[Intel-gfx] [PATCH 06/11] drm: add a path blob property


This one looks fine to me.

Reviewed-by: Todd Previte 

> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, May 20, 2014 7:54 PM
> From: Dave Airlie 
>
> This property will be used by the MST code to provide userspace
> with a path to parse so it can recognise connectors around hotplugs.
>
> Signed-off-by: Dave Airlie 
> ---
> drivers/gpu/drm/drm_crtc.c | 26 ++
> include/drm/drm_crtc.h | 5 +
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8bf87a6..06b9255 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1165,6 +1165,7 @@ static int 
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
> {
> struct drm_property *edid;
> struct drm_property *dpms;
> + struct drm_property *dev_path;
>
> /*
> * Standard properties (apply to all connectors)
> @@ -1179,6 +1180,12 @@ static int 
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
> ARRAY_SIZE(drm_dpms_enum_list));
> dev->mode_config.dpms_property = dpms;
>
> + dev_path = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB |
> + DRM_MODE_PROP_IMMUTABLE,
> + "PATH", 0);
> + dev->mode_config.path_property = dev_path;
> +
> return 0;
> }
>
> @@ -3637,6 +3644,25 @@ done:
> return ret;
> }
>
> +int drm_mode_connector_set_path_property(struct drm_connector *connector,
> + char *path)
> +{
> + struct drm_device *dev = connector->dev;
> + int ret, size;
> + size = strlen(path) + 1;
> +
> + connector->path_blob_ptr = drm_property_create_blob(connector->dev,
> + size, path);
> + if (!connector->path_blob_ptr)
> + return -EINVAL;
> +
> + ret = drm_object_property_set_value(&connector->base,
> + dev->mode_config.path_property,
> + connector->path_blob_ptr->base.id);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_path_property);
> +
> /**
> * drm_mode_connector_update_edid_property - update the edid property 
> of a connector
> * @connector: drm connector
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 55bc523..e33959b 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -500,6 +500,8 @@ struct drm_connector {
> struct drm_property_blob *edid_blob_ptr;
> struct drm_object_properties properties;
>
> + struct drm_property_blob *path_blob_ptr;
> +
> uint8_t polled; /* DRM_CONNECTOR_POLL_* */
>
> /* requested DPMS state */
> @@ -774,6 +776,7 @@ struct drm_mode_config {
> struct list_head property_blob_list;
> struct drm_property *edid_property;
> struct drm_property *dpms_property;
> + struct drm_property *path_property;
> struct drm_property *plane_type_property;
>
> /* DVI-I properties */
> @@ -926,6 +929,8 @@ extern void drm_mode_config_init(struct drm_device 
> *dev);
> extern void drm_mode_config_reset(struct drm_device *dev);
> extern void drm_mode_config_cleanup(struct drm_device *dev);
>
> +extern int drm_mode_connector_set_path_property(struct drm_connector 
> *connector,
> + char *path);
> extern int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
> struct edid *edid);
> extern int drm_object_property_set_value(struct drm_mode_object *obj,
> Dave Airlie <mailto:airlied at gmail.com>
> Tuesday, May 20, 2014 7:54 PM
> Hey,
>
> So this set is pretty close to what I think we should be merging 
> initially,
>
> Since the last set, it makes fbcon and suspend/resume work a lot better,
>
> I've also fixed a couple of bugs in -intel that make things work a lot
> better.
>
> I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked
> to add 3 monitor support.
>
> It still generates a fair few i915 state checker backtraces, and some
> of them are fairly hard to work out, it might be we should just tone
> down the state checker for encoders/connectors with no actual hw backing
> them.
>
> Dave.
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sent using Postbox:
http://www.getpostbox.com
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/92b836b3/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1291 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140617/92b836b3/attachment-0001.jpg>

[Intel-gfx] [PATCH 05/11] drm/fb_helper: allow adding/removing connectors later