date:20140227

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

Michel D?nzer  changed:

   What|Removed |Added

Version|git |unspecified

--- Comment #5 from Michel D?nzer  ---
I finally figured out why PTS failed to install the specviewperf10 test for me
(the installation hangs with ccache).

The proe-04 test only draws the splash screen here, after that I get lines
like:

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

in dmesg, indicating the kernel fails to process the drawing command streams,
probably due to running out of VRAM or GTT memory.

Does that match what you're seeing?

-- 
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/20140227/d283eae6/attachment.html>

[PATCH v4 00/34] drm/exynos: Refactor parts of the exynos driver

2014-02-27 Thread Inki Dae

Hi Tomasz,

2014-02-08 11:48 GMT+09:00 Tomasz Figa :
> On 06.02.2014 20:54, Olof Johansson wrote:
>>
>> On Thu, Jan 30, 2014 at 1:18 PM, Sean Paul  wrote:
>>>
>>> This patchset refactors parts of the exynos driver to move it closer to a
>>> proper
>>> drm driver (rather than just implementing a drm layer on top of the
>>> hardware
>>> drivers). The hope is to get to a point where the dp/hdmi drivers can
>>> implement
>>> drm_connector/drm_encoder directly, and fimd/mixer can directly implement
>>> drm_crtc.
>>>
>>> The notable changes in this set:
>>>  - drm_encoder funcs no longer route through the crtc
>>>  - DP driver has been moved from video into the drm driver
>>>  - fimd no longer implements encoder callbacks
>>>  - exynos_drm_hdmi is removed in favor of generic manager/display
>>>handling
>>>
>>> At a glance, differences between v1 and v2:
>>>  - Passing manager/display in callbacks instead of ctx
>>>  - Tacked on some dpms patches on the end to handle
>>> suspend/resume
>>>through the dpms path
>>>
>>> At a glance, differences between v2 and v3:
>>>  - Fixed vidi issues
>>>  - Moved exynos_drm_hdmi.c removal to the right place
>>>  - Added the exynos_drm_connector removal patches on the end
>>>
>>> At a glance, differences between v3 and v4:
>>>  - Rebased on top of exynos-drm-next
>>>  - Addressed review comments, no major functional changes
>>>
>>> Sean
>>
>>
>> Even if there is room for even more cleanups and refactorings on top
>> of this, it's good enough as a base and keeping it out of tree is
>> hurting productivity and usefulness for everybody. Let's get this
>> merged for 3.15 so that we can make progress with the rest of the
>> platform!
>
>
> I wouldn't be overly excited about merging this series yet...
>
> If I have applied it correctly (and I believe so, as reading the code tells
> me the same), it introduces a regression due to removal of support of
> standard parallel displays from FIMD driver.
>
> I had mentioned this in my review comments for previous version, but
> apparently I got ignored. Please fix this.
>

Right, and also some my comments. Sean should have commented his
opinions even if our comments aren't  reasonable to him.

I sent a email about the progress of this refactoring patch series to
Sean and Olof personally because there was no any follow-up action for
about two months since v3 had been posted, and I found out that Sean
was busy with other works.

And there are no any his comments until now so I'd like to believe
Sean would still be busy. So I already started to clean up and enhance
Exynos drm framework using the component framework for super device
posted by Russell like below,

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a41e6070dd7ef539d0f3b1652b4839d04378e11

Last month, Russell had posted this framework, and it has been merged
to mainline. This provides a generic way to gather up the individual
sub devices together using super node?? (not sure if it's a proper
expression) of device tree.
With this, we could remove existing exynos_drm_core.c and I guess we
could also resolve your concern about dt broken this time.

The patch series I'm preparing will go to on top of Sean's refactoring
patch series.

Thanks,
Inki Dae

> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75433] xserver crashes after suspend with radeonsi and glamor, poor 2d performance

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

Michel D?nzer  changed:

   What|Removed |Added

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

-- 
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/20140227/ebb32be2/attachment-0001.html>

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

--- Comment #14 from Jakob Nixdorf  ---
This is the log for the patched LLVM (SVN) with R600_DEBUG=ps,vs enabled:
http://shadowice.org/~flocke/linux/misc/ADVGame_R600_DEBUG_patched.log

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

[Bug 75433] xserver crashes after suspend with radeonsi and glamor, poor 2d performance

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

--- Comment #4 from Michel D?nzer  ---
Please attach the output of dmesg after the crash.

Can you get a backtrace of the crash with gdb?

Note that there is no EXA support for Southern Islands and newer Radeons,
Option "AccelMethod" "EXA" just disables all hardware acceleration with those.

-- 
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/20140227/2905f1cc/attachment.html>

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi

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

Michel D?nzer  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|10.0|unspecified
  Component|Drivers/Gallium/radeonsi|DRM/Radeon

--- Comment #4 from Michel D?nzer  ---
(In reply to comment #1)
> Created attachment 94713 [details]
> dmesg

Looks like the GPU locks up on resume, and the GPU reset fails to get it back
in shape.

Does this also happen with DPM disabled?

-- 
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/20140227/2b743709/attachment.html>

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi

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

--- Comment #5 from Jarno Lepp?nen  ---
Yes, setting kernel parameter radeon.dpm=0 doesn't help.

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

[Bug 75361] freeze in Mass Effect 3 (wine)

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

--- Comment #13 from Michel D?nzer  ---
(In reply to comment #12)
> Created attachment 94775 [details]
> gdb backtrace

Unfortunately, this backtrace is useless because it doesn't show any symbol
names.

It might be easier to do this with glretrace than with Wine.


(In reply to comment #11)
> --with-optimize-option= --disable-optimized --enable-expensive-checks

Does building LLVM without these options help, or maybe with --enable-optimized
instead of them?

-- 
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/20140227/f70231d6/attachment.html>

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi

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

--- Comment #6 from Jarno Lepp?nen  ---
Also, I need to reboot the machine in order to get hardware acceleration
working again. If I try to restart X after the crash it reverts to software
rendering with Xorg.log complaining that "Screen 0 is not DRI2 capable".
Nothing on dmesg though.

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

[Bug 75491] Radeon HD7750 no Monitors connected

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

--- Comment #6 from Eric Gr?ttefien  ---
Anything else i can do / try ?

-- 
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/20140227/2cf052b0/attachment-0001.html>

[Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

2014-02-27 Thread Ville Syrjälä

On Thu, Feb 27, 2014 at 12:11:39AM -0800, Carl Worth wrote:
> With Haswell, 5.4Gbps is supported. And almost all of the code was
> already in place already. All that was missing was this tiny bit of
> additional wiring.

Todd already implemented 5.4Gbps support a while back. So it seems your
tree is a bit out of date.

-- 
Ville Syrj?l?
Intel OTC

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #6 from commiethebeastie at gmail.com ---
No any regressions with R600_DEBUG=hyperz on Asus DirectCU RHD6850.

Tested on Serious Sam III, Unigine, Portal 2, Compiz, Lightsmark 2008, Europe
Universalis IV, Fallout New Vegas :) 

Are you need in more info?

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

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #7 from commiethebeastie at gmail.com ---
echo $R600_DEBUG
hyperz

-- 
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/20140227/b2ca8c1b/attachment.html>

[PATCH] drm/radeon: free uvd ring on unload

2014-02-27 Thread Christian König

Am 27.02.2014 01:22, schrieb j.glisse at gmail.com:
> From: Jerome Glisse 
>
> Need to free the uvd ring. Also reshuffle gart tear down to
> happen after uvd tear down.
>
> Signed-off-by: J?r?me Glisse 
> Cc: stable at vger.kernel.org

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/evergreen.c  | 2 +-
>   drivers/gpu/drm/radeon/radeon_uvd.c | 2 ++
>   drivers/gpu/drm/radeon/rv770.c  | 2 +-
>   3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 5623e75..8a2c010 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -5475,9 +5475,9 @@ void evergreen_fini(struct radeon_device *rdev)
>   radeon_wb_fini(rdev);
>   radeon_ib_pool_fini(rdev);
>   radeon_irq_kms_fini(rdev);
> - evergreen_pcie_gart_fini(rdev);
>   uvd_v1_0_fini(rdev);
>   radeon_uvd_fini(rdev);
> + evergreen_pcie_gart_fini(rdev);
>   r600_vram_scratch_fini(rdev);
>   radeon_gem_fini(rdev);
>   radeon_fence_driver_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 6781fee..3e6804b 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -171,6 +171,8 @@ void radeon_uvd_fini(struct radeon_device *rdev)
>   
>   radeon_bo_unref(&rdev->uvd.vcpu_bo);
>   
> + radeon_ring_fini(rdev, &rdev->ring[R600_RING_TYPE_UVD_INDEX]);
> +
>   release_firmware(rdev->uvd_fw);
>   }
>   
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index 6c772e5..4e37a42 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -1955,9 +1955,9 @@ void rv770_fini(struct radeon_device *rdev)
>   radeon_wb_fini(rdev);
>   radeon_ib_pool_fini(rdev);
>   radeon_irq_kms_fini(rdev);
> - rv770_pcie_gart_fini(rdev);
>   uvd_v1_0_fini(rdev);
>   radeon_uvd_fini(rdev);
> + rv770_pcie_gart_fini(rdev);
>   r600_vram_scratch_fini(rdev);
>   radeon_gem_fini(rdev);
>   radeon_fence_driver_fini(rdev);

[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace

2014-02-27 Thread Christian König

Am 26.02.2014 19:25, schrieb Marek Ol??k:
> From: Marek Ol??k 
>
> Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
> a number from 0 to 15. The higher the number, the higher the priority,
> which means a buffer with a higher number will be validated sooner.
>
> The old behavior is preserved: Buffers used for write are prioritized over
> read-only buffers if the userspace doesn't set the number.
>
> v2: add buffers to buckets directly, then concatenate them
>
> Signed-off-by: Marek Ol??k 
> ---
>   drivers/gpu/drm/radeon/radeon.h|  2 +-
>   drivers/gpu/drm/radeon/radeon_cs.c | 68 
> --
>   drivers/gpu/drm/radeon/radeon_object.c | 10 -
>   drivers/gpu/drm/radeon/radeon_object.h |  2 -
>   4 files changed, 66 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index d37a57a..f7a3174 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -481,7 +481,7 @@ struct radeon_bo_list {
>   struct ttm_validate_buffer tv;
>   struct radeon_bo*bo;
>   uint64_tgpu_offset;
> - boolwritten;
> + unsignedpriority;

As far as I can see priority is only used temporary in 
radeon_cs_parser_relocs, so we probably don't need it in here.

Apart from that patch looks good to me,
Christian.

>   unsigneddomain;
>   unsignedalt_domain;
>   u32 tiling_flags;
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index d49a3f7..779fa02 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -31,10 +31,57 @@
>   #include "radeon.h"
>   #include "radeon_trace.h"
>   
> +#define RADEON_CS_MAX_PRIORITY   33u
> +#define RADEON_CS_MAX_BUCKET (RADEON_CS_MAX_PRIORITY / 2u)
> +#define RADEON_CS_NUM_BUCKETS(RADEON_CS_MAX_BUCKET + 1u)
> +
> +/* This is based on the bucket sort with O(n) time complexity.
> + * Relocations are sorted from the highest to the lowest priority as
> + * they are added.
> + *
> + * Odd numbers are added at the head of a bucket and even numbers are
> + * added at the tail, therefore all buckets are always sorted. */
> +struct radeon_cs_buckets {
> + struct list_head bucket[RADEON_CS_NUM_BUCKETS];
> +};
> +
> +static void radeon_cs_buckets_init(struct radeon_cs_buckets *b)
> +{
> + unsigned i;
> +
> + for (i = 0; i < RADEON_CS_NUM_BUCKETS; i++)
> + INIT_LIST_HEAD(&b->bucket[i]);
> +}
> +
> +static void radeon_cs_buckets_add(struct radeon_cs_buckets *b,
> +   struct radeon_bo_list *reloc)
> +{
> + unsigned priority = reloc->priority;
> + unsigned i = min(priority / 2u, RADEON_CS_MAX_BUCKET);
> +
> + if (priority % 2 == 1) {
> + list_add(&reloc->tv.head, &b->bucket[i]);
> + } else {
> + list_add_tail(&reloc->tv.head, &b->bucket[i]);
> + }
> +}
> +
> +static void radeon_cs_buckets_get_list(struct radeon_cs_buckets *b,
> +struct list_head *out_list)
> +{
> + unsigned i;
> +
> + /* Connect the sorted buckets in the output list. */
> + for (i = 0; i < RADEON_CS_NUM_BUCKETS; i++) {
> + list_splice(&b->bucket[i], out_list);
> + }
> +}
> +
>   static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
>   {
>   struct drm_device *ddev = p->rdev->ddev;
>   struct radeon_cs_chunk *chunk;
> + struct radeon_cs_buckets buckets;
>   unsigned i, j;
>   bool duplicate;
>   
> @@ -53,6 +100,9 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
> *p)
>   if (p->relocs == NULL) {
>   return -ENOMEM;
>   }
> +
> + radeon_cs_buckets_init(&buckets);
> +
>   for (i = 0; i < p->nrelocs; i++) {
>   struct drm_radeon_cs_reloc *r;
>   
> @@ -80,7 +130,15 @@ static int radeon_cs_parser_relocs(struct 
> radeon_cs_parser *p)
>   p->relocs_ptr[i] = &p->relocs[i];
>   p->relocs[i].robj = gem_to_radeon_bo(p->relocs[i].gobj);
>   p->relocs[i].lobj.bo = p->relocs[i].robj;
> - p->relocs[i].lobj.written = !!r->write_domain;
> +
> + /* The userspace buffer priorities are from 0 to 15. A higher
> +  * number means the buffer is more important.
> +  * Also, the buffers used for write have a higher priority than
> +  * the buffers used for read only, which doubles the range
> +  * to 0 to 31. Numbers 32 and 33 are reserved for the kernel
> +  * driver.
> +  */
> + p->relocs[i].lobj.priority = (r->flags & 0xf) * 2 + 
> !!r->write_domain;
>   
>   /* the first reloc of an UVD job is the msg and that must be in
>  VRAM, also but everything into V

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Borislav Petkov

On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> there to BAR is at a completely different address. Same thing on my
> Haswell desktop system.

Hrrm, I'd like to see what Rafael finds out, whether what we're reading
from PCI config space is even sane.

> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally
> unstable. They hang if I type make in my kernel tree. Whereas 3.14-rc3
> is stable. I am not so sure this is all related to the uncore IMC
> support, though.

Easy to test - just disable the uncore thing.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Peter Zijlstra

On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> They  hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
> not so sure this is all related to the uncore IMC support, though.

Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial
patch missing. I'll try and get Thomas to merge it if Ingo doesn't show
up soon.

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Peter Zijlstra

On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra  
> wrote:
> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> >> They  hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I 
> >> am
> >> not so sure this is all related to the uncore IMC support, though.
> >
> > Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial
> > patch missing. I'll try and get Thomas to merge it if Ingo doesn't show
> > up soon.
> 
> Yes, I mean from tip.git.

lkml.kernel.org/r/20140224121218.GR15586 at twins.programming.kicks-ass.net

Should cure things; unless there's more borkage.

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Russell King - ARM Linux

On Thu, Feb 27, 2014 at 01:06:52PM +0200, Tomi Valkeinen wrote:
> On 25/02/14 16:23, Philipp Zabel wrote:
> 
> > +Freescale i.MX DRM master device
> > +
> > +
> > +The freescale i.MX DRM master device is a virtual device needed to list all
> > +IPU or other display interface nodes that comprise the graphics subsystem.
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx-drm"
> > +- ports: Should contain a list of phandles pointing to display interface 
> > ports
> > +  of IPU devices
> > +
> > +example:
> > +
> > +imx-drm {
> > +   compatible = "fsl,imx-drm";
> > +   ports = <&ipu_di0>;
> > +};
> 
> I'm not a fan of having non-hardware related things in the DT data.
> Especially if it makes direct references to our SW, in this case DRM.
> There's no DRM on the board. I wanted to avoid all that with OMAP
> display bindings.
> 
> Is there even need for such a master device? You can find all the
> connected display devices from any single display device, by just
> following the endpoint links.

Please read up on what has been discussed over previous years:

http://lists.freedesktop.org/archives/dri-devel/2013-July/041159.html

and please, let's not endlessly rehash old discussions because someone
wasn't involved and has a different opinion, otherwise we're never going
to get anywhere.

Thanks.

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

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #8 from Grigori Goronzy  ---
Please check the bugs this one depends on. There are various well known
applications and games that have problems (GPU hangs and/or image corruption)
with HyperZ enabled. The geometry shader refactoring also introduced a
regression.

-- 
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/20140227/f9d87fb5/attachment.html>

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Philipp Zabel

Am Donnerstag, den 27.02.2014, 13:06 +0200 schrieb Tomi Valkeinen:
> On 25/02/14 16:23, Philipp Zabel wrote:
> 
> > +Freescale i.MX DRM master device
> > +
> > +
> > +The freescale i.MX DRM master device is a virtual device needed to list all
> > +IPU or other display interface nodes that comprise the graphics subsystem.
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx-drm"
> > +- ports: Should contain a list of phandles pointing to display interface 
> > ports
> > +  of IPU devices
> > +
> > +example:
> > +
> > +imx-drm {
> > +   compatible = "fsl,imx-drm";
> > +   ports = <&ipu_di0>;
> > +};
> 
> I'm not a fan of having non-hardware related things in the DT data.
> Especially if it makes direct references to our SW, in this case DRM.
> There's no DRM on the board. I wanted to avoid all that with OMAP
> display bindings.
> 
> Is there even need for such a master device? You can find all the
> connected display devices from any single display device, by just
> following the endpoint links.

I don't particularly like this either, but it kind of has been decided.

For the i.MX6 display subsystem there is no clear single master device,
and the physical configuration changes across the SoC family. The
i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
IPU2, with two output ports each. The i.MX6DL/i.MX6S SoCs only have one
IPU1, but it is accompanied by separate lower-power LCDIF display
controller with a single output. These may or may not be connected
indirectly across the encoder input multiplexers, so collecting them
would require scanning the whole device tree from an always-enabled
imx-drm platform device if we didn't have this node.

Also, we are free to just ignore this node in the future, if a better
way is found.

> >  display at di0 {
> > compatible = "fsl,imx-parallel-display";
> > edid = [edid-data];
> > -   crtc = <&ipu 0>;
> > interface-pix-fmt = "rgb24";
> > +
> > +   port {
> > +   display_in: endpoint {
> > +   remote-endpoint = <&ipu_di0_disp0>;
> > +   };
> > +   };
> >  };
> 
> Shouldn't the pix-fmt be defined in the endpoint node? It is about pixel
> format for a particular endpoint, isn't it?
> 
> > diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt 
> > b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
> > index ed93778..578a1fc 100644
> > --- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
> > +++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
> > @@ -50,12 +50,14 @@ have a look at 
> > Documentation/devicetree/bindings/video/display-timing.txt.
> >  
> >  Required properties:
> >   - reg : should be <0> or <1>
> > - - crtcs : a list of phandles with index pointing to the IPU display 
> > interfaces
> > -   that can be used as video source for this channel.
> >   - fsl,data-mapping : should be "spwg" or "jeida"
> >This describes how the color bits are laid out in the
> >serialized LVDS signal.
> >   - fsl,data-width : should be <18> or <24>
> > + - port: A port node with endpoint definitions as defined in
> > +   Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +   On i.MX6, there should be four ports (port@[0-3]) that correspond
> > +   to the four LVDS multiplexer inputs.
> 
> Is the ldb something that's on the imx SoC?

Yes. It consists of two LVDS encoders. On i.MX5 each channel is
connected to one display interface of the single IPU.
On i.MX6Q its parallel input can be connected to any of the four IPU1/2
display interfaces using a 4-port multiplexer (and on i.MX6DL it can be
connected to IPU1 or LCDIF).

> Do you have a public branch somewhere? It'd be easier to look at the
> final result, as I'm not familiar with imx.

Not yet, I will prepare a branch with the next version.

regards
Philipp

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Russell King - ARM Linux

On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
> For the i.MX6 display subsystem there is no clear single master device,
> and the physical configuration changes across the SoC family. The
> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
> IPU2, with two output ports each.

Not also forgetting that there's another scenario too: you may wish
to drive IPU1 and IPU2 as two completely separate display subsystems
in some hardware, but as a combined display subsystem in others.

Here's another scenario.  You may have these two IPUs on the SoC, but
there's only one display output.  You want to leave the second IPU
disabled, as you wouldn't want it to be probed or even exposed to
userland.

On the face of it, the top-level super-device node doesn't look very
hardware-y, but it actually is - it's about how a board uses the
hardware provided.  This is entirely in keeping with the spirit of DT,
which is to describe what hardware is present and how it's connected
together, whether it be at the chip or board level.

If this wasn't the case, we wouldn't even attempt to describe what devices
we have on which I2C buses - we'd just list the hardware on the board
without giving any information about how it's wired together.

This is no different - however, it doesn't have (and shouldn't) be
subsystem specific... but - and this is the challenge we then face - how
do you decide that on one board with a single zImage kernel, with both
DRM and fbdev built-in, whether to use the DRM interfaces or the fbdev
interfaces?  We could have both matching the same compatible string, but
we'd also need some way to tell each other that they're not allowed to
bind.

Before anyone argues against "it isn't hardware-y", stop and think.
What if I design a board with two Epson LCD controllers on board and
put a muxing arrangement on their output.  Is that one or two devices?
What if I want them to operate as one combined system?  What if I have
two different LCD controllers on a board.  How is this any different
from the two independent IPU hardware blocks integrated inside an iMX6
SoC with a muxing arrangement on their output?

It's very easy to look at a SoC and make the wrong decision...

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

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Rob Clark

On Thu, Feb 27, 2014 at 8:00 AM, Russell King - ARM Linux
 wrote:
> On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
>> For the i.MX6 display subsystem there is no clear single master device,
>> and the physical configuration changes across the SoC family. The
>> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
>> IPU2, with two output ports each.
>
> Not also forgetting that there's another scenario too: you may wish
> to drive IPU1 and IPU2 as two completely separate display subsystems
> in some hardware, but as a combined display subsystem in others.
>
> Here's another scenario.  You may have these two IPUs on the SoC, but
> there's only one display output.  You want to leave the second IPU
> disabled, as you wouldn't want it to be probed or even exposed to
> userland.

I agree with Russell here, purely hw description is not always going
to be enough information to know how to assemble a bag of parts into a
system.

Maybe there is some way we should be splitting this "meta" description
into different dt files or something like this (?) to make it easier
for alternative configurations, but if the hw description alone is not
enough information for the drivers to know what to do, some (for lack
of a better word) "use-case" configuration is needed, and that has to
go *somewhere*... better to put it in DT than hard code it in the
driver.

BR,
-R

> On the face of it, the top-level super-device node doesn't look very
> hardware-y, but it actually is - it's about how a board uses the
> hardware provided.  This is entirely in keeping with the spirit of DT,
> which is to describe what hardware is present and how it's connected
> together, whether it be at the chip or board level.
>
> If this wasn't the case, we wouldn't even attempt to describe what devices
> we have on which I2C buses - we'd just list the hardware on the board
> without giving any information about how it's wired together.
>
> This is no different - however, it doesn't have (and shouldn't) be
> subsystem specific... but - and this is the challenge we then face - how
> do you decide that on one board with a single zImage kernel, with both
> DRM and fbdev built-in, whether to use the DRM interfaces or the fbdev
> interfaces?  We could have both matching the same compatible string, but
> we'd also need some way to tell each other that they're not allowed to
> bind.
>
> Before anyone argues against "it isn't hardware-y", stop and think.
> What if I design a board with two Epson LCD controllers on board and
> put a muxing arrangement on their output.  Is that one or two devices?
> What if I want them to operate as one combined system?  What if I have
> two different LCD controllers on a board.  How is this any different
> from the two independent IPU hardware blocks integrated inside an iMX6
> SoC with a muxing arrangement on their output?
>
> It's very easy to look at a SoC and make the wrong decision...
>
> --
> 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

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Russell King - ARM Linux

On Thu, Feb 27, 2014 at 03:16:03PM +0200, Tomi Valkeinen wrote:
> On 27/02/14 13:56, Russell King - ARM Linux wrote:
> 
> >> Is there even need for such a master device? You can find all the
> >> connected display devices from any single display device, by just
> >> following the endpoint links.
> > 
> > Please read up on what has been discussed over previous years:
> > 
> > http://lists.freedesktop.org/archives/dri-devel/2013-July/041159.html
> 
> Thanks, that was an interesting thread. Too bad I missed it, it was
> during the holiday season. And seems Laurent missed it also, as he
> didn't make any replies.
> 
> The thread seemed to go over the very same things that had already been
> discussed with CDF.

That may be - but the problem with CDF solving this problem is that it's
wrong.  It's fixing what is in actual fact a *generic* problem in a much
too specific way.  To put it another way, it's forcing everyone to fix
the same problem in their own separate ways because no one is willing to
take a step back and look at the larger picture.

We can see that because ASoC has exactly the same problem - it has to
wait until all devices (DMA, CPU DAIs, codecs etc) are present before it
can initialise, just like DRM.  Can you re-use the CDF solution for ASoC?
No.  Can it be re-used elsewhere in non-display subsystems?  No.

Therefore, CDF is yet another implementation specific solution to a
generic problem which can't be re-used.

Yes, I realise that CDF may do other stuff, but because of the above, it's
a broken solution.

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

[PATCH v4 00/34] drm/exynos: Refactor parts of the exynos driver

2014-02-27 Thread Tomasz Figa

Hi Inki,

On 27.02.2014 05:43, Inki Dae wrote:
> Hi Tomasz,
>
>
> 2014-02-08 11:48 GMT+09:00 Tomasz Figa :
>> On 06.02.2014 20:54, Olof Johansson wrote:
>>>
>>> On Thu, Jan 30, 2014 at 1:18 PM, Sean Paul  wrote:

 This patchset refactors parts of the exynos driver to move it closer to a
 proper
 drm driver (rather than just implementing a drm layer on top of the
 hardware
 drivers). The hope is to get to a point where the dp/hdmi drivers can
 implement
 drm_connector/drm_encoder directly, and fimd/mixer can directly implement
 drm_crtc.

 The notable changes in this set:
   - drm_encoder funcs no longer route through the crtc
   - DP driver has been moved from video into the drm driver
   - fimd no longer implements encoder callbacks
   - exynos_drm_hdmi is removed in favor of generic manager/display
 handling

 At a glance, differences between v1 and v2:
   - Passing manager/display in callbacks instead of ctx
   - Tacked on some dpms patches on the end to handle
 suspend/resume
 through the dpms path

 At a glance, differences between v2 and v3:
   - Fixed vidi issues
   - Moved exynos_drm_hdmi.c removal to the right place
   - Added the exynos_drm_connector removal patches on the end

 At a glance, differences between v3 and v4:
   - Rebased on top of exynos-drm-next
   - Addressed review comments, no major functional changes

 Sean
>>>
>>>
>>> Even if there is room for even more cleanups and refactorings on top
>>> of this, it's good enough as a base and keeping it out of tree is
>>> hurting productivity and usefulness for everybody. Let's get this
>>> merged for 3.15 so that we can make progress with the rest of the
>>> platform!
>>
>>
>> I wouldn't be overly excited about merging this series yet...
>>
>> If I have applied it correctly (and I believe so, as reading the code tells
>> me the same), it introduces a regression due to removal of support of
>> standard parallel displays from FIMD driver.
>>
>> I had mentioned this in my review comments for previous version, but
>> apparently I got ignored. Please fix this.
>>
>
> Right, and also some my comments. Sean should have commented his
> opinions even if our comments aren't  reasonable to him.
>
> I sent a email about the progress of this refactoring patch series to
> Sean and Olof personally because there was no any follow-up action for
> about two months since v3 had been posted, and I found out that Sean
> was busy with other works.
>
> And there are no any his comments until now so I'd like to believe
> Sean would still be busy. So I already started to clean up and enhance
> Exynos drm framework using the component framework for super device
> posted by Russell like below,
>  
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a41e6070dd7ef539d0f3b1652b4839d04378e11
>
> Last month, Russell had posted this framework, and it has been merged
> to mainline. This provides a generic way to gather up the individual
> sub devices together using super node?? (not sure if it's a proper
> expression) of device tree.
> With this, we could remove existing exynos_drm_core.c and I guess we
> could also resolve your concern about dt broken this time.
>
> The patch series I'm preparing will go to on top of Sean's refactoring
> patch series.

Andrzej Hajda from our team is already working on addressing remaining 
issues with Sean's series, including fixing removed parallel display 
support. Earlier this month he sent a series restoring support for DSI 
panels: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27044 . 
Now he's also trying to make the design more modular. He will give you 
more information on Monday, as he's on holiday for next two days.

Also Tomasz Stanislawski will have some patches to enable HDMI support 
using Exynos DRM on Exynos 4 SoCs on top of this series, along with 
reworking Sean's and Daniel's patch for HDMI driver's DT bindings as he 
mentioned in reply to other message of this thread.

Best regards,
Tomasz

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #9 from commiethebeastie at gmail.com ---
Created attachment 94823
  --> https://bugs.freedesktop.org/attachment.cgi?id=94823&action=edit
gpulockup rhd3200

-- 
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/20140227/0904e1b2/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #10 from commiethebeastie at gmail.com ---
Created attachment 94824
  --> https://bugs.freedesktop.org/attachment.cgi?id=94824&action=edit
xorg rhd3200

-- 
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/20140227/b91b6882/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #11 from commiethebeastie at gmail.com ---
Created attachment 94825
  --> https://bugs.freedesktop.org/attachment.cgi?id=94825&action=edit
lspci rhd3200

-- 
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/20140227/f26346be/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #12 from commiethebeastie at gmail.com ---
lockup with rhd3200 in Lightsmark 2008.

[ 1506.221260] radeon :01:05.0: GPU lockup CP stall for more than 1msec
[ 1506.221275] radeon :01:05.0: GPU lockup (waiting for 0x00011a82
last fence id 0x00011a71 on ring 0)
[ 1506.221283] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35).
[ 1506.221293] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-35).
[ 1506.221299] radeon :01:05.0: ib ring test failed (-35).
[ 1506.221305] [drm] Disabling audio 0 support
[ 1506.222343] radeon :01:05.0: GPU softreset: 0x0009
[ 1506.222349] radeon :01:05.0:   R_008010_GRBM_STATUS  = 0xE6733030
[ 1506.222355] radeon :01:05.0:   R_008014_GRBM_STATUS2 = 0x00110103
[ 1506.222360] radeon :01:05.0:   R_000E50_SRBM_STATUS  = 0x2040
[ 1506.222365] radeon :01:05.0:   R_008674_CP_STALLED_STAT1 = 0x
[ 1506.222371] radeon :01:05.0:   R_008678_CP_STALLED_STAT2 = 0x8002
[ 1506.222376] radeon :01:05.0:   R_00867C_CP_BUSY_STAT = 0x8086
[ 1506.222382] radeon :01:05.0:   R_008680_CP_STAT  = 0x80018645
[ 1506.222387] radeon :01:05.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[ 1506.272140] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEF
[ 1506.272196] radeon :01:05.0: SRBM_SOFT_RESET=0x0100
[ 1506.274289] radeon :01:05.0:   R_008010_GRBM_STATUS  = 0xA0003030
[ 1506.274295] radeon :01:05.0:   R_008014_GRBM_STATUS2 = 0x0003
[ 1506.274300] radeon :01:05.0:   R_000E50_SRBM_STATUS  = 0x20008040
[ 1506.274305] radeon :01:05.0:   R_008674_CP_STALLED_STAT1 = 0x
[ 1506.274311] radeon :01:05.0:   R_008678_CP_STALLED_STAT2 = 0x
[ 1506.274316] radeon :01:05.0:   R_00867C_CP_BUSY_STAT = 0x
[ 1506.274321] radeon :01:05.0:   R_008680_CP_STAT  = 0x8010
[ 1506.274326] radeon :01:05.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[ 1506.274333] radeon :01:05.0: GPU reset succeeded, trying to resume

-- 
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/20140227/c6601089/attachment-0001.html>

[PATCH] drm/edid: request HDMI underscan by default

2014-02-27 Thread Daniel Drake

Working with HDMI TVs is a real pain as they tend to overscan by
default, meaning that the pixels around the edge of the framebuffer
are not displayed. This is well explained here:
http://mjg59.dreamwidth.org/8705.html

There is a bit in the HDMI info frame that can request that the
remote display shows the full pixel data ("underscan"). For the
remote display, the HDMI spec states that this is optional - it
doesn't have to listen. That means that most TVs will probably ignore
this.

But, maybe there are a handful of TVs for which this would help
the situation. As we live in a digital world, ask the remote
display not to overscan by default.

Signed-off-by: Daniel Drake 
---
 drivers/gpu/drm/drm_edid.c | 1 +
 1 file changed, 1 insertion(+)

Replaces the patch titled "video: hdmi: request underscan by default"
This version moves the change to the DRM layer, as requested by
Ville Syrj?l?.

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b924306..f8d8a1d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3599,6 +3599,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,

frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
+   frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;

return 0;
 }
-- 
1.8.3.2

[PATCH] drm/edid: request HDMI underscan by default

2014-02-27 Thread Ville Syrjälä

On Thu, Feb 27, 2014 at 09:19:30AM -0600, Daniel Drake wrote:
> Working with HDMI TVs is a real pain as they tend to overscan by
> default, meaning that the pixels around the edge of the framebuffer
> are not displayed. This is well explained here:
> http://mjg59.dreamwidth.org/8705.html
> 
> There is a bit in the HDMI info frame that can request that the
> remote display shows the full pixel data ("underscan"). For the
> remote display, the HDMI spec states that this is optional - it
> doesn't have to listen. That means that most TVs will probably ignore
> this.
> 
> But, maybe there are a handful of TVs for which this would help
> the situation. As we live in a digital world, ask the remote
> display not to overscan by default.
> 
> Signed-off-by: Daniel Drake 

Reviewed-by: Ville Syrj?l? 

> ---
>  drivers/gpu/drm/drm_edid.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> Replaces the patch titled "video: hdmi: request underscan by default"
> This version moves the change to the DRM layer, as requested by
> Ville Syrj?l?.
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b924306..f8d8a1d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3599,6 +3599,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> hdmi_avi_infoframe *frame,
>  
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
>   frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> + frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
>  
>   return 0;
>  }
> -- 
> 1.8.3.2

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm/edid: request HDMI underscan by default

2014-02-27 Thread Damien Lespiau

On Thu, Feb 27, 2014 at 05:42:36PM +0200, Ville Syrj?l? wrote:
> On Thu, Feb 27, 2014 at 09:19:30AM -0600, Daniel Drake wrote:
> > Working with HDMI TVs is a real pain as they tend to overscan by
> > default, meaning that the pixels around the edge of the framebuffer
> > are not displayed. This is well explained here:
> > http://mjg59.dreamwidth.org/8705.html
> > 
> > There is a bit in the HDMI info frame that can request that the
> > remote display shows the full pixel data ("underscan"). For the
> > remote display, the HDMI spec states that this is optional - it
> > doesn't have to listen. That means that most TVs will probably ignore
> > this.
> > 
> > But, maybe there are a handful of TVs for which this would help
> > the situation. As we live in a digital world, ask the remote
> > display not to overscan by default.
> > 
> > Signed-off-by: Daniel Drake 
> 
> Reviewed-by: Ville Syrj?l? 

As a small note, I never managed to find a TV (out of the 2 I have
around) that honour that flag, which is why I haven't pushed that patch
before. I also had the hope that we could automatically overscan with
the right amount at some point (with some sort of database) and with
that flag set, we don't know if the sink is overscanning or not, but
then I guess we could include whether the TV honour in that flag in a db
as well.

In any case, I echo the review:

Reviewed-by: Damien Lespiau 

-- 
Damien

[Bug 74878] DRI_PRIME not working correctly

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

--- Comment #2 from Nikita Mikhailov  ---
Hello
You are using wrong xrandr command, try this: 
"xrandr --setprovideroffloadsink 1 0"

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

[Bug 75361] freeze in Mass Effect 3 (wine)

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

--- Comment #14 from wdr  ---
I am build llvm with:
/var/tmp/portage/sys-devel/llvm-/work/llvm-/configure --prefix=/usr
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib --disable-timestamps
--enable-keep-symbols --enable-shared --enable-optimized --enable-assertions
--disable-terminfo --enable-libffi ac_cv_prog_XML2CONFIG=
--enable-targets=host,cpp,r600 --enable-bindings=none

no effect

new apitrace trace (170 MB):
https://bft.usu.edu/3hkhw

glretrace -w -v /tmp/me3_new.trace > tmp/me3
28591: warning: unsupported glXSwapIntervalMESA call
28929: warning: unsupported glXSwapIntervalMESA call
54241: warning: unsupported glXSwapIntervalMESA call
54579: warning: unsupported glXSwapIntervalMESA call
79891: warning: unsupported glXSwapIntervalMESA call
80229: warning: unsupported glXSwapIntervalMESA call
118028: warning: unsupported glXSwapIntervalMESA call
118366: warning: unsupported glXSwapIntervalMESA call
118704: warning: unsupported glXSwapIntervalMESA call
119060: warning: unsupported glXSwapIntervalMESA call
158337: warning: unsupported glXSwapIntervalMESA call
158675: warning: unsupported glXSwapIntervalMESA call
apitrace: warning: caught signal 11
6523336: error: caught an unhandled exception
apitrace: info: taking default action for signal 11
?? ???

https://bft.usu.edu/bf8x6


it's correctly?

-- 
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/20140227/873b9533/attachment.html>

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Philipp Zabel

Hi Tomi,

Am Donnerstag, den 27.02.2014, 15:55 +0200 schrieb Tomi Valkeinen:
> On 27/02/14 15:00, Russell King - ARM Linux wrote:
> > On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
> >> For the i.MX6 display subsystem there is no clear single master device,
> >> and the physical configuration changes across the SoC family. The
> >> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
> >> IPU2, with two output ports each.
> > 
> > Not also forgetting that there's another scenario too: you may wish
> > to drive IPU1 and IPU2 as two completely separate display subsystems
> > in some hardware, but as a combined display subsystem in others.
> > 
> > Here's another scenario.  You may have these two IPUs on the SoC, but
> > there's only one display output.  You want to leave the second IPU
> > disabled, as you wouldn't want it to be probed or even exposed to
> > userland.
> 
> I first want to say I don't see anything wrong with such a super node.
> As you say, it does describe hardware. But I also want to say that I
> still don't see a need for it. Or, maybe more exactly, I don't see a
> need for it in general. Maybe there are certain cases where two devices
> has to be controlled by a master device. Maybe this one is one of those.
> 
> In the imx case, why wouldn't this work, without any master node, with
> the IPU nodes separate in the DT data:
> 
> - One IPU enabled, one disabled: nothing special here, just set the
> other IPU to status="disabled" in the DT data. The driver for the
> enabled IPU would register the required DRM entities.

that should work. Let the enabled IPU create the imx-drm platform device
on probe, parse the device tree and ignore everything only hanging off
of the disabled IPU.

[Reordering a bit...]
>- Two IPUs in combined mode:
> 
> Pick one IPU as the master, and one as slave. Link the IPU nodes in DT
> data with phandles, say: master=<&ipu1> on the slave IPU and
> slave=<&ipu0> on the master.
> 
> The master one will register the DRM entities, and the slave one will
> just do what the master says.

That might work, too. Just let the each IPU scan the graph and try to
find the imx-drm master before creating the imx-drm platform device.
The first IPU fill find no preexisting master and create the imx-drm
platform device as above, adding the other IPU as well as the other
components with component_master_add_child. It just has to make sure
that the other IPU is added to the list before the encoders are.

The second IPU will scan the graph, find a preexisting master for the
other IPU node, register its component and just wait to be bound by the
master.

> - Two IPUs as separate units: almost the same as above, but both would
> independently register the DRM entities.

Here the second IPU would not be connected to the first IPU via the
graph - it would not find a preexisting imx-drm device when scanning its
graph and create its own imx-drm device just like the first IPU did.
As a result there are two completely separate DRM devices.

That being said, this change could be made at any time in the future,
in a backwards compatible fashion, by just declaring the imx-drm node
optional and ignoring it if it exists.

> As for the probe time "are we ready yet?" problem, the IPU driver can
> just delay registering the DRM entities until all the nodes in its graph
> have been probed. The component helpers can probably be used here.

This is what is happening right now, except that the two IPUs are not
obtained from the graph but are given as starting points via the ports
property in the imx-drm node.

> > On the face of it, the top-level super-device node doesn't look very
> > hardware-y, but it actually is - it's about how a board uses the
> > hardware provided.  This is entirely in keeping with the spirit of DT,
> > which is to describe what hardware is present and how it's connected
> > together, whether it be at the chip or board level.
> 
> No disagreement there. I'm mostly put off by the naming. The binding doc
> says it's a "DRM master device", compatible with "fsl,imx-drm". Now,
> naming may not be the most important thing in the world, but I'd rather
> use generic terms, not linux driver stack names.

Did anybody propose such a generic term? How about:

-imx-drm {
-   compatible = "fsl,imx-drm";
-   ports = <&ipu1_di0>, <&ipu1_di1>;
-};
+display-subsystem {
+   compatible = "fsl,imx-display-subsystem";
+   ports = <&ipu1_di0>, <&ipu1_di1>;
+};

> > If this wasn't the case, we wouldn't even attempt to describe what devices
> > we have on which I2C buses - we'd just list the hardware on the board
> > without giving any information about how it's wired together.
> > 
> > This is no different - however, it doesn't have (and shouldn't) be
> > subsystem specific... but - and this is the challenge we then face - how
> > do you decide that on one board with a single zImage kernel, with both
> > DRM and fbdev built-in, whether to use the DRM inter

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #13 from commiethebeastie at gmail.com ---
Also it hangs without hyperz :( (rhd3200)

-- 
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/20140227/b99c5fb7/attachment.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #14 from funkydude  ---
I honestly don't know why you thought spamming this ticket (and the people CC'd
to it) was a good idea with something that has nothing to do with the issue.
Maybe someone can purge it?

Please make a separate ticket for issues.

-- 
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/20140227/6cd35b54/attachment.html>

[Bug 32830] X server freezes when running emulator pcsx-r or another psx emulator x86/x86_64.

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

smoki  changed:

   What|Removed |Added

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

-- 
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/20140227/3a247722/attachment.html>

[PATCH] drm/radeon: free uvd ring on unload

2014-02-27 Thread Alex Deucher

Applied to my -fixes tree.  thanks!

On Wed, Feb 26, 2014 at 7:22 PM,   wrote:
> From: Jerome Glisse 
>
> Need to free the uvd ring. Also reshuffle gart tear down to
> happen after uvd tear down.
>
> Signed-off-by: J?r?me Glisse 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/radeon/evergreen.c  | 2 +-
>  drivers/gpu/drm/radeon/radeon_uvd.c | 2 ++
>  drivers/gpu/drm/radeon/rv770.c  | 2 +-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 5623e75..8a2c010 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -5475,9 +5475,9 @@ void evergreen_fini(struct radeon_device *rdev)
> radeon_wb_fini(rdev);
> radeon_ib_pool_fini(rdev);
> radeon_irq_kms_fini(rdev);
> -   evergreen_pcie_gart_fini(rdev);
> uvd_v1_0_fini(rdev);
> radeon_uvd_fini(rdev);
> +   evergreen_pcie_gart_fini(rdev);
> r600_vram_scratch_fini(rdev);
> radeon_gem_fini(rdev);
> radeon_fence_driver_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 6781fee..3e6804b 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -171,6 +171,8 @@ void radeon_uvd_fini(struct radeon_device *rdev)
>
> radeon_bo_unref(&rdev->uvd.vcpu_bo);
>
> +   radeon_ring_fini(rdev, &rdev->ring[R600_RING_TYPE_UVD_INDEX]);
> +
> release_firmware(rdev->uvd_fw);
>  }
>
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index 6c772e5..4e37a42 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -1955,9 +1955,9 @@ void rv770_fini(struct radeon_device *rdev)
> radeon_wb_fini(rdev);
> radeon_ib_pool_fini(rdev);
> radeon_irq_kms_fini(rdev);
> -   rv770_pcie_gart_fini(rdev);
> uvd_v1_0_fini(rdev);
> radeon_uvd_fini(rdev);
> +   rv770_pcie_gart_fini(rdev);
> r600_vram_scratch_fini(rdev);
> radeon_gem_fini(rdev);
> radeon_fence_driver_fini(rdev);
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75491] Radeon HD7750 no Monitors connected

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

--- Comment #7 from Alex Deucher  ---
(In reply to comment #5)
> I'm sure they are pasive ones. They cost 1 Eur each ;-)

Maybe they are too cheap and don't properly connect the ddc wires or pull the
right pins down.  Can you confirm that they actually work with windows or
different hardware?  If they do work, can you attach the same logs but with
debugging enabled?  (add drm.debug=0xff to the kernel command line in grub)

-- 
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/20140227/ebd8bc5b/attachment.html>

[Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

2014-02-27 Thread Keith Packard

Ville Syrj?l?  writes:

> Todd already implemented 5.4Gbps support a while back. So it seems your
> tree is a bit out of date.

I didn't find it on drm-intel-fixes-2014-02-14; can you explain which
tree it is present in?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/2903a617/attachment.pgp>

[Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

2014-02-27 Thread Paulo Zanoni

2014-02-27 15:21 GMT-03:00 Keith Packard :
> Ville Syrj?l?  writes:
>
>> Todd already implemented 5.4Gbps support a while back. So it seems your
>> tree is a bit out of date.
>
> I didn't find it on drm-intel-fixes-2014-02-14; can you explain which
> tree it is present in?

It's on the drm-intel-next-queued branch. Please notice we recently
moved the tree from freedesktop.org/~danvet/drm-intel to
freedesktop.org/drm-intel.

http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=06ea66b6bb445043dc25a9626254d5c130093199


>
> --
> keith.packard at intel.com
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>



-- 
Paulo Zanoni

[pull] radeon fixes 3.14

2014-02-27 Thread Alex Deucher

Hi Dave,

Some more radeon fixes.

The following changes since commit b0447888dc29f4fb91c3b3b02e3f1f0bfc6e1222:

  MAINTAINERS: update drm git tree entry (2014-02-27 14:49:55 +1000)

are available in the git repository at:

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

for you to fetch changes up to 3803c8e5b50946dd6bc18972d9190757d05648f0:

  drm/radeon: enable speaker allocation setup on dce3.2 (2014-02-27 14:21:37 
-0500)


Alex Deucher (5):
  drm/radeon: print the supported atpx function mask
  drm/radeon: disable pll sharing for DP on DCE4.1
  drm/radeon: fix audio disable on dce6+
  drm/radeon: change audio enable logic
  drm/radeon: enable speaker allocation setup on dce3.2

Christian K?nig (1):
  drm/radeon: fix missing bo reservation

Jerome Glisse (1):
  drm/radeon: free uvd ring on unload

 drivers/gpu/drm/radeon/atombios_crtc.c   | 16 +++-
 drivers/gpu/drm/radeon/dce6_afmt.c   | 15 +--
 drivers/gpu/drm/radeon/evergreen.c   |  2 +-
 drivers/gpu/drm/radeon/evergreen_hdmi.c  | 26 +++---
 drivers/gpu/drm/radeon/r600_audio.c  | 14 --
 drivers/gpu/drm/radeon/r600_hdmi.c   | 15 +++
 drivers/gpu/drm/radeon/radeon.h  |  6 ++
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |  3 ++-
 drivers/gpu/drm/radeon/radeon_kms.c  |  6 ++
 drivers/gpu/drm/radeon/radeon_uvd.c  |  2 ++
 drivers/gpu/drm/radeon/rv770.c   |  2 +-
 11 files changed, 72 insertions(+), 35 deletions(-)

[PATCH] drm/radeon: TTM must be init with cpu-visible VRAM

2014-02-27 Thread Lauri Kasanen

Without this, a bo may get created in the cpu-inaccessible vram.
Before the CP engines get setup, all copies are done via cpu memcpy.

This means that the cpu tries to read from inaccessible memory, fails,
and the radeon module proceeds to disable acceleration.

Doing this has no downsides, as the real VRAM size gets set as soon as the
CP engines get init.

This is a candidate for 3.14 fixes.

Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 3aa853c..35eae91 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -715,6 +715,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
}
+   radeon_ttm_set_active_vram_size(rdev, rdev->mc.visible_vram_size);
+
r = radeon_bo_create(rdev, 256 * 1024, PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM,
 NULL, &rdev->stollen_vga_memory);
-- 
1.8.3.1

[Bug 73504] Segfault in _save_Normal3fv running FlightGear

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

--- Comment #8 from nine at detonation.org ---
I've been running your patches for two weeks now forward porting them to
current git master.  FlightGear has been perfectly stable with them.

Unfortunatley I now get compilation errors and since I don't know the code base
at all they are kind of hard to fix. See any chance you can commit them to
master?

-- 
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/20140227/da8efbe1/attachment.html>

[RFC] drm/ttm: Add optional support for two-ended allocation

2014-02-27 Thread Lauri Kasanen

Allocating small bos from one end and large ones from the other helps
improve the quality of fragmentation.

I have measured a suitable threshold to reduce eviction by up to 20%,
and to cause no harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases improved slightly (openarena, urban 
terror).

This depends on "drm: Optionally create mm blocks from top-to-bottom" by
Chris Wilson, and so is just RFC for now.
---
 drivers/gpu/drm/ttm/ttm_bo.c |  4 +++-
 drivers/gpu/drm/ttm/ttm_bo_manager.c | 12 +---
 include/drm/ttm/ttm_bo_driver.h  |  5 -
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a066513..7f30c2d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1450,7 +1450,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
   struct ttm_bo_global *glob,
   struct ttm_bo_driver *driver,
   uint64_t file_page_offset,
-  bool need_dma32)
+  bool need_dma32,
+  uint32_t alloc_threshold)
 {
int ret = -EINVAL;

@@ -1473,6 +1474,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
bdev->dev_mapping = NULL;
bdev->glob = glob;
bdev->need_dma32 = need_dma32;
+   bdev->alloc_threshold = alloc_threshold;
bdev->val_seq = 0;
spin_lock_init(&bdev->fence_lock);
mutex_lock(&glob->device_list_mutex);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index c58eba33..bd1cbf1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -55,6 +55,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager 
*man,
struct ttm_range_manager *rman = (struct ttm_range_manager *) man->priv;
struct drm_mm *mm = &rman->mm;
struct drm_mm_node *node = NULL;
+   enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
unsigned long lpfn;
int ret;

@@ -66,11 +67,16 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager 
*man,
if (!node)
return -ENOMEM;

+   if (man->bdev->alloc_threshold &&
+   man->bdev->alloc_threshold < (mem->num_pages * PAGE_SIZE))
+   aflags = DRM_MM_CREATE_TOP;
+
spin_lock(&rman->lock);
-   ret = drm_mm_insert_node_in_range(mm, node, mem->num_pages,
- mem->page_alignment,
+   ret = drm_mm_insert_node_in_range_generic(mm, node, mem->num_pages,
+ mem->page_alignment, 0,
  placement->fpfn, lpfn,
- DRM_MM_SEARCH_BEST);
+ DRM_MM_SEARCH_BEST,
+ aflags);
spin_unlock(&rman->lock);

if (unlikely(ret)) {
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 32d34eb..831320e 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -565,6 +565,7 @@ struct ttm_bo_device {
struct delayed_work wq;

bool need_dma32;
+   uint32_t alloc_threshold;
 };

 /**
@@ -758,7 +759,9 @@ extern int ttm_bo_device_release(struct ttm_bo_device 
*bdev);
 extern int ttm_bo_device_init(struct ttm_bo_device *bdev,
  struct ttm_bo_global *glob,
  struct ttm_bo_driver *driver,
- uint64_t file_page_offset, bool need_dma32);
+ uint64_t file_page_offset,
+ bool need_dma32,
+ uint32_t alloc_threshold);

 /**
  * ttm_bo_unmap_virtual
-- 
1.8.3.1

[Bug 70701] With DPM enabled, Radeon 4570 (R710) doesn't remain in Single_Disp state

2014-02-27 Thread bugzilla-dae...@bugzilla.kernel.org

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

Abhinav K  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

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

[PATCH 0/4] Expose primary planes to userspace

One of the stepping stones on the way to atomic/nuclear operation is to expose
CRTC primary planes (and eventually cursor planes too) to userspace in the same
manner that sprites/overlays are today.  This patch series takes the first step
of allowing drivers to register a CRTC's primary plane with the DRM core; the
core will then include this primary plane in the plane list returned to
userspace for clients that set an appropriate client capability bit.

This patchset isn't terribly interesting on its own; you can call the
traditional KMS plane API's (like SetPlane) on the CRTC's primary plane now,
but this doesn't really allow us to do anything we couldn't before.  The real
goal here is to pave the way for a cleaner API as we move toward atomic/nuclear
updates and the eventual property-ification of all settings.

This patch set only updates the i915 driver at the moment, but drivers that
aren't updated should continue to function as they have in the past (i.e., the
plane list returned to userspace will contain only sprite/overlay planes,
regardless of whether the userspace client sets the capability bit or not).

The patch set is organized as follows:
 - Patch 1 updates the DRM core with general support for primary planes, adding
   the interface for drivers to register primary planes, and a client cap bit
   that determines whether these primary planes should be returned to userspace
   clients.

 - Patch 2 adds a new "plane type" property to plane objects which allow
   userspace to distinguish primary planes (and probably cursor planes in the
   future) from regular sprite/overlay planes.

 - Patch 3 simply renames the i915 'update_plane' functions in intel_display.c
   to 'update_primary_plane.'  This change just helps prevent confusion between
   these functions and the similarly named sprite-related ones in
   intel_sprite.c.  We also rename the intel_disable_primary_plane() function
   to prevent confusion with a new intel_primary_plane_disable() function
   added in patch #4.

 - Patch 4 updates the i915 driver to create a primary plane for each CRTC at
   CRTC initialization time and register it with the DRM core.  The setplane
   handler for primary planes simply performs an MMIO flip of the provided
   framebuffer.

Matt Roper (4):
  drm: Add support for CRTC primary planes
  drm: Add plane type property
  drm/i915: Rename similar plane functions to avoid confusion
  drm/i915: Register primary plane for each CRTC

 drivers/gpu/drm/drm_crtc.c   | 200 ++-
 drivers/gpu/drm/drm_ioctl.c  |   5 +
 drivers/gpu/drm/i915/i915_drv.h  |   5 +-
 drivers/gpu/drm/i915/intel_display.c | 132 ---
 include/drm/drmP.h   |   2 +
 include/drm/drm_crtc.h   |  12 +++
 include/uapi/drm/drm.h   |   8 ++
 include/uapi/drm/drm_mode.h  |   3 +
 8 files changed, 343 insertions(+), 24 deletions(-)

-- 
1.8.5.1

[PATCH 2/4] drm: Add plane type property

Add a plane type property to allow userspace to distinguish
sprite/overlay planes from primary planes.  In the future we may extend
this to cover cursor planes as well.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c  | 32 
 include/drm/drm_crtc.h  |  1 +
 include/uapi/drm/drm_mode.h |  3 +++
 3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 21c6d4b..1032eaf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -114,6 +114,14 @@ static const struct drm_prop_enum_list 
drm_dpms_enum_list[] =

 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)

+static const struct drm_prop_enum_list drm_plane_type_enum_list[] =
+{
+   { DRM_MODE_PLANE_TYPE_SPRITE, "Sprite" },
+   { DRM_MODE_PLANE_TYPE_PRIMARY, "Primary" },
+};
+
+DRM_ENUM_NAME_FN(drm_get_plane_type, drm_plane_type_enum_list)
+
 /*
  * Optional properties
  */
@@ -1046,6 +1054,10 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
INIT_LIST_HEAD(&plane->head);
}

+   drm_object_attach_property(&plane->base,
+  dev->mode_config.plane_type_property,
+  DRM_MODE_PLANE_TYPE_SPRITE);
+
  out:
drm_modeset_unlock_all(dev);

@@ -1114,6 +1126,10 @@ int drm_plane_set_primary(struct drm_device *dev, struct 
drm_plane *plane,
dev->mode_config.num_primary_plane++;
INIT_LIST_HEAD(&plane->head);

+   drm_object_attach_property(&plane->base,
+  dev->mode_config.plane_type_property,
+  DRM_MODE_PLANE_TYPE_PRIMARY);
+
  out:
drm_modeset_unlock_all(dev);

@@ -1236,6 +1252,21 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
return 0;
 }

+static int drm_mode_create_standard_plane_properties(struct drm_device *dev)
+{
+   struct drm_property *type;
+
+   /*
+* Standard properties (apply to all planes)
+*/
+   type = drm_property_create_enum(dev, 0,
+   "TYPE", drm_plane_type_enum_list,
+   ARRAY_SIZE(drm_plane_type_enum_list));
+   dev->mode_config.plane_type_property = type;
+
+   return 0;
+}
+
 /**
  * drm_mode_create_dvi_i_properties - create DVI-I specific connector 
properties
  * @dev: DRM device
@@ -4211,6 +4242,7 @@ void drm_mode_config_init(struct drm_device *dev)

drm_modeset_lock_all(dev);
drm_mode_create_standard_connector_properties(dev);
+   drm_mode_create_standard_plane_properties(dev);
drm_modeset_unlock_all(dev);

/* Just to be sure */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 33a955b..d25cd9c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -884,6 +884,7 @@ struct drm_mode_config {
struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
+   struct drm_property *plane_type_property;

/* DVI-I properties */
struct drm_property *dvi_i_subconnector_property;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f104c26..c19705b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -496,4 +496,7 @@ struct drm_mode_destroy_dumb {
uint32_t handle;
 };

+#define DRM_MODE_PLANE_TYPE_SPRITE  0
+#define DRM_MODE_PLANE_TYPE_PRIMARY 1
+
 #endif
-- 
1.8.5.1

[PATCH 1/4] drm: Add support for CRTC primary planes

Allow drivers to provide a drm_plane structure corresponding to a CRTC's
primary plane.  These planes will be included in the plane list for any
clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c  | 168 ++--
 drivers/gpu/drm/drm_ioctl.c |   5 ++
 include/drm/drmP.h  |   2 +
 include/drm/drm_crtc.h  |  11 +++
 include/uapi/drm/drm.h  |   8 +++
 5 files changed, 189 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 35ea15d..21c6d4b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -274,6 +274,74 @@ const char *drm_get_connector_status_name(enum 
drm_connector_status status)
 }
 EXPORT_SYMBOL(drm_get_connector_status_name);

+/*
+ * Default set of pixel formats supported by primary planes.  This matches the
+ * set of formats accepted by the traditional modesetting interfaces; drivers
+ * need only provide their own format list if it differs from the default.
+ */
+static const uint32_t default_primary_plane_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB332,
+   DRM_FORMAT_BGR233,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBX,
+   DRM_FORMAT_BGRX,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_RGBA,
+   DRM_FORMAT_BGRA,
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_XBGR1555,
+   DRM_FORMAT_RGBX5551,
+   DRM_FORMAT_BGRX5551,
+   DRM_FORMAT_ARGB1555,
+   DRM_FORMAT_ABGR1555,
+   DRM_FORMAT_RGBA5551,
+   DRM_FORMAT_BGRA5551,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_BGR565,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBX,
+   DRM_FORMAT_BGRX,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_RGBA,
+   DRM_FORMAT_BGRA,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_RGBX1010102,
+   DRM_FORMAT_BGRX1010102,
+   DRM_FORMAT_ARGB2101010,
+   DRM_FORMAT_ABGR2101010,
+   DRM_FORMAT_RGBA1010102,
+   DRM_FORMAT_BGRA1010102,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_AYUV,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_NV21,
+   DRM_FORMAT_NV16,
+   DRM_FORMAT_NV61,
+   DRM_FORMAT_NV24,
+   DRM_FORMAT_NV42,
+   DRM_FORMAT_YUV410,
+   DRM_FORMAT_YVU410,
+   DRM_FORMAT_YUV411,
+   DRM_FORMAT_YVU411,
+   DRM_FORMAT_YUV420,
+   DRM_FORMAT_YVU420,
+   DRM_FORMAT_YUV422,
+   DRM_FORMAT_YVU422,
+   DRM_FORMAT_YUV444,
+   DRM_FORMAT_YVU444,
+};
+
 /**
  * drm_get_subpixel_order_name - return a string for a given subpixel enum
  * @order: enum of subpixel_order
@@ -921,7 +989,7 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 EXPORT_SYMBOL(drm_encoder_cleanup);

 /**
- * drm_plane_init - Initialise a new plane object
+ * drm_plane_init - Initialise a new sprite plane object
  * @dev: DRM device
  * @plane: plane object to init
  * @possible_crtcs: bitmask of possible CRTCs
@@ -930,7 +998,9 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
  * @format_count: number of elements in @formats
  * @priv: plane is private (hidden from userspace)?
  *
- * Inits a new object created as base part of a driver plane object.
+ * Inits a new object created as base part of a driver plane object.  This
+ * function should only be called for traditional sprite/overlay planes.
+ * Primary planes should be initialized via @drm_plane_set_primary.
  *
  * RETURNS:
  * Zero on success, error code on failure.
@@ -984,6 +1054,74 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
 EXPORT_SYMBOL(drm_plane_init);

 /**
+ * drm_plane_set_primary - Supply a primary plane for a CRTC
+ * @dev DRM device
+ * @plane: plane object representing the primary plane
+ * @crtc: CRTC this plane is associated with
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*).  If NULL, the
+ *   default list of formats traditionally supported by modesetting
+ *   API's will be used and @format_count will be ignored.
+ * @format_count: number of elements in @formats
+ *
+ * Provides a drm_plane representing a CRTC's primary plane.  This plane will
+ * only be exposed to clients that set the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES
+ * capability bit.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+int drm_plane_set_primary(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ const struct drm_plane_funcs *funcs,
+ const uint32_t *formats, uint32_t format_count)
+{
+   int ret;
+
+   drm_modeset_lock_all(dev);
+
+   ret

[PATCH 3/4] drm/i915: Rename similar plane functions to avoid confusion

The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.

On a similar note, intel_display.c already had a function called
intel_disable_primary_plane() that programs the hardware to disable a
pipe's primary plane.  When we hook up primary planes through the DRM
plane interface, one of the natural handler names will be
intel_primary_plane_disable(), which is very similar.  To avoid
confusion, rename the existing intel_disable_primary_plane() to
intel_disable_primary_hw_plane() to make the two names a little more
distinct.

Cc: Intel Graphics Development 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +++--
 drivers/gpu/drm/i915/intel_display.c | 40 +---
 2 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c64831..fc36e6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -450,8 +450,9 @@ struct drm_i915_display_funcs {
  struct drm_framebuffer *fb,
  struct drm_i915_gem_object *obj,
  uint32_t flags);
-   int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
-   int x, int y);
+   int (*update_primary_plane)(struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   int x, int y);
void (*hpd_irq_setup)(struct drm_device *dev);
/* clock updates for mode set */
/* cursor updates */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f19e6ea..9757010 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1905,15 +1905,15 @@ static void intel_enable_primary_plane(struct 
drm_i915_private *dev_priv,
 }

 /**
- * intel_disable_primary_plane - disable the primary plane
+ * intel_disable_primary_hw_plane - disable the primary hardware plane
  * @dev_priv: i915 private structure
  * @plane: plane to disable
  * @pipe: pipe consuming the data
  *
  * Disable @plane; should be an independent operation.
  */
-static void intel_disable_primary_plane(struct drm_i915_private *dev_priv,
-   enum plane plane, enum pipe pipe)
+static void intel_disable_primary_hw_plane(struct drm_i915_private *dev_priv,
+  enum plane plane, enum pipe pipe)
 {
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
@@ -2047,8 +2047,9 @@ unsigned long intel_gen4_compute_page_offset(int *x, int 
*y,
}
 }

-static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
-int x, int y)
+static int i9xx_update_primary_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int x, int y)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2147,8 +2148,9 @@ static int i9xx_update_plane(struct drm_crtc *crtc, 
struct drm_framebuffer *fb,
return 0;
 }

-static int ironlake_update_plane(struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int x, int y)
+static int ironlake_update_primary_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int x, int y)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2252,7 +2254,7 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
dev_priv->display.disable_fbc(dev);
intel_increase_pllclock(crtc);

-   return dev_priv->display.update_plane(crtc, fb, x, y);
+   return dev_priv->display.update_primary_plane(crtc, fb, x, y);
 }

 void intel_display_handle_reset(struct drm_device *dev)
@@ -2292,7 +2294,7 @@ void intel_display_handle_reset(struct drm_device *dev)
 * a NULL crtc->fb.
 */
if (intel_crtc->active && crtc->fb)
-   dev_priv->display.update_plane(crtc, crtc->fb,
+   dev_priv->display.update_primary_plane(crtc, crtc->fb,
   crtc->x, crtc->y);
mutex_unlock(&crtc->mutex);
}
@@ -2385,7 +2387,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
}

-   ret = dev_priv->display.update_plane(crtc, fb, x, y);
+   ret = dev_priv->display.update_primary_plane(crtc, fb, x, y);

[PATCH 4/4] drm/i915: Register primary plane for each CRTC

Create a primary plane at CRTC init and hook up handlers for the various
operations that may be performed on it.  The DRM core will only
advertise the primary planes to clients that set the appropriate
capability bit.

Since we're limited to the legacy plane operations at the moment
(SetPlane and such) this isn't terribly interesting yet; the plane
update handler will perform an MMIO flip of the display plane and the
disable handler will disable the CRTC.  Once we migrate more of the
plane and CRTC info over to properties in preparation for atomic/nuclear
operations, primary planes will be more useful.

Cc: Intel Graphics Development 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 92 
 1 file changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9757010..d9a5cd5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8260,6 +8260,10 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)

intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);

+   drm_plane_cleanup(crtc->primary_plane);
+   kfree(crtc->primary_plane);
+   crtc->primary_plane = NULL;
+
drm_crtc_cleanup(crtc);

kfree(intel_crtc);
@@ -10272,17 +10276,105 @@ static void intel_shared_dpll_init(struct drm_device 
*dev)
BUG_ON(dev_priv->num_shared_dpll > I915_NUM_PLLS);
 }

+static int
+intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   /* setplane API takes shifted source rectangle values; unshift them */
+   src_x >>= 16;
+   src_y >>= 16;
+   src_w >>= 16;
+   src_h >>= 16;
+
+   if (fb->width < 3 || fb->height < 3 || fb->pitches[0] > 16384) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer for primary plane\n");
+   return -EINVAL;
+   }
+
+   /*
+* Current hardware can't reposition the primary plane or scale it
+* (although this could change in the future).  This means that we
+* don't actually need any of the destination (crtc) rectangle values,
+* or the source rectangle width/height; only the source x/y winds up
+* getting used for panning.  Nevertheless, let's sanity check the
+* incoming values to make sure userspace didn't think it could scale
+* or reposition this plane.
+*/
+   if (crtc_w != crtc->mode.hdisplay || crtc_h != crtc->mode.vdisplay ||
+   crtc_x != 0 || crtc_y != 0) {
+   DRM_DEBUG_KMS("Primary plane must cover entire CRTC\n");
+   return -EINVAL;
+   }
+   if (crtc_w != src_w || crtc_h != src_h) {
+   DRM_DEBUG_KMS("Can't scale primary plane\n");
+   return -EINVAL;
+   }
+
+   intel_pipe_set_base(crtc, src_x, src_y, fb);
+   dev_priv->display.crtc_enable(crtc);
+
+   return 0;
+}
+
+static int
+intel_primary_plane_disable(struct drm_plane *plane)
+{
+   struct drm_device *dev = plane->dev;
+   drm_i915_private_t *dev_priv = dev->dev_private;
+
+   if (!plane->fb)
+   return 0;
+
+   if (WARN_ON(!plane->crtc || plane->crtc->primary_plane != plane))
+   return -EINVAL;
+
+   dev_priv->display.crtc_disable(plane->crtc);
+
+   return 0;
+}
+
+static void intel_primary_plane_destroy(struct drm_plane *plane)
+{
+   /*
+* Since primary planes are never put on the mode_config plane list,
+* this entry point should never be called.  Primary plane cleanup
+* happens during CRTC destruction.
+*/
+   BUG();
+}
+
+static const struct drm_plane_funcs intel_primary_plane_funcs = {
+   .update_plane = intel_primary_plane_setplane,
+   .disable_plane = intel_primary_plane_disable,
+   .destroy = intel_primary_plane_destroy,
+};
+
 static void intel_crtc_init(struct drm_device *dev, int pipe)
 {
drm_i915_private_t *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc;
+   struct drm_plane *primary_plane;
int i;

intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
if (intel_crtc == NULL)
return;

+   primary_plane = kzalloc(sizeof(*primary_plane), GFP_KERNEL);
+   if (primary_plane == NULL) {
+   kfree(intel_crtc);
+   return;
+   }
+
drm_crtc_init(dev, &intel_crtc->base, &intel_crtc_funcs);
+   drm_plane_set_primary(dev, primary_plane, &intel_crtc->base,
+ &intel_primary_plane_funcs, NULL, 0);

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Borislav Petkov

On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
> I won't be able to look at that before Monday I'm afraid (personal
> stuff).

No worries, sir, whenever. It can wait.

Thanks a lot!

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH 2/4] drm: Add plane type property

2014-02-27 Thread Rob Clark

On Thu, Feb 27, 2014 at 5:14 PM, Matt Roper  
wrote:
> Add a plane type property to allow userspace to distinguish
> sprite/overlay planes from primary planes.  In the future we may extend
> this to cover cursor planes as well.
>
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c  | 32 
>  include/drm/drm_crtc.h  |  1 +
>  include/uapi/drm/drm_mode.h |  3 +++
>  3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 21c6d4b..1032eaf 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -114,6 +114,14 @@ static const struct drm_prop_enum_list 
> drm_dpms_enum_list[] =
>
>  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>
> +static const struct drm_prop_enum_list drm_plane_type_enum_list[] =
> +{
> +   { DRM_MODE_PLANE_TYPE_SPRITE, "Sprite" },

I'm not the *hugest* fan of using the name "sprite".. at least that
too me implies sort of a subset of possible functionality of a plane..

> +   { DRM_MODE_PLANE_TYPE_PRIMARY, "Primary" },
> +};
> +
> +DRM_ENUM_NAME_FN(drm_get_plane_type, drm_plane_type_enum_list)
> +
>  /*
>   * Optional properties
>   */
> @@ -1046,6 +1054,10 @@ int drm_plane_init(struct drm_device *dev, struct 
> drm_plane *plane,
> INIT_LIST_HEAD(&plane->head);
> }
>
> +   drm_object_attach_property(&plane->base,
> +  dev->mode_config.plane_type_property,
> +  DRM_MODE_PLANE_TYPE_SPRITE);
> +
>   out:
> drm_modeset_unlock_all(dev);
>
> @@ -1114,6 +1126,10 @@ int drm_plane_set_primary(struct drm_device *dev, 
> struct drm_plane *plane,


fwiw, this comment probably belongs in #1/4 but:

you probably don't need to introduce drm_plane_set_primary()..
instead you could just rename the 'bool priv' to 'bool prim'.  I think
there are just three drivers using primary planes..  I'm not 100% sure
about exynos, but both omap and msm, the private plane == primary
plane.  At least it was the intention to morph that into primary
planes.

Anyways, other than that I like the patchset.  Hopefully I should get
to rebasing the atomic patches real soon now, so I'll try rebasing on
top of this and see how it goes.

BR,
-R


> dev->mode_config.num_primary_plane++;
> INIT_LIST_HEAD(&plane->head);
>
> +   drm_object_attach_property(&plane->base,
> +  dev->mode_config.plane_type_property,
> +  DRM_MODE_PLANE_TYPE_PRIMARY);
> +
>   out:
> drm_modeset_unlock_all(dev);
>
> @@ -1236,6 +1252,21 @@ static int 
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
> return 0;
>  }
>
> +static int drm_mode_create_standard_plane_properties(struct drm_device *dev)
> +{
> +   struct drm_property *type;
> +
> +   /*
> +* Standard properties (apply to all planes)
> +*/
> +   type = drm_property_create_enum(dev, 0,
> +   "TYPE", drm_plane_type_enum_list,
> +   ARRAY_SIZE(drm_plane_type_enum_list));
> +   dev->mode_config.plane_type_property = type;
> +
> +   return 0;
> +}
> +
>  /**
>   * drm_mode_create_dvi_i_properties - create DVI-I specific connector 
> properties
>   * @dev: DRM device
> @@ -4211,6 +4242,7 @@ void drm_mode_config_init(struct drm_device *dev)
>
> drm_modeset_lock_all(dev);
> drm_mode_create_standard_connector_properties(dev);
> +   drm_mode_create_standard_plane_properties(dev);
> drm_modeset_unlock_all(dev);
>
> /* Just to be sure */
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 33a955b..d25cd9c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -884,6 +884,7 @@ struct drm_mode_config {
> struct list_head property_blob_list;
> struct drm_property *edid_property;
> struct drm_property *dpms_property;
> +   struct drm_property *plane_type_property;
>
> /* DVI-I properties */
> struct drm_property *dvi_i_subconnector_property;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index f104c26..c19705b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -496,4 +496,7 @@ struct drm_mode_destroy_dumb {
> uint32_t handle;
>  };
>
> +#define DRM_MODE_PLANE_TYPE_SPRITE  0
> +#define DRM_MODE_PLANE_TYPE_PRIMARY 1
> +
>  #endif
> --
> 1.8.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

--- Comment #15 from Marek Ol??k  ---
Please file separate bug reports for your issues. This is only a meta bug
aggregating all HyperZ bugs.

-- 
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/20140227/e68e899d/attachment.html>

[PATCH 2/4] drm: Add plane type property

On Thu, Feb 27, 2014 at 05:39:00PM -0500, Rob Clark wrote:
> On Thu, Feb 27, 2014 at 5:14 PM, Matt Roper  
> wrote:
> > Add a plane type property to allow userspace to distinguish
> > sprite/overlay planes from primary planes.  In the future we may extend
> > this to cover cursor planes as well.
> >
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/drm_crtc.c  | 32 
> >  include/drm/drm_crtc.h  |  1 +
> >  include/uapi/drm/drm_mode.h |  3 +++
> >  3 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 21c6d4b..1032eaf 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -114,6 +114,14 @@ static const struct drm_prop_enum_list 
> > drm_dpms_enum_list[] =
> >
> >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> >
> > +static const struct drm_prop_enum_list drm_plane_type_enum_list[] =
> > +{
> > +   { DRM_MODE_PLANE_TYPE_SPRITE, "Sprite" },
> 
> I'm not the *hugest* fan of using the name "sprite".. at least that
> too me implies sort of a subset of possible functionality of a plane..

Any suggestions on a better name?  Maybe call them "traditional" planes
and then just give new names to the other types (primary, cursor) that
we wind up exposing when appropriate client caps are set?

> 
> > +   { DRM_MODE_PLANE_TYPE_PRIMARY, "Primary" },
> > +};
> > +
> > +DRM_ENUM_NAME_FN(drm_get_plane_type, drm_plane_type_enum_list)
> > +
> >  /*
> >   * Optional properties
> >   */
> > @@ -1046,6 +1054,10 @@ int drm_plane_init(struct drm_device *dev, struct 
> > drm_plane *plane,
> > INIT_LIST_HEAD(&plane->head);
> > }
> >
> > +   drm_object_attach_property(&plane->base,
> > +  dev->mode_config.plane_type_property,
> > +  DRM_MODE_PLANE_TYPE_SPRITE);
> > +
> >   out:
> > drm_modeset_unlock_all(dev);
> >
> > @@ -1114,6 +1126,10 @@ int drm_plane_set_primary(struct drm_device *dev, 
> > struct drm_plane *plane,
> 
> 
> fwiw, this comment probably belongs in #1/4 but:
> 
> you probably don't need to introduce drm_plane_set_primary()..
> instead you could just rename the 'bool priv' to 'bool prim'.  I think
> there are just three drivers using primary planes..  I'm not 100% sure
> about exynos, but both omap and msm, the private plane == primary
> plane.  At least it was the intention to morph that into primary
> planes.

I'd like to handle cursors with this eventually as well, so I'm not sure
whether just changing the meaning of priv by itself will get us
everything we need.  It seems like we probably need to provide a whole
lot more information about the capabilities and limitations of each
plane at drm_plane_init() and then expose those all as plane
properties so that userspace knows what it can and can't do.  In theory
we could expose cursor planes exactly the same way we expose
"traditional" planes today as long as we made sufficient plane
properties available to userspace to describe the min/max size
limitations and such.

> 
> Anyways, other than that I like the patchset.  Hopefully I should get
> to rebasing the atomic patches real soon now, so I'll try rebasing on
> top of this and see how it goes.
> 
> BR,
> -R

Sounds good; thanks for the review.


Matt

-- 
Matt Roper
Graphics Software Engineer
ISG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

2014-02-27 Thread Carl Worth

With Haswell, 5.4Gbps is supported. And almost all of the code was
already in place already. All that was missing was this tiny bit of
additional wiring.

Signed-off-by: Carl Worth 
Reviewed-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_dp.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 57552eb..ce9739e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -101,7 +101,11 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
case DP_LINK_BW_1_62:
case DP_LINK_BW_2_7:
break;
-   case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */
+   case DP_LINK_BW_5_4:
+   /* XXX: But not HASWELL ULX. */
+   if (IS_HASWELL(intel_dp_to_dev(intel_dp)))
+   break;
+   /* Prior to HASWELL, maximum support is for 2.7 Gbps */
max_link_bw = DP_LINK_BW_2_7;
break;
default:
@@ -810,12 +814,24 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = encoder->new_crtc;
struct intel_connector *intel_connector = intel_dp->attached_connector;
-   int lane_count, clock;
+   int lane_count;
int max_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
-   int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 : 
0;
int bpp, mode_rate;
-   static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
int link_avail, link_clock;
+   int max_link_bw;
+   /* The clock and max_clock values are an index into bws. */
+   int clock, max_clock = 0;
+   static int bws[3] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4};
+
+   max_link_bw = intel_dp_max_link_bw(intel_dp);
+
+   for (clock = 0; clock < ARRAY_SIZE(bws); clock++) {
+   if (bws[clock] == max_link_bw) {
+   max_clock = clock;
+   break;
+   }
+   }
+

if (HAS_PCH_SPLIT(dev) && !HAS_DDI(dev) && port != PORT_A)
pipe_config->has_pch_encoder = true;
-- 
1.9.0

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Stephane Eranian

On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov  wrote:
> Can you please, pretty please, not top-post...
>
> On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
>> Hi,
>>
>> Ok, so I am getting the same error message as you.
>> I checked my syslog now.
>>
>> I have my uncore_imc addr=0xfed1 (after masking)
>>
>> And I also have pnp 00:01 overlapping the imc range completely.
>>
>> What pnp device does  it really represent? the DRAM controller?
>>
>> So I think my laptop behaves like yours.
>
> grep -Er . /sys/devices/pnp0/00\:01/* 2>/dev/null
> /sys/devices/pnp0/00:01/firmware_node/hid:PNP0C02
> ...
>
> so this PNP0C02 is
>
> [0.363943] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
>
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
there to BAR is at a completely different address. Same thing on my Haswell
desktop system.

As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They  hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
not so sure this is all related to the uncore IMC support, though.

> @Rafael, can you please make sense of this whole ACPI gunk?
>
> We have a resource conflict with pnp 00:01, analysis here:
> http://lkml.kernel.org/r/20140226092903.GA22639 at pd.tnic
>
> This is the rest of the 00:01 info from sysfs:
>
> /sys/devices/pnp0/00:01/firmware_node/uid:0
> /sys/devices/pnp0/00:01/firmware_node/path:\_SB_.PCI0.LPC_.SIO_
> /sys/devices/pnp0/00:01/firmware_node/power/control:auto
> /sys/devices/pnp0/00:01/firmware_node/power/runtime_active_time:0
> /sys/devices/pnp0/00:01/firmware_node/power/runtime_status:unsupported
> /sys/devices/pnp0/00:01/firmware_node/power/runtime_suspended_time:0
> /sys/devices/pnp0/00:01/firmware_node/modalias:acpi:PNP0C02:
> /sys/devices/pnp0/00:01/firmware_node/uevent:MODALIAS=acpi:PNP0C02:
> /sys/devices/pnp0/00:01/id:PNP0c02
> /sys/devices/pnp0/00:01/power/control:auto
> /sys/devices/pnp0/00:01/power/runtime_active_time:0
> /sys/devices/pnp0/00:01/power/runtime_status:unsupported
> /sys/devices/pnp0/00:01/power/runtime_suspended_time:0
> /sys/devices/pnp0/00:01/resources:state = active
> /sys/devices/pnp0/00:01/resources:io 0x10-0x1f
> /sys/devices/pnp0/00:01/resources:io 0x90-0x9f
> /sys/devices/pnp0/00:01/resources:io 0x24-0x25
> /sys/devices/pnp0/00:01/resources:io 0x28-0x29
> /sys/devices/pnp0/00:01/resources:io 0x2c-0x2d
> /sys/devices/pnp0/00:01/resources:io 0x30-0x31
> /sys/devices/pnp0/00:01/resources:io 0x34-0x35
> /sys/devices/pnp0/00:01/resources:io 0x38-0x39
> /sys/devices/pnp0/00:01/resources:io 0x3c-0x3d
> /sys/devices/pnp0/00:01/resources:io 0xa4-0xa5
> /sys/devices/pnp0/00:01/resources:io 0xa8-0xa9
> /sys/devices/pnp0/00:01/resources:io 0xac-0xad
> /sys/devices/pnp0/00:01/resources:io 0xb0-0xb5
> /sys/devices/pnp0/00:01/resources:io 0xb8-0xb9
> /sys/devices/pnp0/00:01/resources:io 0xbc-0xbd
> /sys/devices/pnp0/00:01/resources:io 0x50-0x53
> /sys/devices/pnp0/00:01/resources:io 0x72-0x77
> /sys/devices/pnp0/00:01/resources:io 0x400-0x47f
> /sys/devices/pnp0/00:01/resources:io 0x500-0x57f
> /sys/devices/pnp0/00:01/resources:io 0x800-0x80f
> /sys/devices/pnp0/00:01/resources:io 0x15e0-0x15ef
> /sys/devices/pnp0/00:01/resources:io 0x1600-0x167f
> /sys/devices/pnp0/00:01/resources:mem 0xf800-0xfbff
> /sys/devices/pnp0/00:01/resources:mem 0xf000-0x
> /sys/devices/pnp0/00:01/resources:mem 0xfed1c000-0xfed1
> /sys/devices/pnp0/00:01/resources:mem 0xfed1-0xfed13fff
> /sys/devices/pnp0/00:01/resources:mem 0xfed18000-0xfed18fff
> /sys/devices/pnp0/00:01/resources:mem 0xfed19000-0xfed19fff
> /sys/devices/pnp0/00:01/resources:mem 0xfed45000-0xfed4bfff
> /sys/devices/pnp0/00:01/resources:mem 0xfed4-0xfed44fff
> /sys/devices/pnp0/00:01/subsystem/drivers_autoprobe:1
> /sys/devices/pnp0/00:01/uevent:DRIVER=system
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

On 25/02/14 16:23, Philipp Zabel wrote:

> +Freescale i.MX DRM master device
> +
> +
> +The freescale i.MX DRM master device is a virtual device needed to list all
> +IPU or other display interface nodes that comprise the graphics subsystem.
> +
> +Required properties:
> +- compatible: Should be "fsl,imx-drm"
> +- ports: Should contain a list of phandles pointing to display interface 
> ports
> +  of IPU devices
> +
> +example:
> +
> +imx-drm {
> + compatible = "fsl,imx-drm";
> + ports = <&ipu_di0>;
> +};

I'm not a fan of having non-hardware related things in the DT data.
Especially if it makes direct references to our SW, in this case DRM.
There's no DRM on the board. I wanted to avoid all that with OMAP
display bindings.

Is there even need for such a master device? You can find all the
connected display devices from any single display device, by just
following the endpoint links.

>  display at di0 {
>   compatible = "fsl,imx-parallel-display";
>   edid = [edid-data];
> - crtc = <&ipu 0>;
>   interface-pix-fmt = "rgb24";
> +
> + port {
> + display_in: endpoint {
> + remote-endpoint = <&ipu_di0_disp0>;
> + };
> + };
>  };

Shouldn't the pix-fmt be defined in the endpoint node? It is about pixel
format for a particular endpoint, isn't it?

> diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt 
> b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
> index ed93778..578a1fc 100644
> --- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
> +++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
> @@ -50,12 +50,14 @@ have a look at 
> Documentation/devicetree/bindings/video/display-timing.txt.
>  
>  Required properties:
>   - reg : should be <0> or <1>
> - - crtcs : a list of phandles with index pointing to the IPU display 
> interfaces
> -   that can be used as video source for this channel.
>   - fsl,data-mapping : should be "spwg" or "jeida"
>This describes how the color bits are laid out in the
>serialized LVDS signal.
>   - fsl,data-width : should be <18> or <24>
> + - port: A port node with endpoint definitions as defined in
> +   Documentation/devicetree/bindings/media/video-interfaces.txt.
> +   On i.MX6, there should be four ports (port@[0-3]) that correspond
> +   to the four LVDS multiplexer inputs.

Is the ldb something that's on the imx SoC?

Do you have a public branch somewhere? It'd be easier to look at the
final result, as I'm not familiar with imx.

 Tomi


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

[PATCH 2/3] fbdev: move fbdev core files to separate directory

Instead of having fbdev framework core files at the root fbdev
directory, mixed with random fbdev device drivers, move the fbdev core
files to a separate core directory. This makes it much clearer which of
the files are actually part of the fbdev framework, and which are part
of device drivers.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Acked-by: Jingoo Han 
---
 drivers/video/fbdev/Makefile | 16 +---
 drivers/video/fbdev/core/Makefile| 16 
 drivers/video/fbdev/{ => core}/cfbcopyarea.c |  0
 drivers/video/fbdev/{ => core}/cfbfillrect.c |  0
 drivers/video/fbdev/{ => core}/cfbimgblt.c   |  0
 drivers/video/fbdev/{ => core}/fb_ddc.c  |  2 +-
 drivers/video/fbdev/{ => core}/fb_defio.c|  0
 drivers/video/fbdev/{ => core}/fb_draw.h |  0
 drivers/video/fbdev/{ => core}/fb_notify.c   |  0
 drivers/video/fbdev/{ => core}/fb_sys_fops.c |  0
 drivers/video/fbdev/{ => core}/fbcmap.c  |  0
 drivers/video/fbdev/{ => core}/fbcvt.c   |  0
 drivers/video/fbdev/{ => core}/fbmem.c   |  0
 drivers/video/fbdev/{ => core}/fbmon.c   |  2 +-
 drivers/video/fbdev/{ => core}/fbsysfs.c |  0
 drivers/video/fbdev/{ => core}/modedb.c  |  0
 drivers/video/fbdev/{ => core}/svgalib.c |  0
 drivers/video/fbdev/{ => core}/syscopyarea.c |  0
 drivers/video/fbdev/{ => core}/sysfillrect.c |  0
 drivers/video/fbdev/{ => core}/sysimgblt.c   |  0
 drivers/video/fbdev/wmt_ge_rops.c|  2 +-
 21 files changed, 20 insertions(+), 18 deletions(-)
 create mode 100644 drivers/video/fbdev/core/Makefile
 rename drivers/video/fbdev/{ => core}/cfbcopyarea.c (100%)
 rename drivers/video/fbdev/{ => core}/cfbfillrect.c (100%)
 rename drivers/video/fbdev/{ => core}/cfbimgblt.c (100%)
 rename drivers/video/fbdev/{ => core}/fb_ddc.c (99%)
 rename drivers/video/fbdev/{ => core}/fb_defio.c (100%)
 rename drivers/video/fbdev/{ => core}/fb_draw.h (100%)
 rename drivers/video/fbdev/{ => core}/fb_notify.c (100%)
 rename drivers/video/fbdev/{ => core}/fb_sys_fops.c (100%)
 rename drivers/video/fbdev/{ => core}/fbcmap.c (100%)
 rename drivers/video/fbdev/{ => core}/fbcvt.c (100%)
 rename drivers/video/fbdev/{ => core}/fbmem.c (100%)
 rename drivers/video/fbdev/{ => core}/fbmon.c (99%)
 rename drivers/video/fbdev/{ => core}/fbsysfs.c (100%)
 rename drivers/video/fbdev/{ => core}/modedb.c (100%)
 rename drivers/video/fbdev/{ => core}/svgalib.c (100%)
 rename drivers/video/fbdev/{ => core}/syscopyarea.c (100%)
 rename drivers/video/fbdev/{ => core}/sysfillrect.c (100%)
 rename drivers/video/fbdev/{ => core}/sysimgblt.c (100%)

diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 616e0975ae6e..6ef2c66110e3 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -4,25 +4,11 @@

 # Each configuration option enables a list of files.

-obj-y += fb_notify.o
-obj-$(CONFIG_FB)  += fb.o
-fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
- modedb.o fbcvt.o
-fb-objs   := $(fb-y)
+obj-y  += core/

 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/

-obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
-obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
-obj-$(CONFIG_FB_CFB_IMAGEBLIT) += cfbimgblt.o
-obj-$(CONFIG_FB_SYS_FILLRECT)  += sysfillrect.o
-obj-$(CONFIG_FB_SYS_COPYAREA)  += syscopyarea.o
-obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o
-obj-$(CONFIG_FB_SYS_FOPS)  += fb_sys_fops.o
-obj-$(CONFIG_FB_SVGALIB)   += svgalib.o
 obj-$(CONFIG_FB_MACMODES)  += macmodes.o
-obj-$(CONFIG_FB_DDC)   += fb_ddc.o
-obj-$(CONFIG_FB_DEFERRED_IO)   += fb_defio.o
 obj-$(CONFIG_FB_WMT_GE_ROPS)   += wmt_ge_rops.o

 # Hardware specific drivers go first
diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
new file mode 100644
index ..fa306538dac2
--- /dev/null
+++ b/drivers/video/fbdev/core/Makefile
@@ -0,0 +1,16 @@
+obj-y += fb_notify.o
+obj-$(CONFIG_FB)  += fb.o
+fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
+ modedb.o fbcvt.o
+fb-objs   := $(fb-y)
+
+obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
+obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
+obj-$(CONFIG_FB_CFB_IMAGEBLIT) += cfbimgblt.o
+obj-$(CONFIG_FB_SYS_FILLRECT)  += sysfillrect.o
+obj-$(CONFIG_FB_SYS_COPYAREA)  += syscopyarea.o
+obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o
+obj-$(CONFIG_FB_SYS_FOPS)  += fb_sys_fops.o
+obj-$(CONFIG_FB_SVGALIB)   += svgalib.o
+obj-$(CONFIG_FB_DDC)   += fb_ddc.o
+obj-$(CONFIG_FB_DEFERRED_IO)   += fb_defio.o
diff --git a/drivers/video/fbdev/cfbcopyarea.c 
b/drivers/video/fbdev/core/cfbcopyarea.c
similarity index 100%
rename from drivers/video/fbdev/cfb

[PATCH 3/3] video: Kconfig: move drm and fb into separate menus

At the moment the "Device Drivers / Graphics support" kernel config page
looks rather messy, with DRM and fbdev driver selections on the same
page, some on the top level Graphics support page, some under their
respective subsystems.

If I'm not mistaken, this is caused by the drivers depending on other
things than DRM or FB, which causes Kconfig to arrange the options in
not-so-neat manner.

Both DRM and FB have a main menuconfig option for the whole DRM or FB
subsystem. Optimally, this would be enough to arrange all DRM and FB
options under the respective subsystem, but for whatever reason this
doesn't work reliably.

This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Reviewed-by: Jingoo Han 
---
 drivers/video/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index f0f26a0b746e..70d174090a54 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,9 +21,13 @@ source "drivers/gpu/vga/Kconfig"

 source "drivers/gpu/host1x/Kconfig"

+menu "Direct Rendering Manager"
 source "drivers/gpu/drm/Kconfig"
+endmenu

+menu "Framebuffer Devices"
 source "drivers/video/fbdev/Kconfig"
+endmenu

 source "drivers/video/backlight/Kconfig"

-- 
1.8.3.2

[PATCH 1/3] video: move fbdev to drivers/video/fbdev

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
Acked-by: Geert Uytterhoeven 
Acked-by: Rob Clark 
Acked-by: Jingoo Han 
---
 drivers/Makefile   |4 +-
 drivers/video/Kconfig  | 2483 +---
 drivers/video/Makefile |  168 +-
 drivers/video/{ => fbdev}/68328fb.c|0
 drivers/video/fbdev/Kconfig| 2481 +++
 drivers/video/fbdev/Makefile   |  167 ++
 drivers/video/{ => fbdev}/acornfb.c|0
 drivers/video/{ => fbdev}/acornfb.h|0
 drivers/video/{ => fbdev}/amba-clcd.c  |0
 drivers/video/{ => fbdev}/amifb.c  |0
 drivers/video/{ => fbdev}/arcfb.c  |0
 drivers/video/{ => fbdev}/arkfb.c  |0
 drivers/video/{ => fbdev}/asiliantfb.c |0
 drivers/video/{ => fbdev}/atafb.c  |0
 drivers/video/{ => fbdev}/atafb.h  |0
 drivers/video/{ => fbdev}/atafb_iplan2p2.c |0
 drivers/video/{ => fbdev}/atafb_iplan2p4.c |0
 drivers/video/{ => fbdev}/atafb_iplan2p8.c |0
 drivers/video/{ => fbdev}/atafb_mfb.c  |0
 drivers/video/{ => fbdev}/atafb_utils.h|0
 drivers/video/{ => fbdev}/atmel_lcdfb.c|0
 drivers/video/{ => fbdev}/aty/Makefile |0
 drivers/video/{ => fbdev}/aty/ati_ids.h|0
 drivers/video/{ => fbdev}/aty/aty128fb.c   |0
 drivers/video/{ => fbdev}/aty/atyfb.h  |0
 drivers/video/{ => fbdev}/aty/atyfb_base.c |0
 drivers/video/{ => fbdev}/aty/mach64_accel.c   |0
 drivers/video/{ => fbdev}/aty/mach64_ct.c  |0
 drivers/video/{ => fbdev}/aty/mach64_cursor.c  |0
 drivers/video/{ => fbdev}/aty/mach64_gx.c  |0
 drivers/video/{ => fbdev}/aty/radeon_accel.c   |0
 drivers/video/{ => fbdev}/aty/radeon_backlight.c   |0
 drivers/video/{ => fbdev}/aty/radeon_base.c|0
 drivers/video/{ => fbdev}/aty/radeon_i2c.c |0
 drivers/video/{ => fbdev}/aty/radeon_monitor.c |0
 drivers/video/{ => fbdev}/aty/radeon_pm.c  |0
 drivers/video/{ => fbdev}/aty/radeonfb.h   |0
 drivers/video/{ => fbdev}/au1100fb.c   |0
 drivers/video/{ => fbdev}/au1100fb.h   |0
 drivers/video/{ => fbdev}/au1200fb.c   |0
 drivers/video/{ => fbdev}/au1200fb.h   |0
 drivers/video/{ => fbdev}/auo_k1900fb.c|0
 drivers/video/{ => fbdev}/auo_k1901fb.c|0
 drivers/video/{ => fbdev}/auo_k190x.c  |0
 drivers/video/{ => fbdev}/auo_k190x.h  |0
 drivers/video/{ => fbdev}/bf537-lq035.c|0
 drivers/video/{ => fbdev}/bf54x-lq043fb.c  |0
 drivers/video/{ => fbdev}/bfin-lq035q1-fb.c|0
 drivers/video/{ => fbdev}/bfin-t350mcqb-fb.c   |0
 drivers/video/{ => fbdev}/bfin_adv7393fb.c |0
 drivers/video/{ => fbdev}/bfin_adv7393fb.h |0
 drivers/video/{ => fbdev}/broadsheetfb.c   |0
 drivers/video/{ => fbdev}/bt431.h  |0
 drivers/video/{ => fbdev}/bt455.h  |0
 drivers/video/{ => fbdev}/bw2.c|0
 drivers/video/{ => fbdev}/c2p.h|0
 drivers/video/{ => fbdev}/c2p_core.h   |0
 drivers/video/{ => fbdev}/c2p_iplan2.c |0
 drivers/video/{ => fbdev}/c2p_planar.c |0
 drivers/video/{ => fbdev}/carminefb.c  |0
 drivers/video/{ => fbdev}/carminefb.h  |0
 drivers/video/{ => fbdev}/carminefb_regs.h |0
 drivers/video/{ => fbdev}/cfbcopyarea.c|0
 drivers/video/{ => fbdev}/cfbfillrect.c|0
 drivers/video/{ => fbdev}/cfbimgblt.c  |0
 drivers/video/{ => fbdev}/cg14.c   |0
 drivers/video/{ => fbdev}/cg3.c|0
 drivers/video/{ => fbdev}/cg6.c|0
 drivers/video/{ => fbdev}/chipsfb.c|0
 drivers/video/{ => fbdev}/cirrusfb.c   |0
 drivers/video/{ => fbdev}/clps711xfb.c |0
 drivers/video/{ => fbdev}/cobalt_lcdfb.c   |0
 drivers/video/{ => fbdev}/controlfb.c  |0
 drivers/video/{ => fbdev}/controlfb.h  |0
 dri

[PATCH 0/3] Reorder drivers/video directory

Hi,

This is a re-send of the series, with RFC removed from the subject, and a bunch
of acks added.

I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
make sure this is not a bad idea, doomed to fail horribly.

So this series creates a new directory, drivers/video/fbdev/, to which all
fbdev related files are moved. Also, a new directory, drivers/video/fbdev/core/
is created, to which the core fbdev framework files are moved. This makes the
drivers/video hierarchy much more clear.

Presuming no one has objections to this as such, I wonder what's the least
painful way to merge this? Normally, like any other fbdev change? As a separate
pull request, maybe at -rc2 time frame, based on -rc1? Something else?

 Tomi

Tomi Valkeinen (3):
  video: move fbdev to drivers/video/fbdev
  fbdev: move fbdev core files to separate directory
  video: Kconfig: move drm and fb into separate menus

 drivers/Makefile   |4 +-
 drivers/video/Kconfig  | 2487 +---
 drivers/video/Makefile |  168 +-
 drivers/video/{ => fbdev}/68328fb.c|0
 drivers/video/fbdev/Kconfig| 2481 +++
 drivers/video/fbdev/Makefile   |  153 ++
 drivers/video/{ => fbdev}/acornfb.c|0
 drivers/video/{ => fbdev}/acornfb.h|0
 drivers/video/{ => fbdev}/amba-clcd.c  |0
 drivers/video/{ => fbdev}/amifb.c  |0
 drivers/video/{ => fbdev}/arcfb.c  |0
 drivers/video/{ => fbdev}/arkfb.c  |0
 drivers/video/{ => fbdev}/asiliantfb.c |0
 drivers/video/{ => fbdev}/atafb.c  |0
 drivers/video/{ => fbdev}/atafb.h  |0
 drivers/video/{ => fbdev}/atafb_iplan2p2.c |0
 drivers/video/{ => fbdev}/atafb_iplan2p4.c |0
 drivers/video/{ => fbdev}/atafb_iplan2p8.c |0
 drivers/video/{ => fbdev}/atafb_mfb.c  |0
 drivers/video/{ => fbdev}/atafb_utils.h|0
 drivers/video/{ => fbdev}/atmel_lcdfb.c|0
 drivers/video/{ => fbdev}/aty/Makefile |0
 drivers/video/{ => fbdev}/aty/ati_ids.h|0
 drivers/video/{ => fbdev}/aty/aty128fb.c   |0
 drivers/video/{ => fbdev}/aty/atyfb.h  |0
 drivers/video/{ => fbdev}/aty/atyfb_base.c |0
 drivers/video/{ => fbdev}/aty/mach64_accel.c   |0
 drivers/video/{ => fbdev}/aty/mach64_ct.c  |0
 drivers/video/{ => fbdev}/aty/mach64_cursor.c  |0
 drivers/video/{ => fbdev}/aty/mach64_gx.c  |0
 drivers/video/{ => fbdev}/aty/radeon_accel.c   |0
 drivers/video/{ => fbdev}/aty/radeon_backlight.c   |0
 drivers/video/{ => fbdev}/aty/radeon_base.c|0
 drivers/video/{ => fbdev}/aty/radeon_i2c.c |0
 drivers/video/{ => fbdev}/aty/radeon_monitor.c |0
 drivers/video/{ => fbdev}/aty/radeon_pm.c  |0
 drivers/video/{ => fbdev}/aty/radeonfb.h   |0
 drivers/video/{ => fbdev}/au1100fb.c   |0
 drivers/video/{ => fbdev}/au1100fb.h   |0
 drivers/video/{ => fbdev}/au1200fb.c   |0
 drivers/video/{ => fbdev}/au1200fb.h   |0
 drivers/video/{ => fbdev}/auo_k1900fb.c|0
 drivers/video/{ => fbdev}/auo_k1901fb.c|0
 drivers/video/{ => fbdev}/auo_k190x.c  |0
 drivers/video/{ => fbdev}/auo_k190x.h  |0
 drivers/video/{ => fbdev}/bf537-lq035.c|0
 drivers/video/{ => fbdev}/bf54x-lq043fb.c  |0
 drivers/video/{ => fbdev}/bfin-lq035q1-fb.c|0
 drivers/video/{ => fbdev}/bfin-t350mcqb-fb.c   |0
 drivers/video/{ => fbdev}/bfin_adv7393fb.c |0
 drivers/video/{ => fbdev}/bfin_adv7393fb.h |0
 drivers/video/{ => fbdev}/broadsheetfb.c   |0
 drivers/video/{ => fbdev}/bt431.h  |0
 drivers/video/{ => fbdev}/bt455.h  |0
 drivers/video/{ => fbdev}/bw2.c|0
 drivers/video/{ => fbdev}/c2p.h|0
 drivers/video/{ => fbdev}/c2p_core.h   |0
 drivers/video/{ => fbdev}/c2p_iplan2.c |0
 drivers/video/{ => fbdev}/c2p_planar.c |0
 drivers/video/{ => fbdev}/carminefb.c  |0
 drivers/video/{ => fbdev}/carminefb.h  |0
 drivers/video/{ => fbdev}/carminefb_regs.h |0
 drivers/video/{ => fbdev}/cg14.c   |0
 drivers/video/{ => fbdev}/cg3.c|0
 drivers/video/{ => fbdev}/cg6.c|0
 drivers/video/{ => fbdev}/chipsfb.c|0
 drivers/video/{ => fbdev}/cirrusfb.c   |0
 drivers/video/{ => fbdev}/clps711xfb.c |0
 drivers/video/{ =>

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Stephane Eranian

On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra  
wrote:
> On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
>> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra  
>> wrote:
>> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
>> >> They  hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. 
>> >> I am
>> >> not so sure this is all related to the uncore IMC support, though.
>> >
>> > Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial
>> > patch missing. I'll try and get Thomas to merge it if Ingo doesn't show
>> > up soon.
>>
>> Yes, I mean from tip.git.
>
> lkml.kernel.org/r/20140224121218.GR15586 at twins.programming.kicks-ass.net
>
> Should cure things; unless there's more borkage.

Works again now with your patch.
Thanks.

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

On 27/02/14 15:43, Russell King - ARM Linux wrote:

> That may be - but the problem with CDF solving this problem is that it's
> wrong.  It's fixing what is in actual fact a *generic* problem in a much
> too specific way.  To put it another way, it's forcing everyone to fix
> the same problem in their own separate ways because no one is willing to
> take a step back and look at the larger picture.
> 
> We can see that because ASoC has exactly the same problem - it has to
> wait until all devices (DMA, CPU DAIs, codecs etc) are present before it
> can initialise, just like DRM.  Can you re-use the CDF solution for ASoC?
> No.  Can it be re-used elsewhere in non-display subsystems?  No.
> 
> Therefore, CDF is yet another implementation specific solution to a
> generic problem which can't be re-used.
> 
> Yes, I realise that CDF may do other stuff, but because of the above, it's
> a broken solution.

What? Because CDF didn't fix a particular subproblem for everyone, it's
broken solution? Or did I miss your point?

The main point of CDF is not solving the initialization issue. If that
was the point, it would've been Common Initialization Framework.

The main point of CDF is to allow us to have encoder and panel drivers
that can be used by all platforms, in complex display pipeline setups.
It just also has to have some solution for the initialization problem to
get things working.

In fact, Laurent's CDF version has a solution for init problem which, I
my memory serves me right, is very much similar to yours. It just wasn't
generic. I don't remember if Laurent had a specific master node defined,
but the LCD controller was very much like it. It would be trivial to
change it to use the component helpers.

My solution is different, because I don't like the idea of requiring all
the display components to be up and running to use any of the displays.
In fact, it's not a solution at all for me, as it would prevent displays
working on boards that do not have all the display components installed,
or if the user didn't compile all the drivers.

 Tomi

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

[PATCH] Memory leak in nouveau_sgdma_create_ttm

2014-02-27 Thread xypron.g...@gmx.de

From: Heinrich Schuchardt 

In case of failure memory was not freed.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c 
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index a4d22e5..23d880b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -109,7 +109,9 @@ nouveau_sgdma_create_ttm(struct ttm_bo_device *bdev,
else
nvbe->ttm.ttm.func = &nv50_sgdma_backend;

-   if (ttm_dma_tt_init(&nvbe->ttm, bdev, size, page_flags, 
dummy_read_page))
+   if (ttm_dma_tt_init(&nvbe->ttm, bdev, size, page_flags, 
dummy_read_page)) {
+   kfree(nvbe);
return NULL;
+   }
return &nvbe->ttm.ttm;
 }
-- 
1.7.10.4

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Rafael J. Wysocki

On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> > there to BAR is at a completely different address. Same thing on my
> > Haswell desktop system.
> 
> Hrrm, I'd like to see what Rafael finds out, whether what we're reading
> from PCI config space is even sane.

I won't be able to look at that before Monday I'm afraid (personal stuff).

Rafael

[PATCH 0/3] Reorder drivers/video directory

2014-02-27 Thread Randy Dunlap

On 02/27/2014 03:54 AM, Tomi Valkeinen wrote:
> Hi,
> 
> This is a re-send of the series, with RFC removed from the subject, and a 
> bunch
> of acks added.
> 
> I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
> make sure this is not a bad idea, doomed to fail horribly.

What does this patch apply to?  I can't get it to apply cleanly to
-rc4 or Linus's current git tree.

I like what I see so far.

Thanks.

> So this series creates a new directory, drivers/video/fbdev/, to which all
> fbdev related files are moved. Also, a new directory, 
> drivers/video/fbdev/core/
> is created, to which the core fbdev framework files are moved. This makes the
> drivers/video hierarchy much more clear.
> 
> Presuming no one has objections to this as such, I wonder what's the least
> painful way to merge this? Normally, like any other fbdev change? As a 
> separate
> pull request, maybe at -rc2 time frame, based on -rc1? Something else?


-- 
~Randy

Info: mapping multiple BARs. Your kernel is fine.

2014-02-27 Thread Stephane Eranian

On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra  
wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
>> They  hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
>> not so sure this is all related to the uncore IMC support, though.
>
> Unstable with 3.14-rc4-tip you mean? Yeah, there's a rather crucial
> patch missing. I'll try and get Thomas to merge it if Ingo doesn't show
> up soon.

Yes, I mean from tip.git.

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

rs to operate together more closely, you
always need special code for that particular case.

This is what CDF has been trying to accomplish: individual drivers for
each display entity, connected together via ports and endpoints. Driver
for Epson LCD controller would expose an API, that can be used handle
the LCD controller, it wouldn't make any other demands on how it's used,
is it part of DRM or fbdev, what's before or after it, etc.

Now, and I think this was your point, some kind of master device/driver
is needed to register the required DRM or fbdev entities. Usually that
can be the driver for the SoCs display controller, i.e. the first
display entity in the display pipeline. Sometimes, if it's required to
have multiple devices act together, it may be a driver specifically
designed for that purpose.

So no, I don't have a problem with master device nodes in DT. I have a
problem having pure SW stack nomenclature in the DT data (or even worse,
SW stack entities in the DT data), and I have a problem requiring
everyone to have a master device node if it's only needed for special cases.

And yes, this series is about IMX bindings, not generic ones. And I'm
also fine with requiring everyone to have a master device node, if it
can be shown that it's the only sensible approach.

Tomi

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

[Intel-gfx] Request for feedback : New Panel-fitter property for connectors

2014-02-27 Thread Goel, Akash

> Either we should have two range properties (eg. crtc_width and crtc_height), 
> or we could define a new property type that has both in the same value.
> Not sure if it's worth adding another type for this. Although we might be 
> able to use such a type to reduce the number of properties a bit for planes 
> and such (src and dst coordinages). The issue is that it limits the range a 
> bit. Not a real  > issue for this case, but for plane src coordiantes we'd 
> end up limit ourselves to 16.16 again, which may be a bit short sighted.

> And please, no scaling ratio property. Just explicit input and output sizes 
> are better IMO. The output size should really be part of the mode as borders, 
> but I'm not sure we want to be redefining the mode structure. I have no 
> problem with > the idea, but maybe other people are more reluctant. The 
> alternative is to define the border through properties as well.

In VLV, we have to program PANEL fitter control register in terms of 
Auto/Manual/LetterBox/PillarBox modes, along with explicit scaling ratios, if 
Manual mode is used.
Whereas for HSW, we program the PF register in terms of the display window size 
& its location. 
So the new interface should be such that this difference is handled seamlessly 
on Driver side and also it has to be used in conjunction with 'scaling_mode' 
property.  

Can we expose the property where User can specify the Display Window size & its 
location, & based on that Driver will decide with which mode to program the 
Panel fitter. The SRC dimensions can be read from the PIPE_SRC register 
programmed earlier in the Mode set. This will fit directly into the HSW case, 
but for VLV a conversion will be needed. 

The 'scaling_mode' property provides 3 Panel fitter modes. 
1.  Full Screen: Since the SRC image is to be shown on full screen , we 
may not need any other input from User for this mode.
2.  Aspect Ratio :  Here User wants to preserve the Aspect ratio of SRC, 
but here Driver currently on its own decides that whether the Letterboxing or 
Pillar boxing is required. Here probably there is a scope of input from User 
side,
 where it can specify both the horizontal & 
vertical borders in Display window. 
3.  Centered  :  Here User wants to show up the SRC image in the middle 
of the screen, here also same input of horizontal & vertical borders in Display 
window could be accepted from User. 

Best Regards
Akash

-Original Message-
From: Ville Syrj?l? [mailto:ville.syrj...@linux.intel.com] 
Sent: Wednesday, February 26, 2014 7:28 PM
To: Goel, Akash
Cc: Chris Wilson; intel-gfx at lists.freedesktop.org; G, Pallavi; Kannan, 
Vandana; dri-devel at lists.freedesktop.org
Subject: Re: [Intel-gfx] Request for feedback : New Panel-fitter property for 
connectors

On Wed, Feb 26, 2014 at 01:32:44PM +, Goel, Akash wrote:
> To expose the panel fitter for arbitrary use by User-space, we will expose 
> the manual scaling ratio & Input/Src size info to User, apart from the 
> available scaling modes like Full screen, Centered, Aspect. 
> Please suggest that how shall we extend the current interface to incorporate 
> these extra info, considering the options we have .
> DRM_MODE_PROP_ENUM
> DRM_MODE_PROP_RANGE
> DRM_MODE_PROP_BITMASK
> DRM_MODE_PROP_BLOB

Either we should have two range properties (eg. crtc_width and crtc_height), or 
we could define a new property type that has both in the same value.
Not sure if it's worth adding another type for this. Although we might be able 
to use such a type to reduce the number of properties a bit for planes and such 
(src and dst coordinages). The issue is that it limits the range a bit. Not a 
real issue for this case, but for plane src coordiantes we'd end up limit 
ourselves to 16.16 again, which may be a bit short sighted.

And please, no scaling ratio property. Just explicit input and output sizes are 
better IMO. The output size should really be part of the mode as borders, but 
I'm not sure we want to be redefining the mode structure. I have no problem 
with the idea, but maybe other people are more reluctant. The alternative is to 
define the border through properties as well.

We'd also need to figure out how to make this stuff cooperate decently with the 
way we deal with panel fixed modes currently. IMO ideally if the user specified 
the pfit stuff explicitly, we should really treat the display mode the user 
passed in as the adjusted_mode, and not just blindly overwrite it. This would 
also make it much easier to use cloning when one of the cloned displays has a 
fixed mode. Currently the user has no idea that the mode he passes in isn't 
what gets programmed into the timing generator, so other displays may not be 
able handle the mode even though it seemed perfectly valid from the user's 
perspective. I guess we could just add a new mode type flag to indicate the 
native mode of the display, but only in case where the di

[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings