[Bug 88669] clover on radeonsi fails in radeon_shader_binary_config_start

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

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

--- Comment #5 from Tom Stellard  ---
Can you run the program with CLOVER_DEBUG=clc,llvm,asm and post the 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/20150122/b0bd4c29/attachment.html>

[Bug 85204] [Radeon HD 5650] return from sleep state failed

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

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

--- Comment #22 from Rafael Pereira  ---
Tested here on v3.19-rc5 + patches, and (after 15 trials) no sign of the bug.

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

[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

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

--- Comment #2 from Tom Stellard  ---
Created attachment 112689
  --> https://bugs.freedesktop.org/attachment.cgi?id=112689=edit
Possible fix

Can you try this patch?

-- 
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/20150122/1edaa69b/attachment.html>

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #10 from Alex Deucher  ---
Possibly related to bug 90741.

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

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #9 from Jon Arne Jørgensen  ---
Finaly managed to get a clean bisect, this is the culprit:

commit f2c24b83ae90292d315aa7ac029c6ce7929e01aa
Author: Maarten Lankhorst 
Date:   Wed Apr 2 17:14:48 2014 +0200

drm/ttm: flip the switch, and convert to dma_fence

Signed-off-by: Maarten Lankhorst 

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

[PATCH 1/5] drm/atomic: Add drm_crtc_state->active

[Ville Syrjälä]

On Thu, Jan 22, 2015 at 06:38:32PM +0100, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 5:42 PM, Ville Syrjälä
>  wrote:
> >> Which is pretty much what I do - you can only access the per-crtc ACTIVE
> >> property from the atomic ioctl, the per-connector dpms property is _not_
> >> exposed through atomic. Vice-versa legacy clients wont see atomic
> >> properties (and hence this new one) either.
> >
> > Oh, OK. I didn't see anything obvious that would filter out the dpms
> > prop for non-atomic, nor do I see code to reject stuff in setprop/getprop
> > ioctls etc. But I suppose such stuff may be in flight and I've just not
> > paid attention.
> 
> On the atomic side the dpms prop is simple not decoded. The driver
> /could/ do that itself, but that would be really pointless. In
> getprops atomic ioctls are filtered out for non-atomic clients. Which
> means that an atomic client could do a dpms on the connector through
> the legacy setprop ioctl, but that would be rather stupid.

Well I'd rather it refused the entire thing. Less weird interactions to
worry about if we're strict and block all the silly stuff at the top.

> 
> >> Is that good enough?
> >
> > I suppose.
> >
> > Another thing that came to mind wrt. the 'this can't fail rule' was
> > fb pinning. So is the rule now going to be that we need to pin even
> > when ACTIVE==false, or otherwise make sure all the FBs can be pinned
> > simultaneosly? If we don't want to everything pinned all the time when
> > ACTIVE==false, then we would need to prevent pinning of anything else
> > in the meantime to make sure we don't run out of address space.
> 
> fb pinning is done irrespective of the state of active. So if you
> update the fb while the display pipe is off the helpers will upin/pin
> correctly. Imo that's totally fine, since failing to pin when setting
> the display back to active really isn't a great thing. And we need to
> be able to tell userspace when something has gone wrong with the
> pinning (e.g. due to giant framebuffer or something).

Yeah that was pretty much my original idea too. I suppose now that's the
call comes from the core it's a bit less likely to be messed up again.

-- 
Ville Syrjälä
Intel OTC

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #18 from Gustaw Smolarczyk  ---
Only the second version (with the 2 lines uncommented) of the new patch does
fix the problem.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #17 from Maarten Lankhorst  ---
Created attachment 164421
  --> https://bugzilla.kernel.org/attachment.cgi?id=164421=edit
Another approach

Don't need to test anything but final version, can you test this version
though? I want to see if the bug's in the wait code or something with the
interrupt handling..

If this version fails too, can you uncomment the sw_irq_get and sw_irq_put
calls added in the patch?

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

[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

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

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

--- Comment #17 from Ismael  ---
(In reply to Michel Dänzer from comment #16)
> Created attachment 112528 [details] [review]
> Reinstate radeon_gart_restore for when the GART table is in VRAM
> 
> Do these two patches help?

Yes it helps. Suspend and resume work perfectly now.

Xan 22 21:20:20 boreal kernel: [drm] enabling PCIE gen 2 link speeds, disable
with radeon.pcie_gen2=0
Xan 22 21:20:20 boreal kernel: [drm] PCIE GART of 1024M enabled (table at
0x0025E000).
Xan 22 21:20:20 boreal kernel: radeon :01:00.0: WB enabled
Xan 22 21:20:20 boreal kernel: radeon :01:00.0: fence driver on ring 0 use
gpu addr 0x4c00 and cpu addr 0x88041693cc00
Xan 22 21:20:20 boreal kernel: radeon :01:00.0: fence driver on ring 3 use
gpu addr 0x4c0c and cpu addr 0x88041693cc0c
Xan 22 21:20:20 boreal kernel: radeon :01:00.0: fence driver on ring 5 use
gpu addr 0x0005c418 and cpu addr 0xc9000471c418
Xan 22 21:20:20 boreal kernel: [drm] ring test on 0 succeeded in 1 usecs
Xan 22 21:20:20 boreal kernel: [drm] ring test on 3 succeeded in 2 usecs
Xan 22 21:20:20 boreal kernel: usb 6-1.6.2: reset high-speed USB device number
5 using ehci-pci
Xan 22 21:20:20 boreal kernel: [drm] ring test on 5 succeeded in 1 usecs
Xan 22 21:20:20 boreal kernel: [drm] UVD initialized successfully.
Xan 22 21:20:20 boreal kernel: [drm] ib test on ring 0 succeeded in 0 usecs
Xan 22 21:20:20 boreal kernel: [drm] ib test on ring 3 succeeded in 0 usecs

-- 
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/20150122/27f0313a/attachment.html>

[Bug 88719] While using nine gallium tracker and wine Dark Souls 2 causes gpu hang

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

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

Bug ID: 88719
   Summary: While using nine gallium tracker and wine Dark Souls 2
causes gpu hang
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: sobkas at gmail.com

Created attachment 112683
  --> https://bugs.freedesktop.org/attachment.cgi?id=112683=edit
A console log from gpu hang

While using nine gallium tracker and wine Dark Souls 2 causes gpu hang
It happens in no mans wharf while entering shacks or in the last bonfire of old
iron crown dlc.
It can be worked around by adding R600_DEBUG=notiling to env.

Kernel: 3.19.0-rc5-00119-gb942c65-dirty with resume patches:
https://bugs.freedesktop.org/attachment.cgi?id=112527
https://bugs.freedesktop.org/attachment.cgi?id=112528
Mesa: I have tried mesa git master(bc6e57e019bd2399a70acabcad21217aadf2944c),
https://github.com/iXit/Mesa-3D.git(both rebased on top of mesa git and clean
5ff32e24921c86b087085929e86720cc5b64be35 with additional fix for crash during
the start)
There was no difference

Video card:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba]

I have opened a bug on github: https://github.com/iXit/Mesa-3D/issues/63
and other person was able to reproduce it:
https://github.com/iXit/Mesa-3D/issues/59#issuecomment-70933707

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

[PATCH v2 2/3] drm/radeon: Restore GART table contents after pinning it in VRAM

[Michel Dänzer]

On 22.01.2015 18:06, Christian König wrote:
> Am 22.01.2015 um 08:30 schrieb Michel Dänzer:
>> From: Michel Dänzer 
>>
>> The GART table BO has to be moved out of VRAM for suspend/resume. Any
>> updates to the GART table during that time were silently dropped without
>> this change. This caused GPU lockups on resume in some cases, see the bug
>> reports referenced below.
>>
>> This might also make GPU reset more robust in some cases, as we no longer
>> rely on the GART table in VRAM being preserved across the GPU
>> lockup/reset.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Michel Dänzer 
>> ---
>>
>> v2: Add logic to radeon_gart_table_vram_pin directly instead of
>> reinstating
>>  radeon_gart_restore function
>>
>>   drivers/gpu/drm/radeon/radeon_gart.c | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
>> b/drivers/gpu/drm/radeon/radeon_gart.c
>> index a530932..0c8c739 100644
>> --- a/drivers/gpu/drm/radeon/radeon_gart.c
>> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
>> @@ -163,6 +163,14 @@ int radeon_gart_table_vram_pin(struct
>> radeon_device *rdev)
>>   r = radeon_bo_kmap(rdev->gart.robj, >gart.ptr);
>>   if (r)
>>   radeon_bo_unpin(rdev->gart.robj);
>> +else {
> 
> I would add a comment why we do this here.

Added in v3.


>> +int i;
>> +
>> +for (i = 0; i < rdev->gart.num_gpu_pages; i++)
>> +radeon_gart_set_page(rdev, i, rdev->gart.pages_entry[i]);
>> +mb();
>> +radeon_gart_tlb_flush(rdev);
> 
> That TLB flush won't work correctly because the table_addr isn't up to
> date yet.

Ugh, thanks for the catch.

>> +}
>>   radeon_bo_unreserve(rdev->gart.robj);
>>   rdev->gart.table_addr = gpu_addr;
> It's updated here instead. Maybe completely drop the local gpu_addr
> variable and update the table_addr directly instead.

I chose the less invasive fix in v3.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 2/3] drm/radeon: Restore GART table contents after pinning it in VRAM v3

[Michel Dänzer]

From: Michel Dänzer 

The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.

This might also make GPU reset more robust in some cases, as we no longer
rely on the GART table in VRAM being preserved across the GPU
lockup/reset.

v2: Add logic to radeon_gart_table_vram_pin directly instead of
reinstating radeon_gart_restore
v3: Move code after assignment of rdev->gart.table_addr so that the GART
TLB flush can work as intended, add code comment explaining why we're
doing this

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_gart.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index a530932..c7be612 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -165,6 +165,19 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
radeon_bo_unpin(rdev->gart.robj);
radeon_bo_unreserve(rdev->gart.robj);
rdev->gart.table_addr = gpu_addr;
+
+   if (!r) {
+   int i;
+
+   /* We might have dropped some GART table updates while it wasn't
+* mapped, restore all entries
+*/
+   for (i = 0; i < rdev->gart.num_gpu_pages; i++)
+   radeon_gart_set_page(rdev, i, 
rdev->gart.pages_entry[i]);
+   mb();
+   radeon_gart_tlb_flush(rdev);
+   }
+
return r;
 }

-- 
2.1.4

[PATCH] drm/atomic-helper: add connector->dpms() implementation

[Daniel Vetter]

This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.

Of course it also clamps everything that's not ON to OFF.

v2: Fix spelling in one comment.

v3: Don't do an async commit (Thierry)

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 75 +
 include/drm/drm_atomic_helper.h |  2 +
 2 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3f17933b1d2c..f693344d9573 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1887,6 +1887,81 @@ backoff:
 EXPORT_SYMBOL(drm_atomic_helper_page_flip);

 /**
+ * drm_atomic_helper_connector_dpms() - connector dpms helper implementation
+ * @connector: affected connector
+ * @mode: DPMS mode
+ *
+ * This is the main helper function provided by the atomic helper framework for
+ * implementing the legacy DPMS connector interface. It computes the new 
desired
+ * ->active state for the corresponding CRTC (if the connector is enabled) and
+ *  updates it.
+ */
+void drm_atomic_helper_connector_dpms(struct drm_connector *connector,
+ int mode)
+{
+   struct drm_mode_config *config = >dev->mode_config;
+   struct drm_atomic_state *state;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   struct drm_connector *tmp_connector;
+   int ret;
+   bool active = false;
+
+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+
+   connector->dpms = mode;
+   crtc = connector->state->crtc;
+
+   if (!crtc)
+   return;
+
+   /* FIXME: ->dpms has no return value so can't forward the -ENOMEM. */
+   state = drm_atomic_state_alloc(connector->dev);
+   if (!state)
+   return;
+
+   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+retry:
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+
+   WARN_ON(!drm_modeset_is_locked(>connection_mutex));
+
+   list_for_each_entry(tmp_connector, >connector_list, head) {
+   if (connector->state->crtc != crtc)
+   continue;
+
+   if (connector->dpms == DRM_MODE_DPMS_ON) {
+   active = true;
+   break;
+   }
+   }
+   crtc_state->active = active;
+
+   ret = drm_atomic_commit(state);
+   if (ret != 0)
+   goto fail;
+
+   /* Driver takes ownership of state on successful async commit. */
+   return;
+fail:
+   if (ret == -EDEADLK)
+   goto backoff;
+
+   drm_atomic_state_free(state);
+
+   WARN(1, "Driver bug: Changing ->active failed with ret=%i\n", ret);
+
+   return;
+backoff:
+   drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);
+
+   goto retry;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
+
+/**
  * DOC: atomic state reset and initialization
  *
  * Both the drm core and the atomic helpers assume that there is always the 
full
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 2095917ff8c7..cf501df9e513 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -82,6 +82,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event,
uint32_t flags);
+void drm_atomic_helper_connector_dpms(struct drm_connector *connector,
+ int mode);

 /* default implementations for state handling */
 void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
-- 
2.1.4

[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

[Michel Dänzer]

On 22.01.2015 18:28, Michel Dänzer wrote:
> On 22.01.2015 18:08, Christian König wrote:
>> Am 22.01.2015 um 08:31 schrieb Michel Dänzer:
>>> On 21.01.2015 18:22, Christian König wrote:
 Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
> From: Michel Dänzer 
>
> The GART table BO has to be moved out of VRAM for suspend/resume. Any
> updates to the GART table during that time were silently dropped
> without
> this change. This caused GPU lockups on resume in some cases, see
> the bug
> reports referenced below.
>
> This might also make GPU reset more robust in some cases, as we no
> longer
> rely on the GART table in VRAM being preserved across the GPU
> lockup/reset.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 
 Can we make that directly part of radeon_gart_table_vram_pin? Doesn't
 seem to make sense to always need to call both functions.
>>> Good point, fixed in v2.
>>>
>>>
 Additional to that couldn't we just stop mapping/unmapping the BO in
 radeon_gart_table_vram_pin? As far as I know CPU mapped BOs can still
 move around.
>>> You're probably thinking of userspace mappings. I think the kernel
>>> mapping would continue pointing to the same area of VRAM even while the
>>> BO is evicted from VRAM or pinned back to another area of VRAM.
>>
>>
>> Oh really? I was always under the impression that we only need to wait
>> for moves to complete and the kernel page tables would point to the new
>> location after that automatically.
>>
>> If that's not the case we might have a problem in the UVD code as well.
> 
> AFAIK it's not the case. If you can't confirm it either way from looking
> at the TTM code, maybe you can hack up a test to verify it?

Actually, I think I already tested it a couple of years ago, when I
tried un-pinning the fbdev BO while it's not being scanned out. I could
see fbcon scribbling over other BOs in VRAM when there was console
output. :)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

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

--- Comment #1 from Fabio Pedretti  ---
Created attachment 112679
  --> https://bugs.freedesktop.org/attachment.cgi?id=112679=edit
console output running with RADEON_DEBUG=fp

I have a Radeon RV530.

-- 
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/20150122/9b075d86/attachment.html>

[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

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

Bug ID: 88717
   Summary: [r300g] r300compiler error: Failed to translate rgb
instruction - while running a game with gallium-nine
   Product: Mesa
   Version: git
  Hardware: x86 (IA32)
   URL: https://github.com/iXit/Mesa-3D/issues/64
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: fabio.ped at libero.it
QA Contact: dri-devel at lists.freedesktop.org

When running Tales of Monkey Island game with quality >= 7/9 using iXit mesa
master branch I get the following error:

r300compiler error: Failed to translate rgb instruction.
r300 FP: Compiler Error:
Failed to translate rgb instruction.
Using a dummy shader instead.
r300: Initial fragment program

If useful I attached the output when running with "RADEON_DEBUG=fp wine
MonkeyIsland101.exe > ~/nine-tales-monkey-island.txt 2>&1".

According to axeldavy on the gallium-nine github issue tracker (
https://github.com/iXit/Mesa-3D/issues/64 ) the shader seems fine, it is likely
a r300 compiler error.

-- 
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/20150122/aee17f14/attachment-0001.html>

[PATCH 1/5] drm/atomic: Add drm_crtc_state->active

[Ville Syrjälä]

On Thu, Jan 22, 2015 at 05:15:26PM +0100, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 05:56:54PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 22, 2015 at 04:36:21PM +0100, Daniel Vetter wrote:
> > > This is the infrastructure for DPMS ported to the atomic world.
> > > Fundamental changes compare to legacy DPMS are:
> > > 
> > > - No more per-connector dpms state, instead there's just one per each
> > >   display pipeline. So if you clone either you have to unclone first
> > >   if you only want to switch off one screen, or you just switch of
> > >   everything (like all desktops do). This massively reduces complexity
> > >   for cloning since now there's no more half-enabled cloned configs to
> > >   consider.
> > > 
> > > - Only on/off, dpms standby/suspend are as dead as real CRTs. Again
> > >   reduces complexity a lot.
> > > 
> > > Now especially for backwards compat the really important part for dpms
> > > support is that dpms on always succeeds (except for hw death and
> > > unplugged cables ofc). Which means everything that could fail (like
> > > configuration checking, resources assignments and buffer management)
> > > must be done irrespective from ->active. ->active is really only a
> > > toggle to change the hardware state. More precisely:
> > > 
> > > - Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
> > >   Changes to ->active MUST always suceed if nothing else changes.
> > > 
> > > - Drivers using the atomic helpers MUST NOT look at ->active anywhere,
> > >   period. The helpers will take care of calling the respective
> > >   enable/modeset/disable hooks as necessary. As before the helpers
> > >   will carefully keep track of the state and not call any hooks
> > >   unecessarily, so still no double-disables or enables like with crtc
> > >   helpers.
> > > 
> > > - ->mode_set hooks are only called when the mode or output
> > >   configuration changes, not for changes in ->active state.
> > > 
> > > - Drivers which reconstruct the state objects in their ->reset hooks
> > >   or through some other hw state readout infrastructure must ensure
> > >   that ->active reflects actual hw state.
> > > 
> > > This just implements the core bits and helper logic, a subsequent
> > > patch will implement the helper code to implement legacy dpms with
> > > this.
> > 
> > So we now have multiple conflicting properties for the same thing? I
> > don't particularly relish that idea.
> > 
> > I suppose a rather easy way to way to deal with that would be to hide
> > the dpms properties from non-atomic clients, and conversly hide the
> > active property from legacy clients.
> 
> Which is pretty much what I do - you can only access the per-crtc ACTIVE
> property from the atomic ioctl, the per-connector dpms property is _not_
> exposed through atomic. Vice-versa legacy clients wont see atomic
> properties (and hence this new one) either.

Oh, OK. I didn't see anything obvious that would filter out the dpms
prop for non-atomic, nor do I see code to reject stuff in setprop/getprop
ioctls etc. But I suppose such stuff may be in flight and I've just not
paid attention.

> Is that good enough?

I suppose.

Another thing that came to mind wrt. the 'this can't fail rule' was
fb pinning. So is the rule now going to be that we need to pin even
when ACTIVE==false, or otherwise make sure all the FBs can be pinned
simultaneosly? If we don't want to everything pinned all the time when
ACTIVE==false, then we would need to prevent pinning of anything else
in the meantime to make sure we don't run out of address space.

-- 
Ville Syrjälä
Intel OTC

[PATCH 1/5] drm/atomic: Add drm_crtc_state->active

[Daniel Vetter]

On Thu, Jan 22, 2015 at 5:42 PM, Ville Syrjälä
 wrote:
>> Which is pretty much what I do - you can only access the per-crtc ACTIVE
>> property from the atomic ioctl, the per-connector dpms property is _not_
>> exposed through atomic. Vice-versa legacy clients wont see atomic
>> properties (and hence this new one) either.
>
> Oh, OK. I didn't see anything obvious that would filter out the dpms
> prop for non-atomic, nor do I see code to reject stuff in setprop/getprop
> ioctls etc. But I suppose such stuff may be in flight and I've just not
> paid attention.

On the atomic side the dpms prop is simple not decoded. The driver
/could/ do that itself, but that would be really pointless. In
getprops atomic ioctls are filtered out for non-atomic clients. Which
means that an atomic client could do a dpms on the connector through
the legacy setprop ioctl, but that would be rather stupid.

>> Is that good enough?
>
> I suppose.
>
> Another thing that came to mind wrt. the 'this can't fail rule' was
> fb pinning. So is the rule now going to be that we need to pin even
> when ACTIVE==false, or otherwise make sure all the FBs can be pinned
> simultaneosly? If we don't want to everything pinned all the time when
> ACTIVE==false, then we would need to prevent pinning of anything else
> in the meantime to make sure we don't run out of address space.

fb pinning is done irrespective of the state of active. So if you
update the fb while the display pipe is off the helpers will upin/pin
correctly. Imo that's totally fine, since failing to pin when setting
the display back to active really isn't a great thing. And we need to
be able to tell userspace when something has gone wrong with the
pinning (e.g. due to giant framebuffer or something).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 2/2] drm/rockchip: vop: set vop enabled after enable iommu

[Mark Yao]

there is a Bug that:
  vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.

after enable vop clocks and iommu regs, we can sure that
R/W vop regs and do vop plane flip is safe, so place
is_enabled = true after enable iommu is suitable.

Signed-off-by: Mark Yao 
---
Changes in v2:
- fix mistake that set is_enabled wrong.

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d03eb7e..fb25836 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -420,6 +420,11 @@ static void vop_enable(struct drm_crtc *crtc)
goto err_disable_aclk;
}

+   /*
+* At here, vop clock & iommu is enable, R/W vop regs would be safe.
+*/
+   vop->is_enabled = true;
+
spin_lock(>reg_lock);

VOP_CTRL_SET(vop, standby, 0);
@@ -430,8 +435,6 @@ static void vop_enable(struct drm_crtc *crtc)

drm_vblank_on(vop->drm_dev, vop->pipe);

-   vop->is_enabled = true;
-
return;

 err_disable_aclk:
@@ -462,6 +465,8 @@ static void vop_disable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, standby, 1);

spin_unlock(>reg_lock);
+
+   vop->is_enabled = false;
/*
 * disable dclk to stop frame scan, so we can safely detach iommu,
 */
@@ -471,8 +476,6 @@ static void vop_disable(struct drm_crtc *crtc)

clk_disable(vop->aclk);
clk_disable(vop->hclk);
-
-   vop->is_enabled = false;
 }

 /*
-- 
1.7.9.5

[PATCH v2 1/2] drm/rockchip: vop use is_enabled instead of dpms mode

[Mark Yao]

drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
 --> DRM_DPMS_ON: power on vop
 --> DRM_DPMS_SUSPEND: power off vop
 --> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.

Signed-off-by: Mark Yao 
---
Changes in v2:
- fix mistake that set is_enabled wrong.

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   34 ++-
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9a5c571..d03eb7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -81,7 +81,7 @@ struct vop {
struct drm_crtc crtc;
struct device *dev;
struct drm_device *drm_dev;
-   unsigned int dpms;
+   bool is_enabled;

int connector_type;
int connector_out_mode;
@@ -387,6 +387,9 @@ static void vop_enable(struct drm_crtc *crtc)
struct vop *vop = to_vop(crtc);
int ret;

+   if (vop->is_enabled)
+   return;
+
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
@@ -427,6 +430,8 @@ static void vop_enable(struct drm_crtc *crtc)

drm_vblank_on(vop->drm_dev, vop->pipe);

+   vop->is_enabled = true;
+
return;

 err_disable_aclk:
@@ -441,6 +446,9 @@ static void vop_disable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);

+   if (!vop->is_enabled)
+   return;
+
drm_vblank_off(crtc->dev, vop->pipe);

disable_irq(vop->irq);
@@ -463,6 +471,8 @@ static void vop_disable(struct drm_crtc *crtc)

clk_disable(vop->aclk);
clk_disable(vop->hclk);
+
+   vop->is_enabled = false;
 }

 /*
@@ -742,7 +752,7 @@ static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
struct vop *vop = to_vop(crtc);
unsigned long flags;

-   if (vop->dpms != DRM_MODE_DPMS_ON)
+   if (!vop->is_enabled)
return -EPERM;

spin_lock_irqsave(>irq_lock, flags);
@@ -759,8 +769,9 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
struct vop *vop = to_vop(crtc);
unsigned long flags;

-   if (vop->dpms != DRM_MODE_DPMS_ON)
+   if (!vop->is_enabled)
return;
+
spin_lock_irqsave(>irq_lock, flags);
vop_mask_write(vop, INTR_CTRL0, FS_INTR_MASK, FS_INTR_EN(0));
spin_unlock_irqrestore(>irq_lock, flags);
@@ -773,15 +784,8 @@ static const struct rockchip_crtc_funcs private_crtc_funcs 
= {

 static void vop_crtc_dpms(struct drm_crtc *crtc, int mode)
 {
-   struct vop *vop = to_vop(crtc);
-
DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);

-   if (vop->dpms == mode) {
-   DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
-   return;
-   }
-
switch (mode) {
case DRM_MODE_DPMS_ON:
vop_enable(crtc);
@@ -795,8 +799,6 @@ static void vop_crtc_dpms(struct drm_crtc *crtc, int mode)
DRM_DEBUG_KMS("unspecified mode %d\n", mode);
break;
}
-
-   vop->dpms = mode;
 }

 static void vop_crtc_prepare(struct drm_crtc *crtc)
@@ -934,9 +936,9 @@ static int vop_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
int ret;

-   /* when the page flip is requested, crtc's dpms should be on */
-   if (vop->dpms > DRM_MODE_DPMS_ON) {
-   DRM_DEBUG("failed page flip request at dpms[%d].\n", vop->dpms);
+   /* when the page flip is requested, crtc should be on */
+   if (!vop->is_enabled) {
+   DRM_DEBUG("page flip request rejected because crtc is off.\n");
return 0;
}

@@ -1302,7 +1304,7 @@ static int vop_initial(struct vop *vop)

clk_disable(vop->hclk);

-   vop->dpms = DRM_MODE_DPMS_OFF;
+   vop->is_enabled = false;

return 0;

-- 
1.7.9.5

[PATCH v2 0/2] drm/rockchip: Optimization vop dpms control

[Mark Yao]

drm dpms have many power modes, ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
 --> DRM_DPMS_ON: power on vop
 --> DRM_DPMS_SUSPEND: power off vop
 --> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.

another problem at vop_crtc_dpms:
  vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.

Changes in v2:
- fix mistake that set is_enabled wrong.

Mark Yao (2):
  drm/rockchip: vop use is_enabled instead of dpms mode
  drm/rockchip: vop: set vop enabled after enable iommu

 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |   17 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |3 +--
 3 files changed, 7 insertions(+), 15 deletions(-)

-- 
1.7.9.5

[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

[Michel Dänzer]

On 22.01.2015 18:08, Christian König wrote:
> Am 22.01.2015 um 08:31 schrieb Michel Dänzer:
>> On 21.01.2015 18:22, Christian König wrote:
>>> Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
 From: Michel Dänzer 

 The GART table BO has to be moved out of VRAM for suspend/resume. Any
 updates to the GART table during that time were silently dropped
 without
 this change. This caused GPU lockups on resume in some cases, see
 the bug
 reports referenced below.

 This might also make GPU reset more robust in some cases, as we no
 longer
 rely on the GART table in VRAM being preserved across the GPU
 lockup/reset.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
 Cc: stable at vger.kernel.org
 Signed-off-by: Michel Dänzer 
>>> Can we make that directly part of radeon_gart_table_vram_pin? Doesn't
>>> seem to make sense to always need to call both functions.
>> Good point, fixed in v2.
>>
>>
>>> Additional to that couldn't we just stop mapping/unmapping the BO in
>>> radeon_gart_table_vram_pin? As far as I know CPU mapped BOs can still
>>> move around.
>> You're probably thinking of userspace mappings. I think the kernel
>> mapping would continue pointing to the same area of VRAM even while the
>> BO is evicted from VRAM or pinned back to another area of VRAM.
> 
> 
> Oh really? I was always under the impression that we only need to wait
> for moves to complete and the kernel page tables would point to the new
> location after that automatically.
> 
> If that's not the case we might have a problem in the UVD code as well.

AFAIK it's not the case. If you can't confirm it either way from looking
at the TTM code, maybe you can hack up a test to verify it?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 1/5] drm/atomic: Add drm_crtc_state->active

[Ville Syrjälä]

On Thu, Jan 22, 2015 at 04:36:21PM +0100, Daniel Vetter wrote:
> This is the infrastructure for DPMS ported to the atomic world.
> Fundamental changes compare to legacy DPMS are:
> 
> - No more per-connector dpms state, instead there's just one per each
>   display pipeline. So if you clone either you have to unclone first
>   if you only want to switch off one screen, or you just switch of
>   everything (like all desktops do). This massively reduces complexity
>   for cloning since now there's no more half-enabled cloned configs to
>   consider.
> 
> - Only on/off, dpms standby/suspend are as dead as real CRTs. Again
>   reduces complexity a lot.
> 
> Now especially for backwards compat the really important part for dpms
> support is that dpms on always succeeds (except for hw death and
> unplugged cables ofc). Which means everything that could fail (like
> configuration checking, resources assignments and buffer management)
> must be done irrespective from ->active. ->active is really only a
> toggle to change the hardware state. More precisely:
> 
> - Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
>   Changes to ->active MUST always suceed if nothing else changes.
> 
> - Drivers using the atomic helpers MUST NOT look at ->active anywhere,
>   period. The helpers will take care of calling the respective
>   enable/modeset/disable hooks as necessary. As before the helpers
>   will carefully keep track of the state and not call any hooks
>   unecessarily, so still no double-disables or enables like with crtc
>   helpers.
> 
> - ->mode_set hooks are only called when the mode or output
>   configuration changes, not for changes in ->active state.
> 
> - Drivers which reconstruct the state objects in their ->reset hooks
>   or through some other hw state readout infrastructure must ensure
>   that ->active reflects actual hw state.
> 
> This just implements the core bits and helper logic, a subsequent
> patch will implement the helper code to implement legacy dpms with
> this.

So we now have multiple conflicting properties for the same thing? I
don't particularly relish that idea.

I suppose a rather easy way to way to deal with that would be to hide
the dpms properties from non-atomic clients, and conversly hide the
active property from legacy clients.

> 
> v2: Rebase on top of the drm ioctl work:
> - Move crtc checks to the core check function.
> - Also check for ->active_changed when deciding whether a modeset
>   might happen (for the ALLOW_MODESET mode).
> - Expose the ->active state with an atomic prop.
> 
> v3: Review from Rob
> - Spelling fix in comment.
> - Extract needs_modeset helper to consolidate the ->mode_changed ||
>   ->active_changed checks.
> 
> v4: Fixup fumble between crtc->state and crtc_state.
> 
> Cc: Rob Clark 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c| 18 +++--
>  drivers/gpu/drm/drm_atomic_helper.c | 54 
> +
>  drivers/gpu/drm/drm_crtc.c  | 10 +++
>  include/drm/drm_crtc.h  |  3 +++
>  4 files changed, 78 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1e38dfc8e462..ee68267bb326 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -241,7 +241,13 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   struct drm_crtc_state *state, struct drm_property *property,
>   uint64_t val)
>  {
> - if (crtc->funcs->atomic_set_property)
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + /* FIXME: Mode prop is missing, which also controls ->enable. */
> + if (property == config->prop_active) {
> + state->active = val;
> + } else if (crtc->funcs->atomic_set_property)
>   return crtc->funcs->atomic_set_property(crtc, state, property, 
> val);
>   return -EINVAL;
>  }
> @@ -282,6 +288,13 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>*
>* TODO: Add generic modeset state checks once we support those.
>*/
> +
> + if (state->active && !state->enable) {
> + DRM_DEBUG_KMS("[CRTC:%d] active without enabled\n",
> +   crtc->base.id);
> + return -EINVAL;
> + }
> +
>   return 0;
>  }
>  
> @@ -976,7 +989,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>   if (!crtc)
>   continue;
>  
> - if (crtc_state->mode_changed) {
> + if (crtc_state->mode_changed ||
> + crtc_state->active_changed) {
>   DRM_DEBUG_KMS("[CRTC:%d] requires full 
> modeset\n",
> crtc->base.id);
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> 

[Bug 88658] (bisected) Slow video playback on Kabini

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

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

--- Comment #7 from jtossenb  ---
(In reply to smoki from comment #6)
>  Well he can just try to revert this one again, Kodi seems to does not like
> that:
> 
>  http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/
> r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786

Thanks, it was a good idea!
I've built Mesa 10.4.2 with the reverted commit and the problem solved, Kodi
works fine now.
I used the original 3.18.2-2-ARCH kernel during the test.

-- 
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/20150122/640988c4/attachment.html>

[Bug 87796] radeonsi 120Hz graphic glitches

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

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

--- Comment #17 from Alex Deucher  ---
(In reply to Clésio Luiz from comment #16)
> I didn't compiled the driver myself, got it from a repository. I'm afraid
> that applying a patch and compile the driver is out of my knowledge... But
> I'm more than happy to follow instructions.

If you can download the source to your kernel, copy the patch to the root of
the kernel tree then do the following:

patch -p1 -i dpm_vblank_dump.diff
make -j5
sudo make modules_install
sudo make install

Then reboot and select the new kernel from the grub menu.

-- 
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/20150122/880ce3a0/attachment.html>

[PATCH 1/5] drm/atomic: Add drm_crtc_state->active

[Daniel Vetter]

On Thu, Jan 22, 2015 at 05:56:54PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 22, 2015 at 04:36:21PM +0100, Daniel Vetter wrote:
> > This is the infrastructure for DPMS ported to the atomic world.
> > Fundamental changes compare to legacy DPMS are:
> > 
> > - No more per-connector dpms state, instead there's just one per each
> >   display pipeline. So if you clone either you have to unclone first
> >   if you only want to switch off one screen, or you just switch of
> >   everything (like all desktops do). This massively reduces complexity
> >   for cloning since now there's no more half-enabled cloned configs to
> >   consider.
> > 
> > - Only on/off, dpms standby/suspend are as dead as real CRTs. Again
> >   reduces complexity a lot.
> > 
> > Now especially for backwards compat the really important part for dpms
> > support is that dpms on always succeeds (except for hw death and
> > unplugged cables ofc). Which means everything that could fail (like
> > configuration checking, resources assignments and buffer management)
> > must be done irrespective from ->active. ->active is really only a
> > toggle to change the hardware state. More precisely:
> > 
> > - Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
> >   Changes to ->active MUST always suceed if nothing else changes.
> > 
> > - Drivers using the atomic helpers MUST NOT look at ->active anywhere,
> >   period. The helpers will take care of calling the respective
> >   enable/modeset/disable hooks as necessary. As before the helpers
> >   will carefully keep track of the state and not call any hooks
> >   unecessarily, so still no double-disables or enables like with crtc
> >   helpers.
> > 
> > - ->mode_set hooks are only called when the mode or output
> >   configuration changes, not for changes in ->active state.
> > 
> > - Drivers which reconstruct the state objects in their ->reset hooks
> >   or through some other hw state readout infrastructure must ensure
> >   that ->active reflects actual hw state.
> > 
> > This just implements the core bits and helper logic, a subsequent
> > patch will implement the helper code to implement legacy dpms with
> > this.
> 
> So we now have multiple conflicting properties for the same thing? I
> don't particularly relish that idea.
> 
> I suppose a rather easy way to way to deal with that would be to hide
> the dpms properties from non-atomic clients, and conversly hide the
> active property from legacy clients.

Which is pretty much what I do - you can only access the per-crtc ACTIVE
property from the atomic ioctl, the per-connector dpms property is _not_
exposed through atomic. Vice-versa legacy clients wont see atomic
properties (and hence this new one) either.

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

[RFC v2 7/7] s5p-cec: Add s5p-cec driver

[Kamil Debski]

Add CEC interface driver present in the Samsung Exynos range of
SoCs.

The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c

Signed-off-by: Kamil Debski 
---
 drivers/media/platform/Kconfig |7 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +++
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 ++
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 +++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  290 
 drivers/media/platform/s5p-cec/s5p_cec.h   |  113 
 8 files changed, 756 insertions(+)
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 71e8873..4d199ac 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -156,6 +156,13 @@ config VIDEO_MEM2MEM_DEINTERLACE
help
Generic deinterlacing V4L2 driver.

+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS)
+   default n
+   ---help---
+ This is a v4l2 driver for Samsung S5P HDMI CEC interface.
+
 config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 3ec1547..17be832 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += 
m2m-deinterlace.o

 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..7f84226
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
+
+
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec hardware
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _EXYNOS_HDMI_CEC_H_
+#define _EXYNOS_HDMI_CEC_H_ __FILE__
+
+#include 
+#include 
+#include "s5p_cec.h"
+
+void s5p_cec_set_divider(struct s5p_cec_dev *cec);
+void s5p_cec_enable_rx(struct s5p_cec_dev *cec);
+void s5p_cec_mask_rx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_unmask_rx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_mask_tx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_unmask_tx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_reset(struct s5p_cec_dev *cec);
+void s5p_cec_tx_reset(struct s5p_cec_dev *cec);
+void s5p_cec_rx_reset(struct s5p_cec_dev *cec);
+void s5p_cec_threshold(struct s5p_cec_dev *cec);
+void s5p_cec_copy_packet(struct s5p_cec_dev *cec, char *data, size_t count);
+void s5p_cec_set_addr(struct s5p_cec_dev *cec, u32 addr);
+u32 s5p_cec_get_status(struct s5p_cec_dev *cec);
+void s5p_clr_pending_tx(struct s5p_cec_dev *cec);
+void s5p_clr_pending_rx(struct s5p_cec_dev *cec);
+void s5p_cec_get_rx_buf(struct s5p_cec_dev *cec, u32 size, u8 *buffer);
+
+#endif /* _EXYNOS_HDMI_CEC_H_ */
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
new file mode 100644
index 000..65fe55e
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
@@ -0,0 +1,208 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
+ *
+ * Copyright (c) 2009, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * cec ftn file for Samsung TVOUT driver
+ *
+ * This program is free software; you can redistribute 

[RFC v2 6/7] adv7511: add cec support.

[Kamil Debski]

From: Hans Verkuil 

Add CEC support to the adv7511 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7511.c |  325 ++-
 include/media/adv7511.h |6 +-
 2 files changed, 323 insertions(+), 8 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 81736aa..63ec6c1 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 static int debug;
 module_param(debug, int, 0644);
@@ -91,6 +92,12 @@ struct adv7511_state {
int chip_revision;
uint8_t i2c_edid_addr;
uint8_t i2c_cec_addr;
+
+   struct i2c_client *i2c_cec;
+   u8   cec_addr[3];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
@@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client 
*client,
return ret;
 }

-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, 
uint8_t *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
 {
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -237,6 +244,33 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, 
uint16_t len, uint8_t
v4l2_err(sd, "%s: i2c read error\n", __func__);
 }

+static inline int cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+
+   return i2c_smbus_read_byte_data(state->i2c_cec, reg);
+}
+
+static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+   int ret;
+   int i;
+
+   for (i = 0; i < 3; i++) {
+   ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val);
+   if (ret == 0)
+   return 0;
+   }
+   v4l2_err(sd, "%s: I2C Write Problem\n", __func__);
+   return ret;
+}
+
+static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+}
+
 static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd)
 {
return adv7511_rd(sd, 0x42) & MASK_ADV7511_HPD_DETECT;
@@ -381,16 +415,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
 #ifdef CONFIG_VIDEO_ADV_DEBUG
 static void adv7511_inv_register(struct v4l2_subdev *sd)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, "0x000-0x0ff: Main Map\n");
+   if (state->i2c_cec)
+   v4l2_info(sd, "0x100-0x1ff: CEC Map\n");
 }

 static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register 
*reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
reg->size = 1;
switch (reg->reg >> 8) {
case 0:
reg->val = adv7511_rd(sd, reg->reg & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   reg->val = cec_read(sd, reg->reg & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -401,10 +447,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, 
struct v4l2_dbg_register *

 static int adv7511_s_register(struct v4l2_subdev *sd, const struct 
v4l2_dbg_register *reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
switch (reg->reg >> 8) {
case 0:
adv7511_wr(sd, reg->reg & 0xff, reg->val & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   cec_write(sd, reg->reg & 0xff, reg->val & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -418,6 +472,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
 {
struct adv7511_state *state = get_adv7511_state(sd);
struct adv7511_state_edid *edid = >edid;
+   int i;

static const char * const states[] = {
"in reset",
@@ -486,7 +541,20 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
else
v4l2_info(sd, "no timings set\n");
v4l2_info(sd, "i2c edid addr: 0x%x\n", state->i2c_edid_addr);
+
+   if (state->i2c_cec == NULL)
+   return 0;
+
v4l2_info(sd, "i2c cec addr: 0x%x\n", state->i2c_cec_addr);
+
+   if (cec_read(sd, 0x4e) & 0x01) {
+   v4l2_info(sd, "cec: enabled\n");
+  

[RFC v2 5/7] adv7604: add cec support.

[Kamil Debski]

From: Hans Verkuil 

Add CEC support ot the adv7604 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7604.c |  182 +++
 1 file changed, 182 insertions(+)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..f0ea929 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 

 static int debug;
 module_param(debug, int, 0644);
@@ -158,6 +159,10 @@ struct adv7604_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+   u8   cec_addr[3];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -1935,6 +1940,176 @@ static int adv7604_set_format(struct v4l2_subdev *sd, 
struct v4l2_subdev_fh *fh,
return 0;
 }

+static void adv7604_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+   if ((cec_read(sd, 0x11) & 0x01) == 0) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+   return;
+   }
+
+   if (tx_raw_status & 0x02) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n", 
__func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void 
*)CEC_TX_STATUS_ARB_LOST);
+   return;
+   }
+   if (tx_raw_status & 0x04) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void 
*)CEC_TX_STATUS_RETRY_TIMEOUT);
+   return;
+   }
+   if (tx_raw_status & 0x01) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void 
*)CEC_TX_STATUS_OK);
+   return;
+   }
+}
+
+static void adv7604_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+   struct cec_msg msg;
+   u8 cec_irq;
+
+   /* cec controller */
+   cec_irq = io_read(sd, 0x4d) & 0x0f;
+   if (!cec_irq)
+   return;
+
+   v4l2_dbg(1, debug, sd, "%s: cec: irq 0x%x\n", __func__, cec_irq);
+   adv7604_cec_tx_raw_status(sd, cec_irq);
+   if (cec_irq & 0x08) {
+   msg.len = cec_read(sd, 0x25) & 0x1f;
+   if (msg.len > 16)
+   msg.len = 16;
+
+   if (msg.len) {
+   u8 i;
+
+   for (i = 0; i < msg.len; i++)
+   msg.msg[i] = cec_read(sd, i + 0x15);
+   cec_write(sd, 0x26, 0x01); /* re-enable rx */
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, );
+   }
+   }
+
+   /* note: the bit order is swapped between 0x4d and 0x4e */
+   cec_irq = ((cec_irq & 0x08) >> 3) | ((cec_irq & 0x04) >> 1) |
+ ((cec_irq & 0x02) << 1) | ((cec_irq & 0x01) << 3);
+   io_write(sd, 0x4e, cec_irq);
+
+   if (handled)
+   *handled = true;
+}
+
+static int adv7604_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+   struct adv7604_state *state = to_state(sd);
+   
+   if (!state->cec_enabled_adap && enable) {
+   cec_write_and_or(sd, 0x2a, 0xfe, 0x01); /* power up cec */
+   cec_write(sd, 0x2c, 0x01);  /* cec soft reset */
+   cec_write_and_or(sd, 0x11, 0xfe, 0);  /* initially disable tx */
+   /* enabled irqs: */
+   /* tx: ready */
+   /* tx: arbitration lost */
+   /* tx: retry timeout */
+   /* rx: ready */
+   io_write_and_or(sd, 0x50, 0xf0, 0x0f);
+   cec_write(sd, 0x26, 0x01);/* enable rx */
+   } else if (state->cec_enabled_adap && !enable) {
+   io_write_and_or(sd, 0x50, 0xf0, 0x00);  /* disable cec 
interrupts */
+   cec_write_and_or(sd, 0x27, 0x8f, 0x70); /* disable address mask 
1-3 */
+   cec_write_and_or(sd, 0x2a, 0xfe, 0x00); /* power down cec 
section */
+   state->cec_valid_addrs = 0;
+   }
+   state->cec_enabled_adap = enable;
+   return 0;
+}
+
+#define ADV7604_MAX_ADDRS (3)
+
+static int adv7604_cec_log_addr(struct v4l2_subdev *sd, u8 addr)
+{
+   struct adv7604_state *state = to_state(sd);
+   unsigned i, free_idx = ADV7604_MAX_ADDRS;
+   
+   if (!state->cec_enabled_adap)
+   return -EIO;
+
+   for (i = 0; i < ADV7604_MAX_ADDRS; i++) {
+   bool is_valid = state->cec_valid_addrs & (1 << i);
+
+   if (free_idx == ADV7604_MAX_ADDRS && !is_valid)
+   free_idx = i;
+   if (is_valid && 

[RFC v2 4/7] v4l2-subdev: add cec ops.

[Kamil Debski]

From: Hans Verkuil 

Add callbacks to the v4l2_subdev_video_ops.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 include/media/v4l2-subdev.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5beeb87..fdf620d 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -40,6 +40,9 @@
 #define V4L2_SUBDEV_IR_TX_NOTIFY   _IOW('v', 1, u32)
 #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001

+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32)
+#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg)
+
 struct v4l2_device;
 struct v4l2_ctrl_handler;
 struct v4l2_event_subscription;
@@ -48,6 +51,7 @@ struct v4l2_subdev;
 struct v4l2_subdev_fh;
 struct tuner_setup;
 struct v4l2_mbus_frame_desc;
+struct cec_msg;

 /* decode_vbi_line */
 struct v4l2_decode_vbi_line {
@@ -354,6 +358,10 @@ struct v4l2_subdev_video_ops {
 const struct v4l2_mbus_config *cfg);
int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
   unsigned int *size);
+   int (*cec_enable)(struct v4l2_subdev *sd, bool enable);
+   int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+   int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg);
+   void (*cec_transmit_timed_out)(struct v4l2_subdev *sd);
 };

 /*
-- 
1.7.9.5

[RFC v2 3/7] cec: add new framework for cec support.

[Kamil Debski]

Add the CEC framework.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski at samsung.com: change kthread handling when setting logical
address]
[k.debski at samsung.com: code cleanup]
[k.debski at samsung.com: add missing CEC commands to match spec]
[k.debski at samsung.com: add RC framework support]
[k.debski at samsung.com: move and edit documentation]
---
 Documentation/cec.txt|  318 +
 drivers/media/Kconfig|5 +
 drivers/media/Makefile   |2 +
 drivers/media/cec.c  |  ++
 include/media/cec.h  |  136 ++
 include/uapi/linux/cec.h |  276 
 6 files changed, 1848 insertions(+)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..8a04be3
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,318 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware. Adding to
+the flexibility of the framework it enables to set which parts of the CEC
+protocol processing is handled by the hardware, by the driver and by the
+userspace application.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables cosumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physicall addressis determined by physical connection
+between devices.
+
+The protocol enables control of compatible devices with a single remote.
+Synchronous power on/standby, instant playback with changing the content source
+on the TV.
+
+The Kernel Interface
+
+
+CEC Adaptor
+---
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+/* The maximum number of logical addresses one device can be assigned to.
+ * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+ * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */
+#define CEC_MAX_LOG_ADDRS 4
+
+/* The "Primary Device Type" */
+#define CEC_PRIM_DEVTYPE_TV0
+#define CEC_PRIM_DEVTYPE_RECORD1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK  4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM   5
+#define CEC_PRIM_DEVTYPE_SWITCH6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The "All Device Types" flags (CEC 2.0) */
+#define CEC_FL_ALL_DEVTYPE_TV  (1 << 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD  (1 << 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER   (1 << 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 << 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH  (1 << 2)
+/* And if you wondering what happened to VIDEOPROC devices: those should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV   0
+#define CEC_LOG_ADDR_TYPE_RECORD   1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM  4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_VERSION_1_4B   5
+#define CEC_VERSION_2_06
+
+struct cec_adapter {
+   /* internal fields removed */
+
+   u16 phys_addr;
+   u32 capabilities;
+   u8 version;
+   u8 num_log_addrs;
+   u8 prim_device[CEC_MAX_LOG_ADDRS];
+   u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+   u8 log_addr[CEC_MAX_LOG_ADDRS];
+
+   int (*adap_enable)(struct cec_adapter *adap, bool enable);
+   int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+   int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg);
+   void (*adap_transmit_timed_out)(struct cec_adapter *adap);
+
+   int (*received_tv)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_record)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_tuner)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_playback)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_audiosystem)(struct cec_adapter *adap, struct cec_msg 
*msg);
+   int (*received_switch)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_videoproc)(struct cec_adapter *adap, struct cec_msg 

[RFC v2 2/7] media: rc: Add cec protocol handling

[Kamil Debski]

Add cec protocol handling the RC framework.

Signed-off-by: Kamil Debski 
---
 drivers/media/rc/keymaps/Makefile |1 +
 drivers/media/rc/keymaps/rc-cec.c |  133 +
 drivers/media/rc/rc-main.c|1 +
 include/media/rc-core.h   |1 +
 include/media/rc-map.h|5 +-
 5 files changed, 140 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+   rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c 
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..f2826c5
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,133 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+/* CEC Spec "High-Definition Multimedia Interface Specification" can be 
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+   { 0x00, KEY_SELECT }, /* XXX CEC Spec: Select, should it be KEY_SELECT 
or KEY_OK? */
+   { 0x01, KEY_UP },
+   { 0x02, KEY_DOWN },
+   { 0x03, KEY_LEFT },
+   { 0x04, KEY_RIGHT },
+   /* XXX 0x05-0x08 CEC Spec: Right-Up, Right-Down, Left-Up, Left-Down */
+   { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */
+   /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device’s current state. */
+   { 0x0a, KEY_SETUP },
+   { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+   { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+   { 0x0d, KEY_EXIT },
+   /* 0x0e-0x1f: Reserved */
+   /* 0x20-0x29: Keys 0 to 9 */
+   { 0x20, KEY_0 },
+   { 0x21, KEY_1 },
+   { 0x22, KEY_2 },
+   { 0x23, KEY_3 },
+   { 0x24, KEY_4 },
+   { 0x25, KEY_5 },
+   { 0x26, KEY_6 },
+   { 0x27, KEY_7 },
+   { 0x28, KEY_8 },
+   { 0x29, KEY_9 },
+   { 0x2a, KEY_DOT },
+   { 0x2b, KEY_ENTER },
+   { 0x2c, KEY_CLEAR },
+   /* 0x2d-0x2e: Reserved */
+   /* XXX 0x2f: CEC Spec: Next Favorite */
+   { 0x30, KEY_CHANNELUP },
+   { 0x31, KEY_CHANNELDOWN },
+   { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+   { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+   /* XXX 0x34: CEC Spec: Input Select */
+   { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+   { 0x36, KEY_HELP },
+   { 0x37, KEY_PAGEUP },
+   { 0x38, KEY_PAGEDOWN },
+   /* 0x39-0x3f: Reserved */
+   { 0x40, KEY_POWER },
+   { 0x41, KEY_VOLUMEUP },
+   { 0x42, KEY_VOLUMEDOWN },
+   { 0x43, KEY_MUTE },
+   { 0x44, KEY_PLAY },
+   { 0x45, KEY_STOP }, /* XXX CEC Spec: Stop, what about KEY_STOPCD? */
+   { 0x46, KEY_PAUSE },/* XXX CEC Spec: Pause, what about KEY_PAUSECD? */
+   { 0x47, KEY_RECORD },
+   { 0x48, KEY_REWIND },
+   { 0x49, KEY_FASTFORWARD },
+   { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+   { 0x4b, KEY_FORWARD },
+   { 0x4c, }, /* XXX */
+   { 0x4d, KEY_STOP }, /* XXX CEC Spec: Stop-Record, what about 
KEY_STOPCD? */
+   { 0x4e, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record, what about 
KEY_PAUSECD? */
+   /* 0x4f: Reserved */
+   { 0x50, KEY_ANGLE },
+   { 0x51, KEY_SUBTITLE }, /* XXX CEC Spec: Sub picture, should it be 
KEY_SUBTITLE or something else? */
+   { 0x52, KEY_VIDEO }, /* XXX CEC Spec: Video on Demand / input.h: AL 
Movie Browser, maybe KEY_DIRECTORY? */
+   { 0x53, KEY_EPG },
+   { 0x54, KEY_TIME }, /* XXX CEC Spec: Timer */
+   { 0x55, KEY_CONFIG },
+   /* 0x56-0x5f: Reserved */
+   { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */
+   { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */
+   { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */
+   { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record Function */
+   { 0x64, KEY_STOP }, /* XXX 

[RFC v2 1/7] ARM: dts: add hdmi cec driver to exynos4412-odroidu3

[Kamil Debski]

Add device tree node for the s5p-cec hdmi CEC driver.

Signed-off-by: Kamil Debski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |7 +++
 arch/arm/boot/dts/exynos4412-odroidu3.dts   |   13 +
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3fbf588..0aa6664 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -403,4 +403,11 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index c8a64be..934c9f8 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,19 @@
linux,default-trigger = "heartbeat";
};
};
+
+   hdmicec: cec at 100B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x100B 0x200>;
+   interrupts = <0 114 0>;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   cec-gpio = < 6 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "okay";
+   };
 };

  {
-- 
1.7.9.5

[RFC v2 0/7] HDMI CEC framework

[Kamil Debski]

Hi,

This is the second version of my attempt at the CEC framework patches.
As mentioned in the previous cover letter the original work was done by
Hans Verkuil, but he was short of time and the CEC framework was stalled
for some time. The original cover letter attached below will surely shed
more light on the history of these patches.

Thank you very much for your comments to the v1 . It was near the end of the
year when I sent the previous version, so I really appreciate your time.

Apart from fixes and additions to the documentation this version of the RFC
tackles the subject of processing the key down/up from the remote. To make
the solution most flexible there are two modes. In the default the mesages
related to key presses on the remote are parsed and handled by the CEC
framework. In the pass-through mode the key down/up messages are not handled
by the CEC framewrok and are passed to the userspace. The mode can be changed by
an appropriate ioctl. I would especially welcome comment to the CEC keymap.

Best wishes,
Kamil Debski

Changes since v2

- documentation edited and moved to the Documentation folder
- added key up/down message handling
- add missing CEC commands to the cec.h file

Original cover letter
=

Hi,

The work on a common CEC framework was started over three years ago by Hans
Verkuil. Unfortunately the work has stalled. As I have received the task of
creating a driver for the CEC interface module present on the Exynos range of
SoCs, I got in touch with Hans. He repied that the work stalled due to his
lack of time.

The driver was done in the most part and there were only minor fixes that needed
to be implemented. I would like to bring back the discussion on a common CEC
interface framework.

There are a few things that were still left as TODO, I think they might need
some discussion - for instance the way how the remote controls should be
handled.

Best wishes,
Kamil Debski

Original RFC by Hans Verkuil/Martin Bugge
=
https://www.mail-archive.com/linux-media at vger.kernel.org/msg28735.html

Hans Verkuil (3):
  v4l2-subdev: add cec ops.
  adv7604: add cec support.
  adv7511: add cec support.

Kamil Debski (4):
  ARM: dts: add hdmi cec driver to exynos4412-odroidu3
  media: rc: Add cec protocol handling
  cec: add new framework for cec support.
  s5p-cec: Add s5p-cec driver

 Documentation/cec.txt  |  318 ++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|7 +
 arch/arm/boot/dts/exynos4412-odroidu3.dts  |   13 +
 drivers/media/Kconfig  |5 +
 drivers/media/Makefile |2 +
 drivers/media/cec.c|  
 drivers/media/i2c/adv7511.c|  325 +-
 drivers/media/i2c/adv7604.c|  182 
 drivers/media/platform/Kconfig |7 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 ++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  290 +
 drivers/media/platform/s5p-cec/s5p_cec.h   |  113 ++
 drivers/media/rc/keymaps/Makefile  |1 +
 drivers/media/rc/keymaps/rc-cec.c  |  133 +++
 drivers/media/rc/rc-main.c |1 +
 include/media/adv7511.h|6 +-
 include/media/cec.h|  136 +++
 include/media/rc-core.h|1 +
 include/media/rc-map.h |5 +-
 include/media/v4l2-subdev.h|8 +
 include/uapi/linux/cec.h   |  276 +
 25 files changed, 3277 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

-- 
1.7.9.5

[PATCH 03/36] drm/plane: Add optional ->atomic_disable() callback

[Gustavo Padovan]

2015-01-20 Thierry Reding :

> From: Thierry Reding 
> 
> In order to prevent drivers from having to perform the same checks over
> and over again, add an optional ->atomic_disable callback which the core
> calls under the right circumstances.
> 
> v2: pass old state and detect edges to avoid calling ->atomic_disable on
> already disabled planes, remove redundant comment (Daniel Vetter)
> 
> v3: rename helper to drm_atomic_plane_disabling() to clarify that it is
> checking for transitions, move helper to drm_atomic_helper.h, clarify
> check for !old_state and its relation to transitional helpers
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  9 -
>  drivers/gpu/drm/drm_plane_helper.c  | 10 +-
>  include/drm/drm_atomic_helper.h | 37 
> +
>  include/drm/drm_plane_helper.h  |  3 +++
>  4 files changed, 57 insertions(+), 2 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 1/2] drm/rockchip: vop use is_enabled instead of dpms mode

[Mark yao]

On 2015年01月22日 15:33, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 03:05:32PM +0800, Mark Yao wrote:
>> drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
>> but vop only have enable/disable mode, maybe case such bug:
>>   --> DRM_DPMS_ON: power on vop
>>   --> DRM_DPMS_SUSPEND: power off vop
>>   --> DRM_DPMS_OFF: already power off at SUSPEND, crash
>> so use a bool val is more suitable.
>>
>> Signed-off-by: Mark Yao 
> Long term I highly suggest you switch to atomic, since with atomic all the
> legacy dpms modes are remapped to a simple on/off. Also the new atomic
> helpers make sure that your backend isn't called multiple times, so you
> can ditch all your is_enabled tracking with that.
> -Daniel
Hi Daniel
is there some documents teach me how to switch to atomic easily?
I found many other drivers which use atomic also remap dpms modes to 
simple on/off at its driver,
and I don't know where atomic helper do the remapped, can you give me 
some suggestions?

- Mark.
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   34 
>> ++-
>>   1 file changed, 18 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 9a5c571..f278c09 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -81,7 +81,7 @@ struct vop {
>>  struct drm_crtc crtc;
>>  struct device *dev;
>>  struct drm_device *drm_dev;
>> -unsigned int dpms;
>> +bool is_enabled;
>>   
>>  int connector_type;
>>  int connector_out_mode;
>> @@ -387,6 +387,9 @@ static void vop_enable(struct drm_crtc *crtc)
>>  struct vop *vop = to_vop(crtc);
>>  int ret;
>>   
>> +if (vop->is_enabled)
>> +return;
>> +
>>  ret = clk_enable(vop->hclk);
>>  if (ret < 0) {
>>  dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
>> @@ -427,6 +430,8 @@ static void vop_enable(struct drm_crtc *crtc)
>>   
>>  drm_vblank_on(vop->drm_dev, vop->pipe);
>>   
>> +vop->is_enabled = false;
>> +
>>  return;
>>   
>>   err_disable_aclk:
>> @@ -441,6 +446,9 @@ static void vop_disable(struct drm_crtc *crtc)
>>   {
>>  struct vop *vop = to_vop(crtc);
>>   
>> +if (vop->is_enabled)
>> +return;
>> +
>>  drm_vblank_off(crtc->dev, vop->pipe);
>>   
>>  disable_irq(vop->irq);
>> @@ -463,6 +471,8 @@ static void vop_disable(struct drm_crtc *crtc)
>>   
>>  clk_disable(vop->aclk);
>>  clk_disable(vop->hclk);
>> +
>> +vop->is_enabled = false;
>>   }
>>   
>>   /*
>> @@ -742,7 +752,7 @@ static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
>>  struct vop *vop = to_vop(crtc);
>>  unsigned long flags;
>>   
>> -if (vop->dpms != DRM_MODE_DPMS_ON)
>> +if (!vop->is_enabled)
>>  return -EPERM;
>>   
>>  spin_lock_irqsave(>irq_lock, flags);
>> @@ -759,8 +769,9 @@ static void vop_crtc_disable_vblank(struct drm_crtc 
>> *crtc)
>>  struct vop *vop = to_vop(crtc);
>>  unsigned long flags;
>>   
>> -if (vop->dpms != DRM_MODE_DPMS_ON)
>> +if (!vop->is_enabled)
>>  return;
>> +
>>  spin_lock_irqsave(>irq_lock, flags);
>>  vop_mask_write(vop, INTR_CTRL0, FS_INTR_MASK, FS_INTR_EN(0));
>>  spin_unlock_irqrestore(>irq_lock, flags);
>> @@ -773,15 +784,8 @@ static const struct rockchip_crtc_funcs 
>> private_crtc_funcs = {
>>   
>>   static void vop_crtc_dpms(struct drm_crtc *crtc, int mode)
>>   {
>> -struct vop *vop = to_vop(crtc);
>> -
>>  DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
>>   
>> -if (vop->dpms == mode) {
>> -DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
>> -return;
>> -}
>> -
>>  switch (mode) {
>>  case DRM_MODE_DPMS_ON:
>>  vop_enable(crtc);
>> @@ -795,8 +799,6 @@ static void vop_crtc_dpms(struct drm_crtc *crtc, int 
>> mode)
>>  DRM_DEBUG_KMS("unspecified mode %d\n", mode);
>>  break;
>>  }
>> -
>> -vop->dpms = mode;
>>   }
>>   
>>   static void vop_crtc_prepare(struct drm_crtc *crtc)
>> @@ -934,9 +936,9 @@ static int vop_crtc_page_flip(struct drm_crtc *crtc,
>>  struct drm_framebuffer *old_fb = crtc->primary->fb;
>>  int ret;
>>   
>> -/* when the page flip is requested, crtc's dpms should be on */
>> -if (vop->dpms > DRM_MODE_DPMS_ON) {
>> -DRM_DEBUG("failed page flip request at dpms[%d].\n", vop->dpms);
>> +/* when the page flip is requested, crtc should be on */
>> +if (!vop->is_enabled) {
>> +DRM_DEBUG("page flip request rejected because crtc is off.\n");
>>  return 0;
>>  }
>>   
>> @@ -1302,7 +1304,7 @@ static int vop_initial(struct vop *vop)
>>   
>>  clk_disable(vop->hclk);
>>   
>> -vop->dpms = DRM_MODE_DPMS_OFF;
>> +vop->is_enabled = false;
>>   
>>  return 0;
>>   
>> -- 
>> 1.7.9.5
>>

drm: exynos: mixer: fix using usleep() in atomic context

[Seung-Woo Kim]

Hello,

On 2015년 01월 22일 07:46, Tobias Jakobi wrote:
> Hello!
> 
> 
> Inki Dae wrote:
>> The use of spin lock, reg_slock, has been used for a long time and we
>> hadn't some cleanups to spin lock codes so far. The spin lock is also
>> used in here and there of mixer driver. And at least, it seems that
>> the use of spin lock isn't required in mixer_win_reset. I don't see
>> any atomic contexts in mixer module except interrupt handler.
>>
>> To Seung-Woo,
>> I know that you referred to mixer codes of v4l2 based mixer driver. So
>> was the spin lock used in origin v4l2 driver? or Is there any reason
>> that you used the spin lock?

The spinlock usage was originated from Tomasz Stanislawski's s5p-tv.

>>
>> Anyway, we will have some testing to check hdmi and mixer drivers
>> without spin lock. So we will remove or replace it with mutex if
>> needed.
>>
>> Thanks,
>> Inki Dae
> 
> So it's some weeks later and as far as I can see there has been no
> changes to the spinlock usage. Wouldn't it be better to apply this patch
> _now_ (since the use of 'usleep_range' is just plain wrong while under
> spinlock). When the spinlock setup gets cleaned up later, then we can
> always change back to 'usleep_range' again.
> 
> Any thoughts?

In s5p-tv, same patch is already applied by Tomasz, so I agree to apply
this patch also.

Best Regards,
- Seung-Woo Kim

> 
> With best wishes,
> Tobias
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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

[PATCH 5/5] drm/atomic-helper: debug output for modesets

[Daniel Vetter]

With the combination of ->enable and ->active it's a bit complicated
to follow what exactly is going on sometimes within a full modeset.
Add debug output to make this all traceable.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index b67754035fec..b7ac83555b11 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -591,6 +591,9 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)

funcs = encoder->helper_private;

+   DRM_DEBUG_KMS("disabling [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
/*
 * Each encoder has at most one connector (since we always steal
 * it away), so we won't call call disable hooks twice.
@@ -627,6 +630,10 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)

funcs = crtc->helper_private;

+   DRM_DEBUG_KMS("disabling [CRTC:%d]\n",
+ crtc->base.id);
+
+
/* Right function depends upon target state. */
if (crtc->state->enable && funcs->prepare)
funcs->prepare(crtc);
@@ -707,8 +714,12 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)

funcs = crtc->helper_private;

-   if (crtc->state->enable)
+   if (crtc->state->enable) {
+   DRM_DEBUG_KMS("modeset on [CRTC:%d]\n",
+ crtc->base.id);
+
funcs->mode_set_nofb(crtc);
+   }
}

for (i = 0; i < old_state->num_connector; i++) {
@@ -732,6 +743,9 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)
if (!new_crtc_state->mode_changed)
continue;

+   DRM_DEBUG_KMS("modeset on [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
/*
 * Each encoder has at most one connector (since we always steal
 * it away), so we won't call call mode_set hooks twice.
@@ -793,6 +807,9 @@ void drm_atomic_helper_commit_post_planes(struct drm_device 
*dev,
funcs = crtc->helper_private;

if (crtc->state->enable) {
+   DRM_DEBUG_KMS("enabling [CRTC:%d]\n",
+ crtc->base.id);
+
if (funcs->enable)
funcs->enable(crtc);
else
@@ -816,6 +833,9 @@ void drm_atomic_helper_commit_post_planes(struct drm_device 
*dev,
encoder = connector->state->best_encoder;
funcs = encoder->helper_private;

+   DRM_DEBUG_KMS("enabling [ENCODER:%d:%s]\n",
+ encoder->base.id, encoder->name);
+
/*
 * Each encoder has at most one connector (since we always steal
 * it away), so we won't call call enable hooks twice.
-- 
2.1.4

[PATCH 4/5] drm/atomic-helpers: Saner encoder/crtc callbacks

[Daniel Vetter]

For historical reasons going all the way back to how the Xrandr code
was implemented the semantics of the callbacks used to enable/disable
crtcs and encoders are ... interesting.

But with atomic helpers all that complexity has been binned, with only
a well-defined on/off action left. Unfortunately the names stuck.

Let's fix that by adding enable/disable hooks every, make them the
preferred variant for atomic and update documentations.

Later on we add debug warnings when drivers have deprecated hooks. But
while everything is in-flight with lots of drivers converting to
atomic that's a bit too much - better wait for things to settle a bit
first.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 17 -
 include/drm/drm_crtc_helper.h   | 20 ++--
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index a74a22db4dea..b67754035fec 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -599,7 +599,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
encoder->bridge->funcs->disable(encoder->bridge);

/* Right function depends upon target state. */
-   if (connector->state->crtc)
+   if (connector->state->crtc && funcs->prepare)
funcs->prepare(encoder);
else if (funcs->disable)
funcs->disable(encoder);
@@ -628,7 +628,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
funcs = crtc->helper_private;

/* Right function depends upon target state. */
-   if (crtc->state->enable)
+   if (crtc->state->enable && funcs->prepare)
funcs->prepare(crtc);
else if (funcs->disable)
funcs->disable(crtc);
@@ -792,8 +792,12 @@ void drm_atomic_helper_commit_post_planes(struct 
drm_device *dev,

funcs = crtc->helper_private;

-   if (crtc->state->enable)
-   funcs->commit(crtc);
+   if (crtc->state->enable) {
+   if (funcs->enable)
+   funcs->enable(crtc);
+   else
+   funcs->commit(crtc);
+   }
}

for (i = 0; i < old_state->num_connector; i++) {
@@ -819,7 +823,10 @@ void drm_atomic_helper_commit_post_planes(struct 
drm_device *dev,
if (encoder->bridge)
encoder->bridge->funcs->pre_enable(encoder->bridge);

-   funcs->commit(encoder);
+   if (funcs->enable)
+   funcs->enable(encoder);
+   else
+   funcs->commit(encoder);

if (encoder->bridge)
encoder->bridge->funcs->enable(encoder->bridge);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index e76828d81a8b..c36f1bc26837 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -58,11 +58,19 @@ enum mode_set_atomic {
  * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
  * @load_lut: load color palette
  * @disable: disable CRTC when no longer in use
+ * @disable: enable CRTC
  * @atomic_check: check for validity of an atomic state
  * @atomic_begin: begin atomic update
  * @atomic_flush: flush atomic update
  *
  * The helper operations are called by the mid-layer CRTC helper.
+ *
+ * Note that with atomic helpers @dpms, @prepare and @commit hooks are
+ * deprecated. Used @enable and @disable instead exclusively.
+ *
+ * With legacy crtc helpers there's a big semantic difference between @disable
+ * and the other hooks: @disable also needs to release any resources acquired 
in
+ * @mode_set (like shared PLLs).
  */
 struct drm_crtc_helper_funcs {
/*
@@ -93,8 +101,8 @@ struct drm_crtc_helper_funcs {
/* reload the current crtc LUT */
void (*load_lut)(struct drm_crtc *crtc);

-   /* disable crtc when not in use - more explicit than dpms off */
void (*disable)(struct drm_crtc *crtc);
+   void (*enable)(struct drm_crtc *crtc);

/* atomic helpers */
int (*atomic_check)(struct drm_crtc *crtc,
@@ -115,8 +123,16 @@ struct drm_crtc_helper_funcs {
  * @get_crtc: return CRTC that the encoder is currently attached to
  * @detect: connection status detection
  * @disable: disable encoder when not in use (overrides DPMS off)
+ * @disable: enable encoder
  *
  * The helper operations are called by the mid-layer CRTC helper.
+ *
+ * Note that with atomic helpers @dpms, @prepare and @commit hooks are
+ * deprecated. Used @enable and @disable instead exclusively.
+ *
+ * With legacy crtc helpers there's a big semantic difference between @disable
+ * and the 

[PATCH 3/5] drm/atomic-helpers: Recover full cursor plane behaviour

[Daniel Vetter]

Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor specific behaviour with a hint
flag and some hacks to drop the vblank wait.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 11 +++
 include/drm/drm_crtc.h  |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 736ab924ddc9..a74a22db4dea 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -909,6 +909,11 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
if (!crtc->state->enable)
continue;

+   /* Legacy cursor ioctls are completely unsynced, and userspace
+* relies on that (by doing tons of cursor updates). */
+   if (old_state->legacy_cursor_update)
+   continue;
+
if (!framebuffer_changed(dev, old_state, crtc))
continue;

@@ -1335,6 +1340,9 @@ retry:
if (ret != 0)
goto fail;

+   if (plane == crtc->cursor)
+   state->legacy_cursor_update = true;
+
/* Driver takes ownership of state on successful commit. */
return 0;
 fail:
@@ -1410,6 +1418,9 @@ retry:
plane_state->src_h = 0;
plane_state->src_w = 0;

+   if (plane == plane->crtc->cursor)
+   state->legacy_cursor_update = true;
+
ret = drm_atomic_commit(state);
if (ret != 0)
goto fail;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4d3f3b874dd6..8b626ff3d3bd 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -929,6 +929,7 @@ struct drm_bridge {
  * struct struct drm_atomic_state - the global state object for atomic updates
  * @dev: parent DRM device
  * @allow_modeset: allow full modeset
+ * @allow_modeset: hint to enforce legacy cursor ioctl semantics
  * @planes: pointer to array of plane pointers
  * @plane_states: pointer to array of plane states pointers
  * @crtcs: pointer to array of CRTC pointers
@@ -941,6 +942,7 @@ struct drm_bridge {
 struct drm_atomic_state {
struct drm_device *dev;
bool allow_modeset : 1;
+   bool legacy_cursor_update : 1;
struct drm_plane **planes;
struct drm_plane_state **plane_states;
struct drm_crtc **crtcs;
-- 
2.1.4

[PATCH 2/5] drm/atomic-helper: add connector->dpms() implementation

[Daniel Vetter]

This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.

Of course it also clamps everything that's not ON to OFF.

v2: Fix spelling in one comment.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 75 +
 include/drm/drm_atomic_helper.h |  2 +
 2 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3f17933b1d2c..736ab924ddc9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1887,6 +1887,81 @@ backoff:
 EXPORT_SYMBOL(drm_atomic_helper_page_flip);

 /**
+ * drm_atomic_helper_connector_dpms() - connector dpms helper implementation
+ * @connector: affected connector
+ * @mode: DPMS mode
+ *
+ * This is the main helper function provided by the atomic helper framework for
+ * implementing the legacy DPMS connector interface. It computes the new 
desired
+ * ->active state for the corresponding CRTC (if the connector is enabled) and
+ *  updates it.
+ */
+void drm_atomic_helper_connector_dpms(struct drm_connector *connector,
+ int mode)
+{
+   struct drm_mode_config *config = >dev->mode_config;
+   struct drm_atomic_state *state;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   struct drm_connector *tmp_connector;
+   int ret;
+   bool active = false;
+
+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+
+   connector->dpms = mode;
+   crtc = connector->state->crtc;
+
+   if (!crtc)
+   return;
+
+   /* FIXME: ->dpms has no return value so can't forward the -ENOMEM. */
+   state = drm_atomic_state_alloc(connector->dev);
+   if (!state)
+   return;
+
+   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+retry:
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+
+   WARN_ON(!drm_modeset_is_locked(>connection_mutex));
+
+   list_for_each_entry(tmp_connector, >connector_list, head) {
+   if (connector->state->crtc != crtc)
+   continue;
+
+   if (connector->dpms == DRM_MODE_DPMS_ON) {
+   active = true;
+   break;
+   }
+   }
+   crtc_state->active = active;
+
+   ret = drm_atomic_async_commit(state);
+   if (ret != 0)
+   goto fail;
+
+   /* Driver takes ownership of state on successful async commit. */
+   return;
+fail:
+   if (ret == -EDEADLK)
+   goto backoff;
+
+   drm_atomic_state_free(state);
+
+   WARN(1, "Driver bug: Changing ->active failed with ret=%i\n", ret);
+
+   return;
+backoff:
+   drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);
+
+   goto retry;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
+
+/**
  * DOC: atomic state reset and initialization
  *
  * Both the drm core and the atomic helpers assume that there is always the 
full
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 2095917ff8c7..cf501df9e513 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -82,6 +82,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event,
uint32_t flags);
+void drm_atomic_helper_connector_dpms(struct drm_connector *connector,
+ int mode);

 /* default implementations for state handling */
 void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
-- 
2.1.4

[PATCH 1/5] drm/atomic: Add drm_crtc_state->active

[Daniel Vetter]

This is the infrastructure for DPMS ported to the atomic world.
Fundamental changes compare to legacy DPMS are:

- No more per-connector dpms state, instead there's just one per each
  display pipeline. So if you clone either you have to unclone first
  if you only want to switch off one screen, or you just switch of
  everything (like all desktops do). This massively reduces complexity
  for cloning since now there's no more half-enabled cloned configs to
  consider.

- Only on/off, dpms standby/suspend are as dead as real CRTs. Again
  reduces complexity a lot.

Now especially for backwards compat the really important part for dpms
support is that dpms on always succeeds (except for hw death and
unplugged cables ofc). Which means everything that could fail (like
configuration checking, resources assignments and buffer management)
must be done irrespective from ->active. ->active is really only a
toggle to change the hardware state. More precisely:

- Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
  Changes to ->active MUST always suceed if nothing else changes.

- Drivers using the atomic helpers MUST NOT look at ->active anywhere,
  period. The helpers will take care of calling the respective
  enable/modeset/disable hooks as necessary. As before the helpers
  will carefully keep track of the state and not call any hooks
  unecessarily, so still no double-disables or enables like with crtc
  helpers.

- ->mode_set hooks are only called when the mode or output
  configuration changes, not for changes in ->active state.

- Drivers which reconstruct the state objects in their ->reset hooks
  or through some other hw state readout infrastructure must ensure
  that ->active reflects actual hw state.

This just implements the core bits and helper logic, a subsequent
patch will implement the helper code to implement legacy dpms with
this.

v2: Rebase on top of the drm ioctl work:
- Move crtc checks to the core check function.
- Also check for ->active_changed when deciding whether a modeset
  might happen (for the ALLOW_MODESET mode).
- Expose the ->active state with an atomic prop.

v3: Review from Rob
- Spelling fix in comment.
- Extract needs_modeset helper to consolidate the ->mode_changed ||
  ->active_changed checks.

v4: Fixup fumble between crtc->state and crtc_state.

Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c| 18 +++--
 drivers/gpu/drm/drm_atomic_helper.c | 54 +
 drivers/gpu/drm/drm_crtc.c  | 10 +++
 include/drm/drm_crtc.h  |  3 +++
 4 files changed, 78 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1e38dfc8e462..ee68267bb326 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -241,7 +241,13 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
uint64_t val)
 {
-   if (crtc->funcs->atomic_set_property)
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+
+   /* FIXME: Mode prop is missing, which also controls ->enable. */
+   if (property == config->prop_active) {
+   state->active = val;
+   } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
return -EINVAL;
 }
@@ -282,6 +288,13 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 *
 * TODO: Add generic modeset state checks once we support those.
 */
+
+   if (state->active && !state->enable) {
+   DRM_DEBUG_KMS("[CRTC:%d] active without enabled\n",
+ crtc->base.id);
+   return -EINVAL;
+   }
+
return 0;
 }

@@ -976,7 +989,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
if (!crtc)
continue;

-   if (crtc_state->mode_changed) {
+   if (crtc_state->mode_changed ||
+   crtc_state->active_changed) {
DRM_DEBUG_KMS("[CRTC:%d] requires full 
modeset\n",
  crtc->base.id);
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 541ba833ed36..3f17933b1d2c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -330,6 +330,12 @@ mode_fixup(struct drm_atomic_state *state)
return 0;
 }

+static bool
+needs_modeset(struct drm_crtc_state *state)
+{
+   return state->mode_changed || state->active_changed;
+}
+
 /**
  * drm_atomic_helper_check - validate state object for modeset changes
  * @dev: DRM device
@@ -404,12 +410,27 @@ 

[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

[Michel Dänzer]

On 21.01.2015 18:22, Christian König wrote:
> Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
>> From: Michel Dänzer 
>>
>> The GART table BO has to be moved out of VRAM for suspend/resume. Any
>> updates to the GART table during that time were silently dropped without
>> this change. This caused GPU lockups on resume in some cases, see the bug
>> reports referenced below.
>>
>> This might also make GPU reset more robust in some cases, as we no longer
>> rely on the GART table in VRAM being preserved across the GPU
>> lockup/reset.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Michel Dänzer 
> 
> Can we make that directly part of radeon_gart_table_vram_pin? Doesn't
> seem to make sense to always need to call both functions.

Good point, fixed in v2.


> Additional to that couldn't we just stop mapping/unmapping the BO in
> radeon_gart_table_vram_pin? As far as I know CPU mapped BOs can still
> move around.

You're probably thinking of userspace mappings. I think the kernel
mapping would continue pointing to the same area of VRAM even while the
BO is evicted from VRAM or pinned back to another area of VRAM.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH v2 2/3] drm/radeon: Restore GART table contents after pinning it in VRAM

[Michel Dänzer]

From: Michel Dänzer 

The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.

This might also make GPU reset more robust in some cases, as we no longer
rely on the GART table in VRAM being preserved across the GPU
lockup/reset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer 
---

v2: Add logic to radeon_gart_table_vram_pin directly instead of reinstating
radeon_gart_restore function

 drivers/gpu/drm/radeon/radeon_gart.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index a530932..0c8c739 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -163,6 +163,14 @@ int radeon_gart_table_vram_pin(struct radeon_device *rdev)
r = radeon_bo_kmap(rdev->gart.robj, >gart.ptr);
if (r)
radeon_bo_unpin(rdev->gart.robj);
+   else {
+   int i;
+
+   for (i = 0; i < rdev->gart.num_gpu_pages; i++)
+   radeon_gart_set_page(rdev, i, 
rdev->gart.pages_entry[i]);
+   mb();
+   radeon_gart_tlb_flush(rdev);
+   }
radeon_bo_unreserve(rdev->gart.robj);
rdev->gart.table_addr = gpu_addr;
return r;
-- 
2.1.4

[PATCH] drm: sti: fix check for clk_pix_main

[Benjamin Gaignard]

I looks good for me.

Ack-by: benjamin.gaignard at linaro.org

2015-01-17 8:18 GMT+01:00 Jassi Brar :
> copy-paste wasn't followed by editing, do it.
>
> Signed-off-by: Jassi Brar 
> ---
>  drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index f3db05d..b0eb62d 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -1025,7 +1025,7 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
> /* Get clock resources */
> hqvdp->clk = devm_clk_get(dev, "hqvdp");
> hqvdp->clk_pix_main = devm_clk_get(dev, "pix_main");
> -   if (IS_ERR(hqvdp->clk) || IS_ERR(hqvdp->clk)) {
> +   if (IS_ERR(hqvdp->clk) || IS_ERR(hqvdp->clk_pix_main)) {
> DRM_ERROR("Cannot get clocks\n");
> return -ENXIO;
> }
> --
> 1.9.1
>



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 77002] hdmi audio problems with 3.14

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

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

bgunteriv at gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #38 from bgunteriv at gmail.com ---
reclosing this, as I see it might be related now to this
https://bugs.freedesktop.org/show_bug.cgi?id=77677

-- 
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/20150122/19372244/attachment-0001.html>

[Bug 91371] UVD not responding error during UVD initialization for AMD 7670M graphics

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

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

--- Comment #5 from Adis Hamzić  ---

I just tested the kernels 3.14.27 and 3.16.7.3 and they both display the issue. 

Now, I had used the 3.14.27 kernel for at least 10 days and I never noticed
this issue. In that time I was doing some kernel debugging which involved a
great number of cold and hard reboots so I think I would have noticed the issue
if it had been there. I'll test some older kernels soon.

What I found out during my testing was:
 * Setting radeon.dpm=0 fixes the issue.
 * Doing a hard reboot / poweroff has a very high chance of triggering the
problem, in fact I managed to reproduce it 10 consecutive times.
 * Doing a soft reboot has very little chance of triggering the problem. With
this I managed to have 10 consecutive successful boots.

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

[PATCH] drm/udl: properly set active_16 flag in udl_crtc_page_flip().

[Haixia Shi]

When page flipping, we need to mark the new fb as active and unmark the active
flag for the old fb (if different).

Signed-off-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/udl/udl_modeset.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 1701f1d..a9c611a 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -340,11 +340,11 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,

wrptr = udl_dummy_render(wrptr);

-   ufb->active_16 = true;
if (old_fb) {
struct udl_framebuffer *uold_fb = to_udl_fb(old_fb);
uold_fb->active_16 = false;
}
+   ufb->active_16 = true;
udl->mode_buf_len = wrptr - buf;

/* damage all of it */
@@ -373,6 +373,13 @@ static int udl_crtc_page_flip(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
unsigned long flags;

+   struct drm_framebuffer *old_fb = crtc->fb;
+   if (old_fb) {
+   struct udl_framebuffer *uold_fb = to_udl_fb(old_fb);
+   uold_fb->active_16 = false;
+   }
+   ufb->active_16 = true;
+
udl_handle_damage(ufb, 0, 0, fb->width, fb->height);

spin_lock_irqsave(>event_lock, flags);
-- 
2.2.0.rc0.207.ga3a616c

[PATCH 1/2] reservation: wait only with non-zero timeout specified (v3)

[Sumit Semwal]

Hi Jammy, All,


On 21 January 2015 at 23:04, Alex Deucher  wrote:
> On Wed, Jan 21, 2015 at 12:30 PM, Maarten Lankhorst
>  wrote:
>> Hey,
>>
>> On 21-01-15 17:16, Alex Deucher wrote:
>>> On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst
>>>  wrote:
 Op 21-01-15 om 11:35 schreef Jammy Zhou:
> When the timeout value passed to reservation_object_wait_timeout_rcuy,
> is zero, no wait should be done if the fences are not signaled.
>
> Return '1' for idle and '0' for busy if the specified timeout is '0'
> to keep consistent with the case of non-zero timeout.
>
> v2: call fence_put if not signaled in the case of timeout==0
>
> v3: switch to reservation_object_test_signaled_rcu
>
> Signed-off-by: Jammy Zhou 
> Reviewed-by: Christian König 
> Reviewed-by: Alex Deucher 
>
 Reviewed-By: Maarten Lankhorst 
>>>
>>> Dave, Maarten,
>>>
>>> Do you want to pick these up, or would you rather I pulled them through my 
>>> tree?
>> This goes through Sumit Semwal's tree. He's the dma-buf maintainer and I 
>> already made him aware of the patches.
>
Both these patches are now pulled and pushed out to my for-next branch.
>
> Thanks!
>
> Alex

-- 
Thanks and Best regards,
Sumit.

[PATCH] drm/vmwgfx: Correctly NULLify dma buffer pointer on failure

[Colin King]

From: Colin Ian King 

cppcheck on lines 917 and 977 show an ineffective assignment
to the dma buffer pointer:

[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]:
  (warning) Assignment of function parameter has no effect
  outside the function. Did you forget dereferencing it?

On a successful DMA buffer lookup, the dma buffer pointer is
assigned, however, on failure it currently is left in an
undefined state.

The original intention in the error exit path was to nullify
the pointer on an error (which the original code failed to
do properly). This patch fixes this also ensures all failure
paths nullify the buffer pointer on the error return.

Fortunately the callers to vmw_translate_mob_ptr and
vmw_translate_guest_ptr are checking on a return status and not
on the dma buffer pointer, so the original code worked.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 33176d0..275149c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -890,7 +890,8 @@ static int vmw_translate_mob_ptr(struct vmw_private 
*dev_priv,
ret = vmw_user_dmabuf_lookup(sw_context->fp->tfile, handle, _bo);
if (unlikely(ret != 0)) {
DRM_ERROR("Could not find or use MOB buffer.\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto out_no_reloc;
}
bo = _bo->base;

@@ -914,7 +915,7 @@ static int vmw_translate_mob_ptr(struct vmw_private 
*dev_priv,

 out_no_reloc:
vmw_dmabuf_unreference(_bo);
-   vmw_bo_p = NULL;
+   *vmw_bo_p = NULL;
return ret;
 }

@@ -951,7 +952,8 @@ static int vmw_translate_guest_ptr(struct vmw_private 
*dev_priv,
ret = vmw_user_dmabuf_lookup(sw_context->fp->tfile, handle, _bo);
if (unlikely(ret != 0)) {
DRM_ERROR("Could not find or use GMR region.\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto out_no_reloc;
}
bo = _bo->base;

@@ -974,7 +976,7 @@ static int vmw_translate_guest_ptr(struct vmw_private 
*dev_priv,

 out_no_reloc:
vmw_dmabuf_unreference(_bo);
-   vmw_bo_p = NULL;
+   *vmw_bo_p = NULL;
return ret;
 }

-- 
2.1.4

[PATCH 2/2] drm/rockchip: vop: set vop enabled after enable iommu

[Mark Yao]

there is a Bug that:
  vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.

after enable vop clocks and iommu regs, we can sure that
R/W vop regs and do vop plane flip is safe, so place
is_enabled = true after enable iommu is suitable.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index f278c09..a009457 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -420,6 +420,11 @@ static void vop_enable(struct drm_crtc *crtc)
goto err_disable_aclk;
}

+   /*
+* At here, vop clock & iommu is enable, R/W vop regs would be safe.
+*/
+   vop->is_enabled = false;
+
spin_lock(>reg_lock);

VOP_CTRL_SET(vop, standby, 0);
@@ -430,8 +435,6 @@ static void vop_enable(struct drm_crtc *crtc)

drm_vblank_on(vop->drm_dev, vop->pipe);

-   vop->is_enabled = false;
-
return;

 err_disable_aclk:
@@ -462,6 +465,8 @@ static void vop_disable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, standby, 1);

spin_unlock(>reg_lock);
+
+   vop->is_enabled = false;
/*
 * disable dclk to stop frame scan, so we can safely detach iommu,
 */
@@ -471,8 +476,6 @@ static void vop_disable(struct drm_crtc *crtc)

clk_disable(vop->aclk);
clk_disable(vop->hclk);
-
-   vop->is_enabled = false;
 }

 /*
-- 
1.7.9.5

[PATCH 1/2] drm/rockchip: vop use is_enabled instead of dpms mode

[Mark Yao]

drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
 --> DRM_DPMS_ON: power on vop
 --> DRM_DPMS_SUSPEND: power off vop
 --> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   34 ++-
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9a5c571..f278c09 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -81,7 +81,7 @@ struct vop {
struct drm_crtc crtc;
struct device *dev;
struct drm_device *drm_dev;
-   unsigned int dpms;
+   bool is_enabled;

int connector_type;
int connector_out_mode;
@@ -387,6 +387,9 @@ static void vop_enable(struct drm_crtc *crtc)
struct vop *vop = to_vop(crtc);
int ret;

+   if (vop->is_enabled)
+   return;
+
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
@@ -427,6 +430,8 @@ static void vop_enable(struct drm_crtc *crtc)

drm_vblank_on(vop->drm_dev, vop->pipe);

+   vop->is_enabled = false;
+
return;

 err_disable_aclk:
@@ -441,6 +446,9 @@ static void vop_disable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);

+   if (vop->is_enabled)
+   return;
+
drm_vblank_off(crtc->dev, vop->pipe);

disable_irq(vop->irq);
@@ -463,6 +471,8 @@ static void vop_disable(struct drm_crtc *crtc)

clk_disable(vop->aclk);
clk_disable(vop->hclk);
+
+   vop->is_enabled = false;
 }

 /*
@@ -742,7 +752,7 @@ static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
struct vop *vop = to_vop(crtc);
unsigned long flags;

-   if (vop->dpms != DRM_MODE_DPMS_ON)
+   if (!vop->is_enabled)
return -EPERM;

spin_lock_irqsave(>irq_lock, flags);
@@ -759,8 +769,9 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
struct vop *vop = to_vop(crtc);
unsigned long flags;

-   if (vop->dpms != DRM_MODE_DPMS_ON)
+   if (!vop->is_enabled)
return;
+
spin_lock_irqsave(>irq_lock, flags);
vop_mask_write(vop, INTR_CTRL0, FS_INTR_MASK, FS_INTR_EN(0));
spin_unlock_irqrestore(>irq_lock, flags);
@@ -773,15 +784,8 @@ static const struct rockchip_crtc_funcs private_crtc_funcs 
= {

 static void vop_crtc_dpms(struct drm_crtc *crtc, int mode)
 {
-   struct vop *vop = to_vop(crtc);
-
DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);

-   if (vop->dpms == mode) {
-   DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
-   return;
-   }
-
switch (mode) {
case DRM_MODE_DPMS_ON:
vop_enable(crtc);
@@ -795,8 +799,6 @@ static void vop_crtc_dpms(struct drm_crtc *crtc, int mode)
DRM_DEBUG_KMS("unspecified mode %d\n", mode);
break;
}
-
-   vop->dpms = mode;
 }

 static void vop_crtc_prepare(struct drm_crtc *crtc)
@@ -934,9 +936,9 @@ static int vop_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
int ret;

-   /* when the page flip is requested, crtc's dpms should be on */
-   if (vop->dpms > DRM_MODE_DPMS_ON) {
-   DRM_DEBUG("failed page flip request at dpms[%d].\n", vop->dpms);
+   /* when the page flip is requested, crtc should be on */
+   if (!vop->is_enabled) {
+   DRM_DEBUG("page flip request rejected because crtc is off.\n");
return 0;
}

@@ -1302,7 +1304,7 @@ static int vop_initial(struct vop *vop)

clk_disable(vop->hclk);

-   vop->dpms = DRM_MODE_DPMS_OFF;
+   vop->is_enabled = false;

return 0;

-- 
1.7.9.5

[PATCH 0/2] drm/rockchip: Optimization vop dpms control

[Mark Yao]

drm dpms have many power modes, ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
 --> DRM_DPMS_ON: power on vop
 --> DRM_DPMS_SUSPEND: power off vop
 --> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.

another problem at vop_crtc_dpms:
  vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.

Mark Yao (2):
  drm/rockchip: vop use is_enabled instead of dpms mode
  drm/rockchip: vop: set vop enabled after enable iommu

 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |   17 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |3 +--
 3 files changed, 7 insertions(+), 15 deletions(-)

-- 
1.7.9.5

[PATCH 1/2] drm/rockchip: vop use is_enabled instead of dpms mode

[Daniel Vetter]

On Thu, Jan 22, 2015 at 04:56:09PM +0800, Mark yao wrote:
> On 2015年01月22日 15:33, Daniel Vetter wrote:
> >On Thu, Jan 22, 2015 at 03:05:32PM +0800, Mark Yao wrote:
> >>drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
> >>but vop only have enable/disable mode, maybe case such bug:
> >>  --> DRM_DPMS_ON: power on vop
> >>  --> DRM_DPMS_SUSPEND: power off vop
> >>  --> DRM_DPMS_OFF: already power off at SUSPEND, crash
> >>so use a bool val is more suitable.
> >>
> >>Signed-off-by: Mark Yao 
> >Long term I highly suggest you switch to atomic, since with atomic all the
> >legacy dpms modes are remapped to a simple on/off. Also the new atomic
> >helpers make sure that your backend isn't called multiple times, so you
> >can ditch all your is_enabled tracking with that.
> >-Daniel
> Hi Daniel
> is there some documents teach me how to switch to atomic easily?
> I found many other drivers which use atomic also remap dpms modes to simple
> on/off at its driver,
> and I don't know where atomic helper do the remapped, can you give me some
> suggestions?

The dpms remapping patches are still in-flight. But for the general atomic
conversion please look at

http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html

If you want to look at an actual driver there's msm already merged, tegra
(conversion just posted) and exynos (iirc not yet published all, but
Gustavo should have a branch for you to look at somewhere).

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

[PATCH v4 9/9] drm/exynos: add support for 'hdmi' clock

[Marek Szyprowski]

Hello,

On 2015-01-22 13:51, Javier Martinez Canillas wrote:
> Hello Marek,
>
> On 01/22/2015 01:41 PM, Marek Szyprowski wrote:

 +  mixer_res->hdmi = devm_clk_get(dev, "hdmi");
>>> You need to update the 
>>> Documentation/devicetree/bindings/video/exynos_mixer.txt
>>> DT binding docs to also mention the "hdmi" clock in the list of clocks.
>> Right, I've send an updated version of the patch.
>>
> Great thanks.
>   
>>> But as I mentioned in "[PATCH v2 0/6] Enable HDMI support on Exynos 
>>> platforms"
>>> thread, while this seems to be enough to prevent the issue on Exynos4 is not
>>> enough on the Exynos5420/5422/5800 boards I've tested.
>>>
>>> So I wonder if $subject is fixing the root cause or just fixing a symptom 
>>> and
>>> the cause is that the exynos_hdmi DPMS handler has to be executed before the
>>> exynos_mixer DPMS handler for DRM_MODE_DPMS_ON like is the case for DPMS_OFF
>>> after commit 245f98f269714 ("drm/exynos: hdmi: fix power order issue").
>> I'm aware of the issues with Exynos542x, I've tested it with Odroid XU3,
>> but I
>> really have no idea how to fix it. The reference manual (both for power
>> domain
>> and mixer/hdmi modules) also doesn't provide any useful information for this
>> case.
>>
> Yeah, I'm in the same situation. All the documentation I had access to doesn't
> now explain what's happening.

Just to let you know. The problem with power domain failure to turn off 
is something
orthogonal to 'Unhandled fault: external abort on non-linefetch' issue 
in drm mixer
driver. It looks that even if domains reports that it failed to turn 
off, it somehow
disabled the power, because this 'external abort' issue happens on 
Odroid XU3 when
driver tries to access mixer registers with power domain turned off. It 
must be
something badly broken in Exynos DRM HDMI/Mixer handling of runtime pm, 
because
such scenario can be easily triggered simply by running
"libdrm/modetest -M exynos -s 16 at 13:1920x1080".

It looks that in case of Exynos4 access to mixer registers in case of 
disabled power
domain doesn't have such terrible results and thus the driver is somehow 
working well.

>> The issue with power on/off sequence definitely IS related to clock
>> configuration,
>> but we didn't figure out how to solve it in a generic way. This will be
>> handled in
>> Exynos HDMI and mixer drivers anyway, so the DTS part (at least for
>> Exynos4 SoC)
>> will not change.
>>
>> We would really like to have HDMI support for Exynos4 merged, especially
>> that the
>> first version of the HDMI patches was posted in v3.16 times and now we
>> are close
>> to v3.20 -next merge window end...
>>
> Sorry, I didn't mean to imply that $subject should be blocked. I agree with
> you that the power on/off sequence has to be fixed in the hdmi and mixer
> drivers and is orthogonal to the DTS changes. That's why I also decided to
> finally post my "Add HDMI support for Exynos5420 platform" [0] series too.

Thanks. I hope that both series will get merged to v3.20 what will bring 
more
attention to this problem.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

[PATCH v4 RESEND 9/9] drm/exynos: add support for 'hdmi' clock

[Javier Martinez Canillas]

Hello Marek,

On 01/22/2015 01:28 PM, Marek Szyprowski wrote:
> Mixed need to have hdmi clock enabled to properly perform power on/off
> sequences, so add handling of this clock directly to the mixer driver.
> Dependency between hdmi clock and mixer module has been observed on
> Exynos4 based boards.
> 
> Suggested-by: Andrzej Hajda 
> Signed-off-by: Marek Szyprowski 
> ---

The patch looks good to me and I tested that it does not regress HDMI on
other platforms (Exynos5420 Peach Pit). I've just a comment below.

Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 

>  Documentation/devicetree/bindings/video/exynos_mixer.txt | 1 +
>  drivers/gpu/drm/exynos/exynos_mixer.c| 9 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 08b394b..3e38128 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -15,6 +15,7 @@ Required properties:
>   a) mixer: Gate of Mixer IP bus clock.
>   b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of
> mixer mux.
> + c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi.
>

You are adding as a required property which means that this breaks DT backward
compatibility. I guess is not a big issue here since HDMI seems to have been
broken in mainline on most Exynos platforms anyways.

Best regards,
Javier

[PATCH] drm/amdkfd: Fix sparse errors

[Oded Gabbay]

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   | 16 ++---
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 28 ++
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  | 20 +---
 3 files changed, 27 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 732087dc..5c50aa8 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -141,8 +141,6 @@ static int kfd_ioctl_get_version(struct file *filep, struct 
kfd_process *p,
 static int set_queue_properties_from_user(struct queue_properties 
*q_properties,
struct kfd_ioctl_create_queue_args *args)
 {
-   void *tmp;
-
if (args->queue_percentage > KFD_MAX_QUEUE_PERCENTAGE) {
pr_err("kfd: queue percentage must be between 0 to 
KFD_MAX_QUEUE_PERCENTAGE\n");
return -EINVAL;
@@ -180,16 +178,18 @@ static int set_queue_properties_from_user(struct 
queue_properties *q_properties,
return -EFAULT;
}

-   tmp = (void *)(uintptr_t)args->eop_buffer_address;
-   if (tmp != NULL &&
-   !access_ok(VERIFY_WRITE, tmp, sizeof(uint32_t))) {
+   if (args->eop_buffer_address &&
+   !access_ok(VERIFY_WRITE,
+   (const void __user *) args->eop_buffer_address,
+   sizeof(uint32_t))) {
pr_debug("kfd: can't access eop buffer");
return -EFAULT;
}

-   tmp = (void *)(uintptr_t)args->ctx_save_restore_address;
-   if (tmp != NULL &&
-   !access_ok(VERIFY_WRITE, tmp, sizeof(uint32_t))) {
+   if (args->ctx_save_restore_address &&
+   !access_ok(VERIFY_WRITE,
+   (const void __user *) args->ctx_save_restore_address,
+   sizeof(uint32_t))) {
pr_debug("kfd: can't access ctx save restore buffer");
return -EFAULT;
}
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 99e2dbb..b189f97 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -62,12 +62,6 @@ enum KFD_MQD_TYPE get_mqd_type_from_queue_type(enum 
kfd_queue_type type)
return KFD_MQD_TYPE_CP;
 }

-inline unsigned int get_pipes_num(struct device_queue_manager *dqm)
-{
-   BUG_ON(!dqm || !dqm->dev);
-   return dqm->dev->shared_resources.compute_pipe_count;
-}
-
 static inline unsigned int get_first_pipe(struct device_queue_manager *dqm)
 {
BUG_ON(!dqm);
@@ -79,25 +73,6 @@ static inline unsigned int get_pipes_num_cpsch(void)
return PIPE_PER_ME_CP_SCHEDULING;
 }

-inline unsigned int
-get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
-{
-   uint32_t nybble;
-
-   nybble = (pdd->lds_base >> 60) & 0x0E;
-
-   return nybble;
-}
-
-inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *pdd)
-{
-   unsigned int shared_base;
-
-   shared_base = (pdd->lds_base >> 16) & 0xFF;
-
-   return shared_base;
-}
-
 void program_sh_mem_settings(struct device_queue_manager *dqm,
struct qcm_process_device *qpd)
 {
@@ -336,7 +311,8 @@ static int update_queue(struct device_queue_manager *dqm, 
struct queue *q)
BUG_ON(!dqm || !q || !q->mqd);

mutex_lock(>lock);
-   mqd = dqm->ops.get_mqd_manager(dqm, q->properties.type);
+   mqd = dqm->ops.get_mqd_manager(dqm,
+   get_mqd_type_from_queue_type(q->properties.type));
if (mqd == NULL) {
mutex_unlock(>lock);
return -ENOMEM;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index 1934795..e7b17b2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -160,10 +160,24 @@ void device_queue_manager_init_cik(struct 
device_queue_manager_ops *ops);
 void device_queue_manager_init_vi(struct device_queue_manager_ops *ops);
 void program_sh_mem_settings(struct device_queue_manager *dqm,
struct qcm_process_device *qpd);
-inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *qpd);
-inline unsigned int get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd);
 int init_pipelines(struct device_queue_manager *dqm,
unsigned int pipes_num, unsigned int first_pipe);
-inline unsigned int get_pipes_num(struct device_queue_manager *dqm);
+
+extern inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *pdd)
+{
+   return (pdd->lds_base >> 16) & 0xFF;
+}
+
+extern inline unsigned int
+get_sh_mem_bases_nybble_64(struct kfd_process_device 

[PATCH v4 9/9] drm/exynos: add support for 'hdmi' clock

[Javier Martinez Canillas]

Hello Marek,

On 01/22/2015 01:41 PM, Marek Szyprowski wrote:
>>>   
>>> +   mixer_res->hdmi = devm_clk_get(dev, "hdmi");
>> You need to update the 
>> Documentation/devicetree/bindings/video/exynos_mixer.txt
>> DT binding docs to also mention the "hdmi" clock in the list of clocks.
> 
> Right, I've send an updated version of the patch.
>

Great thanks.

>> But as I mentioned in "[PATCH v2 0/6] Enable HDMI support on Exynos 
>> platforms"
>> thread, while this seems to be enough to prevent the issue on Exynos4 is not
>> enough on the Exynos5420/5422/5800 boards I've tested.
>>
>> So I wonder if $subject is fixing the root cause or just fixing a symptom and
>> the cause is that the exynos_hdmi DPMS handler has to be executed before the
>> exynos_mixer DPMS handler for DRM_MODE_DPMS_ON like is the case for DPMS_OFF
>> after commit 245f98f269714 ("drm/exynos: hdmi: fix power order issue").
> 
> I'm aware of the issues with Exynos542x, I've tested it with Odroid XU3, 
> but I
> really have no idea how to fix it. The reference manual (both for power 
> domain
> and mixer/hdmi modules) also doesn't provide any useful information for this
> case.
>

Yeah, I'm in the same situation. All the documentation I had access to doesn't
now explain what's happening.

> The issue with power on/off sequence definitely IS related to clock 
> configuration,
> but we didn't figure out how to solve it in a generic way. This will be 
> handled in
> Exynos HDMI and mixer drivers anyway, so the DTS part (at least for 
> Exynos4 SoC)
> will not change.
>
> We would really like to have HDMI support for Exynos4 merged, especially 
> that the
> first version of the HDMI patches was posted in v3.16 times and now we 
> are close
> to v3.20 -next merge window end...
>

Sorry, I didn't mean to imply that $subject should be blocked. I agree with
you that the power on/off sequence has to be fixed in the hdmi and mixer
drivers and is orthogonal to the DTS changes. That's why I also decided to
finally post my "Add HDMI support for Exynos5420 platform" [0] series too.

> Best regards
> 

Best regards,
Javier

[0]: https://lkml.org/lkml/2015/1/20/235

[PATCH v4 9/9] drm/exynos: add support for 'hdmi' clock

[Marek Szyprowski]

Hello,

On 2015-01-20 13:52, Javier Martinez Canillas wrote:
> On 01/20/2015 01:16 PM, Marek Szyprowski wrote:
>> Mixed need to have hdmi clock enabled to properly perform power on/off
>> sequences, so add handling of this clock directly to the mixer driver.
>> Dependency between hdmi clock and mixer module has been observed on
>> Exynos4 based boards.
>>
>> Suggested-by: Andrzej Hajda
>> Signed-off-by: Marek Szyprowski
>> ---
>>   drivers/gpu/drm/exynos/exynos_mixer.c | 9 +
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 820b76234ef4..e5ef1fccd8fb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -72,6 +72,7 @@ struct mixer_resources {
>>  spinlock_t  reg_slock;
>>  struct clk  *mixer;
>>  struct clk  *vp;
>> +struct clk  *hdmi;
>>  struct clk  *sclk_mixer;
>>  struct clk  *sclk_hdmi;
>>  struct clk  *mout_mixer;
>> @@ -774,6 +775,12 @@ static int mixer_resources_init(struct mixer_context 
>> *mixer_ctx)
>>  return -ENODEV;
>>  }
>>   
>> +mixer_res->hdmi = devm_clk_get(dev, "hdmi");
> You need to update the 
> Documentation/devicetree/bindings/video/exynos_mixer.txt
> DT binding docs to also mention the "hdmi" clock in the list of clocks.

Right, I've send an updated version of the patch.

> But as I mentioned in "[PATCH v2 0/6] Enable HDMI support on Exynos platforms"
> thread, while this seems to be enough to prevent the issue on Exynos4 is not
> enough on the Exynos5420/5422/5800 boards I've tested.
>
> So I wonder if $subject is fixing the root cause or just fixing a symptom and
> the cause is that the exynos_hdmi DPMS handler has to be executed before the
> exynos_mixer DPMS handler for DRM_MODE_DPMS_ON like is the case for DPMS_OFF
> after commit 245f98f269714 ("drm/exynos: hdmi: fix power order issue").

I'm aware of the issues with Exynos542x, I've tested it with Odroid XU3, 
but I
really have no idea how to fix it. The reference manual (both for power 
domain
and mixer/hdmi modules) also doesn't provide any useful information for this
case.

The issue with power on/off sequence definitely IS related to clock 
configuration,
but we didn't figure out how to solve it in a generic way. This will be 
handled in
Exynos HDMI and mixer drivers anyway, so the DTS part (at least for 
Exynos4 SoC)
will not change.

We would really like to have HDMI support for Exynos4 merged, especially 
that the
first version of the HDMI patches was posted in v3.16 times and now we 
are close
to v3.20 -next merge window end...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

[PATCH v4 RESEND 9/9] drm/exynos: add support for 'hdmi' clock

[Marek Szyprowski]

Mixed need to have hdmi clock enabled to properly perform power on/off
sequences, so add handling of this clock directly to the mixer driver.
Dependency between hdmi clock and mixer module has been observed on
Exynos4 based boards.

Suggested-by: Andrzej Hajda 
Signed-off-by: Marek Szyprowski 
---
 Documentation/devicetree/bindings/video/exynos_mixer.txt | 1 +
 drivers/gpu/drm/exynos/exynos_mixer.c| 9 +
 2 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 08b394b..3e38128 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -15,6 +15,7 @@ Required properties:
a) mixer: Gate of Mixer IP bus clock.
b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of
mixer mux.
+   c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi.

 Example:

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 820b762..e5ef1fc 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -72,6 +72,7 @@ struct mixer_resources {
spinlock_t  reg_slock;
struct clk  *mixer;
struct clk  *vp;
+   struct clk  *hdmi;
struct clk  *sclk_mixer;
struct clk  *sclk_hdmi;
struct clk  *mout_mixer;
@@ -774,6 +775,12 @@ static int mixer_resources_init(struct mixer_context 
*mixer_ctx)
return -ENODEV;
}

+   mixer_res->hdmi = devm_clk_get(dev, "hdmi");
+   if (IS_ERR(mixer_res->hdmi)) {
+   dev_err(dev, "failed to get clock 'hdmi'\n");
+   return -ENODEV;
+   }
+
mixer_res->sclk_hdmi = devm_clk_get(dev, "sclk_hdmi");
if (IS_ERR(mixer_res->sclk_hdmi)) {
dev_err(dev, "failed to get clock 'sclk_hdmi'\n");
@@ -1095,6 +1102,7 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
pm_runtime_get_sync(ctx->dev);

clk_prepare_enable(res->mixer);
+   clk_prepare_enable(res->hdmi);
if (ctx->vp_enabled) {
clk_prepare_enable(res->vp);
if (ctx->has_sclk)
@@ -1134,6 +1142,7 @@ static void mixer_poweroff(struct exynos_drm_manager *mgr)
ctx->powered = false;
mutex_unlock(>mixer_mutex);

+   clk_disable_unprepare(res->hdmi);
clk_disable_unprepare(res->mixer);
if (ctx->vp_enabled) {
clk_disable_unprepare(res->vp);
-- 
1.9.2

[PATCH v2 3/3] drm/amdkfd: Fix bug in call to init_pipelines()

[Oded Gabbay]

This patch fixes a bug where the first_pipe index passed into init_pipelines()
was a #define instead of the value that is passed into amdkfd by radeon

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index cd0710a..0d8694f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -588,7 +588,7 @@ static int init_scheduler(struct device_queue_manager *dqm)

pr_debug("kfd: In %s\n", __func__);

-   retval = init_pipelines(dqm, get_pipes_num(dqm), KFD_DQM_FIRST_PIPE);
+   retval = init_pipelines(dqm, get_pipes_num(dqm), get_first_pipe(dqm));
if (retval != 0)
return retval;

-- 
1.9.1

[PATCH v2 2/3] drm/amdkfd: Fix bug in pipelines initialization

[Oded Gabbay]

This patch fixes a bug when calling to init_pipeline() interface.
The index that was passed to that function didn't take into account the
first_pipe value, which represents the first pipe index that is under amdkfd's
responsibility.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index b9626ae..cd0710a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -565,10 +565,14 @@ static int init_pipelines(struct device_queue_manager 
*dqm,

for (i = 0; i < pipes_num; i++) {
inx = i + first_pipe;
+   /*
+* HPD buffer on GTT is allocated by amdkfd, no need to waste
+* space in GTT for pipelines we don't initialize
+*/
pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
pr_debug("kfd: pipeline address %llX\n", pipe_hpd_addr);
/* = log2(bytes/4)-1 */
-   kfd2kgd->init_pipeline(dqm->dev->kgd, i,
+   kfd2kgd->init_pipeline(dqm->dev->kgd, inx,
CIK_HPD_EOP_BYTES_LOG2 - 3, pipe_hpd_addr);
}

-- 
1.9.1

[PATCH v2 1/3] drm/radeon: Don't increment pipe_id in kgd_init_pipeline

[Oded Gabbay]

This patch fixes the behavior of kgd_init_pipeline in that this function
shouldn't automatically increase the pipe_id argument by 1 right at the start
of the function.

This is because the first_pipe value might not be always 1, and because a
proper interface function should not hide this info inside its implementation.
In other words, the calling function should provide the real pipe_id and not
count on kgd_init_pipeline to "fix" it.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
b/drivers/gpu/drm/radeon/radeon_kfd.c
index 8bf87f1..bef9a09 100644
--- a/drivers/gpu/drm/radeon/radeon_kfd.c
+++ b/drivers/gpu/drm/radeon/radeon_kfd.c
@@ -436,7 +436,7 @@ static int kgd_init_memory(struct kgd_dev *kgd)
 static int kgd_init_pipeline(struct kgd_dev *kgd, uint32_t pipe_id,
uint32_t hpd_size, uint64_t hpd_gpu_addr)
 {
-   uint32_t mec = (++pipe_id / CIK_PIPE_PER_MEC) + 1;
+   uint32_t mec = (pipe_id / CIK_PIPE_PER_MEC) + 1;
uint32_t pipe = (pipe_id % CIK_PIPE_PER_MEC);

lock_srbm(kgd, mec, pipe, 0, 0);
-- 
1.9.1

[PATCH v2 0/3] Fix bugs related to init pipelines

[Oded Gabbay]

Following comments on original patch, I prepared this patch-set to address
all the issues that were brought up.

Oded

Oded Gabbay (3):
  drm/radeon: Don't increment pipe_id in kgd_init_pipeline
  drm/amdkfd: Fix bug in pipelines initialization
  drm/amdkfd: Fix bug in call to init_pipelines()

 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 8 ++--
 drivers/gpu/drm/radeon/radeon_kfd.c   | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH] drm/amdkfd: Fix bug in pipelines initialization

[Oded Gabbay]

On 01/22/2015 12:22 PM, Zhou, Jammy wrote:
> Hi Oded,
>
> - pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
> + pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
> I think 'i' should still be used here, because it is the real index in the 
> buffer
>
I guess that 'i' can still be used here, because we allocate the HPD buffer in 
GART (which pipelines_addr points to). I'll change that.
However, this made me re-check the entire call path, and I found that in the 
init_pipeline interface function we automatically increase the pipe_id 
parameter 
(which is 'inx' here) by 1. That is definitely wrong on all levels, as 
first_pipe might not be 1 and also we should pass the correct pipe_id to the 
function. So I'm going to fix that as well.


> Besides, for the code below in init_scheduler(), it looks like the 
> KFD_DQM_FIRST_PIPE is not correct, and we probably need to use 
> get_first_pipe(dqm) instead.
>
> retval = init_pipelines(dqm, get_pipes_num(dqm), KFD_DQM_FIRST_PIPE);
>
Yes, it seems you are correct. I'll fix it.

Thanks for the comments.
Oded
> Regards,
> Jammy
>
> -Original Message-
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf 
> Of Gabbay, Oded
> Sent: Thursday, January 22, 2015 5:07 PM
> To: dri-devel at lists.freedesktop.org
> Subject: [PATCH] drm/amdkfd: Fix bug in pipelines initialization
>
> This patch fixes a bug when calling to init_pipeline() interface.
> The index that was passed to that function didn't take into account the 
> first_pipe value, which represents the first pipe index that is under 
> amdkfd's responsibility.
>
> Signed-off-by: Oded Gabbay 
> ---
>   drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index b9626ae..fbb353f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -565,10 +565,10 @@ static int init_pipelines(struct device_queue_manager 
> *dqm,
>
>   for (i = 0; i < pipes_num; i++) {
>   inx = i + first_pipe;
> - pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
> + pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
>   pr_debug("kfd: pipeline address %llX\n", pipe_hpd_addr);
>   /* = log2(bytes/4)-1 */
> - kfd2kgd->init_pipeline(dqm->dev->kgd, i,
> + kfd2kgd->init_pipeline(dqm->dev->kgd, inx,
>   CIK_HPD_EOP_BYTES_LOG2 - 3, pipe_hpd_addr);
>   }
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 3/3] drm/amdkfd: Handle case of invalid queue type

[Oded Gabbay]

On 01/22/2015 12:28 PM, Zhou, Jammy wrote:
> Patches are Reviewed-by: Jammy Zhou 
>
> Regards,
> Jammy
>
Thanks!
Oded
> -Original Message-
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf 
> Of Gabbay, Oded
> Sent: Thursday, January 22, 2015 5:42 PM
> To: dri-devel at lists.freedesktop.org
> Subject: [PATCH 3/3] drm/amdkfd: Handle case of invalid queue type
>
> This patch handles a case where amdkfd tries to destroy a queue but the queue 
> type is invalid.
> This case occurs in non-HWS path.
>
> Signed-off-by: Oded Gabbay 
> ---
>   drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 85387c8..99e2dbb 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -301,6 +301,11 @@ static int destroy_queue_nocpsch(struct 
> device_queue_manager *dqm,
>   }
>   dqm->sdma_queue_count--;
>   deallocate_sdma_queue(dqm, q->sdma_id);
> + } else {
> + pr_debug("q->properties.type is invalid (%d)\n",
> + q->properties.type);
> + retval = -EINVAL;
> + goto out;
>   }
>
>   retval = mqd->destroy_mqd(mqd, q->mqd,
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH v2] clk: Introduce clk_has_parent()

[Stephen Boyd]

On 01/22, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:16:05PM -0800, Stephen Boyd wrote:
> > On 01/21/2015 08:13 AM, Thierry Reding wrote:
> > > From: Thierry Reding 
> > >
> > > This new function is similar to clk_set_parent(), except that it doesn't
> > > actually change the parent. It merely checks that the given parent clock
> > > can be a parent for the given clock.
> > >
> > > A situation where this is useful is to check that a particular setup is
> > > valid before switching to it. One specific use-case for this is atomic
> > > modesetting in the DRM framework where setting a mode is divided into a
> > > check phase where a given configuration is validated before applying
> > > changes to the hardware.
> > >
> > > Cc: Russell King 
> > > Cc: Mike Turquette 
> > > Cc: Stephen Boyd 
> > > Signed-off-by: Thierry Reding 
> > > ---
> > 
> > Reviewed-by: Stephen Boyd 
> > 
> > This will slightly conflict with Tomeu's  patches for per-user clock
> > constraints. It would be best if we can take this through the clk tree
> > to fix up any conflicts
> 
> I had hoped to take this through the drm tree to resolve the build-time.
> Another possibility would be for me to include the clk tree (or a subset
> thereof) in my pull-request. That way you can still fix things up in the
> clock tree if there are any conflicts with other work. We could make
> that work two ways: this patch gets applied to the clk tree and I pull
> it, or I provide a stable branch that I base my pull request on and that
> branch can be pulled into the clk tree.
> 
> Yet another alternative would be to split out the clk_has_parent()
> change from the series and not use it for now. That way we're going to
> miss this check, but we do that anyway currently and it will only be
> temporary until v3.21.
> 
> Perhaps given where we are in the release cycle the latter would make
> the most sense for now.

Ok well let's see what Mike wants to do given that he's doing all
the patch applying right now. I'd think that we could put this
one patch on a different branch that we can merge into clk-next
and you can merge into the drm tree. At least that's the typical
workflow that usually works for everyone.

> 
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> [...]
> > > + /* Optimize for the case where the parent is already the parent. */
> > > + if (clk->parent == parent)
> > > + return true;
> > 
> > I worry that we'll need to grab a lock here with Tomeu's patches, but
> > maybe I'm wrong.
> 
> Why would this need a lock? Worst case somebody concurrently changes the
> parent, in which case will not succeed and fallback to the lookup below.

I was mostly worried about clk_core going away but we would
already have a reference on it so you're right, we don't need any
locks.

> 
> It's been a while since I last looked at Tomeu's series, but I seem to
> remember that struct clk was going to be per-user, in which case I guess
> the code would have to be modified anyway since ->parent and
> ->parent_names will likely become properties of the clock structure
> shared by all users (was it struct clk_core?).
> 

Yes it will have to be fixed up, hence the comment about slight
conflicts.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[pull] radeon drm-fixes-3.19

[Alex Deucher]

Hi Dave,

Suspend/resume regression fix for 3.19.

The following changes since commit 67cf2d391292f8bf0598236e7b4ec343eae6234f:

  Merge tag 'drm-amdkfd-fixes-2015-01-13' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes (2015-01-21 09:26:47 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.19

for you to fetch changes up to 16653dbae06609b9d0a7427de6c7f4c98d76523c:

  drm/radeon: Remove rdev->gart.pages_addr array (2015-01-22 11:48:03 -0500)


Michel Dänzer (3):
  drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry
  drm/radeon: Restore GART table contents after pinning it in VRAM v3
  drm/radeon: Remove rdev->gart.pages_addr array

 drivers/gpu/drm/radeon/cik_sdma.c  |  1 -
 drivers/gpu/drm/radeon/ni_dma.c|  1 -
 drivers/gpu/drm/radeon/r100.c  | 10 +--
 drivers/gpu/drm/radeon/r300.c  | 16 ++
 drivers/gpu/drm/radeon/radeon.h|  9 --
 drivers/gpu/drm/radeon/radeon_asic.c   | 24 +++
 drivers/gpu/drm/radeon/radeon_asic.h   | 12 +---
 drivers/gpu/drm/radeon/radeon_device.c |  2 ++
 drivers/gpu/drm/radeon/radeon_gart.c   | 54 --
 drivers/gpu/drm/radeon/radeon_vm.c |  6 ++--
 drivers/gpu/drm/radeon/rs400.c | 14 +
 drivers/gpu/drm/radeon/rs600.c | 14 +
 drivers/gpu/drm/radeon/si_dma.c|  1 -
 13 files changed, 111 insertions(+), 53 deletions(-)

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

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

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

--- Comment #23 from Arthur Marsh  ---
Created attachment 112660
  --> https://bugs.freedesktop.org/attachment.cgi?id=112660=edit
201501dmesg.txt test after upgrading vlc.

I upgraded vlc to 2.2.0~rc2-2 and re-tested against the same video running
under the current Linus' git head kernel.

There was a gpu lock-up again - each different test seems to have the lock-up
happen at a different stage in play-back, as if there is a non-deterministic
event leading to the lock-up.

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

[GIT PULL] drm/rockchip: Only alloc a kmap for fbdev gem object

[Mark yao]

Hi Dave
 I'd like this patch, some gem object need not be mapped into kernel 
address space.

The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:

   Merge remote-tracking branch 'origin/master' into drm-next 
(2015-01-22 10:44:41 +1000)

are available in the git repository at:


   https://github.com/markyzq/kernel-drm-rockchip.git drm_next

for you to fetch changes up to 5727d1ac71026dd5dd1454b8cc51d409f05f1808:

   drm/rockchip: Only alloc a kmap for fbdev gem object (2015-01-22 
11:19:13 +0800)


Daniel Kurtz (1):
   drm/rockchip: Only alloc a kmap for fbdev gem object

  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |   17 -
  drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |3 ++-
  3 files changed, 15 insertions(+), 7 deletions(-)

[PATCH 1/3] drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry

[Alex Deucher]

On Wed, Jan 21, 2015 at 3:36 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> get_page_entry calculates the GART page table entry, which is just written
> to the GART page table by set_page_entry.
>
> This is a prerequisite for the following fix.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 

Applied the updated series to my -fixes tree.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/r100.c  | 10 +++--
>  drivers/gpu/drm/radeon/r300.c  | 16 ++-
>  drivers/gpu/drm/radeon/radeon.h|  8 ++--
>  drivers/gpu/drm/radeon/radeon_asic.c   | 24 ++
>  drivers/gpu/drm/radeon/radeon_asic.h   | 12 +++
>  drivers/gpu/drm/radeon/radeon_device.c |  2 ++
>  drivers/gpu/drm/radeon/radeon_gart.c   | 37 
> +-
>  drivers/gpu/drm/radeon/rs400.c | 14 -
>  drivers/gpu/drm/radeon/rs600.c | 14 -
>  9 files changed, 100 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 74f06d5..279801c 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -644,6 +644,7 @@ int r100_pci_gart_init(struct radeon_device *rdev)
> return r;
> rdev->gart.table_size = rdev->gart.num_gpu_pages * 4;
> rdev->asic->gart.tlb_flush = _pci_gart_tlb_flush;
> +   rdev->asic->gart.get_page_entry = _pci_gart_get_page_entry;
> rdev->asic->gart.set_page = _pci_gart_set_page;
> return radeon_gart_table_ram_alloc(rdev);
>  }
> @@ -681,11 +682,16 @@ void r100_pci_gart_disable(struct radeon_device *rdev)
> WREG32(RADEON_AIC_HI_ADDR, 0);
>  }
>
> +uint64_t r100_pci_gart_get_page_entry(uint64_t addr, uint32_t flags)
> +{
> +   return addr;
> +}
> +
>  void r100_pci_gart_set_page(struct radeon_device *rdev, unsigned i,
> -   uint64_t addr, uint32_t flags)
> +   uint64_t entry)
>  {
> u32 *gtt = rdev->gart.ptr;
> -   gtt[i] = cpu_to_le32(lower_32_bits(addr));
> +   gtt[i] = cpu_to_le32(lower_32_bits(entry));
>  }
>
>  void r100_pci_gart_fini(struct radeon_device *rdev)
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 064ad55..08d68f3 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -73,11 +73,8 @@ void rv370_pcie_gart_tlb_flush(struct radeon_device *rdev)
>  #define R300_PTE_WRITEABLE (1 << 2)
>  #define R300_PTE_READABLE  (1 << 3)
>
> -void rv370_pcie_gart_set_page(struct radeon_device *rdev, unsigned i,
> - uint64_t addr, uint32_t flags)
> +uint64_t rv370_pcie_gart_get_page_entry(uint64_t addr, uint32_t flags)
>  {
> -   void __iomem *ptr = rdev->gart.ptr;
> -
> addr = (lower_32_bits(addr) >> 8) |
> ((upper_32_bits(addr) & 0xff) << 24);
> if (flags & RADEON_GART_PAGE_READ)
> @@ -86,10 +83,18 @@ void rv370_pcie_gart_set_page(struct radeon_device *rdev, 
> unsigned i,
> addr |= R300_PTE_WRITEABLE;
> if (!(flags & RADEON_GART_PAGE_SNOOP))
> addr |= R300_PTE_UNSNOOPED;
> +   return addr;
> +}
> +
> +void rv370_pcie_gart_set_page(struct radeon_device *rdev, unsigned i,
> + uint64_t entry)
> +{
> +   void __iomem *ptr = rdev->gart.ptr;
> +
> /* on x86 we want this to be CPU endian, on powerpc
>  * on powerpc without HW swappers, it'll get swapped on way
>  * into VRAM - so no need for cpu_to_le32 on VRAM tables */
> -   writel(addr, ((void __iomem *)ptr) + (i * 4));
> +   writel(entry, ((void __iomem *)ptr) + (i * 4));
>  }
>
>  int rv370_pcie_gart_init(struct radeon_device *rdev)
> @@ -109,6 +114,7 @@ int rv370_pcie_gart_init(struct radeon_device *rdev)
> DRM_ERROR("Failed to register debugfs file for PCIE gart 
> !\n");
> rdev->gart.table_size = rdev->gart.num_gpu_pages * 4;
> rdev->asic->gart.tlb_flush = _pcie_gart_tlb_flush;
> +   rdev->asic->gart.get_page_entry = _pcie_gart_get_page_entry;
> rdev->asic->gart.set_page = _pcie_gart_set_page;
> return radeon_gart_table_vram_alloc(rdev);
>  }
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 54529b8..40c4c7a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -242,6 +242,7 @@ bool radeon_get_bios(struct radeon_device *rdev);
>   * Dummy page
>   */
>  struct radeon_dummy_page {
> +   uint64_tentry;
> struct page *page;
> dma_addr_t  addr;
>  };
> @@ -646,6 +647,7 @@ struct radeon_gart {
> unsignedtable_size;
> struct page **pages;
> dma_addr_t  *pages_addr;
> +   uint64_t*pages_entry;
> bool 

[PATCH] drm/rockchip: vop: fix vop vsync/hsync polarity

[Caesar Wang]

Mark,

在 2015年01月22日 11:15, Mark Yao 写道:
> Vop set wrong vsync/hsync polarity, it may cause some
> display problem. known problem is that caused HDMI hdcp
> authenticate failed, caused pixel offset with hdmi display.
> the polarity description at RK3288 TRM doc:
>dsp_vsync_pol
>  VSYNC polarity
>1'b0 : negative
>1'b1 : positive
>dsp_hsync_pol
>  HSYNC polarity
>1'b0 : negative
>1'b1 : positive
>
> Signed-off-by: Mark Yao 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 9a5c571..2b145ba5 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -874,8 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
>   VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
>   
>   val = 0x8;
> - val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 1 : 0;
> - val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? (1 << 1) : 0;
> + val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
> + val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
Tested-by: Caesar Wang 
>   VOP_CTRL_SET(vop, pin_pol, val);
>   
>   VOP_CTRL_SET(vop, htotal_pw, (htotal << 16) | hsync_len);

[PULL] drm-amdkfd-next

[Oded Gabbay]

On 01/22/2015 01:47 AM, Dave Airlie wrote:
> On 21 January 2015 at 22:38, Oded Gabbay  wrote:
>> Hi Dave,
>>
>> Another pull request for 3.20.
>>
>> drm-amdkfd-next-2015-01-21:
>>
>> - Infrastructure work in amdkfd to prepare for VI support. This work mainly
>>includes separating modules into ASIC-specific functionality, adding
>>new properties that are relevant for VI, making sure that shared code is
>>reused, etc.
>>
>> - Improve mechanism of submitting packets to HIQ (the kernel queue that 
>> amdkfd
>>uses to issue commands to the GPU). The driver used to verify that each CS
>>was read by the GPU. However, this proved to be both unnecessary and 
>> erroneous.
>>Therefore, we cancelled this verification.
>>
>> - Moved initialization of compute VMIDs into radeon driver
>>
>> - Various minor fixes
>
>
>   CC [M]  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.o
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:
> In function ‘destroy_queue_nocpsch’:
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:291:9:
> warning: ‘mqd’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>retval = mqd->destroy_mqd(mqd, q->mqd,
>   ^
>
> Looks valid to me, I've pulled this but please follow up ASAP with a
> fix for the new warning.
>
> Dave.
>
Thanks, sent the fix (and others) to the mailing list.

Oded

[pull] radeon drm-next-3.20

[Alex Deucher]

Hi Dave,

Radeon drm-next changes for 3.20.  Highlights:
- Indirect draw support for evergreen/NI hw
- SMC fan control support for SI/CI
- Manual fan control for SI/CI
- DP audio support
- Lots of code cleanup

The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:

  Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 
10:44:41 +1000)

are available in the git repository at:


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

for you to fetch changes up to 5a1aa4b447868b0ea66d2903df479b3b94c34151:

  drm/radeon: make MMU_NOTIFIER optional (2015-01-22 10:42:21 -0500)


Alex Deucher (15):
  drm/radeon: bind fan control on SI cards to hwmon interface
  drm/radeon: enable smc fan control on SI
  drm/radeon: comment out some currently unused ci dpm code
  drm/radeon: comment out some currently unused si dpm code
  drm/radeon: comment out some currently unused kv dpm code
  drm/radeon: comment out some currently unused ni dpm code
  drm/radeon: comment out some currently unused btc dpm code
  drm/radeon: comment out some currently unused tn dpm code
  drm/radeon: comment out some currently unused sumo dpm code
  drm/radeon: comment out some currently unused eg dpm code
  drm/radeon: comment out some currently unused 7xx dpm code
  radeon/audio: consolidate write_sad_regs() functions
  radeon/audio: moved VBI packet programming to separate functions
  drm/radeon: whitespace clean up in radeon_audio.c
  drm/radeon: use NULL rather then 0 in audio detect

Glenn Kennard (1):
  drm/radeon: evergreen/cayman indirect draw support (v2)

Oleg Chernovskiy (4):
  add common fan control asic callbacks
  drm/radeon: add hwmon interface for managing fan pwm (v2)
  drm/radeon: bind fan control on CI cards to hwmon interface (v2)
  fixes for SI fan handling

Rickard Strandqvist (3):
  drm/radeon/radeon_i2c: Remove unused function
  drm/radeon/radeon_fb: Remove unused function
  gpu: drm: radeon: radeon_object: Remove unused function

Rob Clark (1):
  drm/radeon: make MMU_NOTIFIER optional

Slava Grigorev (21):
  radeon/audio: consolidate audio_init() functions
  radeon/audio: defined initial audio interface that gets initialized via 
detect() call
  radeon/audio: consolidate write_speaker_allocation() functions
  radeon/audio: consolidate write_latency_fields() functions
  radeon/audio: consolidate audio_get_pin() functions
  radeon/audio: consolidate select_pin() functions
  radeon/audio: consolidate audio_enable() functions
  radeon/audio: consolidate audio_fini() functions
  radeon/audio: consolidate audio_set_dto() functions
  radeon/audio: consolidate update_avi_infoframe() functions
  radeon/audio: consolidate update_acr() functions (v2)
  radeon: moved HDMI color depth programming to a separate function
  radeon/audio: removed unnecessary CRC control programing
  radeon/audio: set_avi_packet() function cleanup
  radeon/audio: moved audio packet programming to a separate function
  radeon/audio: moved mute programming to a separate function
  radeon/audio: removed unnecessary debug settings
  radeon/audio: consolidate audio_mode_set() functions
  radeon/audio: applied audio_dpms() and audio_mode_set() calls
  radeon/audio: moved audio caps programming to audio_hotplug() function
  radeon/audio: enable DP audio

 drivers/gpu/drm/Kconfig|   1 -
 drivers/gpu/drm/radeon/Makefile|   6 +-
 drivers/gpu/drm/radeon/atombios_encoders.c |  29 +-
 drivers/gpu/drm/radeon/btc_dpm.c   |   2 +
 drivers/gpu/drm/radeon/ci_dpm.c|  57 ++-
 drivers/gpu/drm/radeon/ci_dpm.h|   1 +
 drivers/gpu/drm/radeon/ci_smc.c|   2 +
 drivers/gpu/drm/radeon/cik.c   |   5 +-
 drivers/gpu/drm/radeon/cypress_dpm.c   |   2 +
 drivers/gpu/drm/radeon/dce3_1_afmt.c   | 264 +-
 drivers/gpu/drm/radeon/dce6_afmt.c | 218 
 drivers/gpu/drm/radeon/evergreen.c |   7 +-
 drivers/gpu/drm/radeon/evergreen_cs.c  |  76 +++
 drivers/gpu/drm/radeon/evergreen_hdmi.c| 478 --
 drivers/gpu/drm/radeon/evergreen_reg.h |  15 +
 drivers/gpu/drm/radeon/evergreend.h|   1 +
 drivers/gpu/drm/radeon/kv_dpm.c|   2 +
 drivers/gpu/drm/radeon/ni.c|  18 +-
 drivers/gpu/drm/radeon/ni_dpm.c|   2 +
 drivers/gpu/drm/radeon/r600.c  |   7 +-
 drivers/gpu/drm/radeon/r600_hdmi.c | 399 ---
 drivers/gpu/drm/radeon/radeon.h|  15 +
 drivers/gpu/drm/radeon/radeon_asic.c   |  36 +-
 drivers/gpu/drm/radeon/radeon_asic.h   |  21 +-
 drivers/gpu/drm/radeon/radeon_audio.c  | 766 +
 drivers/gpu/drm/radeon/radeon_audio.h  |  84 
 

[PATCH 3/3] drm/amdkfd: Handle case of invalid queue type

[Oded Gabbay]

This patch handles a case where amdkfd tries to destroy a queue but the queue
type is invalid.
This case occurs in non-HWS path.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 85387c8..99e2dbb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -301,6 +301,11 @@ static int destroy_queue_nocpsch(struct 
device_queue_manager *dqm,
}
dqm->sdma_queue_count--;
deallocate_sdma_queue(dqm, q->sdma_id);
+   } else {
+   pr_debug("q->properties.type is invalid (%d)\n",
+   q->properties.type);
+   retval = -EINVAL;
+   goto out;
}

retval = mqd->destroy_mqd(mqd, q->mqd,
-- 
1.9.1

[PATCH 2/3] drm/amdkfd: Add break at the end of case

[Oded Gabbay]

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 +++
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 23a1e95..85387c8 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1114,8 +1114,11 @@ struct device_queue_manager 
*device_queue_manager_init(struct kfd_dev *dev)
switch (dev->device_info->asic_family) {
case CHIP_CARRIZO:
device_queue_manager_init_vi(>ops_asic_specific);
+   break;
+
case CHIP_KAVERI:
device_queue_manager_init_cik(>ops_asic_specific);
+   break;
}

if (dqm->ops.initialize(dqm) != 0) {
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
index c04b1ac..e415a2a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
@@ -288,8 +288,11 @@ struct kernel_queue *kernel_queue_init(struct kfd_dev *dev,
switch (dev->device_info->asic_family) {
case CHIP_CARRIZO:
kernel_queue_init_vi(>ops_asic_specific);
+   break;
+
case CHIP_KAVERI:
kernel_queue_init_cik(>ops_asic_specific);
+   break;
}

if (kq->ops.initialize(kq, dev, type, KFD_KERNEL_QUEUE_SIZE) == false) {
-- 
1.9.1

[PATCH 1/3] drm/amdkfd: Remove negative check of uint variable

[Oded Gabbay]

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index a5c69e9..23a1e95 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -587,7 +587,7 @@ static int allocate_sdma_queue(struct device_queue_manager 
*dqm,
 static void deallocate_sdma_queue(struct device_queue_manager *dqm,
unsigned int sdma_queue_id)
 {
-   if (sdma_queue_id < 0 || sdma_queue_id >= CIK_SDMA_QUEUES)
+   if (sdma_queue_id >= CIK_SDMA_QUEUES)
return;
set_bit(sdma_queue_id, (unsigned long *)>sdma_bitmap);
 }
-- 
1.9.1

[PATCH 2/3] drm/radeon: Restore GART table contents after pinning it in VRAM v3

[Christian König]

Am 22.01.2015 um 10:58 schrieb Michel Dänzer:
> From: Michel Dänzer 
>
> The GART table BO has to be moved out of VRAM for suspend/resume. Any
> updates to the GART table during that time were silently dropped without
> this change. This caused GPU lockups on resume in some cases, see the bug
> reports referenced below.
>
> This might also make GPU reset more robust in some cases, as we no longer
> rely on the GART table in VRAM being preserved across the GPU
> lockup/reset.
>
> v2: Add logic to radeon_gart_table_vram_pin directly instead of
>  reinstating radeon_gart_restore
> v3: Move code after assignment of rdev->gart.table_addr so that the GART
>  TLB flush can work as intended, add code comment explaining why we're
>  doing this
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 

This one and the two others in the series are Reviewed-by: Christian 
König 

> ---
>   drivers/gpu/drm/radeon/radeon_gart.c | 13 +
>   1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index a530932..c7be612 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -165,6 +165,19 @@ int radeon_gart_table_vram_pin(struct radeon_device 
> *rdev)
>   radeon_bo_unpin(rdev->gart.robj);
>   radeon_bo_unreserve(rdev->gart.robj);
>   rdev->gart.table_addr = gpu_addr;
> +
> + if (!r) {
> + int i;
> +
> + /* We might have dropped some GART table updates while it wasn't
> +  * mapped, restore all entries
> +  */
> + for (i = 0; i < rdev->gart.num_gpu_pages; i++)
> + radeon_gart_set_page(rdev, i, 
> rdev->gart.pages_entry[i]);
> + mb();
> + radeon_gart_tlb_flush(rdev);
> + }
> +
>   return r;
>   }
>   

[PATCH] drm/rockchip: vop: fix vop vsync/hsync polarity

[Daniel Kurtz]

On Thu, Jan 22, 2015 at 11:15 AM, Mark Yao  wrote:
> Vop set wrong vsync/hsync polarity, it may cause some
> display problem. known problem is that caused HDMI hdcp
> authenticate failed, caused pixel offset with hdmi display.
> the polarity description at RK3288 TRM doc:
>   dsp_vsync_pol
> VSYNC polarity
>   1'b0 : negative
>   1'b1 : positive
>   dsp_hsync_pol
> HSYNC polarity
>   1'b0 : negative
>   1'b1 : positive
>
> Signed-off-by: Mark Yao 

Looks good!

Reviewed-by: Daniel Kurtz 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 9a5c571..2b145ba5 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -874,8 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
> VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
>
> val = 0x8;
> -   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 1 : 0;
> -   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? (1 << 1) : 0;
> +   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
> +   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
> VOP_CTRL_SET(vop, pin_pol, val);
>
> VOP_CTRL_SET(vop, htotal_pw, (htotal << 16) | hsync_len);
> --
> 1.7.9.5
>
>

[PATCH] drm/rockchip: vop: fix vop vsync/hsync polarity

[Mark Yao]

Vop set wrong vsync/hsync polarity, it may cause some
display problem. known problem is that caused HDMI hdcp
authenticate failed, caused pixel offset with hdmi display.
the polarity description at RK3288 TRM doc:
  dsp_vsync_pol
VSYNC polarity
  1'b0 : negative
  1'b1 : positive
  dsp_hsync_pol
HSYNC polarity
  1'b0 : negative
  1'b1 : positive

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9a5c571..2b145ba5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -874,8 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc,
VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);

val = 0x8;
-   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 1 : 0;
-   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? (1 << 1) : 0;
+   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
+   val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
VOP_CTRL_SET(vop, pin_pol, val);

VOP_CTRL_SET(vop, htotal_pw, (htotal << 16) | hsync_len);
-- 
1.7.9.5

[PATCH] drm/amdkfd: Fix bug in pipelines initialization

[Oded Gabbay]

This patch fixes a bug when calling to init_pipeline() interface.
The index that was passed to that function didn't take into account the
first_pipe value, which represents the first pipe index that is under amdkfd's
responsibility.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index b9626ae..fbb353f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -565,10 +565,10 @@ static int init_pipelines(struct device_queue_manager 
*dqm,

for (i = 0; i < pipes_num; i++) {
inx = i + first_pipe;
-   pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
+   pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
pr_debug("kfd: pipeline address %llX\n", pipe_hpd_addr);
/* = log2(bytes/4)-1 */
-   kfd2kgd->init_pipeline(dqm->dev->kgd, i,
+   kfd2kgd->init_pipeline(dqm->dev->kgd, inx,
CIK_HPD_EOP_BYTES_LOG2 - 3, pipe_hpd_addr);
}

-- 
1.9.1

[PATCH v4 9/9] drm/exynos: add support for 'hdmi' clock

[Fabio Estevam]

On Tue, Jan 20, 2015 at 10:16 AM, Marek Szyprowski
 wrote:

> +   mixer_res->hdmi = devm_clk_get(dev, "hdmi");
> +   if (IS_ERR(mixer_res->hdmi)) {
> +   dev_err(dev, "failed to get clock 'hdmi'\n");
> +   return -ENODEV;

'return PTR_ERR(mixer_res->hdmi);' would be better.

> +   }
> +
> mixer_res->sclk_hdmi = devm_clk_get(dev, "sclk_hdmi");
> if (IS_ERR(mixer_res->sclk_hdmi)) {
> dev_err(dev, "failed to get clock 'sclk_hdmi'\n");
> @@ -1095,6 +1102,7 @@ static void mixer_poweron(struct exynos_drm_manager 
> *mgr)
> pm_runtime_get_sync(ctx->dev);
>
> clk_prepare_enable(res->mixer);
> +   clk_prepare_enable(res->hdmi);

Better check whether clk_prepare_enable failed.

[PATCH v2 1/3] drm/radeon: Don't increment pipe_id in kgd_init_pipeline

[Alex Deucher]

On Thu, Jan 22, 2015 at 5:59 AM, Oded Gabbay  wrote:
> This patch fixes the behavior of kgd_init_pipeline in that this function
> shouldn't automatically increase the pipe_id argument by 1 right at the start
> of the function.
>
> This is because the first_pipe value might not be always 1, and because a
> proper interface function should not hide this info inside its implementation.
> In other words, the calling function should provide the real pipe_id and not
> count on kgd_init_pipeline to "fix" it.
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
> b/drivers/gpu/drm/radeon/radeon_kfd.c
> index 8bf87f1..bef9a09 100644
> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
> @@ -436,7 +436,7 @@ static int kgd_init_memory(struct kgd_dev *kgd)
>  static int kgd_init_pipeline(struct kgd_dev *kgd, uint32_t pipe_id,
> uint32_t hpd_size, uint64_t hpd_gpu_addr)
>  {
> -   uint32_t mec = (++pipe_id / CIK_PIPE_PER_MEC) + 1;
> +   uint32_t mec = (pipe_id / CIK_PIPE_PER_MEC) + 1;
> uint32_t pipe = (pipe_id % CIK_PIPE_PER_MEC);
>
> lock_srbm(kgd, mec, pipe, 0, 0);
> --
> 1.9.1
>

[PATCH v2 2/3] drm/amdkfd: Fix bug in pipelines initialization

[Alex Deucher]

On Thu, Jan 22, 2015 at 5:59 AM, Oded Gabbay  wrote:
> This patch fixes a bug when calling to init_pipeline() interface.
> The index that was passed to that function didn't take into account the
> first_pipe value, which represents the first pipe index that is under amdkfd's
> responsibility.
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index b9626ae..cd0710a 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -565,10 +565,14 @@ static int init_pipelines(struct device_queue_manager 
> *dqm,
>
> for (i = 0; i < pipes_num; i++) {
> inx = i + first_pipe;
> +   /*
> +* HPD buffer on GTT is allocated by amdkfd, no need to waste
> +* space in GTT for pipelines we don't initialize
> +*/
> pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
> pr_debug("kfd: pipeline address %llX\n", pipe_hpd_addr);
> /* = log2(bytes/4)-1 */
> -   kfd2kgd->init_pipeline(dqm->dev->kgd, i,
> +   kfd2kgd->init_pipeline(dqm->dev->kgd, inx,
> CIK_HPD_EOP_BYTES_LOG2 - 3, pipe_hpd_addr);
> }
>
> --
> 1.9.1
>

[Bug 88658] (bisected) Slow video playback on Kabini

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

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

--- Comment #6 from smoki  ---

 Well he can just try to revert this one again, Kodi seems to does not like
that:


http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786

 @Michel

 I guess this should be reverted again as Valley does not stutter with 3.19
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/20150122/620d0d5e/attachment.html>

[PATCH v2 3/3] drm/amdkfd: Fix bug in call to init_pipelines()

[Alex Deucher]

On Thu, Jan 22, 2015 at 5:59 AM, Oded Gabbay  wrote:
> This patch fixes a bug where the first_pipe index passed into init_pipelines()
> was a #define instead of the value that is passed into amdkfd by radeon
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index cd0710a..0d8694f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -588,7 +588,7 @@ static int init_scheduler(struct device_queue_manager 
> *dqm)
>
> pr_debug("kfd: In %s\n", __func__);
>
> -   retval = init_pipelines(dqm, get_pipes_num(dqm), KFD_DQM_FIRST_PIPE);
> +   retval = init_pipelines(dqm, get_pipes_num(dqm), get_first_pipe(dqm));
> if (retval != 0)
> return retval;
>
> --
> 1.9.1
>

[PATCH] drm/amdkfd: Fix sparse errors

[Alex Deucher]

On Thu, Jan 22, 2015 at 6:55 AM, Oded Gabbay  wrote:
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   | 16 ++---
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 28 
> ++
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  | 20 +---
>  3 files changed, 27 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 732087dc..5c50aa8 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -141,8 +141,6 @@ static int kfd_ioctl_get_version(struct file *filep, 
> struct kfd_process *p,
>  static int set_queue_properties_from_user(struct queue_properties 
> *q_properties,
> struct kfd_ioctl_create_queue_args *args)
>  {
> -   void *tmp;
> -
> if (args->queue_percentage > KFD_MAX_QUEUE_PERCENTAGE) {
> pr_err("kfd: queue percentage must be between 0 to 
> KFD_MAX_QUEUE_PERCENTAGE\n");
> return -EINVAL;
> @@ -180,16 +178,18 @@ static int set_queue_properties_from_user(struct 
> queue_properties *q_properties,
> return -EFAULT;
> }
>
> -   tmp = (void *)(uintptr_t)args->eop_buffer_address;
> -   if (tmp != NULL &&
> -   !access_ok(VERIFY_WRITE, tmp, sizeof(uint32_t))) {
> +   if (args->eop_buffer_address &&
> +   !access_ok(VERIFY_WRITE,
> +   (const void __user *) args->eop_buffer_address,
> +   sizeof(uint32_t))) {
> pr_debug("kfd: can't access eop buffer");
> return -EFAULT;
> }
>
> -   tmp = (void *)(uintptr_t)args->ctx_save_restore_address;
> -   if (tmp != NULL &&
> -   !access_ok(VERIFY_WRITE, tmp, sizeof(uint32_t))) {
> +   if (args->ctx_save_restore_address &&
> +   !access_ok(VERIFY_WRITE,
> +   (const void __user *) args->ctx_save_restore_address,
> +   sizeof(uint32_t))) {
> pr_debug("kfd: can't access ctx save restore buffer");
> return -EFAULT;
> }
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 99e2dbb..b189f97 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -62,12 +62,6 @@ enum KFD_MQD_TYPE get_mqd_type_from_queue_type(enum 
> kfd_queue_type type)
> return KFD_MQD_TYPE_CP;
>  }
>
> -inline unsigned int get_pipes_num(struct device_queue_manager *dqm)
> -{
> -   BUG_ON(!dqm || !dqm->dev);
> -   return dqm->dev->shared_resources.compute_pipe_count;
> -}
> -
>  static inline unsigned int get_first_pipe(struct device_queue_manager *dqm)
>  {
> BUG_ON(!dqm);
> @@ -79,25 +73,6 @@ static inline unsigned int get_pipes_num_cpsch(void)
> return PIPE_PER_ME_CP_SCHEDULING;
>  }
>
> -inline unsigned int
> -get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
> -{
> -   uint32_t nybble;
> -
> -   nybble = (pdd->lds_base >> 60) & 0x0E;
> -
> -   return nybble;
> -}
> -
> -inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *pdd)
> -{
> -   unsigned int shared_base;
> -
> -   shared_base = (pdd->lds_base >> 16) & 0xFF;
> -
> -   return shared_base;
> -}
> -
>  void program_sh_mem_settings(struct device_queue_manager *dqm,
> struct qcm_process_device *qpd)
>  {
> @@ -336,7 +311,8 @@ static int update_queue(struct device_queue_manager *dqm, 
> struct queue *q)
> BUG_ON(!dqm || !q || !q->mqd);
>
> mutex_lock(>lock);
> -   mqd = dqm->ops.get_mqd_manager(dqm, q->properties.type);
> +   mqd = dqm->ops.get_mqd_manager(dqm,
> +   get_mqd_type_from_queue_type(q->properties.type));
> if (mqd == NULL) {
> mutex_unlock(>lock);
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> index 1934795..e7b17b2 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> @@ -160,10 +160,24 @@ void device_queue_manager_init_cik(struct 
> device_queue_manager_ops *ops);
>  void device_queue_manager_init_vi(struct device_queue_manager_ops *ops);
>  void program_sh_mem_settings(struct device_queue_manager *dqm,
> struct qcm_process_device *qpd);
> -inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *qpd);
> -inline unsigned int get_sh_mem_bases_nybble_64(struct kfd_process_device 
> *pdd);
>  int init_pipelines(struct device_queue_manager *dqm,
> unsigned int 

[Bug 91371] UVD not responding error during UVD initialization for AMD 7670M graphics

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

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

--- Comment #4 from Adis Hamzić  ---
(In reply to Michel Dänzer from comment #3)
> (In reply to Adis Hamzić from comment #2)
> > Have the same issue since my kernel update yesterday.
> 
> What kernel version did you update from? Can you bisect?

According to the logs it's was 3.14.27, but I can't see anything in the diff
that relates to radeon:

[2015-01-19 19:54] [ALPM] upgraded linux314 (3.14.27-1 -> 3.14.28-1)

I'll try to compile and install the old version and see if the issue is still
there.

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

[PATCH] drm/radeon: make MMU_NOTIFIER optional

[Alex Deucher]

On Wed, Jan 21, 2015 at 5:49 PM, Rob Clark  wrote:
> In cases where MMU_NOTIFIER is not available, userptr will not be
> available.  Similar to i915, although not making an exception for
> CAP_SYS_ADMIN.
>
> The proposed userspace patches for userptr seem to handle the fall-
> back properly, so a userptr-less kernel should not be a problem.
>
> Signed-off-by: Rob Clark 

Applied to my -next tree.  thanks!

Alex

> ---
>  drivers/gpu/drm/Kconfig | 1 -
>  drivers/gpu/drm/radeon/Makefile | 5 +++--
>  drivers/gpu/drm/radeon/radeon.h | 8 
>  3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c3413b6..75e6a88 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -110,7 +110,6 @@ config DRM_RADEON
> select HWMON
> select BACKLIGHT_CLASS_DEVICE
> select INTERVAL_TREE
> -   select MMU_NOTIFIER
> help
>   Choose this option if you have an ATI Radeon graphics card.  There
>   are both PCI and AGP versions.  You don't need to choose this to
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 12bc212..5e7a38b 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -80,8 +80,9 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
> rv740_dpm.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> trinity_dpm.o \
> trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> -   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o 
> radeon_mn.o \
> -   radeon_sync.o
> +   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o 
> radeon_sync.o
> +
> +radeon-$(CONFIG_MMU_NOTIFIER) += radeon_mn.o
>
>  # add async DMA block
>  radeon-y += \
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 54529b8..52611d2 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1777,8 +1777,16 @@ void radeon_test_syncing(struct radeon_device *rdev);
>  /*
>   * MMU Notifier
>   */
> +#if defined(CONFIG_MMU_NOTIFIER)
>  int radeon_mn_register(struct radeon_bo *bo, unsigned long addr);
>  void radeon_mn_unregister(struct radeon_bo *bo);
> +#else
> +static inline int radeon_mn_register(struct radeon_bo *bo, unsigned long 
> addr)
> +{
> +   return -ENODEV;
> +}
> +static inline void radeon_mn_unregister(struct radeon_bo *bo) {}
> +#endif
>
>  /*
>   * Debugfs
> --
> 2.1.0
>

[PATCH 3/3] drm/amdkfd: Handle case of invalid queue type

[Zhou, Jammy]

Patches are Reviewed-by: Jammy Zhou 

Regards,
Jammy

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Gabbay, Oded
Sent: Thursday, January 22, 2015 5:42 PM
To: dri-devel at lists.freedesktop.org
Subject: [PATCH 3/3] drm/amdkfd: Handle case of invalid queue type

This patch handles a case where amdkfd tries to destroy a queue but the queue 
type is invalid.
This case occurs in non-HWS path.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 85387c8..99e2dbb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -301,6 +301,11 @@ static int destroy_queue_nocpsch(struct 
device_queue_manager *dqm,
}
dqm->sdma_queue_count--;
deallocate_sdma_queue(dqm, q->sdma_id);
+   } else {
+   pr_debug("q->properties.type is invalid (%d)\n",
+   q->properties.type);
+   retval = -EINVAL;
+   goto out;
}

retval = mqd->destroy_mqd(mqd, q->mqd,
--
1.9.1

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

[PATCH] drm/amdkfd: Fix bug in pipelines initialization

[Zhou, Jammy]

Hi Oded,

-   pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
+   pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
I think 'i' should still be used here, because it is the real index in the 
buffer

Besides, for the code below in init_scheduler(), it looks like the 
KFD_DQM_FIRST_PIPE is not correct, and we probably need to use 
get_first_pipe(dqm) instead.

retval = init_pipelines(dqm, get_pipes_num(dqm), KFD_DQM_FIRST_PIPE);

Regards,
Jammy

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Gabbay, Oded
Sent: Thursday, January 22, 2015 5:07 PM
To: dri-devel at lists.freedesktop.org
Subject: [PATCH] drm/amdkfd: Fix bug in pipelines initialization

This patch fixes a bug when calling to init_pipeline() interface.
The index that was passed to that function didn't take into account the 
first_pipe value, which represents the first pipe index that is under amdkfd's 
responsibility.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index b9626ae..fbb353f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -565,10 +565,10 @@ static int init_pipelines(struct device_queue_manager 
*dqm,

for (i = 0; i < pipes_num; i++) {
inx = i + first_pipe;
-   pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
+   pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
pr_debug("kfd: pipeline address %llX\n", pipe_hpd_addr);
/* = log2(bytes/4)-1 */
-   kfd2kgd->init_pipeline(dqm->dev->kgd, i,
+   kfd2kgd->init_pipeline(dqm->dev->kgd, inx,
CIK_HPD_EOP_BYTES_LOG2 - 3, pipe_hpd_addr);
}

--
1.9.1

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

[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

[Christian König]

Am 22.01.2015 um 08:31 schrieb Michel Dänzer:
> On 21.01.2015 18:22, Christian König wrote:
>> Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
>>> From: Michel Dänzer 
>>>
>>> The GART table BO has to be moved out of VRAM for suspend/resume. Any
>>> updates to the GART table during that time were silently dropped without
>>> this change. This caused GPU lockups on resume in some cases, see the bug
>>> reports referenced below.
>>>
>>> This might also make GPU reset more robust in some cases, as we no longer
>>> rely on the GART table in VRAM being preserved across the GPU
>>> lockup/reset.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
>>> Cc: stable at vger.kernel.org
>>> Signed-off-by: Michel Dänzer 
>> Can we make that directly part of radeon_gart_table_vram_pin? Doesn't
>> seem to make sense to always need to call both functions.
> Good point, fixed in v2.
>
>
>> Additional to that couldn't we just stop mapping/unmapping the BO in
>> radeon_gart_table_vram_pin? As far as I know CPU mapped BOs can still
>> move around.
> You're probably thinking of userspace mappings. I think the kernel
> mapping would continue pointing to the same area of VRAM even while the
> BO is evicted from VRAM or pinned back to another area of VRAM.


Oh really? I was always under the impression that we only need to wait 
for moves to complete and the kernel page tables would point to the new 
location after that automatically.

If that's not the case we might have a problem in the UVD code as well.

Regards,
Christian.

[PATCH v2 2/3] drm/radeon: Restore GART table contents after pinning it in VRAM

[Christian König]

Am 22.01.2015 um 08:30 schrieb Michel Dänzer:
> From: Michel Dänzer 
>
> The GART table BO has to be moved out of VRAM for suspend/resume. Any
> updates to the GART table during that time were silently dropped without
> this change. This caused GPU lockups on resume in some cases, see the bug
> reports referenced below.
>
> This might also make GPU reset more robust in some cases, as we no longer
> rely on the GART table in VRAM being preserved across the GPU
> lockup/reset.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 
> ---
>
> v2: Add logic to radeon_gart_table_vram_pin directly instead of reinstating
>  radeon_gart_restore function
>
>   drivers/gpu/drm/radeon/radeon_gart.c | 8 
>   1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index a530932..0c8c739 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -163,6 +163,14 @@ int radeon_gart_table_vram_pin(struct radeon_device 
> *rdev)
>   r = radeon_bo_kmap(rdev->gart.robj, >gart.ptr);
>   if (r)
>   radeon_bo_unpin(rdev->gart.robj);
> + else {

I would add a comment why we do this here.

> + int i;
> +
> + for (i = 0; i < rdev->gart.num_gpu_pages; i++)
> + radeon_gart_set_page(rdev, i, 
> rdev->gart.pages_entry[i]);
> + mb();
> + radeon_gart_tlb_flush(rdev);

That TLB flush won't work correctly because the table_addr isn't up to 
date yet.

> + }
>   radeon_bo_unreserve(rdev->gart.robj);
>   rdev->gart.table_addr = gpu_addr;
It's updated here instead. Maybe completely drop the local gpu_addr 
variable and update the table_addr directly instead.

Christian.

>   return r;

[PATCH] drm/atomic: Add drm_crtc_state->active

[Thierry Reding]

On Thu, Jan 22, 2015 at 08:04:33AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
> @@ -1391,6 +1395,12 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_crtc_id = prop;
>  
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> + "ACTIVE");

We seem to have a weird mix of property names. Some are all caps, others
all lowercase. I guess we can't really make it consistent anymore since
the only one so far that stands out is "type" and we've already exposed
that to userspace, so ABI...

Otherwise, this looks good, but I don't feel like I understand this good
enough to give my Reviewed-by. I'll go give this a spin on Tegra, see if
that improves my understanding.

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

[PATCH] drm: Add standardized boolean props

[Thierry Reding]

On Wed, Jan 21, 2015 at 08:47:38AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
> @@ -3738,6 +3738,24 @@ struct drm_property *drm_property_create_range(struct 
> drm_device *dev, int flags
>  }
>  EXPORT_SYMBOL(drm_property_create_range);
>  
> +/**
> + * drm_property_create_signed_range - create a new signed ranged property 
> type
> + * @dev: drm device
> + * @flags: flags specifying the property type
> + * @name: name of the property
> + * @min: minimum value of the property
> + * @max: maximum value of the property
> + *
> + * This creates a new generic drm property which can then be attached to a 
> drm

Nit: s/drm/DRM/ but that's the same for all others so can be done in a
follow-up. I'll volunteer because I realize that not everybody is that
pedantic.

>  /**
> + * drm_property_create_bool - create a new boolean property type
> + * @dev: drm device
> + * @flags: flags specifying the property type
> + * @name: name of the property
> + *
> + * This creates a new generic drm property which can then be attached to a 
> drm
> + * object with drm_object_attach_property. The returned property object must 
> be
> + * freed with drm_property_destroy.
> + *
> + * This is implemented as a ranged property with only {0, 1} as valid values.
> + *
> + * Returns:
> + * A pointer to the newly created property on success, NULL on failure.
> + */
> +struct drm_property *drm_property_create_bool(struct drm_device *dev, int 
> flags,

I find that int is a strange type for flags. unsigned long is a little
more idiomatic in my opinion. But again all other functions seem to do
the same, so no need to respin because of that.

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/c6f75ee2/attachment.sig>

[PULL] drm-amdkfd-next

[Dave Airlie]

On 21 January 2015 at 22:38, Oded Gabbay  wrote:
> Hi Dave,
>
> Another pull request for 3.20.
>
> drm-amdkfd-next-2015-01-21:
>
> - Infrastructure work in amdkfd to prepare for VI support. This work mainly
>   includes separating modules into ASIC-specific functionality, adding
>   new properties that are relevant for VI, making sure that shared code is
>   reused, etc.
>
> - Improve mechanism of submitting packets to HIQ (the kernel queue that amdkfd
>   uses to issue commands to the GPU). The driver used to verify that each CS
>   was read by the GPU. However, this proved to be both unnecessary and 
> erroneous.
>   Therefore, we cancelled this verification.
>
> - Moved initialization of compute VMIDs into radeon driver
>
> - Various minor fixes


 CC [M]  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.o
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:
In function ‘destroy_queue_nocpsch’:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:291:9:
warning: ‘mqd’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  retval = mqd->destroy_mqd(mqd, q->mqd,
 ^

Looks valid to me, I've pulled this but please follow up ASAP with a
fix for the new warning.

Dave.

[PATCH 4/4] drm/atomic-helpers: Recover full cursor plane behaviour

[Thierry Reding]

On Tue, Jan 20, 2015 at 11:09:14PM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 4d3f3b874dd6..8b626ff3d3bd 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -929,6 +929,7 @@ struct drm_bridge {
>   * struct struct drm_atomic_state - the global state object for atomic 
> updates
>   * @dev: parent DRM device
>   * @allow_modeset: allow full modeset
> + * @allow_modeset: hint to enforce legacy cursor ioctl semantics

This should be legacy_cursor_update. With that fixed:

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/8721f6b7/attachment.sig>

[PATCH v3] drm: imx: imx-tve: Check and propagate the errors

[Philipp Zabel]

Am Dienstag, den 20.01.2015, 20:44 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam 
> 
> In the case of errors we should propagate them.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v2:
> - Propage the error in more places like suggested by Philipp

Thank you, I have queued this patch.

regards
Philipp

[Bug 88658] (bisected) Slow video playback on Kabini

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

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

--- Comment #5 from Michel Dänzer  ---
(In reply to jtossenb from comment #4)
> My Arch Linux is up-to-date, I use Mesa 10.4.2 and so commit
> 07c65b85eada8dd34019763b6e82ed4257a9b4a6 is included.

If it wasn't included, you wouldn't have the problem. :)

My question was: If you build Mesa *at* commit
07c65b85eada8dd34019763b6e82ed4257a9b4a6, does the problem occur with that? If
not, please bisect Mesa between that commit and the 10.4.2 release. If yes,
there's nothing to bisect.

> I am ready to do bisecting Mesa if you wish, but at the moment I don't know
> where to start, what kernel version to use during bisecting Mesa.

Any kernel which exposes the problem in your testing so far should do.

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

[RFCv2 1/2] device: add dma_params->max_segment_count

[Sumit Semwal]

Hi Robin!

On 22 January 2015 at 00:26, Robin Murphy  wrote:
> Hi Sumit,
>
>
> On 21/01/15 04:16, Sumit Semwal wrote:
>>
>> From: Rob Clark 
>>
>> For devices which have constraints about maximum number of segments in
>> an sglist.  For example, a device which could only deal with contiguous
>> buffers would set max_segment_count to 1.
>>
>> The initial motivation is for devices sharing buffers via dma-buf,
>> to allow the buffer exporter to know the constraints of other
>> devices which have attached to the buffer.  The dma_mask and fields
>> in 'struct device_dma_parameters' tell the exporter everything else
>> that is needed, except whether the importer has constraints about
>> maximum number of segments.
>>
>> Signed-off-by: Rob Clark 
>>   [sumits: Minor updates wrt comments on the first version]
>> Signed-off-by: Sumit Semwal 
>> ---
>>   include/linux/device.h  |  1 +
>>   include/linux/dma-mapping.h | 19 +++
>>   2 files changed, 20 insertions(+)
>>
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index fb50673..a32f9b6 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -647,6 +647,7 @@ struct device_dma_parameters {
>>  * sg limitations.
>>  */
>> unsigned int max_segment_size;
>> +   unsigned int max_segment_count;/* INT_MAX for unlimited */
>> unsigned long segment_boundary_mask;
>>   };
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index c3007cb..38e2835 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -154,6 +154,25 @@ static inline unsigned int
>> dma_set_max_seg_size(struct device *dev,
>> return -EIO;
>>   }
>>
>> +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
>> +
>> +static inline unsigned int dma_get_max_seg_count(struct device *dev)
>> +{
>> +   return dev->dma_parms ?
>> +   dev->dma_parms->max_segment_count :
>> +   DMA_SEGMENTS_MAX_SEG_COUNT;
>> +}
>
>
> I know this copies the style of the existing code, but unfortunately it also
> copies the subtle brokenness. Plenty of drivers seem to set up a dma_parms
> struct just for max_segment_size, thus chances are you'll come across a
> max_segment_count of 0 sooner or later. How badly is that going to break
> things? I posted a fix recently[1] having hit this problem with
> segment_boundary_mask in IOMMU code.
>
Thanks very much for reviewing this code; and apologies for missing
your patch that you mentioned here; sure, I will update my patch
accordingly as well.
>> +
>> +static inline int dma_set_max_seg_count(struct device *dev,
>> +   unsigned int count)
>> +{
>> +   if (dev->dma_parms) {
>> +   dev->dma_parms->max_segment_count = count;
>> +   return 0;
>> +   } else
>
>
> This "else" is just as unnecessary as the other two I've taken out ;)
>
>
> Robin.
>
> [1]:http://article.gmane.org/gmane.linux.kernel.iommu/8175/
>
>
>> +   return -EIO;
>> +}
>> +
>>   static inline unsigned long dma_get_seg_boundary(struct device *dev)
>>   {
>> return dev->dma_parms ?
>>
>
>

BR,
Sumit.