date:20140703

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

--- Comment #4 from Aaron Watry  ---
Created attachment 102226
  --> https://bugs.freedesktop.org/attachment.cgi?id=102226=edit
bitcode, assembly, and rest of stderr from slg4 run

This contains the llvm bitcode, R600 assembly, and the rest of the stdout as
generated from:
R600_DUMP_SHADERS=1 RADEON_DUMP_SHADERS=1 R600_DEBUG=cs,compute,trace_cs
bin/slg4 2> bitcode.ll

-- 
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/20140703/031858b5/attachment.html>

[PATCH v5 00/11] Add DRM for stih4xx platforms

On Thu, Jul 03, 2014 at 10:52:00PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
> > >From a brief look, it looks like my comments have been addressed, so I
> > think this is starting to shape up..
> > 
> > Laurent/Thierry/Russell, I don't suppose any of you are likely to have
> > time before 3.17 merge window to give sti one last once-over to see
> > what I missed ;-)
> 
> As this appears to be using the component helpers, it would be good for
> the author to be pre-warned about the change to the API.  I'm going to
> be doing this as a two step thing.

More on this... just found it in the series.

It looks fine, and I expect that the update would be trivial:

- the body of sti_drm_add_components() moves into sti_drm_master_probe()
  and sti_drm_add_components() is removed.
- component_master_add_child() is updated to call component_match_add()
- component_master_add() is updated to call component_master_add_with_match()
  instead.

So I don't think there's any problem here.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v5 00/11] Add DRM for stih4xx platforms

On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
> >From a brief look, it looks like my comments have been addressed, so I
> think this is starting to shape up..
> 
> Laurent/Thierry/Russell, I don't suppose any of you are likely to have
> time before 3.17 merge window to give sti one last once-over to see
> what I missed ;-)

As this appears to be using the component helpers, it would be good for
the author to be pre-warned about the change to the API.  I'm going to
be doing this as a two step thing.

The first stage of it has just been taken by Greg this evening.  This
retires old behaviour that was needed for the initial versions of imx-drm,
and fixes a bug.  More importantly, it introduces a new interface where
you build the list of expected components before calling
component_master_add(), passing it into that function.

It is slightly less flexible from the driver writer's view point, but
allows us to do more in the component helper, and support some features
that others would like to see (such as being able to add additional
optional components after the initial bind (that's not much interest
to DRM though.)

This should make the v3.17 merge window.  I'm hoping that by forewarning
about the change, that people can be aware of it and have patches
prepared for v3.18 (or maybe even v3.17) to convert over to it, so we
can get rid of the older interface before we get too many users of it.

I've just peeked at the binding document in the first patch.  I notice
that it isn't making use of the of_graph stuff, which is a bit of a
shame because I've sent a RFC patch adding drivers/gpu/drm/drm_of.c
to provide a helper which encoders can use to get the CRTC mask from
an of_graph representation.

I'm using this not only for imx-drm, but also for tda998x - and that's
where the problems are likely to start if we end up with different
DRM implementations doing different solutions to the connectivity
problem.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

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

--- Comment #5 from Thadd?us Tintenfisch  ---
I'm also affected by this bug and I can confirm the performance hit after
resuming the system from suspend.

Radeon HD 4330 + kernel 3.15.2

[ 4772.472528] [drm:rv730_stop_dpm] *ERROR* Could not force DPM to low
[ 4772.954683] [drm] PCIE GART of 1024M enabled (table at 0x0025D000).
[ 4773.002123] [drm] ring test on 0 succeeded in 1 usecs
[ 4773.002180] [drm] ring test on 3 succeeded in 1 usecs
[ 4773.187038] [drm] ring test on 5 succeeded in 1 usecs
[ 4773.187042] [drm] UVD initialized successfully.
[ 4773.187067] [drm] ib test on ring 0 succeeded in 0 usecs
[ 4773.187089] [drm] ib test on ring 3 succeeded in 1 usecs
[ 4773.337007] [drm] ib test on ring 5 succeeded
[ 4773.507776] [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state
failed

-- 
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/20140703/ee53b43b/attachment.html>

[Bug 80876] luxrays/slg4 hangs GPU (CEDAR)

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

--- Comment #3 from Aaron Watry  ---
Grumble..  I was just attempting to get the bitcode since I had lost my
previous dump of that... and now for some reason the GPU's not locking and I'm
instead getting an LLVM diagnostic handler and a segfault due to invalid reads
(according to valgrind).

I'm pretty sure I'll be able to reproduce this, but part of my software stack
needs to be rebuild first.

-- 
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/20140703/9f71ce6f/attachment.html>

[Bug 78464] black rectangles when running Battlefield Bad Company 2 on Wine

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

--- Comment #10 from Damian Nowak  ---
BTW, now using Mesa 10.2.2.

-- 
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/20140703/5dc7d3e6/attachment-0001.html>

[Bug 80876] luxrays/slg4 hangs GPU (CEDAR)

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

--- Comment #2 from Aaron Watry  ---
Created attachment 102224
  --> https://bugs.freedesktop.org/attachment.cgi?id=102224=edit
dmesg from luxrays GPU hang/reset

-- 
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/20140703/1f06874a/attachment.html>

[Bug 80876] luxrays/slg4 hangs GPU (CEDAR)

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

--- Comment #1 from Aaron Watry  ---
Created attachment 102223
  --> https://bugs.freedesktop.org/attachment.cgi?id=102223=edit
Kernel source for luxrays

-- 
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/20140703/49fb0ffa/attachment.html>

[Bug 80876] New: luxrays/slg4 hangs GPU (CEDAR)

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

  Priority: medium
Bug ID: 80876
  Assignee: dri-devel at lists.freedesktop.org
   Summary: luxrays/slg4 hangs GPU (CEDAR)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: awatry at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 10
  --> https://bugs.freedesktop.org/attachment.cgi?id=10=edit
luxrays diff/patch to disable image support while reproducing bug.

While working on getting the Luxrays slg4 program running (which is invoked as
part of the luxmark CL-based raytracing benchmark), I encountered some GPU
hangs on the evergreen card I'm using (CEDAR, Radeon 5400-series).

Hardware:
Core i7-2600k
16GB DDR3
Radeon 5400-series PCI express w/ dual 1080p monitors

Software:
Mesa: Git master
LLVM: 3.5svn
drm: fairly recent git
libclc: git master + a few extra patches to implement missing built-ins
luxrays: From http://src.luxrender.net/luxrays, with the attached patch.

Steps:
1) Checkout luxrays source from the mercurial repository
2) Apply patch to disable image support in the renderer
3) Build luxrays from source (cmake).
4) run bin/slg4
5) Watch the UI start to pop-up and the GPU reset.

dmesg, kernel source, llvm bitcode to be attached.  rlockup_*.c cs trace
available as a 35MB gzipped C file (>300MB uncompressed).

-- 
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/20140703/6b1dd1fd/attachment.html>

[Bug 78464] black rectangles when running Battlefield Bad Company 2 on Wine

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

--- Comment #9 from Damian Nowak  ---
@Michel, I also found this bug in Tappy Chicken, an Unreal Engine Linux build
demo.

http://upload.nowaker.net/nwkr/1404422235_tappy.png
http://upload.nowaker.net/nwkr/1404422288_tappy2.png

Since the game is dead simple, apitrace will probably more usable than from
BFBC2. You can find it here:

https://wiki.unrealengine.com/Linux_Demos
http://ue4linux.raxxy.com/tappy_chicken.zip

-- 
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/20140703/fe12433e/attachment.html>

[Bug 75276] Implement VGPR Register Spilling

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

--- Comment #28 from Damian Nowak  ---
> LLVM ERROR: ran out of registers during register allocation

I get this error when trying out Unreal Engine demo buid. Coredumps always
around the same moment for me, from 9th to 11th second. Here's the link to the
demo in case anyone wants to apitrace and analyze it.
http://ue4linux.raxxy.com/effects_cave_demo.zip
(Demo comes from https://wiki.unrealengine.com/Linux_Demos)

-- 
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/20140703/02fb95ca/attachment.html>

[Bug 80868] Support screen scaling modes for external monitors

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

--- Comment #3 from Henri Verbeet  ---
Some of the games this applies to only know 640x480 and 800x600, and perhaps
1024x768.

-- 
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/20140703/22354239/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #64 from kilobug at kilobug.org ---
Great news !

I tried the -wip branch, and so far no crash (with and without hyperz). I will
keep running it and see how it works. I'll do more tests during the week-end,
and hopefully they won't crash.

I don't know if I fumbled in applying the patch manually (would surprise me,
but not impossible) or if there is another fix in the branch.

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

[Nouveau] [PATCH] drm: default scaling to NONE for external connectors

2014-07-03 Thread Ilia Mirkin

On Thu, Jul 3, 2014 at 8:27 PM, Ben Skeggs  wrote:
> On Fri, Jul 4, 2014 at 5:27 AM, Ilia Mirkin  wrote:
>> Signed-off-by: Ilia Mirkin 
>> ---
>>
>> Based on a recent discussion in #radeon, and also my own observation that the
>> 'full' scaling causes no end of confusion among users.
>>
>> See https://bugs.freedesktop.org/show_bug.cgi?id=80868 for some more details,
>> although it is more radeon-specific.
>>
>> Side-note: the scaling mode update handler disallows setting the mode to none
>> for LVDS... should it be the same for eDP as well? Or perhaps relax the
>> restriction and let people do whatever they want?
> We do need some improvement here, for sure.  What we do currently is
> confusing for a lot of cases, like where people select a
> (non-preferred) 24Hz mode or something and still get 60 because we
> always use the preferred mode on the backend (except for the 'None'
> scaling mode).

Right. That was the confusion I was largely referring to.

>
> I somewhat think we should probably default to something like "if mode
> came from edid (or the user?), no scaling" and "if it's from the
> random list of modes we add to fixed panels to keep old games happy,
> scale to closest edid mode / preferred mode / something".. I'm not
> entirely sure what the best choices are to be honest.

What are "fixed panels" (in the sense of... how does a driver
determine this)? I figured it was just LVDS/eDP == fixed. Everything
else == not fixed. At least that's what radeon does, according to...
someone (Alex, IIRC).

Unfortunately scaling mode is a connector-level property. So it may be
confusing if the user were to set it to something, then connect a
different screen, and have it all of a sudden reset itself to whatever
we feel the default should be. I guess we could keep track of a "has
the user futzed with this" bit.

I guess what you're saying is more of a per-mode property (of which no
such thing currently exists)...

  -ilia

>
> Ben.
>
>>
>>  drm/nouveau_connector.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drm/nouveau_connector.c b/drm/nouveau_connector.c
>> index 1fa222e..295e222 100644
>> --- a/drm/nouveau_connector.c
>> +++ b/drm/nouveau_connector.c
>> @@ -1192,6 +1192,8 @@ nouveau_connector_create(struct drm_device *dev, int 
>> index)
>>   disp->color_vibrance_property,
>>   150);
>>
>> +   nv_connector->scaling_mode = DRM_MODE_SCALE_NONE;
>> +
>> switch (nv_connector->type) {
>> case DCB_CONNECTOR_VGA:
>> if (nv_device(drm->device)->card_type >= NV_50) {
>> @@ -1203,10 +1205,11 @@ nouveau_connector_create(struct drm_device *dev, int 
>> index)
>> case DCB_CONNECTOR_TV_0:
>> case DCB_CONNECTOR_TV_1:
>> case DCB_CONNECTOR_TV_3:
>> -   nv_connector->scaling_mode = DRM_MODE_SCALE_NONE;
>> break;
>> default:
>> -   nv_connector->scaling_mode = DRM_MODE_SCALE_FULLSCREEN;
>> +   if (type == DRM_MODE_CONNECTOR_LVDS ||
>> +   type == DRM_MODE_CONNECTOR_eDP)
>> +   nv_connector->scaling_mode = 
>> DRM_MODE_SCALE_FULLSCREEN;
>>
>> drm_object_attach_property(>base,
>> dev->mode_config.scaling_mode_property,
>> --
>> 1.8.5.5
>>
>> ___
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau

[Bug 42787] Video flickers on X1200 / RS690 over DVI

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

Stephan Diestelhorst  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #5 from Stephan Diestelhorst  ---
Closing, since I do not own the hardware in question anymore.

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

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

2014-07-03 Thread Ajay kumar

ed
> [ 2870.975482] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 48.00 BogoMIPS (lpj=12)
> [ 2870.975499] pid_max: default: 32768 minimum: 301
> [ 2870.975587] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [ 2870.975598] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [ 2870.975950] CPU: Testing write buffer coherency: ok
> [ 2870.976081] CPU0: update cpu_capacity 1024
> [ 2870.976092] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [ 2870.976188] Setting up static identity map for 0x4043c0d8 - 0x4043c130
> [ 2920.607946] CPU1: Booted secondary processor
> [ 2920.607979] CPU1: update cpu_capacity 1024
> [ 2920.607983] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> [ 2920.608027] Brought up 2 CPUs
> [...]
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-- next part --
A non-text attachment was scrubbed...
Name: 0001-ARM-dts-Add-ps8622-and-panel-node-for-spring.patch
Type: application/octet-stream
Size: 2540 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/aed14dc4/attachment-0002.obj>
-- next part --
A non-text attachment was scrubbed...
Name: config-3.16.0-rc2+
Type: application/octet-stream
Size: 101162 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/aed14dc4/attachment-0003.obj>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

--- Comment #35 from theamazingjanet at googlemail.com ---
(In reply to comment #33)
> hie, i' tried to make a trace too, but i've failed to build apitrace frome
> git, and the version of ubuntu 14.04 which is 3.0 segfault with xcom :(
> 
> Does it help instead if i use R600_DUMP_SHADERS= 1 ?
> 
> If yes, someone can explain me how to redirect the output to a file because
> >> doen't work.

Compile apitrace 5.0 from here:

https://github.com/apitrace/apitrace/releases

-- 
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/20140703/2134db1f/attachment.html>

[Bug 80868] Support screen scaling modes for external monitors

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

--- Comment #2 from Alex Deucher  ---
A deeper question is, why run non-native modes to begin with?  Whether it's the
GPU or the monitor, it's always going to end up scaled.  Why do you want to run
1920x1080 when you can run 1920x1200?

-- 
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/20140703/18e41aa0/attachment.html>

[PATCH] drm: Add Drm driver for Rockchip Socs

2014-07-03 Thread mark yao

From: mark 

This patch is a DRM Driver for Rockchip Socs and now only add the
framework of Rockchips Socs, but we will add Rockchips Socs soon.

Signed-off-by: mark 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   35 +
 drivers/gpu/drm/rockchip/Makefile |   14 +
 drivers/gpu/drm/rockchip/rockchip_drm_buf.c   |  191 ++
 drivers/gpu/drm/rockchip/rockchip_drm_buf.h   |   39 ++
 drivers/gpu/drm/rockchip/rockchip_drm_connector.c |  261 
 drivers/gpu/drm/rockchip/rockchip_drm_connector.h |   24 +
 drivers/gpu/drm/rockchip/rockchip_drm_core.c  |  163 +
 drivers/gpu/drm/rockchip/rockchip_drm_crtc.c  |  515 ++
 drivers/gpu/drm/rockchip/rockchip_drm_crtc.h  |   42 ++
 drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.c|  290 
 drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.h|   32 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  618 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  319 +
 drivers/gpu/drm/rockchip/rockchip_drm_encoder.c   |  206 ++
 drivers/gpu/drm/rockchip/rockchip_drm_encoder.h   |   30 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  333 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   39 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  380 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   26 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  738 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |  198 ++
 drivers/gpu/drm/rockchip/rockchip_drm_iommu.c |  149 +
 drivers/gpu/drm/rockchip/rockchip_drm_iommu.h |   76 +++
 drivers/gpu/drm/rockchip/rockchip_drm_plane.c |  290 
 drivers/gpu/drm/rockchip/rockchip_drm_plane.h |   30 +
 include/uapi/drm/rockchip_drm.h   |  155 +
 28 files changed, 5196 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_buf.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_buf.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_core.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_crtc.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_crtc.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_encoder.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_encoder.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_iommu.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_iommu.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_plane.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_plane.h
 create mode 100644 include/uapi/drm/rockchip_drm.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f512004..5951c2c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -170,6 +170,8 @@ config DRM_SAVAGE

 source "drivers/gpu/drm/exynos/Kconfig"

+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd2ba42..40babd2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..9350316
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,35 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip "
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select

[PATCH] add Drm driver for Rockchip

2014-07-03 Thread mark yao

From: mark 

This patch is a DRM Driver for Rockchip Socs and now only add the
framework of Rockchips Socs, but we will add Rockchips Socs soon.

mark (1):
  drm: Add Drm driver for Rockchip Socs


-- 
1.7.9.5

[PATCH v3 0/2] drm: nouveau: memory coherency for ARM

2014-07-03 Thread Alexandre Courbot

While this series is more correct from the DMA API point of view, it
is also much heavier as it strictly disables the use of any cache on
all user-space mapped BOs, and is also much more restricted in terms
of which memory it can use.

I have a v4 in the works that lets us use TTM for user-mapped objects
and only falls back to using the DMA API for kernel-only objects
(fences & PBs basically). Will push it shortly but wanted to signal
this revision as deprecated in the meantime.

On Fri, Jun 27, 2014 at 8:22 PM, Alexandre Courbot  
wrote:
> v2 was doing some pretty nasty things with the DMA API, so I took a different
> approach for this v3.
>
> As suggested, this version uses ttm_dma_populate() to populate BOs. The reason
> for doing this was that it would entitle us to using the DMA sync functions,
> but since the memory returned is already coherent anyway, we do not even
> need to call these functions anymore.
>
> So this series has turned into 2 small patches:
>
> - The first attempts to make it more obvious that Nouveau can use different
> ways to populate TTs, and make it possible to choose which method to use from
> a single place.
> - The second leverages this work to select the DMA allocator to populate TTs
> on ARM.
>
> Doing this solves all our coherency problems with Nouveau on Tegra, and
> hopefully makes the code easier to read in the process.
>
> Alexandre Courbot (2):
>   drm/nouveau: cleanup TTM population logic
>   drm/nouveau: use DMA TT population method on ARM
>
>  drivers/gpu/drm/nouveau/nouveau_bo.c  | 63 
> ++-
>  drivers/gpu/drm/nouveau/nouveau_drm.h | 11 ++
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 17 ++
>  3 files changed, 61 insertions(+), 30 deletions(-)
>
> --
> 2.0.0
>

[Bug 80868] Support screen scaling modes for external monitors

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

--- Comment #1 from Alex Deucher  ---
Created attachment 102216
  --> https://bugs.freedesktop.org/attachment.cgi?id=102216=edit
starter implementation

I'm not sure when I'll have time to implement this, but just about everything
you need is already in place.  The attached patch should get you started and
may even work...

-- 
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/20140703/faa0446a/attachment.html>

[Bug 80868] New: Support screen scaling modes for external monitors

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

Priority: medium
Bug ID: 80868
Assignee: dri-devel at lists.freedesktop.org
Summary: Support screen scaling modes for external monitors
Severity: enhancement
Classification: Unclassified
OS: All
Reporter: kamil.paral at gmail.com
Hardware: Other
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI

As we steadily progress into the year of Linux gaming, there will be many
requests regarding games. This is one of them :)

Currently, it is possible to set scaling mode for a monitor only if the monitor
is internal (LVDS, eDP). This is done through xrandr:

$ xrandr --prop
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
LVDS1 connected primary 1680x1050+0+0 (normal left inverted right x axis y
axis) 331mm x 207mm

scaling mode: Full aspect
supported: None, Full, Center, Full aspect

$ xrandr --output LVDS1 --set "scaling mode" "Center"

However, it is not possible to do this for external panels (VGA, DVI, HDMI,
DP). The "scaling mode" property is not exported for these panels (this was
confirmed to me by ckoenig and agd5f on the #radeon irc channel, many thanks).

Please allow users to set scaling mode even for external panels. There are many
use cases for it, mainly related to gaming.

Note: Many panels provide options to do the scaling on their own, however, only
the very expensive ones provide good options. For example, the majority of
"mainstream" panels don't provide the "center" scaling mode - however, that is
very useful when playing older lower-resolution games when you prefer smaller
and sharp image instead of larger and blurry. Second example are certain panels
which support "full aspect" mode only for a small selection or resolutions,
otherwise they simply scale to "full" ignoring image aspect ratio. For these
panels, GPU scaling is essential if the user doesn't want to see distorted
aspect ratio image.

My personal use case is buying BenQ BL2411PT 1920x1200 panel, which *can not*
display 1920x1080 resolution with correct aspect ratio - it always stretches it
vertically. Yes, it's very dumb, yet that's how modern panels commonly work
(and not just the cheap ones). This hasn't been a large issue in the past,
because we had no games and opensource drivers were hardly able to run them
anyway. Both things are changing rapidly.

The proprietary AMD and NVIDIA drivers have been offering GPU scaling
functionality for a long time, both on Linux and Windows. Here's an example of
their GUI configuration:
https://www.codeweavers.com/support/wiki/linux/faq/43_game_stretch

Please allow us to use GPU scaling even with radeon driver. Thank you.

There has been some technical details on the IRC, it is linked here:
http://paste.fedoraproject.org/115407/

It seems to me that this functionality could be implemented in a simple and
straightforward way:
a) provide a single configuration option - "scaling mode"
b) on internal panels default to "Full aspect" (which you already do) - that is
reasonable default, because these panels have no control buttons
c) on external panels default to "None" - that allows the user to easily
configure scaling through the panel. Only if the user is dissatisfied, he/she
can enable GPU scaling through xrandr.

And here's one more user seconding my thoughts on the IRC:
AbortRetryFail: 1:1 unscaled output for LCDs would be awesome.
AbortRetryFail: 1280x720 looks horrible scaled up to fit a 1366x768 LCD

Thanks.

--
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/20140703/4fa4714f/attachment.html>

[PATCH RFC] drm: add of_graph endpoint helper to find possible CRTCs

On Thu, Jul 3, 2014 at 12:49 PM, Russell King
 wrote:
> Add a helper to allow encoders to find their possible CRTCs from the
> OF graph without having to re-implement this functionality.  We add a
> device_node to drm_crtc which corresponds with the port node in the
> DT description of the CRTC device.
>
> We can then scan the DRM device list for CRTCs to find their index,
> matching the appropriate CRTC using the port device_node, thus building
> up the possible CRTC mask.
>
> Signed-off-by: Russell King 
> ---
> This helper will be shared between imx-drm and Armada DRM, and should
> be useful for other OF-based drivers.  At the moment, this is being
> sent for comments and acks; I need to build upon this patch in order
> to convert Armada DRM to DT.
>
>  drivers/gpu/drm/Makefile |  1 +
>  drivers/gpu/drm/drm_of.c | 65 
> 
>  include/drm/drm_crtc.h   |  2 ++
>  include/drm/drm_of.h | 18 ++

oh, probably also should get links in Documentation/DocBook/drm.tmpl

BR,
-R

>  4 files changed, 86 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_of.c
>  create mode 100644 include/drm/drm_of.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index dd2ba4269740..533d011eab3e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -20,6 +20,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> +drm-$(CONFIG_OF) += drm_of.o
>
>  drm-usb-y   := drm_usb.o
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> new file mode 100644
> index ..46d967881689
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -0,0 +1,65 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
> + * @dev: DRM device
> + * @port: port OF node
> + *
> + * Given a port OF node, return the possible mask of the corresponding
> + * CRTC within a device's list of CRTCs.  Returns zero if not found.
> + */
> +static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> +  struct device_node *port)
> +{
> +   unsigned int index = 0;
> +   struct drm_crtc *tmp;
> +
> +   list_for_each_entry(tmp, >mode_config.crtc_list, head) {
> +   if (tmp->port == port)
> +   return 1 << index;
> +
> +   index++;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * drm_of_find_possible_crtcs - find the possible CRTCs for an encoder port
> + * @dev: DRM device
> + * @port: encoder port to scan for endpoints
> + *
> + * Scan all endpoints attached to a port, locate their attached CRTCs,
> + * and generate the DRM mask of CRTCs which may be attached to this
> + * encoder.
> + */
> +uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> +   struct device_node *port)
> +{
> +   struct device_node *remote_port, *ep = NULL;
> +   uint32_t possible_crtcs = 0;
> +
> +   do {
> +   ep = of_graph_get_next_endpoint(port, ep);
> +   if (!ep)
> +   break;
> +
> +   remote_port = of_graph_get_remote_port(ep);
> +   if (!remote_port) {
> +   of_node_put(ep);
> +   return 0;
> +   }
> +
> +   possible_crtcs |= drm_crtc_port_mask(dev, remote_port);
> +
> +   of_node_put(remote_port);
> +   } while (1);
> +
> +   return possible_crtcs;
> +}
> +EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 251b75e6bf7a..6a94909f1ca9 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -41,6 +41,7 @@ struct drm_framebuffer;
>  struct drm_object_properties;
>  struct drm_file;
>  struct drm_clip_rect;
> +struct device_node;
>
>  #define DRM_MODE_OBJECT_CRTC 0x
>  #define DRM_MODE_OBJECT_CONNECTOR 0xc0c0c0c0
> @@ -314,6 +315,7 @@ struct drm_crtc_funcs {
>   */
>  struct drm_crtc {
> struct drm_device *dev;
> +   struct device_node *port;
> struct list_head head;
>
> /**
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> new file mode 100644
> index ..2441f7112074
> --- /dev/null
> +++ b/include/drm/drm_of.h
> @@ -0,0 +1,18 @@
> +#ifndef __DRM_OF_H__
> +#define __DRM_OF_H__
> +
> +struct drm_device;
> +struct device_node;
> +
> +#ifdef CONFIG_OF
> +extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> +  struct device_node *port);
> +#else
> +static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> + struct

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, 3 Jul 2014 16:43:25 +0100
Russell King - ARM Linux  wrote:

> What you're doing in kirkwood-i2s is providing two plain DAI links,
> and then insisting that only one can be active any any one time.
> 
> A DPCM solution provides at least one frontend DAI link and at least
> one backend DAI link.  Your code does not do this.

You know why I did not insert the DPCM code in the kirkwood driver: it
does not work. But, as I tested it end 2013, I still have the code.
Do you want I propose a patch?

> Which bit of "we need to support both I2S and SPDIF" in my previous
> emails was not clear.  Which bit of "We should only support SPDIF
> on the Cubox" was not clear?
> 
> I *fully* acknowledge that we need to support both, but I'm putting
> a _strong_ recommendation to you _with_ technical reasons why we
> should _only_ support SPDIF on the Cubox.

Sorry, I still don't see why only S/PDIF should be supported on the
Cubox. I have both, and both are working on HDMI. I hope someone will
tell me it also works on S/PDIF: there is no reason it could not.

I don't see your technical reasons: you know the constraints of each
protocol I2S and S/PDIF. If you don't want I2S, just don't declare it
in the DT (see my previous mail). You may also note that I did not put
any change relative to the Cubox DT in my patch.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH RFC] drm: add of_graph endpoint helper to find possible CRTCs

On Thu, Jul 3, 2014 at 12:49 PM, Russell King
 wrote:
> Add a helper to allow encoders to find their possible CRTCs from the
> OF graph without having to re-implement this functionality.  We add a
> device_node to drm_crtc which corresponds with the port node in the
> DT description of the CRTC device.
>
> We can then scan the DRM device list for CRTCs to find their index,
> matching the appropriate CRTC using the port device_node, thus building
> up the possible CRTC mask.
>
> Signed-off-by: Russell King 
> ---
> This helper will be shared between imx-drm and Armada DRM, and should
> be useful for other OF-based drivers.  At the moment, this is being
> sent for comments and acks; I need to build upon this patch in order
> to convert Armada DRM to DT.

ok, possibly a dumb question, but in my defense I don't claim to be a
DT expert ;-)

Do you have somewhere handy a example dts which this would be parsing?
 I think that would help me understand this patch a bit better.

BR,
-R

>  drivers/gpu/drm/Makefile |  1 +
>  drivers/gpu/drm/drm_of.c | 65 
> 
>  include/drm/drm_crtc.h   |  2 ++
>  include/drm/drm_of.h | 18 ++
>  4 files changed, 86 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_of.c
>  create mode 100644 include/drm/drm_of.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index dd2ba4269740..533d011eab3e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -20,6 +20,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> +drm-$(CONFIG_OF) += drm_of.o
>
>  drm-usb-y   := drm_usb.o
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> new file mode 100644
> index ..46d967881689
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -0,0 +1,65 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
> + * @dev: DRM device
> + * @port: port OF node
> + *
> + * Given a port OF node, return the possible mask of the corresponding
> + * CRTC within a device's list of CRTCs.  Returns zero if not found.
> + */
> +static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> +  struct device_node *port)
> +{
> +   unsigned int index = 0;
> +   struct drm_crtc *tmp;
> +
> +   list_for_each_entry(tmp, >mode_config.crtc_list, head) {
> +   if (tmp->port == port)
> +   return 1 << index;
> +
> +   index++;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * drm_of_find_possible_crtcs - find the possible CRTCs for an encoder port
> + * @dev: DRM device
> + * @port: encoder port to scan for endpoints
> + *
> + * Scan all endpoints attached to a port, locate their attached CRTCs,
> + * and generate the DRM mask of CRTCs which may be attached to this
> + * encoder.
> + */
> +uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> +   struct device_node *port)
> +{
> +   struct device_node *remote_port, *ep = NULL;
> +   uint32_t possible_crtcs = 0;
> +
> +   do {
> +   ep = of_graph_get_next_endpoint(port, ep);
> +   if (!ep)
> +   break;
> +
> +   remote_port = of_graph_get_remote_port(ep);
> +   if (!remote_port) {
> +   of_node_put(ep);
> +   return 0;
> +   }
> +
> +   possible_crtcs |= drm_crtc_port_mask(dev, remote_port);
> +
> +   of_node_put(remote_port);
> +   } while (1);
> +
> +   return possible_crtcs;
> +}
> +EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 251b75e6bf7a..6a94909f1ca9 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -41,6 +41,7 @@ struct drm_framebuffer;
>  struct drm_object_properties;
>  struct drm_file;
>  struct drm_clip_rect;
> +struct device_node;
>
>  #define DRM_MODE_OBJECT_CRTC 0x
>  #define DRM_MODE_OBJECT_CONNECTOR 0xc0c0c0c0
> @@ -314,6 +315,7 @@ struct drm_crtc_funcs {
>   */
>  struct drm_crtc {
> struct drm_device *dev;
> +   struct device_node *port;
> struct list_head head;
>
> /**
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> new file mode 100644
> index ..2441f7112074
> --- /dev/null
> +++ b/include/drm/drm_of.h
> @@ -0,0 +1,18 @@
> +#ifndef __DRM_OF_H__
> +#define __DRM_OF_H__
> +
> +struct drm_device;
> +struct device_node;
> +
> +#ifdef CONFIG_OF
> +extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> +  struct device_node *port);

[PATCH v5 00/11] Add DRM for stih4xx platforms

On Thu, Jul 3, 2014 at 5:52 PM, Russell King - ARM Linux
 wrote:
> On Thu, Jul 03, 2014 at 05:31:21PM -0400, Rob Clark wrote:
>> >From a brief look, it looks like my comments have been addressed, so I
>> think this is starting to shape up..
>>
>> Laurent/Thierry/Russell, I don't suppose any of you are likely to have
>> time before 3.17 merge window to give sti one last once-over to see
>> what I missed ;-)
>
> As this appears to be using the component helpers, it would be good for
> the author to be pre-warned about the change to the API.  I'm going to
> be doing this as a two step thing.
>
> The first stage of it has just been taken by Greg this evening.  This
> retires old behaviour that was needed for the initial versions of imx-drm,
> and fixes a bug.  More importantly, it introduces a new interface where
> you build the list of expected components before calling
> component_master_add(), passing it into that function.
>
> It is slightly less flexible from the driver writer's view point, but
> allows us to do more in the component helper, and support some features
> that others would like to see (such as being able to add additional
> optional components after the initial bind (that's not much interest
> to DRM though.)
>
> This should make the v3.17 merge window.  I'm hoping that by forewarning
> about the change, that people can be aware of it and have patches
> prepared for v3.18 (or maybe even v3.17) to convert over to it, so we
> can get rid of the older interface before we get too many users of it.
>
> I've just peeked at the binding document in the first patch.  I notice
> that it isn't making use of the of_graph stuff, which is a bit of a
> shame because I've sent a RFC patch adding drivers/gpu/drm/drm_of.c
> to provide a helper which encoders can use to get the CRTC mask from
> an of_graph representation.

which reminds me, I need to have a look at the drm_of stuff..

> I'm using this not only for imx-drm, but also for tda998x - and that's
> where the problems are likely to start if we end up with different
> DRM implementations doing different solutions to the connectivity
> problem.

If it simplifies merge-order stuff, I'd be ok with a follow-up patch
that converts over (assuming it shouldn't have an impact on the DT
bindings, which I'm only assuming it should not..)

Probably it would be a good idea if Benjamin at least had a patch
ready to go to convert over which could be merged right after your
stuff hits drm-next.

BR,
-R

> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

[PATCH RFC] drm: add of_graph endpoint helper to find possible CRTCs

2014-07-03 Thread Russell King

Add a helper to allow encoders to find their possible CRTCs from the
OF graph without having to re-implement this functionality.  We add a
device_node to drm_crtc which corresponds with the port node in the
DT description of the CRTC device.

We can then scan the DRM device list for CRTCs to find their index,
matching the appropriate CRTC using the port device_node, thus building
up the possible CRTC mask.

Signed-off-by: Russell King 
---
This helper will be shared between imx-drm and Armada DRM, and should
be useful for other OF-based drivers.  At the moment, this is being
sent for comments and acks; I need to build upon this patch in order
to convert Armada DRM to DT.

 drivers/gpu/drm/Makefile |  1 +
 drivers/gpu/drm/drm_of.c | 65 
 include/drm/drm_crtc.h   |  2 ++
 include/drm/drm_of.h | 18 ++
 4 files changed, 86 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_of.c
 create mode 100644 include/drm/drm_of.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd2ba4269740..533d011eab3e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -20,6 +20,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+drm-$(CONFIG_OF) += drm_of.o

 drm-usb-y   := drm_usb.o

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
new file mode 100644
index ..46d967881689
--- /dev/null
+++ b/drivers/gpu/drm/drm_of.c
@@ -0,0 +1,65 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
+ * @dev: DRM device
+ * @port: port OF node
+ *
+ * Given a port OF node, return the possible mask of the corresponding
+ * CRTC within a device's list of CRTCs.  Returns zero if not found.
+ */
+static uint32_t drm_crtc_port_mask(struct drm_device *dev,
+  struct device_node *port)
+{
+   unsigned int index = 0;
+   struct drm_crtc *tmp;
+
+   list_for_each_entry(tmp, >mode_config.crtc_list, head) {
+   if (tmp->port == port)
+   return 1 << index;
+
+   index++;
+   }
+
+   return 0;
+}
+
+/**
+ * drm_of_find_possible_crtcs - find the possible CRTCs for an encoder port
+ * @dev: DRM device
+ * @port: encoder port to scan for endpoints
+ *
+ * Scan all endpoints attached to a port, locate their attached CRTCs,
+ * and generate the DRM mask of CRTCs which may be attached to this
+ * encoder.
+ */
+uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
+   struct device_node *port)
+{
+   struct device_node *remote_port, *ep = NULL;
+   uint32_t possible_crtcs = 0;
+
+   do {
+   ep = of_graph_get_next_endpoint(port, ep);
+   if (!ep)
+   break;
+
+   remote_port = of_graph_get_remote_port(ep);
+   if (!remote_port) {
+   of_node_put(ep);
+   return 0;
+   }
+
+   possible_crtcs |= drm_crtc_port_mask(dev, remote_port);
+
+   of_node_put(remote_port);
+   } while (1);
+
+   return possible_crtcs;
+}
+EXPORT_SYMBOL(drm_of_find_possible_crtcs);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 251b75e6bf7a..6a94909f1ca9 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -41,6 +41,7 @@ struct drm_framebuffer;
 struct drm_object_properties;
 struct drm_file;
 struct drm_clip_rect;
+struct device_node;

 #define DRM_MODE_OBJECT_CRTC 0x
 #define DRM_MODE_OBJECT_CONNECTOR 0xc0c0c0c0
@@ -314,6 +315,7 @@ struct drm_crtc_funcs {
  */
 struct drm_crtc {
struct drm_device *dev;
+   struct device_node *port;
struct list_head head;

/**
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
new file mode 100644
index ..2441f7112074
--- /dev/null
+++ b/include/drm/drm_of.h
@@ -0,0 +1,18 @@
+#ifndef __DRM_OF_H__
+#define __DRM_OF_H__
+
+struct drm_device;
+struct device_node;
+
+#ifdef CONFIG_OF
+extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
+  struct device_node *port);
+#else
+static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
+ struct device_node *port)
+{
+   return 0;
+}
+#endif
+
+#endif /* __DRM_OF_H__ */
-- 
1.8.3.1

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #60 from Mathias Tillman  ---
I've done some further tests with overriding the power state level values as
detailed above, here are my results:

The stock values are
level 0: sclk: 1, mclk: 3, vddc: 950, vddci: 950
level 1: sclk: 77500, mclk: 105000, vddc: 1100 vddci: 1150
level 2: sclk: 9, mclk: 105000, vddc: 1175, vddci: 1150

sclk, vddc and vddci were all at their stock values for all power levels during
my tests.

I changed mclk on power level 2 to the values below (OK means that it does not
get stuck in the highest power level):
95000 = OK
10 = OK
104000 = OK
105000 = NOT OK
11 = NOT OK

So as you can see it gets stuck when the mclk value is 10500 or higher, but why
that is I really have no idea. Could it be a firmware or VBIOS problem?

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

[PATCH Resend 1/1] drm: gem_cma: Use ERR_CAST helper

2014-07-03 Thread Sachin Kamat

From: Sachin Kamat 

Makes the code a bit more readable.

Signed-off-by: Sachin Kamat 
Signed-off-by: Sachin Kamat 
Acked-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_gem_cma_helper.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 05c97c5350a1..e467e67af6e7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -327,7 +327,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev, 
size_t size,
/* Create a CMA GEM buffer. */
cma_obj = __drm_gem_cma_create(dev, size);
if (IS_ERR(cma_obj))
-   return ERR_PTR(PTR_ERR(cma_obj));
+   return ERR_CAST(cma_obj);

cma_obj->paddr = sg_dma_address(sgt->sgl);
cma_obj->sgt = sgt;
-- 
1.7.9.5

[PATCH v5 00/11] Add DRM for stih4xx platforms

>From a brief look, it looks like my comments have been addressed, so I
think this is starting to shape up..

Laurent/Thierry/Russell, I don't suppose any of you are likely to have
time before 3.17 merge window to give sti one last once-over to see
what I missed ;-)

BR,
-R

On Wed, Jun 18, 2014 at 4:51 AM, Benjamin Gaignard
 wrote:
> This series of patches add the support of DRM/KMS drivers for 
> STMicroelectronics
> chipsets stih416 and stih407.
>
> version 5:
> - Rework sti_drm_drv probes functions to support deferred probe.
>   This allow hdmi to delayed framebuffer creation until I2C is 
> available.
> - Add ops functsions in sti_layer structure to simpify GDP and VID 
> code.
> - Add NOTES file to describe how the DRM concepts are mapped on 
> hardware.
>
> patches could be found here: 
> git://git.linaro.org/people/benjamin.gaignard/kernel.git
> on branch: drm_kms_for_next-v5
>
> version 4:
> - Remove depency between TVout it subdevices HDMI and HDA
> - Rework and simplify VTG and VTAC code
> - Fix numbers of typo and indentation
> - Remove debug (will be push in separate patches)
> - Fix remarks done in previous patcheset
>
> patches could be found here: 
> git://git.linaro.org/people/benjamin.gaignard/kernel.git
> on branch: drm_kms_for_next-v4
>
> version 3:
> - Correctly split code between probe and bind funtions
> - Squash some commits
> - remove HQ-VDP device code to have a smaller patcheset,
>   we will introduce it later.
>
> patches could be found here: 
> git://git.linaro.org/people/benjamin.gaignard/kernel.git
> on branch: drm_kms_for_next-v3
>
> version 2:
> - Use componentized device instead of register sub-devices in master
> driver probe function
> - Fix Makefile and Kconfig to only allow built-in compilation
>
> patches could be found here: 
> git://git.linaro.org/people/benjamin.gaignard/kernel.git
> on branch: drm_kms_for_next-v2
>
> version 1:
> - First path submission
>
> Hardware is split in two main blocks: Compositor and TVout. Each of them
> includes specific hardware IPs and the display timing are controlled by a 
> specific
> Video Timing Generator hardware IP (VTG).
>
> Compositor is made of the follow hardware IPs:
>  - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
>buffers
>  - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
>  - HQVDP (High Quality Video Display Processor) that supports scaling,
>deinterlacing and some miscellaneous image quality improvements.
>It fetches the Video decoded buffers from memory, processes them and pushes
>them to the Compositor through a HW dedicated bus.
>  - Mixer is responsible of mixing all the entries depending of their
>respective z-order and layout
>
> TVout is divided in 3 parts:
>  - HDMI to generate HDMI signals, depending of chipset version HDMI phy can
>change.
>  - HDA to generate signals for HD analog TV
>  - VIP to control/switch data path coming from Compositor
>
> On stih416 compositor and Tvout are on different dies so a Video Trafic 
> Advance
> inter-die Communication mechanism (VTAC) is needed.
>
> +-+   
> ++
> | +---+   ++  |   |  ++   
> +--+ |
> | |   |   ||  |   |  ||   |  +-+  
>++  | |
> | | ++  +--+  |   ||  |   |  ||   |  | VIP 
> |>|HDMI|  | |
> | | |GPD +->|  |  |   ||  |   |  ||   |  | |  
>++  | |
> | | ++  |Mixer |--|-->||  |   |  ||---|->| switcher|  
>| |
> | | |  |  |   ||  |   |  ||   |  | |  
>++  | |
> | | |  |  |   ||  |   |  ||   |  | 
> |>|HDA |  | |
> | | +--+  |   |VTAC|>|VTAC|   |  +-+  
>++  | |
> | |   |   ||  |   |  ||   |   
>| |
> | | Compositor|   ||  |   |  ||   |   
> TVout  | |
> | +---+   ||  |   |  ||   
> +--+ |
> |  ^  ||  |   |  || ^ 
>  |
> |  |  ||  |   |  || | 
>  |
> |   +--+  ||  |   |  ||  
> +-+   |
> |   | VTG (master) |->||  |   |  ||->| VTG 
> (slave) |   |
> |   +--+  ++  |   |  ++  
> +-+   |
> |Digital

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, 3 Jul 2014 14:43:46 +0100
Russell King - ARM Linux  wrote:

> > But, this means that there will be a lot of errors when DPCM will be
> > used, because, in most cases for the Cubox (kirkwood audio + tda998x),
> > both ways I2S and S/PDIF will be activated at the same time for a
> > single stream (you may note that the routes from the second input
> > cannot be blocked by the CODEC after it received the first input,
> > because these routes have already been computed).  
> 
> This is /very/ easy to solve on the Cubox, if only you would listen
> to me - I've stated many times that I2S should not be used there.
> 
> Just because the hardware is wired up with both the SPDIF connected
> and the I2S connected, it does *not* mean that we have to wire them
> both up in software.
> 
> Indeed, *everything* works with just SPDIF.  The same is not true of
> I2S.  So, what we do for the Cubox is we just wire up SPDIF in software
> and be done with it - we then get a fully functional setup.  So using
> I2S on the Cubox is mostly pointless - unless you wish to use I2S for
> testing purposes.
> 
> Let me also point out that adding your changes - including the addition
> of this codec patch - explicitly deny the possibility of:
> * using compressed audio streams via the optical SPDIF out socket
> * using compressed audio streams over HDMI
> * using audio rates and formats not supported by the attached HDMI
>   device via the optical SPDIF socket.
> 
> These are serious issues which thus far you have so far failed to
> respond on.  People who use the Cubox as a media platform rather
> than (presumably) just a music jukebox want things like compressed
> audio out and SPDIF out to work.
> 
> Look, one reason to use the optical socket is because you want to
> push out a stream at (eg) 96kHz to your audio system, but your TV
> doesn't support it.  With your approach, you explicitly block that
> because the TDA998x codec assocated with the Kirkwood CPU DAI
> refuses to allow that sample rate.  Fine, if the attached device
> does not support that rate, then the right thing to do may be to
> disable audio transmission over HDMI, but with the Cubox hardware,
> limiting the sample rates is totally the wrong solution.

I think that you did not look at my code.

Both S/PDIF and I2S work with the TDA998x. It is a choice of the audio
subsystem to do this choice, not Russell King. If you want only S/PDIF,
it is easy: just declare the S/PDIF DAIs, on both sides, source
(kirkwood) and sinks (tda998x and S/PDIF):

dai-link at 1 { /* S/PDIF - HDMI */
cpu {
sound-dai = < 1>;
};
,codec {
sound-dai = < 1>;
};
};

dai-link at 2 { /* S/PDIF - S/PDIF */
cpu {
sound-dai = < 1>;
};
codec {
sound-dai = <_codec>;
};
};

When DPCM will handle the formats and rates, the audio subsystem will
find by itself if such stream will go to the HDMI only or to the S/PDIF
only or to both. The kirwood audio driver will work as it is and the tda998x
CODEC will work as it is. There will be no need to change these drivers.
All we need actually is some more code in DPCM or multi-codec or
whatever mechanism which will route the stream according to the rates
and formats.

Actually, as DPCM does not work, the user has to choose which PCM to
use, otherwise, the application does a format and rate translation.

Anyway, if you want S/PDIF output with the actual kernel (3.16-rc3), in
the DT, put:

spdif_codec: spdif-codec {
compatible = "linux,spdif-dit";
#sound-dai-cells = <0>;
};

sound {
compatible = "simple-audio-card";
simple-audio-card,name = "Cubox Audio";
simple-audio-card,format = "i2s";

simple-audio-card,dai-link {/* S/PDIF - S/PDIF */
simple-audio-card,cpu {
sound-dai = < 1>;
};
simple-audio-card,codec {
sound-dai = <_codec>;
};
};
};

 {
status = "okay";
clocks = <_clk 13>, < 2>;
clock-names = "internal", "extclk";
pinctrl-0 = <_audio1_i2s1_spdifo _audio1_extclk>;
pinctrl-names = "default";
#sound-dai-cells = <1>;
};

and the sound should get out of your S/PDIF optical connector.

Eventually, the TDA998x is used in other machines. Are you sure that
the audio controllers of all these machines have a S/PDIF output
connected to the S/PDIF input of the tda998x?

The tda998x CODEC I propose works in all configurations.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] drm: Add Drm driver for Rockchip Socs

On Thu, Jul 3, 2014 at 7:08 AM, mark yao  wrote:
> From: mark 
>
> This patch is a DRM Driver for Rockchip Socs and now only add the
> framework of Rockchips Socs, but we will add Rockchips Socs soon.

just a very quick skim over this..  I expect I'll have some more
comments when I see a usage of the subdrv stuff.

This is not an exhaustive review, and would be good to get review
comments from some others as well.

> Signed-off-by: mark 
> ---
>  drivers/gpu/drm/Kconfig   |2 +
>  drivers/gpu/drm/Makefile  |1 +
>  drivers/gpu/drm/rockchip/Kconfig  |   35 +
>  drivers/gpu/drm/rockchip/Makefile |   14 +
>  drivers/gpu/drm/rockchip/rockchip_drm_buf.c   |  191 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_buf.h   |   39 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_connector.c |  261 
>  drivers/gpu/drm/rockchip/rockchip_drm_connector.h |   24 +
>  drivers/gpu/drm/rockchip/rockchip_drm_core.c  |  163 +
>  drivers/gpu/drm/rockchip/rockchip_drm_crtc.c  |  515 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_crtc.h  |   42 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.c|  290 
>  drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.h|   32 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  618 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  319 +
>  drivers/gpu/drm/rockchip/rockchip_drm_encoder.c   |  206 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_encoder.h   |   30 +
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  333 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   39 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  380 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   26 +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  738 
> +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |  198 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_iommu.c |  149 +
>  drivers/gpu/drm/rockchip/rockchip_drm_iommu.h |   76 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_plane.c |  290 
>  drivers/gpu/drm/rockchip/rockchip_drm_plane.h |   30 +
>  include/uapi/drm/rockchip_drm.h   |  155 +
>  28 files changed, 5196 insertions(+)
>  create mode 100644 drivers/gpu/drm/rockchip/Kconfig
>  create mode 100644 drivers/gpu/drm/rockchip/Makefile
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_buf.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_buf.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_core.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_dmabuf.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_encoder.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_encoder.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_iommu.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_iommu.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_plane.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_plane.h
>  create mode 100644 include/uapi/drm/rockchip_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f512004..5951c2c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -170,6 +170,8 @@ config DRM_SAVAGE
>
>  source "drivers/gpu/drm/exynos/Kconfig"
>
> +source "drivers/gpu/drm/rockchip/Kconfig"
> +
>  source "drivers/gpu/drm/vmwgfx/Kconfig"
>
>  source "drivers/gpu/drm/gma500/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index dd2ba42..40babd2 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
>  obj-$(CONFIG_DRM_VIA)  +=via/
>  obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
>  obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
>  obj-$(CONFIG_DRM_GMA500) += gma500/
>  obj-$(CONFIG_DRM_UDL) += udl/
>  obj-$(CONFIG_DRM_AST) += ast/
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
>

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, Jul 03, 2014 at 05:29:09PM +0200, Jean-Francois Moine wrote:
> I think that you did not look at my code.
> 
> Both S/PDIF and I2S work with the TDA998x. It is a choice of the audio
> subsystem to do this choice, not Russell King.

If you think I'm arguing because I personally want something, then we're
not going to make any progress.

What I want is for this to be _correct_ and _not_ to introduce silly
restrictions which break people's setups.

> When DPCM will handle the formats and rates, the audio subsystem will
> find by itself if such stream will go to the HDMI only or to the S/PDIF
> only or to both. The kirwood audio driver will work as it is and the tda998x
> CODEC will work as it is. There will be no need to change these drivers.

Except, as Mark has already pointed out, and as I keep pointing out to
you, and you keep refusing to accept, the kirkwood driver as it stands
is *not* a DPCM driver.  It makes no use of that stuff at all.

What you're doing in kirkwood-i2s is providing two plain DAI links,
and then insisting that only one can be active any any one time.

A DPCM solution provides at least one frontend DAI link and at least
one backend DAI link.  Your code does not do this.

The second point is that - and as I keep telling you - that as soon
as you couple your existing code (which restricts things like the
sample rates) you can no longer output anything else through the
optical out ON THE CUBOX.  For this statement, I'm not talking
_generally_,  I'm talking _specifically_ about _one_ _platform_.

> All we need actually is some more code in DPCM or multi-codec or
> whatever mechanism which will route the stream according to the rates
> and formats.

Yes, DPCM currently lacks full support, that's been known about for
some time - I've reported it to Mark, but it seems that this isn't
something that is going to get fixed until others put work into it.

> Eventually, the TDA998x is used in other machines. Are you sure that
> the audio controllers of all these machines have a S/PDIF output
> connected to the S/PDIF input of the tda998x?

Which bit of "we need to support both I2S and SPDIF" in my previous
emails was not clear.  Which bit of "We should only support SPDIF
on the Cubox" was not clear?

I *fully* acknowledge that we need to support both, but I'm putting
a _strong_ recommendation to you _with_ technical reasons why we
should _only_ support SPDIF on the Cubox.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[RFC] drm/msm: DT support for 8960/8064

2014-07-03 Thread sv...@codeaurora.org

Hi Rob,

> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
> add necessary DT support so that we can use drm/msm on upstream kernel.
>
> Signed-off-by: Rob Clark 
> ---
> Commence bikeshedding :-)
>

> diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
> b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
> new file mode 100644
> index 000..051a49f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
> @@ -0,0 +1,43 @@
> +Qualcomm adreno/snapdragon hdmi output
> +
> +Required properties:
> +- compatible: "qcom,hdmi-tx-8x60", "qcom,hdmi-tx-8960",
> "qcom,hdmi-tx-8x74"
> +- reg: Physical base address and length of the controller's registers.

Since you are adding "qcom,hdmi-tx-8x74" (separate address space for PHY
registers) in the compatible entry, how about this for the register
description:
- reg: Physical base address and length of the controllers' registers.
- reg-names: names corresponding to the defined register sets,
- "core_physical": HDMI Core registers
- (optional) "phy_physical": HDMI PHY registers

> +- interrupts: The interrupt outputs from the controller.
> +- clocks: device clocks
> +  See ../clocks/clock-bindings.txt for details.
> +- qcom,hdmi-tx-ddc-clk: ddc clk pin
> +- qcom,hdmi-tx-ddc-data: ddc data pin
> +- qcom,hdmi-tx-hpd: hpd pin
> +- core-vdda-supply: phandle to supply regulator
> +- hdmi-mux-supply: phandle to mux regulator
> +
> +Optional properties:
> +- qcom,hdmi-tx-mux-en: hdmi mux enable pin
> +- qcom,hdmi-tx-mux-sel: hdmi mux select pin
> +
> +Example:
> +
> +/ {
> + ...
> +
> + hdmi: qcom,hdmi-tx-8960 at 4a0 {
> + compatible = "qcom,hdmi-tx-8960";
> + reg-names = "core_physical";
> + reg = <0x04a0 0x1000>;
> + interrupts = ;
> + clock-names =
> + "core_clk",
> + "master_iface_clk",
> + "slave_iface_clk";
> + clocks =
> + < HDMI_APP_CLK>,
> + < HDMI_M_AHB_CLK>,
> + < HDMI_S_AHB_CLK>;
> + qcom,hdmi-tx-ddc-clk = < 70 GPIO_ACTIVE_HIGH>;
> + qcom,hdmi-tx-ddc-data = < 71 GPIO_ACTIVE_HIGH>;
> + qcom,hdmi-tx-hpd = < 72 GPIO_ACTIVE_HIGH>;
> + core-vdda-supply = <_hdmi_mvs>;
> + hdmi-mux-supply = <_3p3v>;
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/drm/msm/msm.txt
b/Documentation/devicetree/bindings/drm/msm/msm.txt
> new file mode 100644
> index 000..484cc12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/msm/msm.txt
>  -0,0 +1,40
> +Qualcomm adreno/snapdragon
> +
> +Required properties:
> +- compatible: "qcom,mdp" (mdp4) or "qcom,mdss_mdp" (mdp5)
> +- reg: Physical base address and length of the controller's registers.

As per the code (mdp5_kms.c), there are two sets of registers: "mdp_phys"
and "vbif_phys". They should probably be added in the description here.
"reg-names" entry might be needed as well.

> +- interrupts: The interrupt outputs from the controller.
> +- connectors: array of phandles for output device(s)
> +- clocks: device clocks
> +  See ../clocks/clock-bindings.txt for details.
> +
> +Optional properties:
> +- gpus: phandle for gpu device
> +
> +Example:
> +
> +/ {
> + ...
> +
> + mdp: qcom,mdp  510 {
> + compatible = "qcom,mdp";
> + reg = <0x0510 0xf>;
> + interrupts = ;
> + connectors = <>;
> + gpus = <>;
> + clock-names =
> + "core_clk",
> + "iface_clk",
> + "lut_clk",
> + "src_clk",
> + "hdmi_clk",
> + "mdp_clk";
> + clocks =
> + < MDP_SRC>,
> + < MDP_AHB_CLK>,
> + < MDP_LUT_CLK>,
> + < TV_SRC>,
> + < HDMI_TV_CLK>,
> + < MDP_TV_CLK>;
> + };
> +};

> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c
b/drivers/gpu/drm/msm/hdmi/hdmi.c
> index 7f7aade..0ff8d46 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c

>  -273,24 +275,37  static int hdmi_bind(struct
device *dev, struct device *master, void *data)
>   return gpio;
>   }
>
> - /* TODO actually use DT.. */
> - static const char *hpd_reg_names[] = {"hpd-gdsc", "hpd-5v"};
> - static const char *pwr_reg_names[] = {"core-vdda", "core-vcc"};
> - static const char *hpd_clk_names[] = {"iface_clk", "core_clk",
"mdp_core_clk"};
> - static unsigned long hpd_clk_freq[] = {0, 1920, 0};
> - static const char *pwr_clk_names[] = {"extp_clk", "alt_iface_clk"};
> + if (of_device_is_compatible(of_node, "qcom,hdmi-tx-8x74")) {
> + static const char *hpd_reg_names[] = {"hpd-gdsc", "hpd-5v"};
> + static const char *pwr_reg_names[] = {"core-vdda", "core-vcc"};
> +

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

2014-07-03 Thread Boris BREZILLON

Hello,

It's been almost a month and I only got reviews pointing minor issues.

I'd really like to get feedback/reviews from DRM/KMS maintainers and/or
experienced developers (this is my first DRM/KMS driver I'm pretty sure
there are things to fix).

Best Regards,

Boris 

On Mon,  9 Jun 2014 18:04:16 +0200
Boris BREZILLON  wrote:

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

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, 3 Jul 2014 12:59:24 +0100
Mark Brown  wrote:

> > > Your board happens to only be able to present the same input on both I2S
> > > and S/PDIF but that might not apply to other boards, they may be able to
> > > route different signals to each which would present a practical problem.  
> 
> > If there are two different streamss on I2S and S/PDIF, and if the audio
> > subsystem wants to route these streams to the same connector (widget
> > 'hdmi-out'), then, somewhere, there should be a software or a design
> > bug. No?  
> 
> Yes, which is why the driver shouldn't silently ignore the situation.
> 
> > Anyway, the tda998x cannot know if the double route is wanted or not.  
> 
> It doesn't need to know, it just needs to identify something it can't
> support either by providing a way to pick which interface is used or by
> rejecting the second interface.

OK. no problem, I can do that: only the first stream is switched and
the second is rejected.

But, this means that there will be a lot of errors when DPCM will be
used, because, in most cases for the Cubox (kirkwood audio + tda998x),
both ways I2S and S/PDIF will be activated at the same time for a
single stream (you may note that the routes from the second input
cannot be blocked by the CODEC after it received the first input,
because these routes have already been computed).

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] drm: default scaling to NONE for external connectors

2014-07-03 Thread Ilia Mirkin

Signed-off-by: Ilia Mirkin 
---

Based on a recent discussion in #radeon, and also my own observation that the
'full' scaling causes no end of confusion among users.

See https://bugs.freedesktop.org/show_bug.cgi?id=80868 for some more details,
although it is more radeon-specific.

Side-note: the scaling mode update handler disallows setting the mode to none
for LVDS... should it be the same for eDP as well? Or perhaps relax the
restriction and let people do whatever they want?

 drm/nouveau_connector.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drm/nouveau_connector.c b/drm/nouveau_connector.c
index 1fa222e..295e222 100644
--- a/drm/nouveau_connector.c
+++ b/drm/nouveau_connector.c
@@ -1192,6 +1192,8 @@ nouveau_connector_create(struct drm_device *dev, int 
index)
  disp->color_vibrance_property,
  150);

+   nv_connector->scaling_mode = DRM_MODE_SCALE_NONE;
+
switch (nv_connector->type) {
case DCB_CONNECTOR_VGA:
if (nv_device(drm->device)->card_type >= NV_50) {
@@ -1203,10 +1205,11 @@ nouveau_connector_create(struct drm_device *dev, int 
index)
case DCB_CONNECTOR_TV_0:
case DCB_CONNECTOR_TV_1:
case DCB_CONNECTOR_TV_3:
-   nv_connector->scaling_mode = DRM_MODE_SCALE_NONE;
break;
default:
-   nv_connector->scaling_mode = DRM_MODE_SCALE_FULLSCREEN;
+   if (type == DRM_MODE_CONNECTOR_LVDS ||
+   type == DRM_MODE_CONNECTOR_eDP)
+   nv_connector->scaling_mode = DRM_MODE_SCALE_FULLSCREEN;

drm_object_attach_property(>base,
dev->mode_config.scaling_mode_property,
-- 
1.8.5.5

[Bug 80684] I2C-over-AUX drops single bytes

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

--- Comment #5 from Alex Deucher  ---
Created attachment 102203
  --> https://bugs.freedesktop.org/attachment.cgi?id=102203=edit
return -EIO for flags not zero

Thinking about this more, I think returning -EIO is probably the right thing to
do since we don't know for sure whether the transaction succeeded or not.

-- 
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/20140703/a02ec3e9/attachment.html>

[PATCH 0/2] drm/panel: add support for Foxlink FL500WVR00-A0T panel

2014-07-03 Thread Boris BREZILLON

Hello Thierry,

I haven't had any feedback from you on this pretty straightforward
patch series adding support for a new LCD panel.

Did you receive it in the first place ?

Best Regards,

Boris

On Thu,  5 Jun 2014 15:53:30 +0200
Boris BREZILLON  wrote:

> Hello,
> 
> This series adds a new entry in the vendor-prefixes.txt file for Foxlink
> Group and defines Foxlink FL500WVR00-A0T panel specifications in the simple
> panel driver.
> 
> Best Regards,
> 
> Boris
> 
> 
> Boris BREZILLON (2):
>   DT: add vendor prefix for Foxlink Group
>   drm/panel: add support for Foxlink FL500WVR00-A0T panel
> 
>  .../bindings/panel/foxlink,fl500wvr00-a0t.txt  |  7 ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  drivers/gpu/drm/panel/panel-simple.c   | 25 
> ++
>  3 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #59 from Mathias Tillman  ---
I was using the 3.15 kernel (with your patch applied manually) on my last
reply, but I just updated to the drm-fixes-3.16 branch and unfortunately there
is no difference; it still gets stuck in the highest power level, and echoing
to power_dpm_force_performance_level results in an Invalid argument.

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

[Bug 71891] 3.13 fails to boot with the radeon module

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #40 from sdh  ---
Hi. Do we close this bug report now that I can successfully boot into 3.15
along with the radeon module?

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

[PATCH 12/12] drm/exynos/ipp: simplify ipp_find_driver

The patch puts repeated code sequence into one function, removes verbose
comments and decreases log verbosity.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 74 ++---
 1 file changed, 21 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index ae75a1d..c411399 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -174,18 +174,18 @@ static void *ipp_find_obj(struct idr *id_idr, struct 
mutex *lock, u32 id)
return obj;
 }

-static inline bool ipp_check_dedicated(struct exynos_drm_ippdrv *ippdrv,
-   enum drm_exynos_ipp_cmd cmd)
+static int ipp_check_driver(struct exynos_drm_ippdrv *ippdrv,
+   struct drm_exynos_ipp_property *property)
 {
-   /*
-* check dedicated flag and WB, OUTPUT operation with
-* power on state.
-*/
-   if (ippdrv->dedicated || (!ipp_is_m2m_cmd(cmd) &&
-   !pm_runtime_suspended(ippdrv->dev)))
-   return true;
+   if (ippdrv->dedicated || (!ipp_is_m2m_cmd(property->cmd) &&
+ !pm_runtime_suspended(ippdrv->dev)))
+   return -EBUSY;

-   return false;
+   if (ippdrv->check_property &&
+   ippdrv->check_property(ippdrv->dev, property))
+   return -EINVAL;
+
+   return 0;
 }

 static struct exynos_drm_ippdrv *ipp_find_driver(struct ipp_context *ctx,
@@ -193,62 +193,30 @@ static struct exynos_drm_ippdrv *ipp_find_driver(struct 
ipp_context *ctx,
 {
struct exynos_drm_ippdrv *ippdrv;
u32 ipp_id = property->ipp_id;
-
-   DRM_DEBUG_KMS("ipp_id[%d]\n", ipp_id);
+   int ret;

if (ipp_id) {
-   /* find ipp driver using idr */
-   ippdrv = ipp_find_obj(>ipp_idr, >ipp_lock,
-   ipp_id);
+   ippdrv = ipp_find_obj(>ipp_idr, >ipp_lock, ipp_id);
if (!ippdrv) {
-   DRM_ERROR("not found ipp%d driver.\n", ipp_id);
+   DRM_DEBUG("ipp%d driver not found\n", ipp_id);
return ERR_PTR(-ENODEV);
}

-   /*
-* WB, OUTPUT opertion not supported multi-operation.
-* so, make dedicated state at set property ioctl.
-* when ipp driver finished operations, clear dedicated flags.
-*/
-   if (ipp_check_dedicated(ippdrv, property->cmd)) {
-   DRM_ERROR("already used choose device.\n");
-   return ERR_PTR(-EBUSY);
-   }
-
-   /*
-* This is necessary to find correct device in ipp drivers.
-* ipp drivers have different abilities,
-* so need to check property.
-*/
-   if (ippdrv->check_property &&
-   ippdrv->check_property(ippdrv->dev, property)) {
-   DRM_ERROR("not support property.\n");
-   return ERR_PTR(-EINVAL);
+   ret = ipp_check_driver(ippdrv, property);
+   if (ret < 0) {
+   DRM_DEBUG("ipp%d driver check error %d\n", ipp_id, ret);
+   return ERR_PTR(ret);
}

return ippdrv;
} else {
-   /*
-* This case is search all ipp driver for finding.
-* user application don't set ipp_id in this case,
-* so ipp subsystem search correct driver in driver list.
-*/
list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
-   if (ipp_check_dedicated(ippdrv, property->cmd)) {
-   DRM_DEBUG_KMS("used device.\n");
-   continue;
-   }
-
-   if (ippdrv->check_property &&
-   ippdrv->check_property(ippdrv->dev, property)) {
-   DRM_DEBUG_KMS("not support property.\n");
-   continue;
-   }
-
-   return ippdrv;
+   ret = ipp_check_driver(ippdrv, property);
+   if (ret == 0)
+   return ippdrv;
}

-   DRM_ERROR("not support ipp driver operations.\n");
+   DRM_DEBUG("cannot find driver suitable for given property.\n");
}

return ERR_PTR(-ENODEV);
-- 
1.9.1

[PATCH 11/12] drm/exynos/ipp: simplify ipp_create_id

There is no gain in passing id by pointer to be filled.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 28 +---
 1 file changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 0552f62..ae75a1d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -145,20 +145,15 @@ int exynos_drm_ippdrv_unregister(struct exynos_drm_ippdrv 
*ippdrv)
return 0;
 }

-static int ipp_create_id(struct idr *id_idr, struct mutex *lock, void *obj,
-   u32 *idp)
+static int ipp_create_id(struct idr *id_idr, struct mutex *lock, void *obj)
 {
int ret;

-   /* do the allocation under our mutexlock */
mutex_lock(lock);
ret = idr_alloc(id_idr, obj, 1, 0, GFP_KERNEL);
mutex_unlock(lock);
-   if (ret < 0)
-   return ret;

-   *idp = ret;
-   return 0;
+   return ret;
 }

 static void ipp_remove_id(struct idr *id_idr, struct mutex *lock, u32 id)
@@ -471,13 +466,12 @@ int exynos_drm_ipp_set_property(struct drm_device 
*drm_dev, void *data,
if (!c_node)
return -ENOMEM;

-   /* create property id */
-   ret = ipp_create_id(>prop_idr, >prop_lock, c_node,
-   >prop_id);
-   if (ret) {
+   ret = ipp_create_id(>prop_idr, >prop_lock, c_node);
+   if (ret < 0) {
DRM_ERROR("failed to create id.\n");
goto err_clear;
}
+   property->prop_id = ret;

DRM_DEBUG_KMS("created prop_id[%d]cmd[%d]ippdrv[0x%x]\n",
property->prop_id, property->cmd, (int)ippdrv);
@@ -1636,21 +1630,17 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)

/* get ipp driver entry */
list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
-   u32 ipp_id;
-
ippdrv->drm_dev = drm_dev;

-   ret = ipp_create_id(>ipp_idr, >ipp_lock, ippdrv,
-   _id);
-   if (ret || ipp_id == 0) {
+   ret = ipp_create_id(>ipp_idr, >ipp_lock, ippdrv);
+   if (ret < 0) {
DRM_ERROR("failed to create id.\n");
goto err;
}
+   ippdrv->prop_list.ipp_id = ret;

DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]ipp_id[%d]\n",
-   count++, (int)ippdrv, ipp_id);
-
-   ippdrv->prop_list.ipp_id = ipp_id;
+   count++, (int)ippdrv, ret);

/* store parent device for node */
ippdrv->parent_dev = dev;
-- 
1.9.1

[PATCH 10/12] drm/exynos/ipp: remove redundant messages

In case of error callback prints already corresponding message.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index c7ea047..0552f62 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1152,7 +1152,6 @@ static int ipp_set_property(struct exynos_drm_ippdrv 
*ippdrv,
/* reset h/w block */
if (ippdrv->reset &&
ippdrv->reset(ippdrv->dev)) {
-   DRM_ERROR("failed to reset.\n");
return -EINVAL;
}

@@ -1170,30 +1169,24 @@ static int ipp_set_property(struct exynos_drm_ippdrv 
*ippdrv,
/* set format */
if (ops->set_fmt) {
ret = ops->set_fmt(ippdrv->dev, config->fmt);
-   if (ret) {
-   DRM_ERROR("not support format.\n");
+   if (ret)
return ret;
-   }
}

/* set transform for rotation, flip */
if (ops->set_transf) {
ret = ops->set_transf(ippdrv->dev, config->degree,
config->flip, );
-   if (ret) {
-   DRM_ERROR("not support tranf.\n");
-   return -EINVAL;
-   }
+   if (ret)
+   return ret;
}

/* set size */
if (ops->set_size) {
ret = ops->set_size(ippdrv->dev, swap, >pos,
>sz);
-   if (ret) {
-   DRM_ERROR("not support size.\n");
+   if (ret)
return ret;
-   }
}
}

-- 
1.9.1

[PATCH 09/12] drm/exynos/ipp: simplify ipp_find_obj

The patch simplifies ipp_find_obj and removes debug messages.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 26c8a2c..c7ea047 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -172,18 +172,8 @@ static void *ipp_find_obj(struct idr *id_idr, struct mutex 
*lock, u32 id)
 {
void *obj;

-   DRM_DEBUG_KMS("id[%d]\n", id);
-
mutex_lock(lock);
-
-   /* find object using handle */
obj = idr_find(id_idr, id);
-   if (!obj) {
-   DRM_ERROR("failed to find object.\n");
-   mutex_unlock(lock);
-   return ERR_PTR(-ENODEV);
-   }
-
mutex_unlock(lock);

return obj;
@@ -215,9 +205,9 @@ static struct exynos_drm_ippdrv *ipp_find_driver(struct 
ipp_context *ctx,
/* find ipp driver using idr */
ippdrv = ipp_find_obj(>ipp_idr, >ipp_lock,
ipp_id);
-   if (IS_ERR(ippdrv)) {
+   if (!ippdrv) {
DRM_ERROR("not found ipp%d driver.\n", ipp_id);
-   return ippdrv;
+   return ERR_PTR(-ENODEV);
}

/*
@@ -339,10 +329,10 @@ int exynos_drm_ipp_get_property(struct drm_device 
*drm_dev, void *data,
 */
ippdrv = ipp_find_obj(>ipp_idr, >ipp_lock,
prop_list->ipp_id);
-   if (IS_ERR(ippdrv)) {
+   if (!ippdrv) {
DRM_ERROR("not found ipp%d driver.\n",
prop_list->ipp_id);
-   return PTR_ERR(ippdrv);
+   return -ENODEV;
}

*prop_list = ippdrv->prop_list;
@@ -920,9 +910,9 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
/* find command node */
c_node = ipp_find_obj(>prop_idr, >prop_lock,
qbuf->prop_id);
-   if (IS_ERR(c_node)) {
+   if (!c_node) {
DRM_ERROR("failed to get command node.\n");
-   return PTR_ERR(c_node);
+   return -ENODEV;
}

/* buffer control */
@@ -1055,9 +1045,9 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,

c_node = ipp_find_obj(>prop_idr, >prop_lock,
cmd_ctrl->prop_id);
-   if (IS_ERR(c_node)) {
+   if (!c_node) {
DRM_ERROR("invalid command node list.\n");
-   return PTR_ERR(c_node);
+   return -ENODEV;
}

if (!exynos_drm_ipp_check_valid(ippdrv->dev, cmd_ctrl->ctrl,
-- 
1.9.1

[PATCH 08/12] drm/exynos/ipp: remove useless registration checks

Argument checks are redundant, clients always check ippdrv before calling
these functions.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index b7ce14e..26c8a2c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -129,9 +129,6 @@ void exynos_platform_device_ipp_unregister(void)

 int exynos_drm_ippdrv_register(struct exynos_drm_ippdrv *ippdrv)
 {
-   if (!ippdrv)
-   return -EINVAL;
-
mutex_lock(_drm_ippdrv_lock);
list_add_tail(>drv_list, _drm_ippdrv_list);
mutex_unlock(_drm_ippdrv_lock);
@@ -141,9 +138,6 @@ int exynos_drm_ippdrv_register(struct exynos_drm_ippdrv 
*ippdrv)

 int exynos_drm_ippdrv_unregister(struct exynos_drm_ippdrv *ippdrv)
 {
-   if (!ippdrv)
-   return -EINVAL;
-
mutex_lock(_drm_ippdrv_lock);
list_del(>drv_list);
mutex_unlock(_drm_ippdrv_lock);
-- 
1.9.1

[PATCH 07/12] drm/exynos/ipp: simplify memory check function

The only thing function should check is if there are buffers in respective
queues.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 44 -
 1 file changed, 10 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 89ff7e3..b7ce14e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -574,42 +574,18 @@ static void ipp_clean_cmd_node(struct ipp_context *ctx,
kfree(c_node);
 }

-static int ipp_check_mem_list(struct drm_exynos_ipp_cmd_node *c_node)
+static bool ipp_check_mem_list(struct drm_exynos_ipp_cmd_node *c_node)
 {
-   struct drm_exynos_ipp_property *property = _node->property;
-   struct drm_exynos_ipp_mem_node *m_node;
-   struct list_head *head;
-   int ret, i, count[EXYNOS_DRM_OPS_MAX] = { 0, };
-
-   for_each_ipp_ops(i) {
-   /* source/destination memory list */
-   head = _node->mem_list[i];
-
-   /* find memory node entry */
-   list_for_each_entry(m_node, head, list) {
-   DRM_DEBUG_KMS("%s,count[%d]m_node[0x%x]\n",
-   i ? "dst" : "src", count[i], (int)m_node);
-   count[i]++;
-   }
+   switch (c_node->property.cmd) {
+   case IPP_CMD_WB:
+   return !list_empty(_node->mem_list[EXYNOS_DRM_OPS_DST]);
+   case IPP_CMD_OUTPUT:
+   return !list_empty(_node->mem_list[EXYNOS_DRM_OPS_SRC]);
+   case IPP_CMD_M2M:
+   default:
+   return !list_empty(_node->mem_list[EXYNOS_DRM_OPS_SRC]) &&
+  !list_empty(_node->mem_list[EXYNOS_DRM_OPS_DST]);
}
-
-   DRM_DEBUG_KMS("min[%d]max[%d]\n",
-   min(count[EXYNOS_DRM_OPS_SRC], count[EXYNOS_DRM_OPS_DST]),
-   max(count[EXYNOS_DRM_OPS_SRC], count[EXYNOS_DRM_OPS_DST]));
-
-   /*
-* M2M operations should be need paired memory address.
-* so, need to check minimum count about src, dst.
-* other case not use paired memory, so use maximum count
-*/
-   if (ipp_is_m2m_cmd(property->cmd))
-   ret = min(count[EXYNOS_DRM_OPS_SRC],
-   count[EXYNOS_DRM_OPS_DST]);
-   else
-   ret = max(count[EXYNOS_DRM_OPS_SRC],
-   count[EXYNOS_DRM_OPS_DST]);
-
-   return ret;
 }

 static struct drm_exynos_ipp_mem_node
-- 
1.9.1

[PATCH 06/12] drm/exynos/ipp: remove incorrect checks of list_first_entry result

list_first_entry does not return NULL on empty list so this check
does not make sense. Moreover there is already code which prevents calling
list_first_entry on empty lists.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index f84ef8a..89ff7e3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1277,11 +1277,6 @@ static int ipp_start_property(struct exynos_drm_ippdrv 
*ippdrv,

m_node = list_first_entry(head,
struct drm_exynos_ipp_mem_node, list);
-   if (!m_node) {
-   DRM_ERROR("failed to get node.\n");
-   ret = -EFAULT;
-   goto err_unlock;
-   }

DRM_DEBUG_KMS("m_node[0x%x]\n", (int)m_node);

@@ -1539,11 +1534,6 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
*ippdrv,

m_node = list_first_entry(head,
struct drm_exynos_ipp_mem_node, list);
-   if (!m_node) {
-   DRM_ERROR("empty memory node.\n");
-   ret = -ENOMEM;
-   goto err_mem_unlock;
-   }

tbuf_id[i] = m_node->buf_id;
DRM_DEBUG_KMS("%s buf_id[%d]\n",
@@ -1580,11 +1570,6 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
*ippdrv,

m_node = list_first_entry(head,
struct drm_exynos_ipp_mem_node, list);
-   if (!m_node) {
-   DRM_ERROR("empty memory node.\n");
-   ret = -ENOMEM;
-   goto err_mem_unlock;
-   }

tbuf_id[EXYNOS_DRM_OPS_SRC] = m_node->buf_id;

-- 
1.9.1

[PATCH 05/12] drm/exynos/ipp: remove temporary variable

There is no reason to allocate intermediate variable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index f3d8b5c..f84ef8a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -680,15 +680,14 @@ static struct drm_exynos_ipp_mem_node
struct drm_exynos_ipp_queue_buf *qbuf)
 {
struct drm_exynos_ipp_mem_node *m_node;
-   struct drm_exynos_ipp_buf_info buf_info;
+   struct drm_exynos_ipp_buf_info *buf_info;
int i;

m_node = kzalloc(sizeof(*m_node), GFP_KERNEL);
if (!m_node)
return ERR_PTR(-ENOMEM);

-   /* clear base address for error handling */
-   memset(_info, 0x0, sizeof(buf_info));
+   buf_info = _node->buf_info;

/* operations, buffer id */
m_node->ops_id = qbuf->ops_id;
@@ -712,15 +711,14 @@ static struct drm_exynos_ipp_mem_node
goto err_clear;
}

-   buf_info.handles[i] = qbuf->handle[i];
-   buf_info.base[i] = *addr;
-   DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%x]\n",
-   i, buf_info.base[i], (int)buf_info.handles[i]);
+   buf_info->handles[i] = qbuf->handle[i];
+   buf_info->base[i] = *addr;
+   DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
+ buf_info->base[i], buf_info->handles[i]);
}
}

m_node->filp = file;
-   m_node->buf_info = buf_info;
mutex_lock(_node->mem_lock);
list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
mutex_unlock(_node->mem_lock);
-- 
1.9.1

[PATCH 04/12] drm/exynos/ipp: correct address type

exynos_drm_gem_get_dma_addr returns dma_addr_t, type casting to void* and
back is not necessary.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 34d185c..f3d8b5c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -681,7 +681,6 @@ static struct drm_exynos_ipp_mem_node
 {
struct drm_exynos_ipp_mem_node *m_node;
struct drm_exynos_ipp_buf_info buf_info;
-   void *addr;
int i;

m_node = kzalloc(sizeof(*m_node), GFP_KERNEL);
@@ -704,6 +703,8 @@ static struct drm_exynos_ipp_mem_node

/* get dma address by handle */
if (qbuf->handle[i]) {
+   dma_addr_t *addr;
+
addr = exynos_drm_gem_get_dma_addr(drm_dev,
qbuf->handle[i], file);
if (IS_ERR(addr)) {
@@ -712,7 +713,7 @@ static struct drm_exynos_ipp_mem_node
}

buf_info.handles[i] = qbuf->handle[i];
-   buf_info.base[i] = *(dma_addr_t *) addr;
+   buf_info.base[i] = *addr;
DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%x]\n",
i, buf_info.base[i], (int)buf_info.handles[i]);
}
-- 
1.9.1

[PATCH 03/12] drm/exynos/ipp: remove struct exynos_drm_ipp_private

struct exynos_drm_ipp_private contains only one pointer so all occurrences
of the struct can be replaced by the pointer itself.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  6 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 30 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  4 ++--
 3 files changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 651f37a..5f027f2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -236,13 +236,9 @@ struct exynos_drm_g2d_private {
struct list_headuserptr_list;
 };

-struct exynos_drm_ipp_private {
-   struct device   *dev;
-};
-
 struct drm_exynos_file_private {
struct exynos_drm_g2d_private   *g2d_priv;
-   struct exynos_drm_ipp_private   *ipp_priv;
+   struct device   *ipp_dev;
struct file *anon_filp;
 };

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 5fb89c02..34d185c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -308,8 +308,7 @@ int exynos_drm_ipp_get_property(struct drm_device *drm_dev, 
void *data,
struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv = file->driver_priv;
-   struct exynos_drm_ipp_private *priv = file_priv->ipp_priv;
-   struct device *dev = priv->dev;
+   struct device *dev = file_priv->ipp_dev;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_prop_list *prop_list = data;
struct exynos_drm_ippdrv *ippdrv;
@@ -441,8 +440,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv = file->driver_priv;
-   struct exynos_drm_ipp_private *priv = file_priv->ipp_priv;
-   struct device *dev = priv->dev;
+   struct device *dev = file_priv->ipp_dev;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_property *property = data;
struct exynos_drm_ippdrv *ippdrv;
@@ -501,7 +499,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
property->prop_id, property->cmd, (int)ippdrv);

/* stored property information and ippdrv in private data */
-   c_node->priv = priv;
+   c_node->dev = dev;
c_node->property = *property;
c_node->state = IPP_STATE_IDLE;

@@ -929,8 +927,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv = file->driver_priv;
-   struct exynos_drm_ipp_private *priv = file_priv->ipp_priv;
-   struct device *dev = priv->dev;
+   struct device *dev = file_priv->ipp_dev;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_queue_buf *qbuf = data;
struct drm_exynos_ipp_cmd_node *c_node;
@@ -1061,9 +1058,8 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,
struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv = file->driver_priv;
-   struct exynos_drm_ipp_private *priv = file_priv->ipp_priv;
struct exynos_drm_ippdrv *ippdrv = NULL;
-   struct device *dev = priv->dev;
+   struct device *dev = file_priv->ipp_dev;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_cmd_ctrl *cmd_ctrl = data;
struct drm_exynos_ipp_cmd_work *cmd_work;
@@ -1775,16 +1771,10 @@ static int ipp_subdrv_open(struct drm_device *drm_dev, 
struct device *dev,
struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv = file->driver_priv;
-   struct exynos_drm_ipp_private *priv;
-
-   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-   if (!priv)
-   return -ENOMEM;
-   priv->dev = dev;
-   file_priv->ipp_priv = priv;

+   file_priv->ipp_dev = dev;

-   DRM_DEBUG_KMS("done priv[0x%x]\n", (int)priv);
+   DRM_DEBUG_KMS("done priv[0x%x]\n", (int)dev);

return 0;
 }
@@ -1793,13 +1783,12 @@ static void ipp_subdrv_close(struct drm_device 
*drm_dev, struct device *dev,
struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv = file->driver_priv;
-   struct exynos_drm_ipp_private *priv = file_priv->ipp_priv;
struct exynos_drm_ippdrv *ippdrv = NULL;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_cmd_node *c_node, *tc_node;
int count = 0;

-   DRM_DEBUG_KMS("for priv[0x%x]\n", (int)priv);
+   DRM_DEBUG_KMS("for priv[0x%x]\n", (int)file_priv->ipp_dev);

list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {

[PATCH 02/12] drm/exynos/ipp: remove unused field from exynos_drm_ipp_private

The patch removes unused event_list field from struct exynos_drm_ipp_private.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 06cde45..651f37a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -238,7 +238,6 @@ struct exynos_drm_g2d_private {

 struct exynos_drm_ipp_private {
struct device   *dev;
-   struct list_headevent_list;
 };

 struct drm_exynos_file_private {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index f3f114c..5fb89c02 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -534,7 +534,6 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
INIT_LIST_HEAD(_node->mem_list[i]);

INIT_LIST_HEAD(_node->event_list);
-   list_splice_init(>event_list, _node->event_list);
mutex_lock(>cmd_lock);
list_add_tail(_node->list, >cmd_list);
mutex_unlock(>cmd_lock);
@@ -1784,7 +1783,6 @@ static int ipp_subdrv_open(struct drm_device *drm_dev, 
struct device *dev,
priv->dev = dev;
file_priv->ipp_priv = priv;

-   INIT_LIST_HEAD(>event_list);

DRM_DEBUG_KMS("done priv[0x%x]\n", (int)priv);

-- 
1.9.1

[PATCH 01/12] drm/exynos/ipp: remove type casting

The patch replaces type casting with proper pointer.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index a1888e1..f3f114c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -432,7 +432,7 @@ static struct drm_exynos_ipp_event_work 
*ipp_create_event_work(void)
if (!event_work)
return ERR_PTR(-ENOMEM);

-   INIT_WORK((struct work_struct *)event_work, ipp_sched_event);
+   INIT_WORK(_work->work, ipp_sched_event);

return event_work;
 }
-- 
1.9.1

[PATCH 00/12] drm/exynos/ipp: image post processing improvements, part three

This set of independent patches contains various improvement and fixes
for exynos_drm ipp framework.
The patchset is based on exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (12):
  drm/exynos/ipp: remove type casting
  drm/exynos/ipp: remove unused field from exynos_drm_ipp_private
  drm/exynos/ipp: remove struct exynos_drm_ipp_private
  drm/exynos/ipp: correct address type
  drm/exynos/ipp: remove temporary variable
  drm/exynos/ipp: remove incorrect checks of list_first_entry result
  drm/exynos/ipp: simplify memory check function
  drm/exynos/ipp: remove useless registration checks
  drm/exynos/ipp: simplify ipp_find_obj
  drm/exynos/ipp: remove redundant messages
  drm/exynos/ipp: simplify ipp_create_id
  drm/exynos/ipp: simplify ipp_find_driver

 drivers/gpu/drm/exynos/exynos_drm_drv.h |   7 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 259 +---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |   4 +-
 3 files changed, 73 insertions(+), 197 deletions(-)

-- 
1.9.1

[Bug 78661] GPU sometimes locks up after boot and/or resume

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #7 from Nikolaus Waxweiler  ---
Created attachment 142021
  --> https://bugzilla.kernel.org/attachment.cgi?id=142021=edit
Rebuilt kernel with patch, just got a hang again :(

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

[PULL] vmwgfx-fixes-3.16

2014-07-03 Thread Thomas Hellstrom

Dave, a fix to a 3.15 commit.

The following changes since commit 0fcb70c30131aac40f62ba13f89963d5c13b48a7:

  Merge tag 'drm-intel-fixes-2014-06-26' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-06-27 15:04:06 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-3.16

for you to fetch changes up to 4e578080ed3262ed2c3985868539bc66218d25c0:

  drm/vmwgfx: Fix incorrect write to read-only register v2: (2014-07-03 
05:00:14 -0700)


Thomas Hellstrom (1):
  drm/vmwgfx: Fix incorrect write to read-only register v2:

 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 -
 1 file changed, 1 deletion(-)

[PATCH] drm/vmwgfx: Fix incorrect write to read-only register v2:

2014-07-03 Thread Thomas Hellstrom

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: stable at vger.kernel.org
Cc: Christopher Friedt 
Tested-by: Christopher Friedt 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index a89ad93..b031b48 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -179,7 +179,6 @@ static int vmw_fb_set_par(struct fb_info *info)
vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_Y, 
info->var.yoffset);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_WIDTH, info->var.xres);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_HEIGHT, info->var.yres);
-   vmw_write(vmw_priv, SVGA_REG_BYTES_PER_LINE, 
info->fix.line_length);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
}

-- 
1.8.3.2

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, Jul 03, 2014 at 03:28:26PM +0200, Jean-Francois Moine wrote:
> OK. no problem, I can do that: only the first stream is switched and
> the second is rejected.
> 
> But, this means that there will be a lot of errors when DPCM will be
> used, because, in most cases for the Cubox (kirkwood audio + tda998x),
> both ways I2S and S/PDIF will be activated at the same time for a
> single stream (you may note that the routes from the second input
> cannot be blocked by the CODEC after it received the first input,
> because these routes have already been computed).

This is /very/ easy to solve on the Cubox, if only you would listen
to me - I've stated many times that I2S should not be used there.

Just because the hardware is wired up with both the SPDIF connected
and the I2S connected, it does *not* mean that we have to wire them
both up in software.

Indeed, *everything* works with just SPDIF.  The same is not true of
I2S.  So, what we do for the Cubox is we just wire up SPDIF in software
and be done with it - we then get a fully functional setup.  So using
I2S on the Cubox is mostly pointless - unless you wish to use I2S for
testing purposes.

Let me also point out that adding your changes - including the addition
of this codec patch - explicitly deny the possibility of:
* using compressed audio streams via the optical SPDIF out socket
* using compressed audio streams over HDMI
* using audio rates and formats not supported by the attached HDMI
  device via the optical SPDIF socket.

These are serious issues which thus far you have so far failed to
respond on.  People who use the Cubox as a media platform rather
than (presumably) just a music jukebox want things like compressed
audio out and SPDIF out to work.

Look, one reason to use the optical socket is because you want to
push out a stream at (eg) 96kHz to your audio system, but your TV
doesn't support it.  With your approach, you explicitly block that
because the TDA998x codec assocated with the Kirkwood CPU DAI
refuses to allow that sample rate.  Fine, if the attached device
does not support that rate, then the right thing to do may be to
disable audio transmission over HDMI, but with the Cubox hardware,
limiting the sample rates is totally the wrong solution.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[RFC] drm/msm: DT support for 8960/8064

On Thu, Jul 3, 2014 at 12:36 PM,   wrote:
> Hi Rob,
>
>> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
>> add necessary DT support so that we can use drm/msm on upstream kernel.
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Commence bikeshedding :-)
>>
> 
>> diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
>> b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
>> new file mode 100644
>> index 000..051a49f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
>> @@ -0,0 +1,43 @@
>> +Qualcomm adreno/snapdragon hdmi output
>> +
>> +Required properties:
>> +- compatible: "qcom,hdmi-tx-8x60", "qcom,hdmi-tx-8960",
>> "qcom,hdmi-tx-8x74"
>> +- reg: Physical base address and length of the controller's registers.
>
> Since you are adding "qcom,hdmi-tx-8x74" (separate address space for PHY
> registers) in the compatible entry, how about this for the register
> description:
> - reg: Physical base address and length of the controllers' registers.
> - reg-names: names corresponding to the defined register sets,
> - "core_physical": HDMI Core registers
> - (optional) "phy_physical": HDMI PHY registers

Oh, right.. I forgot 8x74 had phy in a separate region..

>> +- interrupts: The interrupt outputs from the controller.
>> +- clocks: device clocks
>> +  See ../clocks/clock-bindings.txt for details.
>> +- qcom,hdmi-tx-ddc-clk: ddc clk pin
>> +- qcom,hdmi-tx-ddc-data: ddc data pin
>> +- qcom,hdmi-tx-hpd: hpd pin
>> +- core-vdda-supply: phandle to supply regulator
>> +- hdmi-mux-supply: phandle to mux regulator
>> +
>> +Optional properties:
>> +- qcom,hdmi-tx-mux-en: hdmi mux enable pin
>> +- qcom,hdmi-tx-mux-sel: hdmi mux select pin
>> +
>> +Example:
>> +
>> +/ {
>> + ...
>> +
>> + hdmi: qcom,hdmi-tx-8960 at 4a0 {
>> + compatible = "qcom,hdmi-tx-8960";
>> + reg-names = "core_physical";
>> + reg = <0x04a0 0x1000>;
>> + interrupts = ;
>> + clock-names =
>> + "core_clk",
>> + "master_iface_clk",
>> + "slave_iface_clk";
>> + clocks =
>> + < HDMI_APP_CLK>,
>> + < HDMI_M_AHB_CLK>,
>> + < HDMI_S_AHB_CLK>;
>> + qcom,hdmi-tx-ddc-clk = < 70 GPIO_ACTIVE_HIGH>;
>> + qcom,hdmi-tx-ddc-data = < 71 GPIO_ACTIVE_HIGH>;
>> + qcom,hdmi-tx-hpd = < 72 GPIO_ACTIVE_HIGH>;
>> + core-vdda-supply = <_hdmi_mvs>;
>> + hdmi-mux-supply = <_3p3v>;
>> + };
>> +};
>> diff --git a/Documentation/devicetree/bindings/drm/msm/msm.txt
> b/Documentation/devicetree/bindings/drm/msm/msm.txt
>> new file mode 100644
>> index 000..484cc12
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/msm/msm.txt
>>  -0,0 +1,40
>> +Qualcomm adreno/snapdragon
>> +
>> +Required properties:
>> +- compatible: "qcom,mdp" (mdp4) or "qcom,mdss_mdp" (mdp5)
>> +- reg: Physical base address and length of the controller's registers.
>
> As per the code (mdp5_kms.c), there are two sets of registers: "mdp_phys"
> and "vbif_phys". They should probably be added in the description here.
> "reg-names" entry might be needed as well.

hmm.. well, we aren't actually using vbif_phys *yet*.. although not
really sure if that will change.

I am wondering if maybe we should split out mdp4 vs mdp5 DT bindings.
Or at least remove the mdp5 compat string for now.  So far I've only
got mdp4 working upstream, so probably a few things I've missed for
mdp5.  Maybe just removing "qcom,mdss_mdp" for the time being is safer
until we decide.

I guess we should be really close to having all the needed
dependencies for 8074/dragonboard, so I suppose that is something I
should play with.  Although seems unlikely that I'll have time until
after 3.17 merge window.  Mostly I wanted to get mdp4 working first,
since I already have enough overlay support working there to be useful
for atomic modeset/pageflip ;-)

BR,
-R

>> +- interrupts: The interrupt outputs from the controller.
>> +- connectors: array of phandles for output device(s)
>> +- clocks: device clocks
>> +  See ../clocks/clock-bindings.txt for details.
>> +
>> +Optional properties:
>> +- gpus: phandle for gpu device
>> +
>> +Example:
>> +
>> +/ {
>> + ...
>> +
>> + mdp: qcom,mdp  510 {
>> + compatible = "qcom,mdp";
>> + reg = <0x0510 0xf>;
>> + interrupts = ;
>> + connectors = <>;
>> + gpus = <>;
>> + clock-names =
>> + "core_clk",
>> + "iface_clk",
>> + "lut_clk",
>> + "src_clk",
>> + "hdmi_clk",
>> + "mdp_clk";
>> + clocks =
>> + < MDP_SRC>,
>> + < MDP_AHB_CLK>,
>> + < MDP_LUT_CLK>,
>> + < TV_SRC>,
>> + < HDMI_TV_CLK>,
>> + <

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #58 from Alex Deucher  ---
What kernel did you try?  I haven't been able to reproduce this for a while.  I
just tested a bunch of boards yesterday with 3.16 and multi-head dpm worked
properly on all of them.

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

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, 3 Jul 2014 11:44:32 +0100
Mark Brown  wrote:

> > > I'd expect this to return an error for the busy DAI rather than just
> > > silently ignore it failing to start or (better) implement some control
> > > to let the user select which of the DAIs is active.  
> 
> > This is not an error. If the audio subsystem (DPCM, not the user)
> > chooses to activate both I2S and S/PDIF, this means the HDMI audio may
> > be taken either from I2S or from S/PDIF: both inputs have the right
> > format and rate.  
> 
> Your board happens to only be able to present the same input on both I2S
> and S/PDIF but that might not apply to other boards, they may be able to
> route different signals to each which would present a practical problem.

If there are two different streamss on I2S and S/PDIF, and if the audio
subsystem wants to route these streams to the same connector (widget
'hdmi-out'), then, somewhere, there should be a software or a design
bug. No?

Anyway, the tda998x cannot know if the double route is wanted or not.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

2014-07-03 Thread Mark Brown

On Thu, Jul 03, 2014 at 01:34:06PM +0200, Jean-Francois Moine wrote:
> Mark Brown  wrote:

> > Your board happens to only be able to present the same input on both I2S
> > and S/PDIF but that might not apply to other boards, they may be able to
> > route different signals to each which would present a practical problem.

> If there are two different streamss on I2S and S/PDIF, and if the audio
> subsystem wants to route these streams to the same connector (widget
> 'hdmi-out'), then, somewhere, there should be a software or a design
> bug. No?

Yes, which is why the driver shouldn't silently ignore the situation.

> Anyway, the tda998x cannot know if the double route is wanted or not.

It doesn't need to know, it just needs to identify something it can't
support either by providing a way to pick which interface is used or by
rejecting the second interface.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/d5383422/attachment.sig>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

2014-07-03 Thread Michel Dänzer

On 03.07.2014 04:31, Christian K?nig wrote:
>> FWIW, I've also had successful runs with the first three of the split
>> changes, and with all of them.
> Ok I've just pushed a branch testing-3.15-v3 to fdo which moves all page
> table allocation to the end of VRAM. Please try with this memory layout,
> it should give us a good idea if it's indeed a memory corruption or
> something else.

That branch just survived piglit as well.


> Apart from that please try to lockup your system with
> radeon.lockup_timeout=0 on the kernel commandline and then try to get a
> dump of the vm page tables with the script I've send to you in one of
> the mails.

Any preference for which changes of which branch I should try this with?
E.g. with the two overalignment changes from testing-3.15-v2?


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

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

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

--- Comment #30 from Kertesz Laszlo  ---
I activated bapm on my A8-6500 (on a GA-F2A88X-D3H mobo).
It is working as advertised - the CPU reached its 4GHz turbo core speed and was
working between 3.5GHz(nominal top speed) and 4GHz for quite long time periods.
Actually, from a performance point of view, this is the best so far (Catalyst
had some nasty CPU slowdowns, not seen in /proc/cpu).

Now, the problems - about once a day the computer reboots suddenly. Every time
my wife was playing some flash based Facebook game BTW. Using other stuff, even
playing 3D games or using VDPAU acceleration didnt seem to create problems.

Also, i observed this in the system log:

[  299.812285] mce: [Hardware Error]: Machine check events logged

/var/log/mcelog has these:

mcelog: failed to prefill DIMM database from DMI data
mcelog: Unknown CPU type vendor 2 family 15 model 3
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 4
ADDR feb0c114
TIME 1404369155 Thu Jul  3 09:32:35 2014
STATUS b6070f0f MCGSTATUS 0
MCGCAP 107 APICID 0 SOCKETID 0
CPUID Vendor AMD Family 21 Model 3

-- 
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/20140703/e1aa60d6/attachment-0001.html>

[PATCH v2] ARM: tegra: roth: add display DT node

2014-07-03 Thread Alexandre Courbot

DSI support has been fixed to support continuous clock behavior that the
panel used on SHIELD requires, so finally add its device tree node since
it is functional.

Signed-off-by: Alexandre Courbot 
---
Changes since v1:
- Removed unneeded regulator-always-on property for vdd_lcd regulator
Only patch 4/4 of the original series has been resent for this v2.

 arch/arm/boot/dts/tegra114-roth.dts | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-roth.dts 
b/arch/arm/boot/dts/tegra114-roth.dts
index ba210c6e189f..c7c6825f11fb 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -28,6 +28,22 @@
reg = <0x8000 0x7960>;
};

+   host1x at 5000 {
+   dsi at 5430 {
+   status = "okay";
+
+   vdd-supply = <_1v2_ap>;
+
+   panel at 0 {
+   compatible = "lg,lh500wx1-sd03";
+   reg = <0>;
+
+   power-supply = <_lcd>;
+   backlight = <>;
+   };
+   };
+   };
+
pinmux at 7868 {
pinctrl-names = "default";
pinctrl-0 = <_default>;
@@ -811,7 +827,6 @@
regulator-name = "vdd-1v8";
regulator-min-microvolt = 
<180>;
regulator-max-microvolt = 
<180>;
-   regulator-always-on;
regulator-boot-on;
};

@@ -858,10 +873,11 @@
regulator-name = 
"vdd-2v8-display";
regulator-min-microvolt = 
<280>;
regulator-max-microvolt = 
<280>;
+   regulator-always-on;
regulator-boot-on;
};

-   ldo3 {
+   vdd_1v2_ap: ldo3 {
regulator-name = "avdd-1v2";
regulator-min-microvolt = 
<120>;
regulator-max-microvolt = 
<120>;
@@ -1048,7 +1064,7 @@
regulator-boot-on;
};

-   regulator at 1 {
+   vdd_lcd: regulator at 1 {
compatible = "regulator-fixed";
reg = <1>;
regulator-name = "vdd_lcd_1v8";
-- 
2.0.0

[PATCH 4/4] ARM: tegra: roth: add display DT node

2014-07-03 Thread Alexandre Courbot

On 07/03/2014 12:55 AM, Stephen Warren wrote:
> On 07/02/2014 06:19 AM, Alexandre Courbot wrote:
>> DSI support has been fixed to support continuous clock behavior that the
>> panel used on SHIELD requires, so finally add its device tree node since
>> it is functional.
>
>> diff --git a/arch/arm/boot/dts/tegra114-roth.dts 
>> b/arch/arm/boot/dts/tegra114-roth.dts
>
>> +host1x at 5000 {
>> +dsi at 5430 {
>
> That node looks fine, but I wonder why we need to mark a bunch of
> regulators as always-on? shouldn't the references to vdd-supply and
> power-supply from this node be enough? If not, perhaps the tree
> structure of the regulators isn't correct, or the DSI or panel bindings
> don't allow enough regulators to be referenced?

regulator-always-on is indeed not needed for vdd_lcd. I actually had a 
patch in my tree removing this line that I forgot to squash. Will post a 
v2 for this patch that fixes this, thanks.

vdd-2v8-display needs to remain always-on however. Here we may hit a 
limitation of the simple-panel driver, where only one power supply can 
be provided.

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

2014-07-03 Thread Mark Brown

On Thu, Jul 03, 2014 at 07:49:59AM +0200, Jean-Francois Moine wrote:
> Mark Brown  wrote:

> > I'd expect this to return an error for the busy DAI rather than just
> > silently ignore it failing to start or (better) implement some control
> > to let the user select which of the DAIs is active.

> This is not an error. If the audio subsystem (DPCM, not the user)
> chooses to activate both I2S and S/PDIF, this means the HDMI audio may
> be taken either from I2S or from S/PDIF: both inputs have the right
> format and rate.

Your board happens to only be able to present the same input on both I2S
and S/PDIF but that might not apply to other boards, they may be able to
route different signals to each which would present a practical problem.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/d93d80ab/attachment-0001.sig>

[PATCH v3 0/8] component helper improvements

On Thu, Jul 03, 2014 at 01:51:19AM +0200, Laurent Pinchart wrote:
> On Wednesday 02 July 2014 15:59:04 Russell King - ARM Linux wrote:
> > On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote:
> > > A while back, Laurent raised some comments about the component helper,
> > > which this patch set starts to address.
> > 
> > I looked back over the two other times which this series has posted,
> > and noticed that two patches had been reviewed, so I've added those
> > tags.
> > 
> > Unless there's any objections from anyone, I'll send the first three
> > off to Greg either tonight or tomorrow night, which at least gets us
> > moving forward on this.
> > 
> > If anyone has any objections, please shout ASAP.  Thanks.
> 
> No objection from my side at all, this is a nice improvement. For the first 
> three patches,
> 
> Acked-by: Laurent Pinchart 

Thanks, ack added.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PULL] drm-intel-fixes

2014-07-03 Thread Jani Nikula


Hi Dave -

Fixes for 3.16-rc3; most importantly Jesse brings back VGA he took away
on a bunch of machines. Also a vblank fix for BDW and a power workaround
fix for VLV.

BR,
Jani.

The following changes since commit 8525a235c96a548873c6c5644f50df32b31f04c6:

  drm/i915: vlv_prepare_pll is only needed in case of non DSI interfaces 
(2014-06-25 11:22:18 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-07-03

for you to fetch changes up to 5549d25f642a7e6cfb8744d0031a9da404f696d6:

  drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin 
(2014-07-01 11:43:14 +0300)


Deepak S (1):
  drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin

Jesse Barnes (1):
  drm/i915: only apply crt_present check on VLV

Ville Syrj?l? (1):
  drm/i915: Wait for vblank after enabling the primary plane on BDW

 drivers/gpu/drm/i915/intel_display.c | 27 ++-
 drivers/gpu/drm/i915/intel_pm.c  |  8 
 drivers/gpu/drm/i915/intel_sprite.c  |  8 
 3 files changed, 42 insertions(+), 1 deletion(-)


-- 
Jani Nikula, Intel Open Source Technology Center

drm: Possible NULL ptr exceptions in other DRM drivers

2014-07-03 Thread Krzysztof Kozlowski

Hi,

In Exynos DRM driver I found a NULL pointer exception when there were no
components set for DRM driver:
https://lkml.org/lkml/2014/6/30/331

The NULL pointer will happen during driver suspend if drm_driver.load()
is not called. The load() won't be called if no components are added.

After looking at other DRM drivers it seems that they may also be
affected by this issue. Some possible candidates (for my amateur's eyes)
are:
1. vmwgfx/vmwgfx_drv.c (vmw_pci_suspend: dereference of 'dev_priv')
2. qxl/qxl_drv.c (qxl_drm_freeze: dereference of 'qdev')
3. nouveau/nouveau_drm.c (nouveau_do_suspend: dereference of 'drm')
4. msm/msm_drv.c (msm_pm_suspend: dereference of 'ddev')
5. cirrus/cirrus_drv.c (cirrus_pm_suspend: dereference of 'cdev')
6. bochs/bochs_drv.c (bochs_pm_suspend: dereference of 'bochs')

Unfortunately I am not familiar with DRM drivers and I do not have
hardware to test it.

Maybe it is worth looking at?

Best regards,
Krzysztof

[PATCH 1/4] drm/dsi: Add flag for continuous clock behavior


Hi Alexandre,

Thanks for the patch.

On 07/02/2014 02:19 PM, Alexandre Courbot wrote:
> As per section 5.6.1 of the DSI specification, all DSI transmitters must
> support continuous clock behavior on the clock lane, while non-continuous
> mode support is only optional. Add a flag that allows devices to indicate
> that they require continuous clock mode to operate properly.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  include/drm/drm_mipi_dsi.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 944f33f..5913ef4 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -94,6 +94,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
>  #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8)
>  /* disable EoT packets in HS mode */
>  #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> +/* use continuous clock behavior on the clock lane */
> +#define MIPI_DSI_MODE_CLOCK_CONTINUOUS   BIT(10)
>  

According to MIPI DSI specification "All DSI transmitters and receivers
shall support continuous clock behavior on the Clock Lane, and
optionally may support non-continuous clock behavior". It suggests that
continuous clock should be default behavior. So maybe better is to
introduce sth like:
+#define MIPI_DSI_MODE_CLOCK_NON_CONTINUOUS BIT(10)


Regards
Andrzej

[RFC] drm/msm: DT support for 8960/8064

2014-07-03 Thread Mark Rutland

On Wed, Jul 02, 2014 at 10:01:40PM +0100, Rob Clark wrote:
> On Wed, Jul 2, 2014 at 2:09 PM, Mark Rutland  wrote:
> > On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote:
> >> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
> >> add necessary DT support so that we can use drm/msm on upstream kernel.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >> Commence bikeshedding :-)
> >>
> >>  Documentation/devicetree/bindings/drm/msm/gpu.txt  | 51 
> >> 
> >>  Documentation/devicetree/bindings/drm/msm/hdmi.txt | 43 +
> >>  Documentation/devicetree/bindings/drm/msm/msm.txt  | 40 
> >>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  2 +
> >>  drivers/gpu/drm/msm/hdmi/hdmi.c| 55 
> >> ++
> >>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 10 ++--
> >>  drivers/gpu/drm/msm/msm_drv.c  | 29 ++--
> >>  7 files changed, 204 insertions(+), 26 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/drm/msm/gpu.txt
> >>  create mode 100644 Documentation/devicetree/bindings/drm/msm/hdmi.txt
> >>  create mode 100644 Documentation/devicetree/bindings/drm/msm/msm.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt 
> >> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
> >> new file mode 100644
> >> index 000..6e33efe
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt
> >> @@ -0,0 +1,51 @@
> >> +Qualcomm adreno/snapdragon GPU
> >> +
> >> +Required properties:
> >> +- compatible: "qcom,adreno-3xx"
> >
> > As Olof said, choose a definite name here, and have variants claim
> > compatibility with that in addition to a variant specific string.
> >
> >> +- reg: Physical base address and length of the controller's registers.
> >
> > Just the one reg entry?
> 
> as far as I know.. keep in mind, I'm working without docs

Sure. If we only know about one reg entrty that's fine.

> 
> > The example has reg-names. Either document the name or drop it.
> >
> >> +- interrupts: The interrupt outputs from the controller.
> >
> > How many? Which ones? Names?
> >
> >> +- clocks: device clocks
> >> +  See ../clocks/clock-bindings.txt for details.
> >
> > Similarly?
> >
> > I should be able to read the binding and put together a DTS. Currently I
> > cannot.
> >
> >> +- qcom,chipid: gpu chip-id.  Note this may become optional for future
> >> +  devices if we can reliably read the chipid from hw
> >
> > What's the problem with reading chipid from HW at the moment?
> >
> > Should this possibly be optional, and only if not possible to read from
> > HW?
> 
> As far as I can tell from diving downstream android kgsl code, seems
> like some a2xx you might be able to read the value from hw.  Beyond
> that I'm not entirely sure.  (Remember, no docs.)
> 
> I'm leaving it as-is and if someone who has docs wants to submit patch
> to change it, that is fine.

My concern is that the statement "this may become optional" is useless,
as it doesn't tell you what expected if it's not present.

I would reword this as:

- qcom,chip-id: The gpu chip-id, if the hardware value is not reliable.

And then read from the HW if it's not present.

> >> +- qcom,gpu-pwrlevels: array of OPPs, sorted highest to lowest
> >
> > This is confusing. This is a node rather than a property, and in general
> > it's not a good idea to rely on node ordering (there's no such thing as
> > an array of nodes in the DTB).
> >
> >> +  - compatible: "qcom,gpu-pwrlevels"
> >> +  - for each qcom,gpu-pwrlevel:
> >
> > Is that a compatible string for each node, name, or what?
> >
> > Any reason for having this as a container node at all?
> 
> some of the decisions are made to make it easier to re-use/support
> existing bindings in downstream kernel..

I don't see why we should be beholden to downstream kernel bindings.

> 
> >> +- qcom,gpu-freq: requested gpu clock speed
> >> +- NOTE: downstream android driver defines additional parameters to
> >> +  configure memory bandwidth scaling per OPP.
> >
> > So? Either define those or don't bother. Having a halfway house binding
> > is not helpful.
> 
> I'm not really in a position to document them at this point, sorry.

Then drop it.

> >> +
> >> +Optional properties:
> >> +- n/a
> >
> > Drop this if there are no optional properties.
> >
> >> +
> >> +Example:
> >> +
> >> +/ {
> >> +   ...
> >> +
> >> +   gpu: qcom,kgsl-3d0 at 430 {
> >> +   compatible = "qcom,adreno-3xx";
> >> +   reg = <0x0430 0x2>;
> >> +   reg-names = "kgsl_3d0_reg_memory";
> >> +   interrupts = ;
> >> +   interrupt-names = "kgsl_3d0_irq";
> >> +   clock-names =
> >> +   "core_clk",
> >> +   "iface_clk",
> >> +   "mem_iface_clk";
> >> +   clocks =
> >> +   < GFX3D_CLK>,
> >> +

[RE-RESEND PATCH] vgaarb: We can own non-decoded resources

2014-07-03 Thread Alex Williamson

The VGA arbiter does not allow devices to "own" resources that it
doesn't "decode".  However, it does allow devices to "lock" resources
that it doesn't decode.  This gets us into trouble because locking
the resource goes through the same bridge routing updates regardless
of whether we decode the resource.  This means that when a non-decoded
resource is released, the bridge is left with VGA routing enabled and
locking a different device won't clear it.

This happens in the following scenario:

VGA device 01:00.0 (VGA1) is owned by the radeon driver, which
registers a set_vga_decode function which releases legacy VGA decodes.

VGA device 02:00.0 (VGA2) is any VGA device.

VGA1 user locks VGA resources triggering first_use callback of
set_vga_decoded, clearing "decode" and "owns" of legacy resources
on VGA1.

VGA1 user unlocks VGA resources.

VGA2 user locks VGA resources, which skips VGA1 as conflicting as it
does not "own" legacy resources, although VGA routing is still enabled
for the VGA1 bridge.  VGA routing is enabled on VGA2 bridge.

VGA2 may or may not receive VGA transactions depending on the bus
priority of VGA1 vs VGA2 bridge.

To resolve this, we need to allow devices to "own" resources that they
do not "decode".  This way we can track bus ownership of VGA.  When a
device decodes VGA, it only means that we must update the command bits
in cases where the conflicting device is on the same bus.

Signed-off-by: Alex Williamson 
Cc: Ville Syrj?l? 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---

Can someone please claim ownership of vgaarb?

 drivers/gpu/vga/vgaarb.c |   40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index af02597..d2077f0 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -237,12 +237,10 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
if (conflict->locks & lwants)
return conflict;

-   /* Ok, now check if he owns the resource we want. We don't need
-* to check "decodes" since it should be impossible to own
-* own legacy resources you don't decode unless I have a bug
-* in this code...
+   /* Ok, now check if it owns the resource we want.  We can
+* lock resources that are not decoded, therefore a device
+* can own resources it doesn't decode.
 */
-   WARN_ON(conflict->owns & ~conflict->decodes);
match = lwants & conflict->owns;
if (!match)
continue;
@@ -254,13 +252,19 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,
flags = 0;
pci_bits = 0;

+   /* If we can't control legacy resources via the bridge, we
+* also need to disable normal decoding.
+*/
if (!conflict->bridge_has_one_vga) {
-   vga_irq_set_state(conflict, false);
-   flags |= PCI_VGA_STATE_CHANGE_DECODES;
-   if (match & (VGA_RSRC_LEGACY_MEM|VGA_RSRC_NORMAL_MEM))
+   if ((match & conflict->decodes) & VGA_RSRC_LEGACY_MEM)
pci_bits |= PCI_COMMAND_MEMORY;
-   if (match & (VGA_RSRC_LEGACY_IO|VGA_RSRC_NORMAL_IO))
+   if ((match & conflict->decodes) & VGA_RSRC_LEGACY_IO)
pci_bits |= PCI_COMMAND_IO;
+
+   if (pci_bits) {
+   vga_irq_set_state(conflict, false);
+   flags |= PCI_VGA_STATE_CHANGE_DECODES;
+   }
}

if (change_bridge)
@@ -268,18 +272,19 @@ static struct vga_device *__vga_tryget(struct vga_device 
*vgadev,

pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
conflict->owns &= ~match;
-   /* If he also owned non-legacy, that is no longer the case */
-   if (match & VGA_RSRC_LEGACY_MEM)
+
+   /* If we disabled normal decoding, reflect it in owns */
+   if (pci_bits & PCI_COMMAND_MEMORY)
conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
-   if (match & VGA_RSRC_LEGACY_IO)
+   if (pci_bits & PCI_COMMAND_IO)
conflict->owns &= ~VGA_RSRC_NORMAL_IO;
}

 enable_them:
/* ok dude, we got it, everybody conflicting has been disabled, let's
-* enable us. Make sure we don't mark a bit in "owns" that we don't
-* also have in "decodes". We can lock resources we don't decode but
-* not own them.
+* enable us.  Mark any bits in "owns" regardless of whether we
+* decoded them.  We can lock resources we don't decode, therefore
+* we must track

[PATCH] drm/vmwgfx: Fix incorrect write to read-only register

2014-07-03 Thread Thomas Hellstrom

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

There has been some reports of incorrect rendering with the mentioned commit
and Ubuntu 12.04. While hard to reproduce, hopefully this patch will correct
that issue.

Cc: stable at vger.kernel.org
Cc: Christopher Friedt 
Tested-by: Christopher Friedt 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index a89ad93..b031b48 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -179,7 +179,6 @@ static int vmw_fb_set_par(struct fb_info *info)
vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_Y, 
info->var.yoffset);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_WIDTH, info->var.xres);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_HEIGHT, info->var.yres);
-   vmw_write(vmw_priv, SVGA_REG_BYTES_PER_LINE, 
info->fix.line_length);
vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
}

-- 
1.8.3.2

[PATCH] drm/ttm: fix handling of TTM_PL_FLAG_TOPDOWN v2

2014-07-03 Thread Christian König

From: Christian K?nig 

bo->mem.placement is not initialized when ttm_bo_man_get_node is called,
so the flag had no effect at all.

v2: change nouveau and vmwgfx as well

Signed-off-by: Christian K?nig 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 3 +++
 drivers/gpu/drm/ttm/ttm_bo.c  | 6 +++---
 drivers/gpu/drm/ttm/ttm_bo_manager.c  | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 1 +
 include/drm/ttm/ttm_bo_driver.h   | 2 ++
 5 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index ab0228f..7e185c1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -76,6 +76,7 @@ static int
 nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
 struct ttm_buffer_object *bo,
 struct ttm_placement *placement,
+uint32_t flags,
 struct ttm_mem_reg *mem)
 {
struct nouveau_drm *drm = nouveau_bdev(man->bdev);
@@ -162,6 +163,7 @@ static int
 nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
 struct ttm_buffer_object *bo,
 struct ttm_placement *placement,
+uint32_t flags,
 struct ttm_mem_reg *mem)
 {
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
@@ -242,6 +244,7 @@ static int
 nv04_gart_manager_new(struct ttm_mem_type_manager *man,
  struct ttm_buffer_object *bo,
  struct ttm_placement *placement,
+ uint32_t flags,
  struct ttm_mem_reg *mem)
 {
struct nouveau_mem *node;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4ab9f71..a13a100 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -784,7 +784,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
int ret;

do {
-   ret = (*man->func->get_node)(man, bo, placement, mem);
+   ret = (*man->func->get_node)(man, bo, placement, 0, mem);
if (unlikely(ret != 0))
return ret;
if (mem->mm_node)
@@ -897,7 +897,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,

if (man->has_type && man->use_type) {
type_found = true;
-   ret = (*man->func->get_node)(man, bo, placement, mem);
+   ret = (*man->func->get_node)(man, bo, placement,
+cur_flags, mem);
if (unlikely(ret))
return ret;
}
@@ -937,7 +938,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
ttm_flag_masked(_flags, placement->busy_placement[i],
~TTM_PL_MASK_MEMTYPE);

-
if (mem_type == TTM_PL_SYSTEM) {
mem->mem_type = mem_type;
mem->placement = cur_flags;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index bd850c9..9e103a48 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -50,6 +50,7 @@ struct ttm_range_manager {
 static int ttm_bo_man_get_node(struct ttm_mem_type_manager *man,
   struct ttm_buffer_object *bo,
   struct ttm_placement *placement,
+  uint32_t flags,
   struct ttm_mem_reg *mem)
 {
struct ttm_range_manager *rman = (struct ttm_range_manager *) man->priv;
@@ -67,7 +68,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager 
*man,
if (!node)
return -ENOMEM;

-   if (bo->mem.placement & TTM_PL_FLAG_TOPDOWN)
+   if (flags & TTM_PL_FLAG_TOPDOWN)
aflags = DRM_MM_CREATE_TOP;

spin_lock(>lock);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index b1273e8..26f8bdd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -47,6 +47,7 @@ struct vmwgfx_gmrid_man {
 static int vmw_gmrid_man_get_node(struct ttm_mem_type_manager *man,
  struct ttm_buffer_object *bo,
  struct ttm_placement *placement,
+ uint32_t flags,
  struct ttm_mem_reg *mem)
 {
struct vmwgfx_gmrid_man *gman =
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index a5183da..f2fcd3e 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -182,6 +182,7 @@ struct

[PATCH 15/15] drm/omap: Add infoframe & dvi/hdmi mode support

2014-07-03 Thread Tomi Valkeinen

On 24/06/14 13:04, Tomi Valkeinen wrote:
> Make the omapdrm driver use the new HDMI ops when possible.
> 
> omapdrm will call set_hdmi_mode (when available) to tell the encoder
> driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
> monitor, omapdrm will call set_hdmi_infoframe to to set the AVI
> infoframe.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: Rob Clark 
> ---
>  drivers/gpu/drm/omapdrm/omap_connector.c | 12 
>  drivers/gpu/drm/omapdrm/omap_drv.h   |  1 +
>  drivers/gpu/drm/omapdrm/omap_encoder.c   | 27 +++
>  3 files changed, 40 insertions(+)

Ah, I forgot to add dri-devel list for this one.

Dave, is it ok if I queue this one via fbdev tree, as it depends on the
previous patches on this series?

 Tomi

> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
> b/drivers/gpu/drm/omapdrm/omap_connector.c
> index 86f4ead0441d..19492cd31f10 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -32,8 +32,16 @@ struct omap_connector {
>   struct drm_connector base;
>   struct omap_dss_device *dssdev;
>   struct drm_encoder *encoder;
> + bool hdmi_mode;
>  };
>  
> +bool omap_connector_get_hdmi_mode(struct drm_connector *connector)
> +{
> + struct omap_connector *omap_connector = to_omap_connector(connector);
> +
> + return omap_connector->hdmi_mode;
> +}
> +
>  void copy_timings_omap_to_drm(struct drm_display_mode *mode,
>   struct omap_video_timings *timings)
>  {
> @@ -162,10 +170,14 @@ static int omap_connector_get_modes(struct 
> drm_connector *connector)
>   drm_mode_connector_update_edid_property(
>   connector, edid);
>   n = drm_add_edid_modes(connector, edid);
> +
> + omap_connector->hdmi_mode =
> + drm_detect_hdmi_monitor(edid);
>   } else {
>   drm_mode_connector_update_edid_property(
>   connector, NULL);
>   }
> +
>   kfree(edid);
>   } else {
>   struct drm_display_mode *mode = drm_mode_create(dev);
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> index 284b80fc3c54..c204c1e7ce87 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -194,6 +194,7 @@ struct drm_encoder *omap_connector_attached_encoder(
>   struct drm_connector *connector);
>  void omap_connector_flush(struct drm_connector *connector,
>   int x, int y, int w, int h);
> +bool omap_connector_get_hdmi_mode(struct drm_connector *connector);
>  
>  void copy_timings_omap_to_drm(struct drm_display_mode *mode,
>   struct omap_video_timings *timings);
> diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
> b/drivers/gpu/drm/omapdrm/omap_encoder.c
> index 5290a88c681d..7445fb1491ae 100644
> --- a/drivers/gpu/drm/omapdrm/omap_encoder.c
> +++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
> @@ -17,6 +17,8 @@
>   * this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include 
> +
>  #include "omap_drv.h"
>  
>  #include "drm_crtc.h"
> @@ -89,6 +91,31 @@ static void omap_encoder_mode_set(struct drm_encoder 
> *encoder,
>   struct drm_display_mode *mode,
>   struct drm_display_mode *adjusted_mode)
>  {
> + struct drm_device *dev = encoder->dev;
> + struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
> + struct omap_dss_device *dssdev = omap_encoder->dssdev;
> + struct drm_connector *connector;
> + bool hdmi_mode;
> + int r;
> +
> + hdmi_mode = false;
> + list_for_each_entry(connector, >mode_config.connector_list, head) {
> + if (connector->encoder == encoder) {
> + hdmi_mode = omap_connector_get_hdmi_mode(connector);
> + break;
> + }
> + }
> +
> + if (dssdev->driver->set_hdmi_mode)
> + dssdev->driver->set_hdmi_mode(dssdev, hdmi_mode);
> +
> + if (hdmi_mode && dssdev->driver->set_hdmi_infoframe) {
> + struct hdmi_avi_infoframe avi;
> +
> + r = drm_hdmi_avi_infoframe_from_display_mode(, 
> adjusted_mode);
> + if (r == 0)
> + dssdev->driver->set_hdmi_infoframe(dssdev, );
> + }
>  }
>  
>  static void omap_encoder_prepare(struct drm_encoder *encoder)
> 


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140703/abe2d6f8/attachment-0001.sig>

[PATCH] drm/radeon: page table BOs are kernel allocations

2014-07-03 Thread Christian König

Am 02.07.2014 21:53, schrieb Alex Deucher:
> On Wed, Jul 2, 2014 at 3:28 PM, Christian K?nig  
> wrote:
>> From: Christian K?nig 
>>
>> Userspace shouldn't be able to access them.
>>
>> Signed-off-by: Christian K?nig 
>> Cc: stable at vger.kernel.org
> I assume this is for 3.15.  I had to tweak it slightly for 3.16.

Yeah, I've created the patch on a 3.15 branch. Didn't realized that we 
need to change it slightly for 3.16.

> Reviewed-by: Alex Deucher 

Thanks,
Christian.

>
>> ---
>>   drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
>> b/drivers/gpu/drm/radeon/radeon_vm.c
>> index c11b71d..c8c48aa 100644
>> --- a/drivers/gpu/drm/radeon/radeon_vm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
>> @@ -493,7 +493,7 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
>>  mutex_unlock(>mutex);
>>
>>  r = radeon_bo_create(rdev, RADEON_VM_PTE_COUNT * 8,
>> -RADEON_GPU_PAGE_SIZE, false,
>> +RADEON_GPU_PAGE_SIZE, true,
>>   RADEON_GEM_DOMAIN_VRAM, NULL, );
>>  if (r)
>>  return r;
>> @@ -913,7 +913,7 @@ int radeon_vm_init(struct radeon_device *rdev, struct 
>> radeon_vm *vm)
>>  return -ENOMEM;
>>  }
>>
>> -   r = radeon_bo_create(rdev, pd_size, RADEON_VM_PTB_ALIGN_SIZE, false,
>> +   r = radeon_bo_create(rdev, pd_size, RADEON_VM_PTB_ALIGN_SIZE, true,
>>   RADEON_GEM_DOMAIN_VRAM, NULL,
>>   >page_directory);
>>  if (r)
>> --
>> 1.9.1
>>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

2014-07-03 Thread Christian König

Am 03.07.2014 05:48, schrieb Michel D?nzer:
> On 03.07.2014 04:31, Christian K?nig wrote:
>>> FWIW, I've also had successful runs with the first three of the split
>>> changes, and with all of them.
>> Ok I've just pushed a branch testing-3.15-v3 to fdo which moves all page
>> table allocation to the end of VRAM. Please try with this memory layout,
>> it should give us a good idea if it's indeed a memory corruption or
>> something else.
> That branch just survived piglit as well.

Ok, so it's probably not an alignment issue but indeed a memory 
corruption (crap, the former would be easier to fix).

>> Apart from that please try to lockup your system with
>> radeon.lockup_timeout=0 on the kernel commandline and then try to get a
>> dump of the vm page tables with the script I've send to you in one of
>> the mails.
> Any preference for which changes of which branch I should try this with?
> E.g. with the two overalignment changes from testing-3.15-v2?

Just a blank 3.15 should be sufficient, I just want to take a look at 
the hexdump of the page tables to figure out what kind of memory 
corruption we have here.

Thanks,
Christian.

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

--- Comment #20 from dex+fdobugzilla at dragonslave.de ---
I can confirm: drm-next-3.17-wip + new ucode doesn't make any difference.

Testscenario:

* Built/Installed new kernel, copied new ucode into /lib/firmware
* Built new initrd
* reboot with "nomodeset" and gfxpayload=text into multi user runlevel
* modprobe radeon drm=1 modeset=1

Monitor went black (but shows connected DVI), system is unresponsive.

-- 
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/20140703/0ece015a/attachment-0001.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #63 from Michel D?nzer  ---
(In reply to perry3d from comment #61)
> Things are getting worse. Now i got a kernel panic.

That panic is fixed in the current drm-fixes trees, and hopefully soon in
Linus' tree.

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #62 from perry3d at gmail.com ---
Created attachment 142011
  --> https://bugzilla.kernel.org/attachment.cgi?id=142011=edit
jounralctl -k before kernel panic

I also get crashes of the snd_hda module as you can see in the log.

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

2014-07-03 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #61 from perry3d at gmail.com ---
Created attachment 142001
  --> https://bugzilla.kernel.org/attachment.cgi?id=142001=edit
Kernel panic

Things are getting worse. Now i got a kernel panic. But i was able to take a
picture of the stack trace.

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

[PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Wed, 2 Jul 2014 20:42:52 +0100
Mark Brown  wrote:

> > I tested this CODEC with both DAPM and DPCM. If the audio subsystem
> > asks for streaming on both I2S and S/PDIF, only the last call is served
> > (this depends on the order of the DAI links in the audio card creation
> > table).  
> 
> I'd expect this to return an error for the busy DAI rather than just
> silently ignore it failing to start or (better) implement some control
> to let the user select which of the DAIs is active.

Mark,

This is not an error. If the audio subsystem (DPCM, not the user)
chooses to activate both I2S and S/PDIF, this means the HDMI audio may
be taken either from I2S or from S/PDIF: both inputs have the right
format and rate.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

--- Comment #117 from Marc  ---
Same here, no freeze with this patch for 24h so it looks this bug might be
fixed. I'll confirm again at the end of the day.

-- 
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/20140703/ffd3f259/attachment.html>

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

2014-07-03 Thread Andreas Färber

Hi Ajay,

Thanks a lot for your work on this.

Am 11.06.2014 20:26, schrieb Ajay Kumar:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
> 
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.

Unfortunately this series per se does not yet fix my display issues on
the Spring Chromebook. Can you share what dt changes you made for Snow?

Before, if the dp-controller dt node was present, I would get a dark
screen immediately and I could ssh into the system shortly after.
I worked around that by commenting the node out, which would allow me to
graphically boot pretty much instantly.

With these 10 patches applied on top of my dt on top of kgene's tree,
the last U-Boot screen stays visible for ~50 seconds, then the screen
goes blank, and I can ssh in some time later.
If I comment out the dp-controller node again, it takes long for the
kernel boot to graphically proceed but works okay then.
In both cases there's a gap of ~2900 seconds visible in dmesg.

Is presence of a framebuffer dt node or U-Boot not disabling FIMD
interfering here, i.e. do I need to replace nv U-Boot? Or do I need to
cherry-pick any preparatory patches from exynos-drm-next?

I'm building with LPAE, but the only two warnings in drm code I see are
about a NULL cast to dma_addr_t and a %x in debug code, which I consider
non-critical (but would be nice if Inki could silence them).

Regards,
Andreas

https://github.com/afaerber/linux/commits/spring-next
https://github.com/afaerber/u-boot/commits/spring

w/ dp-controller:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc2+ (andreas at chrome11.site) (gcc
version 4.
8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #8 SMP
PREEMPT Thu
Jul 3 05:56:13 CEST 2014
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7),
cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
cache
[0.00] Machine model: Google Spring
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 523264
[0.00] free_area_init_node: node 0, pgdat c0659dc0, node_mem_map
ee7fc00
0
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 2568 pages used for memmap
[0.00]   HighMem zone: 328704 pages, LIFO batch:31
[0.00] PERCPU: Embedded 7 pages/cpu @ee7bb000 s7104 r8192 d13376
u32768
[0.00] pcpu-alloc: s7104 r8192 d13376 u32768 alloc=8*4096
[0.00] pcpu-alloc: [0] 0 [0] 1
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pag
es: 521744
[0.00] Kernel command line: console=tty1 root=/dev/sda3
rootfstype=ext4
rw rootwait clk_ignore_unused
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 2068780K/2093056K available (4454K kernel code,
258K rwdata, 1480K rodata, 278K init, 281K bss, 24276K reserved,
1314816K highmem)
[0.00] Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xffe0   (2048 kB)
vmalloc : 0xf000 - 0xff00   ( 240 MB)
lowmem  : 0xc000 - 0xef80   ( 760 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc05d3dd4   (5936 kB)
  .init : 0xc05d4000 - 0xc0619bc0   ( 279 kB)
  .data : 0xc061a000 - 0xc065a9e0   ( 259 kB)
   .bss : 0xc065a9ec - 0xc06a1080   ( 282 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L2C: failed to init: -19
[0.00] Exynos5250: clock setup completed, armclk=17
[0.00] Architected cp15 timer(s) running at 24.00MHz (virt).
[0.02] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
every 2863311519744ns
[0.07] Switching to timer-based delay loop
[ 2869.295699] sched_clock: 64 bits at 24MHz, resolution 41ns, wraps
every 2863311519744ns
[ 2869.295841] Console: colour dummy device 80x30
[ 2869.296042] console [tty1] enabled
[ 2869.296056] Calibrating delay loop (skipped), value calculated using
timer frequency.. 48.00 BogoMIPS (lpj=12)
[ 2869.296073] pid_max: default: 32768 minimum: 301
[ 2869.296160] Mount-cache hash table entries: 2048 (order: 1, 8192

[RFC] drm/msm: DT support for 8960/8064

On Thu, Jul 3, 2014 at 5:15 AM, Mark Rutland  wrote:
> On Wed, Jul 02, 2014 at 10:01:40PM +0100, Rob Clark wrote:
>> On Wed, Jul 2, 2014 at 2:09 PM, Mark Rutland  wrote:
>> > On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote:
>> >> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
>> >> add necessary DT support so that we can use drm/msm on upstream kernel.
>> >>
>> >> Signed-off-by: Rob Clark 
>> >> ---
>> >> Commence bikeshedding :-)
>> >>
>> >>  Documentation/devicetree/bindings/drm/msm/gpu.txt  | 51 
>> >> 
>> >>  Documentation/devicetree/bindings/drm/msm/hdmi.txt | 43 +
>> >>  Documentation/devicetree/bindings/drm/msm/msm.txt  | 40 
>> >>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  2 +
>> >>  drivers/gpu/drm/msm/hdmi/hdmi.c| 55 
>> >> ++
>> >>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 10 ++--
>> >>  drivers/gpu/drm/msm/msm_drv.c  | 29 ++--
>> >>  7 files changed, 204 insertions(+), 26 deletions(-)
>> >>  create mode 100644 Documentation/devicetree/bindings/drm/msm/gpu.txt
>> >>  create mode 100644 Documentation/devicetree/bindings/drm/msm/hdmi.txt
>> >>  create mode 100644 Documentation/devicetree/bindings/drm/msm/msm.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt 
>> >> b/Documentation/devicetree/bindings/drm/msm/gpu.txt
>> >> new file mode 100644
>> >> index 000..6e33efe
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt
>> >> @@ -0,0 +1,51 @@
>> >> +Qualcomm adreno/snapdragon GPU
>> >> +
>> >> +Required properties:
>> >> +- compatible: "qcom,adreno-3xx"
>> >
>> > As Olof said, choose a definite name here, and have variants claim
>> > compatibility with that in addition to a variant specific string.
>> >
>> >> +- reg: Physical base address and length of the controller's registers.
>> >
>> > Just the one reg entry?
>>
>> as far as I know.. keep in mind, I'm working without docs
>
> Sure. If we only know about one reg entrty that's fine.
>
>>
>> > The example has reg-names. Either document the name or drop it.
>> >
>> >> +- interrupts: The interrupt outputs from the controller.
>> >
>> > How many? Which ones? Names?
>> >
>> >> +- clocks: device clocks
>> >> +  See ../clocks/clock-bindings.txt for details.
>> >
>> > Similarly?
>> >
>> > I should be able to read the binding and put together a DTS. Currently I
>> > cannot.
>> >
>> >> +- qcom,chipid: gpu chip-id.  Note this may become optional for future
>> >> +  devices if we can reliably read the chipid from hw
>> >
>> > What's the problem with reading chipid from HW at the moment?
>> >
>> > Should this possibly be optional, and only if not possible to read from
>> > HW?
>>
>> As far as I can tell from diving downstream android kgsl code, seems
>> like some a2xx you might be able to read the value from hw.  Beyond
>> that I'm not entirely sure.  (Remember, no docs.)
>>
>> I'm leaving it as-is and if someone who has docs wants to submit patch
>> to change it, that is fine.
>
> My concern is that the statement "this may become optional" is useless,
> as it doesn't tell you what expected if it's not present.
>
> I would reword this as:
>
> - qcom,chip-id: The gpu chip-id, if the hardware value is not reliable.

yeah, ok.  That is more clear.

> And then read from the HW if it's not present.
>
>> >> +- qcom,gpu-pwrlevels: array of OPPs, sorted highest to lowest
>> >
>> > This is confusing. This is a node rather than a property, and in general
>> > it's not a good idea to rely on node ordering (there's no such thing as
>> > an array of nodes in the DTB).

btw, we don't actually rely on the ordering in the parsing code.
Although I think it is more readable if it is kept sorted.  So I
suppose consider that as more of a suggestion.

>> >
>> >> +  - compatible: "qcom,gpu-pwrlevels"
>> >> +  - for each qcom,gpu-pwrlevel:
>> >
>> > Is that a compatible string for each node, name, or what?
>> >
>> > Any reason for having this as a container node at all?
>>
>> some of the decisions are made to make it easier to re-use/support
>> existing bindings in downstream kernel..
>
> I don't see why we should be beholden to downstream kernel bindings.

Well, unfortunately since devices that run upstream kernel are few and
far between, I get to port upstream driver to more downstream device
kernels than I'd care to.  To simplify this, as much as possible I'd
like to share DT binding code.  The alternative is more error prone
and time consuming, and it's not exactly like I'm running out of
things to do.

>>
>> >> +- qcom,gpu-freq: requested gpu clock speed
>> >> +- NOTE: downstream android driver defines additional parameters to
>> >> +  configure memory bandwidth scaling per OPP.
>> >
>> > So? Either define those or don't bother. Having a halfway house binding
>> > is not helpful.
>>
>> I'm not really in a position to document

[Bug 80827] [radeonsi,R9 270X] Corruptions in window menus in KDE

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |zhigang.gong at gmail.com
   |.org|
Product|Mesa|xorg
  Component|Drivers/Gallium/radeonsi|Driver/glamor

--- Comment #3 from Michel D?nzer  ---
(In reply to comment #1)
> After quick bisecting, it looks like commit "radeonsi: Use dma_copy when
> possible for si_blit." (5d5c20920e0e570742a497aa047e99a2fa3c04f2) is
> responsible for that.

See bug 80787.

> When reverted, the full screen corruptions disappear, but window menu 
> corruptions still persist.

The kwin menu corruption is most likely a glamor bug. You can work around it by
selecting 'Raster' for the rendering engine in the kwin advanced desktop effect
preferences.

-- 
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/20140703/2ff7047a/attachment.html>

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

--- Comment #116 from Alexandre Demers  ---
Up until now, no problem encountered. The problem fixed by the patch would also
points in the same direction as some of my previous tests and supposions were
heading. I think this might really be our culprit.

Which means we should also be in a position to reenable Spread Spectrum if
everything continues to run smoothly.

I'll give you some updates tomorrow.

-- 
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/20140703/c16847e2/attachment.html>

[PATCH] drm/vmwgfx: Fix incorrect write to read-only register

2014-07-03 Thread Jakob Bornecrantz



- Original Message -
> Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
> vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
> SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
> SVGA_REG_PITCHLOCK.
> 
> There has been some reports of incorrect rendering with the mentioned commit
> and Ubuntu 12.04. While hard to reproduce, hopefully this patch will correct
> that issue.
> 
> Cc: stable at vger.kernel.org
> Cc: Christopher Friedt 
> Tested-by: Christopher Friedt 
> Signed-off-by: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Jakob Bornecrantz 

> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index a89ad93..b031b48 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -179,7 +179,6 @@ static int vmw_fb_set_par(struct fb_info *info)
>   vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_Y, 
> info->var.yoffset);
>   vmw_write(vmw_priv, SVGA_REG_DISPLAY_WIDTH, info->var.xres);
>   vmw_write(vmw_priv, SVGA_REG_DISPLAY_HEIGHT, info->var.yres);
> - vmw_write(vmw_priv, SVGA_REG_BYTES_PER_LINE, 
> info->fix.line_length);
>   vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
>   }
>  
> --
> 1.8.3.2
>

[PATCH v3 0/8] component helper improvements

2014-07-03 Thread Laurent Pinchart

Hi Russell,

Sorry for the late review.

On Wednesday 02 July 2014 15:59:04 Russell King - ARM Linux wrote:
> On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote:
> > A while back, Laurent raised some comments about the component helper,
> > which this patch set starts to address.
> 
> I looked back over the two other times which this series has posted,
> and noticed that two patches had been reviewed, so I've added those
> tags.
> 
> Unless there's any objections from anyone, I'll send the first three
> off to Greg either tonight or tomorrow night, which at least gets us
> moving forward on this.
> 
> If anyone has any objections, please shout ASAP.  Thanks.

No objection from my side at all, this is a nice improvement. For the first 
three patches,

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

--- Comment #34 from Michel D?nzer  ---
(In reply to comment #33)
> Does it help instead if i use R600_DUMP_SHADERS= 1 ?

I'm afraid not.

-- 
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/20140703/3aae7036/attachment.html>

[PATCH RFC v2 3/8] component: add support for component match array

2014-07-03 Thread Inki Dae

2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux :
> On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
>> > Hi Russell,
>> >
>> > On Tue, Jun 24, 2014 at 9:29 PM, Russell King
>> >  wrote:
>> > [...]
>> > > +/*
>> > > + * Add a component to be matched.
>> > > + *
>> > > + * The match array is first created or extended if necessary.
>> > > + */
>> > > +void component_match_add(struct device *dev, struct component_match 
>> > > **matchptr,
>> > > +   int (*compare)(struct device *, void *), void *compare_data)
>> > > +{
>> > > +   struct component_match *match = *matchptr;
>> > > +
>> > > +   if (IS_ERR(match))
>> > > +   return;
>> > > +
>> > > +   if (!match || match->num == match->alloc) {
>> > > +   size_t new_size = match ? match->alloc + 16 : 15;
>> > > +
>> > > +   match = component_match_realloc(dev, match, new_size);
>> > > +
>> > > +   *matchptr = match;
>> > > +
>> > > +   if (IS_ERR(match))
>> > > +   return;
>> > > +   }
>> > > +
>> > > +   match->compare[match->num].fn = compare;
>> > > +   match->compare[match->num].data = compare_data;
>> > > +   match->num++;
>> > > +}
>> >
>> > component_match_add should be exported.
>>
>> Fixed, thanks.
>
> As there's no further comments, and Inki Dae has not responded, I'm

It's has been just a week. I will check and look into your patch
series. I think Exynos drm should also be considered for the use of
component match array.

Thanks,
Inki Dae

> going to send these out without the RFC tag in the hope that people
> will provide acks.  This allows us to move forward with this despite
> the Exynos DRM blockage.
>
> The ultimate plan is for patches 1 to 3 inclusive to be merged into
> Greg's driver tree, 1 to 3 and 5 into Greg's staging tree, and 1 to
> 3 and 4 for David Airlie's DRM tree - patches 1 to 3 are needed for
> both patches 4 and 5.
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] exynos: Put a stop to the userptr heresy.

2014-07-03 Thread Inki Dae

2014-07-02 0:03 GMT+09:00 Jerome Glisse :
> On Tue, Jul 01, 2014 at 05:55:25PM +0900, Inki Dae wrote:
>>
>> Hi Jerome,
>>
>>
>> On 2014? 07? 01? 06:46, j.glisse at gmail.com wrote:
>> > From: Jerome Glisse 
>> >
>> > get_user_pages gives no garanty that page it returns are still
>> > the one backing the vma by the time it returns. Thus any ioctl
>>
>> One of pages from get_user_pages() could be migrated? I think all the
>> pages are pinned so that they cannot be migrated. If not such case, is
>> there other case I missed?
>
> I thought the ksm or gdb path were forcing unmap and replace but they
> still abide by the pin so while page will not be replace you are still
> violating few things. First you are pining memory without any kind of
> accouting from memcg point of view hence userspace can use that as a
> vector of attack to deplete memory.

Hm... right. The attack vector could deplete of system memory because
g2d are pinning all pages from get_user_pages(). But all processes
cannot do it: g2d ioctls can be used by process authorized by master
or root process. Of course, if more strict rule is required, we can
limit the size of memory to be used by g2d.

>
> You also ignore any munmap that might happen, any munmap will not care
> about the page being pin or not. The vma will disappear.

The vma would mean userspace. Physical pages will be freed once g2d
dma releases them. The important thing is that the pages from
get_user_pages() are only valid while g2d dma is running so once the
dma operation is completed the pages will be freed. And also g2d
driver doesn't provide any interface that user process can access the
pages. Give me more details what is the problem?

>
> Nor you respect the page being remapped read only for page write back
> allowing the gpu to write to the page while I/O is in progress.

You mean that it is possible for the g2d dma to access the pages for
write while I/O operation: at this moment, the pages have read only
attribute?

>
>>
>> One more thing, do you think this issue cannot be resolved so you are
>> trying to remove userptr feature from g2d driver?
>>
>
> I am just thinking that this is a somewhat evil api, i understand how
> nice it is for things like zero copy upload/download. But it allows to
> go around some of the memory policy set by other part of the kernel.
>
> But i guess that given you map/unmap accross cmd ioctl that is close
> to the direct-io usage pattern and thus can be forgiven.
>
> Note that if you were to start using GUP-fast then you will also have
> to consider the mmu_notifier range invalidation.

s/GUP-fast/GPU-fast.

Hm.. I think the page tables, one is for user space and other is for
device space, are different each other: they - cpu and dma - use fully
separated page table in case of Exynos drm. So I don't understand why
g2d driver have to consider the mmu_nitifier or relevant things. If
there is my missing point, can you give me more details?

Thanks,
Inki Dae

>
> Cheers,
> J?r?me
>
>> Thanks,
>> Inki Dae
>>
>> > that rely on this behavior is broken and rely on pure luck. To
>> > avoid any false hope from userspace stop such useage by simply
>> > flat out returning -EFAULT. Better to have a reliable behavior
>> > than to depend on pure luck and currently observed behavior of
>> > mm code.
>> >
>> > Note this was not even compile tested but i think i did update
>> > all places.
>> >
>> > Signed-off-by: J?r?me Glisse 
>> > ---
>> >  drivers/gpu/drm/exynos/exynos_drm_drv.h |   1 -
>> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 277 
>> > +---
>> >  drivers/gpu/drm/exynos/exynos_drm_gem.c |  60 ---
>> >  drivers/gpu/drm/exynos/exynos_drm_gem.h |  20 ---
>> >  4 files changed, 3 insertions(+), 355 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> > b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> > index 36535f3..7b55e89 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> > @@ -233,7 +233,6 @@ struct exynos_drm_g2d_private {
>> > struct device   *dev;
>> > struct list_headinuse_cmdlist;
>> > struct list_headevent_list;
>> > -   struct list_headuserptr_list;
>> >  };
>> >
>> >  struct exynos_drm_ipp_private {
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
>> > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> > index 8001587..d0be6dc 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> > @@ -118,9 +118,6 @@
>> >  #define G2D_CMDLIST_POOL_SIZE  (G2D_CMDLIST_SIZE * 
>> > G2D_CMDLIST_NUM)
>> >  #define G2D_CMDLIST_DATA_NUM   (G2D_CMDLIST_SIZE / 
>> > sizeof(u32) - 2)
>> >
>> > -/* maximum buffer pool size of userptr is 64MB as default */
>> > -#define MAX_POOL   (64 * 1024 * 1024)
>> > -
>> >  enum {
>> > BUF_TYPE_GEM = 1,
>> > BUF_TYPE_USERPTR,
>> > @@ -185,19 +182,6 @@ struct

[Bug 80684] I2C-over-AUX drops single bytes

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

--- Comment #4 from Stefan Br?ns  ---
(In reply to comment #2)
> Created attachment 102076 [details] [review]
> possible fix
> 
> Does this patch help?

Nope, unfortunately not.

The transfer has actually worked, even with nonzero flags. *if* we want to
start the transfer again, we have to set the offset before doing so.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 80684] I2C-over-AUX drops single bytes