[Bug 59332] Problems building 32bit Mesa

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

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

Matt Turner  changed:

   What|Removed |Added

   Assignee|idr at freedesktop.org |dri-devel at 
lists.freedesktop
   ||.org
 CC||tstellar at gmail.com
  Component|glsl-compiler   |Drivers/Gallium/r600

--- Comment #5 from Matt Turner  ---
(In reply to comment #3)
> I notice in the glsl directory the Makefile has CFLAGS and CFLAGS_FOR_BUILD
> and the same for CXX too the FOR_BUILD ones don't have -m32 and I think
> could be causing some of the issues I'm seeing

Actually, that doesn't seem related. Looks like this is yet another problem
with 32-bit LLVM.

I wonder if Tom's seen this?

-- 
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/20130130/03d675f2/attachment.html>

BUG: circular locking dependency detected

[Daniel Vetter]

On Wed, Jan 30, 2013 at 11:19 PM, Russell King  wrote:
> So... what you seem to be telling me is that 3.9 is going to be a
> release which issues lockdep complaints when the console blanks, and
> you think that's acceptable?
>
> Adding Linus and Andrew so they're aware of this issue...

Linus was the guy who shot down the patches for 3.9 since one of the
earlier iterations caused instant deadlocks - I've been pushing them
to merge them ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

BUG: circular locking dependency detected

[Daniel Vetter]

On Wed, Jan 30, 2013 at 10:52 PM, Russell King  wrote:
> Also adding Greg and Daniel to this as Daniel introduced the lockdep
> checking.
>
> This looks extremely horrid to be to solve - the paths are rather deep
> where the dependency occurs.  The two paths between the locks are:
>
> console_lock+0x5c/0x70
> register_con_driver+0x44/0x150
> take_over_console+0x24/0x3b4
> fbcon_takeover+0x70/0xd4
> fbcon_event_notify+0x7c8/0x818
> notifier_call_chain+0x4c/0x8c
> __blocking_notifier_call_chain+0x50/0x68
> blocking_notifier_call_chain+0x20/0x28
>
> and
>
> __blocking_notifier_call_chain+0x34/0x68
> blocking_notifier_call_chain+0x20/0x28
> fb_notifier_call_chain+0x20/0x28
> fb_blank+0x40/0xac
> fbcon_blank+0x1f4/0x29c
> do_blank_screen+0x1b8/0x270
> console_callback+0x74/0x138

You want Dave Airlie's pile of locking reworks, which fixes all
currently known offenders around console_lock and fb_notifier. Patches
won't go into 3.9 since it took a few rounds until they did not cause
regression by making these deadlocks easier to hit.

http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes

Long term solution would be to abolish the fb_notifier, at least for
the purpose of linking fbdevs up with the fbcon and just replace those
with direct function calls. But that requires that we no longer allow
fbdev drivers and the fbcon to be loaded in any arbitrary order. Or
just force fbcon to be built-in if enabled, imo the sane choice (no
one's bothering with config_vt=m either, after all).

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

[PATCH 1/2] [media] s5p-g2d: Add DT based discovery support

[Sylwester Nawrocki]

Hi Sachin,

On 01/25/2013 10:55 AM, Sachin Kamat wrote:
> This patch adds device tree based discovery support to G2D driver
>
> Signed-off-by: Sachin Kamat
> ---
>   drivers/media/platform/s5p-g2d/g2d.c |   17 -
>   1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-g2d/g2d.c 
> b/drivers/media/platform/s5p-g2d/g2d.c
> index 7e41529..210e142 100644
> --- a/drivers/media/platform/s5p-g2d/g2d.c
> +++ b/drivers/media/platform/s5p-g2d/g2d.c
> @@ -18,6 +18,7 @@
>   #include
>   #include
>   #include
> +#include
>
>   #include
>   #include
> @@ -796,7 +797,8 @@ static int g2d_probe(struct platform_device *pdev)
>   }
>
>   def_frame.stride = (def_frame.width * def_frame.fmt->depth)>>  3;
> - dev->variant = g2d_get_drv_data(pdev);
> + if (!pdev->dev.of_node)
> + dev->variant = g2d_get_drv_data(pdev);

Don' you need something like:

else {
of_id = of_match_node(exynos_g2d_match, pdev->dev.of_node);
if (!of_id)
return -ENODEV;
dev->variant = (struct g2d_variant *)of_id->data;
}
?

Otherwise dev->variant is left uninitialized...?

>   return 0;
>
> @@ -844,6 +846,18 @@ static struct g2d_variant g2d_drvdata_v4x = {
>   .hw_rev = TYPE_G2D_4X, /* Revision 4.1 for Exynos4X12 and Exynos5 */
>   };
>
> +static const struct of_device_id exynos_g2d_match[] = {
> + {
> + .compatible = "samsung,g2d-v3",
> + .data =_drvdata_v3x,
> + }, {
> + .compatible = "samsung,g2d-v41",
> + .data =_drvdata_v4x,

Didn't you consider adding "exynos" to these compatible strings ?
I'm afraid g2d may be too generic.

> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_g2d_match);
> +
>   static struct platform_device_id g2d_driver_ids[] = {
>   {
>   .name = "s5p-g2d",
> @@ -863,6 +877,7 @@ static struct platform_driver g2d_pdrv = {
>   .driver = {
>   .name = G2D_NAME,
>   .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(exynos_g2d_match),

of_match_ptr() could be dropped, since exynos_g2d_match[] is
always compiled in.

--

Thanks,
Sylwester

[Bug 57567] 3.7 radeonfb broken on efivga screens

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

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

--- Comment #11 from Alex Deucher  ---
this looks like it may be a duplicate of bug 59431.

-- 
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/20130130/2729326f/attachment.html>

BUG: circular locking dependency detected

[Russell King]

On Wed, Jan 30, 2013 at 11:07:16PM +0100, Daniel Vetter wrote:
> On Wed, Jan 30, 2013 at 10:52 PM, Russell King  
> wrote:
> > Also adding Greg and Daniel to this as Daniel introduced the lockdep
> > checking.
> >
> > This looks extremely horrid to be to solve - the paths are rather deep
> > where the dependency occurs.  The two paths between the locks are:
> >
> > console_lock+0x5c/0x70
> > register_con_driver+0x44/0x150
> > take_over_console+0x24/0x3b4
> > fbcon_takeover+0x70/0xd4
> > fbcon_event_notify+0x7c8/0x818
> > notifier_call_chain+0x4c/0x8c
> > __blocking_notifier_call_chain+0x50/0x68
> > blocking_notifier_call_chain+0x20/0x28
> >
> > and
> >
> > __blocking_notifier_call_chain+0x34/0x68
> > blocking_notifier_call_chain+0x20/0x28
> > fb_notifier_call_chain+0x20/0x28
> > fb_blank+0x40/0xac
> > fbcon_blank+0x1f4/0x29c
> > do_blank_screen+0x1b8/0x270
> > console_callback+0x74/0x138
> 
> You want Dave Airlie's pile of locking reworks, which fixes all
> currently known offenders around console_lock and fb_notifier. Patches
> won't go into 3.9 since it took a few rounds until they did not cause
> regression by making these deadlocks easier to hit.
> 
> http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes
> 
> Long term solution would be to abolish the fb_notifier, at least for
> the purpose of linking fbdevs up with the fbcon and just replace those
> with direct function calls. But that requires that we no longer allow
> fbdev drivers and the fbcon to be loaded in any arbitrary order. Or
> just force fbcon to be built-in if enabled, imo the sane choice (no
> one's bothering with config_vt=m either, after all).

So... what you seem to be telling me is that 3.9 is going to be a
release which issues lockdep complaints when the console blanks, and
you think that's acceptable?

Adding Linus and Andrew so they're aware of this issue...

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

[Bug 57567] 3.7 radeonfb broken on efivga screens

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

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

--- Comment #10 from Vladimir  ---
Some news which makes it easier to isolate the bug

ubuntu updated kernel to 3.5.0-22 and bug appeared on this kernel
3.5.0-21 - no bug

looks like they added some upstream changes.

here is list of changes 21 to 22 from their deb pkg for kernel -
http://pastebin.com/4uUWUtLV

-- 
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/20130130/64334f67/attachment.html>

[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D

[Sylwester Nawrocki]

On 01/30/2013 09:50 AM, Inki Dae wrote:
>> +static const struct of_device_id exynos_g2d_match[] = {
>> +   { .compatible = "samsung,g2d-v41" },
>
> not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d
> driver shoud support for all Exynos SoCs. How about using
> "samsung,exynos5-g2d" instead and adding a new property 'version' to
> identify ip version more surely? With this, we could know which SoC
> and its g2d ip version. The version property could have '0x14' or
> others. And please add descriptions to dt document.

Err no. Are you suggesting using "samsung,exynos5-g2d" compatible string
for Exynos4 specific IPs ? This would not be correct, and you still can
match the driver with multiple different revisions of the IP and associate
any required driver's private data with each corresponding compatible
property.

Perhaps it would make more sense to include the SoCs name in the compatible
string, e.g. "samsung,exynos-g2d-v41", but appending revision of the IP
seems acceptable to me. The revisions appear to be well documented and it's
more or less clear which one corresponds to which SoC.

--

Thanks,
Sylwester

[PATCH v2] drm/exynos: Get HDMI version from device tree

[Stephen Warren]

On 01/30/2013 06:16 PM, Inki Dae wrote:
> 2013/1/30 Sylwester Nawrocki :
>> Hi,
>>
>>
>> On 01/08/2013 11:56 PM, Stephen Warren wrote:
>>>
>>> On 01/08/2013 01:16 PM, Sean Paul wrote:

 Add a property to the hdmi node so we can specify the HDMI version in
 the device tree instead of just defaulting to v1.4 with the existence of
 the dt node.
>>>
>>>
>>> I guess this seems OK to me if required, although I'd certainly like to
>>> see someone familiar with the Exynos HW confirm whether this should be
>>> driven purely by DT compatible value for the HDMI IP block instead though.
>>
>>
>> I think the supported HDMI standard is something that could well be derived
>> from the compatible property. The IP supporting v1.3 and v1.4 will be
>> significantly different, so this would anyway already need to be reflected
>> in the compatible property. The only issue I see here is that people tend
>> to make the compatible string overly generic, so it is hardly usable for
>> anything but matching an IP with its driver. For instance for exynos5 we
>> have now (Documentation/devicetree/bindings/drm/exynos/hdmi.txt):
>>
>> compatible = "samsung,exynos5-hdmi";
>>
>> For Exynos4 series there were already some patches proposed [1], but I
>> believe
>> this isn't a clean solution. Instead of things like:
>>
>> compatible = "samsung,exynos4-hdmi13";
>> compatible = "samsung,exynos4-hdmi14";
>>
>> I would much more like to see the SoC version embedded in the compatible
>> string, e.g.
>>
> 
> Hi Sylwester. long time no see.
> 
> I think that if we use the SoC version embedded in the compatible
> string then each driver shoud aware of the ip version to the SoC to

The driver only needs to be aware of one SoC version for each IP version.

So with Sylwester's proposal:

>> compatible = "samsung,exynos4210-hdmi"; /* among others it carries an
>>   information this IP supports
>>   HDMI v1.3 */
>>
>> compatible = "samsung,exynos4212-hdmi"; /* HDMI v1.4, IIRC */

The driver woulud only ever have to know about those two compatible
values (unless further incompatible HW revisions exist); any other SoC
would be listed as being compatible with one of those two strings (but
in addition to the specific value for the specific SoC, e.g. compatible
= "samsung,exynox5xxx-hdmi", "samsung,exynos4212-hdmi").

> use version specific feature so I think it's better to use it without
> the SoC version embedded in the compatible string like this,
> compatible = "samsung,exynos4-hdmi"
> version = "0x104" or "0x103"

That would be quite non-typical.

> With this, all each driver to do  is to check version property and set
> version specific feature properly. And we have some dtsi file to can
> be used commonly.
> 
> For example,
> exynos4.dtsi : have all Exynos4 series SoCs common properties and also
> use common compatible string.
> exynos4412.dtsi, exynos4212.dtsi and so on: have Exynos42xx specific
> properties. So the hdmi version string could be used here as "version
> = "0x104" or "0x103"
> exynos4412-board.dts: have board specific properties.
> 
> compatible = "samsung,exynos5-hdmi" is reasonable to me.
> any opinions?

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #5 from Jerome Glisse  ---
Can you try dumping the bios when booting with kms disable and nothing bind to
the gpu

-- 
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/20130130/53e63661/attachment.html>

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

--- Comment #5 from Andy Furniss  ---
(In reply to comment #4)
> Please update mesa again a bunch of fixes were push. Make sure you have up
> to :
> e1598cb642334c809e6ec219d793e7bc85a213de

I am still seeing it on current head.

-- 
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/20130130/83702e18/attachment-0001.html>

[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D

[Inki Dae]

2013/1/25 Sachin Kamat :
> From: Ajay Kumar 
>
> This patch adds device tree match table for Exynos G2D controller.
>
> Signed-off-by: Ajay Kumar 
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index ddcfb5d..d24b170 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev)
>
>  static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_g2d_match[] = {
> +   { .compatible = "samsung,g2d-v41" },

not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d
driver shoud support for all Exynos SoCs. How about using
"samsung,exynos5-g2d" instead and adding a new property 'version' to
identify ip version more surely? With this, we could know which SoC
and its g2d ip version. The version property could have '0x14' or
others. And please add descriptions to dt document.

> +   {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_g2d_match);
> +#endif
> +
>  struct platform_driver g2d_driver = {
> .probe  = g2d_probe,
> .remove = g2d_remove,
> @@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = {
> .name   = "s5p-g2d",
> .owner  = THIS_MODULE,
> .pm = _pm_ops,
> +   .of_match_table = of_match_ptr(exynos_g2d_match),
> },
>  };
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

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

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

--- Comment #8 from Michel D?nzer  ---
(In reply to comment #6)
> * with "echo 2 > /sys/module/drm/parameters/debug" nothing special in dmesg

Hmm, so maybe the EBUSY error is coming from this code in
drm_mode_page_flip_ioctl():

if (crtc->fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
 * yet discovered.
 */
ret = -EBUSY;
goto out;
}


What does xrandr --current say when the problem occurs? After that, does
running xrandr without arguments make any difference?

-- 
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/20130130/60578c92/attachment.html>

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

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

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

--- Comment #4 from Jerome Glisse  ---
Please update mesa again a bunch of fixes were push. Make sure you have up to :
e1598cb642334c809e6ec219d793e7bc85a213de

-- 
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/20130130/c19d35cb/attachment.html>

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

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

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


J?r?me Glisse  changed:

   What|Removed |Added

 CC||glisse at freedesktop.org




--- Comment #6 from J?r?me Glisse   2013-01-30 
17:22:36 ---
It's not completely a kernel bug. It's userspace asking insane things to
kernel.

This mesa patch should avoid the issue most of the time :
http://people.freedesktop.org/~glisse/0001-r600g-add-cs-memory-usage-accounting-and-limit-it.patch

If you are using a recent mesa with gnome you will probably want this cogl
patch too :
http://people.freedesktop.org/~glisse/0001-glx-do-not-use-multisample-visual-config-for-front-o.patch

And for kernel i am working on better handling of memory fragmentation.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[ANNOUNCE] xf86-video-ati 7.1.0

[Maarten Lankhorst]

If I learned anything from the libdrm mess that was 2.4.41 (sorry about that!),
it is that people check things like md5sums, imo which should really no longer 
be
included in the release announcements. :-)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alex Deucher (5):
  bump verion post release
  radeon: add new SI pci id
  radeon: fix ring count in R300PrepareTexturedVideo
  exa/Xv: fix coordinate limits on AVIVO IGPs
  radeon/r200: program RE_WIDTH_HEIGHT properly

Dave Airlie (1):
  radeon: fix damage reporting for slave pixmaps

Ilija Hadzic (3):
  video: add option to include disabled CRTCs in best CRTC search
  DRI2: change signature of radeon_dri2_drawable_crtc
  DRI2: limit the swap rate when CRTC is in DPMS-off state

Jerome Glisse (2):
  radeon: avoid segfault when pixmap exceed GPU capabilities
  radeon: avoid copying over itself ddx fb

Maarten Lankhorst (1):
  radeon: bump version for release

Michel D?nzer (11):
  Remove dead code flagged by gcc -Wunused-but-set-variable.
  Remove unused local variable 'path'.
  Remove local variables total_size_bytes.
  Remove dead option definitions.
  glamor: Release the drawable after passing to glamor_push_pixels
  glamor: Enable full 2D acceleration for SI as well.
  Drop support for X servers older than 1.7.
  DRI2: Properly use buffer depth passed in by client.
  DRI2/r[345]xx: 16 bit depth buffers use square micro tiling.
  Make CRTC shadow pixmaps usable by glamor.
  Make radeon_glamor_create_textured_pixmap() return TRUE without 
USE_GLAMOR.

git tag: xf86-video-ati-7.1.0

http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.bz2
MD5:  a799371aa8a64ac8f9535963d5135e9a  xf86-video-ati-7.1.0.tar.bz2
SHA1: f94730e5ffc5f75fa3126579bed0222fe8330653  xf86-video-ati-7.1.0.tar.bz2
SHA256: c8ae44051fcb331625217f98c09a3aa69f493052b69d62c03f41fed0bfe610cd  
xf86-video-ati-7.1.0.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.gz
MD5:  8a2694537b1fc6ff85b2aee1c00a0eb9  xf86-video-ati-7.1.0.tar.gz
SHA1: 88b94a7503e813f8a12066dbda8d9642934f5a08  xf86-video-ati-7.1.0.tar.gz
SHA256: 187230127739de179118e54205dd5c17fdb1e04cfbee1f9a63fde0030f39fcb0  
xf86-video-ati-7.1.0.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJRCUcZAAoJEP5VjHKmcBPDDVsP/RrdCI07QVxDANrNqKiUlScI
B7kMYcB4phNn/SiFKElrxikpdrHddHtRdnXs4RzG+0gb6CVGDD48xY1MZNrJRBEY
Lm+g1IKXU2w1LMqj9q3dMasNe73Msws5iRMy31n5NtVNNehcneibLR8Na7vkc30t
bAsCP6Z0kOtrlxbVsEvUbQw4JIWQIBSzWflB1hqsWQKbLEGKC9TUKWNr+ZnoPBCm
5dPYSe/vrTeaC2RvdYGsyMLcyO4D2g67uvDmRvAlE9/VWj7eTLS8QAIy2kSliHbJ
7z2F+VDRjbBYGhIsa7neWzsdA85guSFhQj5+ToLcBNn9YXSxP7MWKJ0fPoaWPTxG
wroTd14/HOCwH7a0w34SdHyB+kblTu9iOVi+DWsJ7YHs5yg/HGeB1c10OtejaZH5
cLiM4Wq1TNUuzX+DFq4JHdOwX9KM8pqyy7yPOvLOik1B7gbljmP6bJEv7NUnhNdT
cY7WOgmvlNcbuY41YI6gY8XMjP4OyEC2cK+za6THEiLL+foj3CpdBcacnMopGTbs
E4HgmzG+wXX1QBXe1y7iNz5B+y/dGNMJsM9yv2POoDZ2OTpnBczOmzGq2lJ7oxGA
/6P66eiKt1NH4CGvojzqTbTc2gJ+KQtmSJtVt2+l+m/iwHInaGbgEtAbCDVK833Y
R7KTbofGO9xkOAwBFRZr
=AnY7
-END PGP SIGNATURE-

[RFC PATCH 4/4] video: display: Add Samsung s6e8ax0 display panel driver

[Tomasz Figa]

This patch adds Common Display Framework driver for Samsung s6e8ax0
MIPI DSI display panel.

Signed-off-by: Tomasz Figa 
Signed-off-by: Kyungmin Park 
---
 drivers/video/display/Kconfig |3 +
 drivers/video/display/Makefile|1 +
 drivers/video/display/panel-s6e8ax0.c | 1027 +
 include/video/panel-s6e8ax0.h |   41 ++
 4 files changed, 1072 insertions(+)
 create mode 100644 drivers/video/display/panel-s6e8ax0.c
 create mode 100644 include/video/panel-s6e8ax0.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index b14527a..f19ec04 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -5,6 +5,9 @@ menuconfig DISPLAY_CORE

 if DISPLAY_CORE

+config DISPLAY_PANEL_S6E8AX0
+   tristate "S6E8AX0 DSI video mode panel"
+   select OF_VIDEOMODE

 config DISPLAY_SOURCE_EXYNOS_DSI
tristate "Samsung SoC MIPI DSI Master"
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 40a283a..0f7fdc2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_S6E8AX0) += panel-s6e8ax0.o
 obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o
diff --git a/drivers/video/display/panel-s6e8ax0.c 
b/drivers/video/display/panel-s6e8ax0.c
new file mode 100644
index 000..4c09fe2
--- /dev/null
+++ b/drivers/video/display/panel-s6e8ax0.c
@@ -0,0 +1,1027 @@
+/* linux/drivers/video/exynos/s6e8ax0.c
+ *
+ * MIPI-DSI based s6e8ax0 AMOLED lcd 4.65 inch panel driver.
+ *
+ * Inki Dae, 
+ * Donghwa Lee, 
+ * Tomasz Figa, 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define LDI_MTP_LENGTH 24
+#define DSIM_PM_STABLE_TIME10
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 24
+#define GAMMA_TABLE_COUNT  26
+
+struct s6e8ax0 {
+   struct display_entity entity;
+   struct device *dev;
+
+   struct s6e8ax0_platform_data *pdata;
+   struct backlight_device *bd;
+   struct lcd_device *ld;
+   struct regulator_bulk_data supplies[2];
+
+   bool enabled;
+   unsigned int id;
+   unsigned int gamma;
+   unsigned int acl_enable;
+   unsigned int cur_acl;
+   int power;
+
+   unsigned int reset_gpio;
+};
+
+#define to_panel(p)container_of(p, struct s6e8ax0, entity)
+
+static const unsigned char s6e8ax0_22_gamma_30[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
+   0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
+   0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
+};
+
+static const unsigned char s6e8ax0_22_gamma_50[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xe8, 0x1f, 0xf7, 0xad, 0xc0,
+   0xb5, 0xc4, 0xdc, 0xc4, 0x9e, 0xc6, 0x9c, 0xbb, 0xd8, 0xbb,
+   0x00, 0x70, 0x00, 0x68, 0x00, 0x86,
+};
+
+static const unsigned char s6e8ax0_22_gamma_60[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xde, 0x1f, 0xef, 0xad, 0xc4,
+   0xb3, 0xc3, 0xdd, 0xc4, 0x9e, 0xc6, 0x9c, 0xbc, 0xd6, 0xba,
+   0x00, 0x75, 0x00, 0x6e, 0x00, 0x8d,
+};
+
+static const unsigned char s6e8ax0_22_gamma_70[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xd8, 0x1f, 0xe7, 0xaf, 0xc8,
+   0xb4, 0xc4, 0xdd, 0xc3, 0x9d, 0xc6, 0x9c, 0xbb, 0xd6, 0xb9,
+   0x00, 0x7a, 0x00, 0x72, 0x00, 0x93,
+};
+
+static const unsigned char s6e8ax0_22_gamma_80[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xc9, 0x1f, 0xde, 0xae, 0xc9,
+   0xb1, 0xc3, 0xdd, 0xc2, 0x9d, 0xc5, 0x9b, 0xbc, 0xd6, 0xbb,
+   0x00, 0x7f, 0x00, 0x77, 0x00, 0x99,
+};
+
+static const unsigned char s6e8ax0_22_gamma_90[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xc7, 0x1f, 0xd9, 0xb0, 0xcc,
+   0xb2, 0xc3, 0xdc, 0xc1, 0x9c, 0xc6, 0x9c, 0xbc, 0xd4, 0xb9,
+   0x00, 0x83, 0x00, 0x7b, 0x00, 0x9e,
+};
+
+static const unsigned char s6e8ax0_22_gamma_100[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xbd, 0x80, 0xcd, 0xba, 0xce,
+   0xb3, 0xc4, 0xde, 0xc3, 0x9c, 0xc4, 0x9, 0xb8, 0xd3, 0xb6,
+   0x00, 0x88, 0x00, 0x80, 0x00, 0xa5,
+};
+
+static const unsigned char s6e8ax0_22_gamma_120[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xb9, 0x95, 0xc8, 0xb1, 0xcf,
+   0xb2, 0xc6, 0xdf, 0xc5, 0x9b, 0xc3, 0x99, 0xb6, 0xd2, 0xb6,
+   0x00, 0x8f, 0x00, 0x86, 0x00, 0xac,
+};
+
+static const unsigned char s6e8ax0_22_gamma_130[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xb7, 0xa0, 0xc7, 0xb1, 0xd0,
+   0xb2, 0xc4, 0xdd, 0xc3, 0x9a, 0xc3, 0x98, 0xb6, 0xd0, 0xb4,
+   0x00, 0x92, 0x00, 0x8a, 0x00, 0xb1,
+};
+

[RFC PATCH 3/4] video: display: Add exynos-dsi video source driver

[Tomasz Figa]

This patch adds new driver for DSI master block available in Samsung
Exynos SoCs. The driver is designed and written specifically for Common
Display Framework.

Signed-off-by: Tomasz Figa 
Signed-off-by: Kyungmin Park 
---
 drivers/video/display/Kconfig |3 +
 drivers/video/display/Makefile|1 +
 drivers/video/display/source-exynos_dsi.c | 1313 +
 include/video/exynos_dsi.h|   41 +
 4 files changed, 1358 insertions(+)
 create mode 100644 drivers/video/display/source-exynos_dsi.c
 create mode 100644 include/video/exynos_dsi.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 477192d..b14527a 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -6,5 +6,8 @@ menuconfig DISPLAY_CORE
 if DISPLAY_CORE


+config DISPLAY_SOURCE_EXYNOS_DSI
+   tristate "Samsung SoC MIPI DSI Master"
+

 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index bd93496..40a283a 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o
diff --git a/drivers/video/display/source-exynos_dsi.c 
b/drivers/video/display/source-exynos_dsi.c
new file mode 100644
index 000..30b15bf
--- /dev/null
+++ b/drivers/video/display/source-exynos_dsi.c
@@ -0,0 +1,1313 @@
+/*
+ * Samsung SoC MIPI DSI Master driver.
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd
+ *
+ * Contacts: Tomasz Figa 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define DSIM_STATUS_REG0x0 /* Status register */
+#define DSIM_SWRST_REG 0x4 /* Software reset register */
+#define DSIM_CLKCTRL_REG   0x8 /* Clock control register */
+#define DSIM_TIMEOUT_REG   0xc /* Time out register */
+#define DSIM_CONFIG_REG0x10/* Configuration register */
+#define DSIM_ESCMODE_REG   0x14/* Escape mode register */
+
+/* Main display image resolution register */
+#define DSIM_MDRESOL_REG   0x18
+#define DSIM_MVPORCH_REG   0x1c/* Main display Vporch register */
+#define DSIM_MHPORCH_REG   0x20/* Main display Hporch register */
+#define DSIM_MSYNC_REG 0x24/* Main display sync area register */
+
+/* Sub display image resolution register */
+#define DSIM_SDRESOL_REG   0x28
+#define DSIM_INTSRC_REG0x2c/* Interrupt source register */
+#define DSIM_INTMSK_REG0x30/* Interrupt mask register */
+#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register 
*/
+#define DSIM_PAYLOAD_REG   0x38/* Payload FIFO register */
+#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */
+#define DSIM_FIFOTHLD_REG  0x40/* FIFO threshold level register */
+#define DSIM_FIFOCTRL_REG  0x44/* FIFO status and control register */
+
+/* FIFO memory AC characteristic register */
+#define DSIM_PLLCTRL_REG   0x4c/* PLL control register */
+#define DSIM_PLLTMR_REG0x50/* PLL timer register */
+#define DSIM_PHYACCHR_REG  0x54/* D-PHY AC characteristic register */
+#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+
+/* DSIM_STATUS */
+#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
+#define DSIM_STOP_STATE_CLK(1 << 8)
+#define DSIM_TX_READY_HS_CLK   (1 << 10)
+#define DSIM_PLL_STABLE(1 << 31)
+
+/* DSIM_SWRST */
+#define DSIM_FUNCRST   (1 << 16)
+#define DSIM_SWRST (1 << 0)
+
+/* DSIM_TIMEOUT */
+#define DSIM_LPDR_TOUT(x)  ((x) << 0)
+#define DSIM_BTA_TOUT(x)   ((x) << 16)
+
+/* DSIM_CLKCTRL */
+#define DSIM_ESC_PRESCALER(x)  (((x) & 0x) << 0)
+#define DSIM_ESC_PRESCALER_MASK(0x << 0)
+#define DSIM_LANE_ESC_CLK_EN_CLK   (1 << 19)
+#define DSIM_LANE_ESC_CLK_EN_DATA(x)   (((x) & 0xf) << 20)
+#define DSIM_LANE_ESC_CLK_EN_DATA_MASK (0xf << 20)
+#define DSIM_BYTE_CLKEN(1 << 24)
+#define DSIM_BYTE_CLK_SRC(x)   (((x) & 0x3) << 25)
+#define DSIM_BYTE_CLK_SRC_MASK (0x3 << 25)
+#define DSIM_PLL_BYPASS(1 << 27)
+#define DSIM_ESC_CLKEN (1 << 28)
+#define DSIM_TX_REQUEST_HSCLK  (1 << 31)
+
+/* DSIM_CONFIG */
+#define DSIM_LANE_EN_CLK   (1 << 0)
+#define DSIM_LANE_EN(x)

[RFC PATCH 2/4] video: add makefile & kconfig

[Tomasz Figa]

Signed-off-by: Tomasz Figa 
Signed-off-by: Kyungmin Park 
---
 drivers/video/Kconfig  |  1 +
 drivers/video/Makefile |  1 +
 drivers/video/display/Kconfig  | 10 ++
 drivers/video/display/Makefile |  1 +
 4 files changed, 13 insertions(+)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 68f17ee..800e98c 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2444,6 +2444,7 @@ source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"

 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index f592f3b..4a091d4 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= display/

 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..477192d
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,10 @@
+menuconfig DISPLAY_CORE
+   tristate "Display Core"
+   ---help---
+ Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..bd93496
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
-- 
1.8.1

[RFC PATCH 1/4] video: add display-core

[Tomasz Figa]

Signed-off-by: Tomasz Figa 
Signed-off-by: Kyungmin Park 
---
 drivers/video/display/display-core.c | 295 +++
 include/video/display.h  | 230 +++
 2 files changed, 525 insertions(+)
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
new file mode 100644
index 000..ed49384
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,295 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct video_source *video_source_bind(struct display_entity *entity);
+static void video_source_unbind(struct display_entity *entity);
+
+/* 
-
+ * Display Entity
+ */
+
+static LIST_HEAD(display_entity_list);
+static DEFINE_MUTEX(display_entity_mutex);
+
+struct display_entity *display_entity_get_first(void)
+{
+   /* FIXME: Don't we need some locking here? */
+
+   if (list_empty(_entity_list))
+   return NULL;
+
+   return list_first_entry(_entity_list, struct display_entity,
+   list);
+}
+EXPORT_SYMBOL(display_entity_get_first);
+
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   int ret;
+
+   if (entity->state == state)
+   return 0;
+
+   if (!entity->ops || !entity->ops->set_state)
+   return 0;
+
+   ret = entity->ops->set_state(entity, state);
+   if (ret < 0)
+   return ret;
+
+   entity->state = state;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+int display_entity_get_modes(struct display_entity *entity,
+const struct videomode **modes)
+{
+   if (!entity->ops || !entity->ops->get_modes)
+   return 0;
+
+   return entity->ops->get_modes(entity, modes);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_modes);
+
+int display_entity_get_size(struct display_entity *entity,
+   unsigned int *width, unsigned int *height)
+{
+   if (!entity->ops || !entity->ops->get_size)
+   return -EOPNOTSUPP;
+
+   return entity->ops->get_size(entity, width, height);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_size);
+
+int display_entity_get_params(struct display_entity *entity,
+ struct display_entity_interface_params *params)
+{
+   if (!entity->ops || !entity->ops->get_params)
+   return -EOPNOTSUPP;
+
+   return entity->ops->get_params(entity, params);
+}
+EXPORT_SYMBOL_GPL(display_entity_get_params);
+
+static void display_entity_release(struct kref *ref)
+{
+   struct display_entity *entity =
+   container_of(ref, struct display_entity, ref);
+
+   if (entity->release)
+   entity->release(entity);
+}
+
+struct display_entity *display_entity_get(struct display_entity *entity)
+{
+   if (entity == NULL)
+   return NULL;
+
+   kref_get(>ref);
+   return entity;
+}
+EXPORT_SYMBOL_GPL(display_entity_get);
+
+void display_entity_put(struct display_entity *entity)
+{
+   kref_put(>ref, display_entity_release);
+}
+EXPORT_SYMBOL_GPL(display_entity_put);
+
+int __must_check __display_entity_register(struct display_entity *entity,
+  struct module *owner)
+{
+   struct video_source *src;
+
+   kref_init(>ref);
+   entity->owner = owner;
+   entity->state = DISPLAY_ENTITY_STATE_OFF;
+   entity->source = NULL;
+
+   src = video_source_bind(entity);
+   if (!src)
+   return -EPROBE_DEFER;
+
+   mutex_lock(_entity_mutex);
+   list_add(>list, _entity_list);
+   mutex_unlock(_entity_mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(__display_entity_register);
+
+void display_entity_unregister(struct display_entity *entity)
+{
+   video_source_unbind(entity);
+
+   mutex_lock(_entity_mutex);
+
+   list_del(>list);
+   mutex_unlock(_entity_mutex);
+
+   display_entity_put(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_unregister);
+
+/* 
-
+ * Video Source
+ */
+
+static LIST_HEAD(video_source_list);
+static DEFINE_MUTEX(video_source_mutex);
+
+static void video_source_release(struct kref *ref)
+{
+   struct video_source *src =
+   container_of(ref, struct video_source, ref);
+
+   if (src->release)
+   

[RFC PATCH 0/4] Common Display Framework-TF

[Tomasz Figa]

Hi,

After pretty long time of trying to adapt Exynos-specific DSI display support
to Common Display Framework I'm ready to show some preliminary RFC patches.
This series shows some ideas for CDF that came to my mind during my work,
some changes based on comments received by Tomi's edition of CDF and also
preliminarys version of Exynos DSI (video source part only, still with some
FIXMEs) and Samsung S6E8AX0 DSI panel drivers.

It is heavily based on Tomi's work which can be found here:
http://thread.gmane.org/gmane.comp.video.dri.devel/78227

The code might be a bit hacky in places, as I wanted to get it to a kind
of complete and working state first. However I hope that some of the ideas
might useful for further works.

So, here comes the TF edition of Common Clock Framework.


Changes done to Tomi's edition of CDF:

 - Replaced set_operation_mode, set_pixel_format and set_size video source
   operations with get_params display entity operation, as it was originally
   in Laurent's version.

   We have discussed this matter on the mailing list
   and decided that it would be better to have the source ask the sink for
   its parameter structure and do whatever appropriate with it.

 - Defined a preliminary set of DSI bus parameters.

   Following parameters are defined:

   1. Pixel format used for video data transmission.
   2. Mode flags (several bit flags ORed together):
 a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command mode),
following DSI_MODE_VIDEO_* flags are relevant only if this flag is set.
b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data
c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed
   to sync events)
d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
   detection
e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets
f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area
g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area
h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area
 i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
 j) DSI_MODE_EOT_PACKET - entity needs EoT packets
   3. Bit (serial) clock frequency in HS mode.
   4. Escape mode clock frequency.
   5. Mask of used data lanes (each bit represents single lane).
   6. Command allow area in video mode - amount of lines after transmitting
  video data when generic commands are accepted.

   Feel free to suggest anything missing or wrong, as the list of
   parameters is based merely on what was used in original Exynos MIPI
   DSIM driver.

 - Redesigned source-entity matching.

   Now each source has name string and integer id and each entity has
   source name and source id. In addition, they can have of_node specified,
   which is used for Device Tree-based matching.

   The matching procedure is as follows:

   1. Matching takes place when display entity registers.
 a) If there is of_node specified for the entity then "video-source"
phandle of this node is being parsed and list of registered sources
is traversed in search of a source with of_node received from
parsing the phandle.
 b) Otherwise the matching key is a pair of source name and id.
   2. If no matching source is found, display_entity_register returns
  -EPROBE_DEFER error which causes the entity driver to defer its
  probe until the source registers.
   3. Otherwise an optional bind operation of video source is called,
  sink field of source and source field of entity are set and the
  matching ends successfully.

 - Some initial concept of source-entity cross-locking.

   Only video source is protected at the moment, as I still have to think
   a bit about locking the entity in a way where removing it by user request
   is still possible.

 - Dropped any panels and chips that I can't test.

   They are irrelevant for this series, so there is no point in including them.

 - Added Exynos DSI video source driver.

   This is a new driver for the DSI controller found in Exynos SoCs. It still
   needs some work, but in current state can be considered an example of DSI
   video source implementation for my version of CDF.

 - Added Samsung S6E8AX0 DSI panel driver.

   This is the old Exynos-specific driver, just migrated to CDF and with
   some hacks to provide control over entity state to userspace using
   lcd device. However it can be used to demonstrate video source ops in use.

Feel free to comment as much as you can.

Tomasz Figa (4):
  video: add display-core
  video: add makefile & kconfig
  video: display: Add exynos-dsi video source driver
  video: display: Add Samsung s6e8ax0 display panel driver

 drivers/video/Kconfig |1 +
 drivers/video/Makefile|1 +
 drivers/video/display/Kconfig |   16 

[PATCH 9/9] drm/i915: Hook PSR functionality

[Rodrigo Vivi]

PSR must be enabled after transcoder and port are running.
And it is only available for HSW.

v2: move enable/disable to intel_ddi

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index feb7a4a..1dba035d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1306,6 +1306,7 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);

ironlake_edp_backlight_on(intel_dp);
+   intel_edp_enable_psr(intel_dp);
}
 }

@@ -1318,6 +1319,7 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);

ironlake_edp_backlight_off(intel_dp);
+   intel_edp_disable_psr(intel_dp);
}
 }

-- 
1.7.11.7

[PATCH 8/9] drm/i915: Added debugfs support for PSR Status

[Rodrigo Vivi]

From: Shobhit Kumar 

Added support for PSR entry counter and performance counters

Signed-off-by: Shobhit Kumar 

v2: Add psr enabled yes/no info
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 90a6fc5..11d2896 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1659,6 +1659,39 @@ static int i915_dpio_info(struct seq_file *m, void *data)
return 0;
 }

+static int i915_edp_psr_status(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int count;
+   u32 psrctl, psrstat, psrperf;
+
+   /* Bit 31 gives the PSR enabled */
+   psrctl = I915_READ(EDP_PSR_CTL);
+   seq_printf(m, "PSR Enabled: %s\n",
+  yesno(psrctl & EDP_PSR_ENABLE));
+
+   /* Bits 19:16 gives the PSR entry count */
+   psrstat = I915_READ(EDP_PSR_STATUS_CTL);
+   count = ((psrstat >> 16) & 0xf);
+
+   /* Format the PSR Entry Count only for now.
+* TBD: Other status information
+*/
+   seq_printf(m, "EDP_PSR_ENTRY_COUNT: %u\n", count);
+
+   /* Current PSR state */
+   count = ((psrstat >> 29) & 0x7);
+   seq_printf(m, "EDP_PSR_CURRENT_STATE: 0x%x\n", count);
+
+   /* Perfromance counter bit 23:0 */
+   psrperf = (I915_READ(EDP_PSR_PERF_CNT)) & 0xff;
+   seq_printf(m, "EDP_PSR_PERF_COUNTER: %u\n", psrperf);
+
+   return 0;
+}
+
 static ssize_t
 i915_wedged_read(struct file *filp,
 char __user *ubuf,
@@ -2228,6 +2261,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{"i915_swizzle_info", i915_swizzle_info, 0},
{"i915_ppgtt_info", i915_ppgtt_info, 0},
{"i915_dpio", i915_dpio_info, 0},
+   {"i915_edp_psr_status", i915_edp_psr_status, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)

-- 
1.7.11.7

[PATCH 7/9] drm/i915: Enable/Disable PSR on HSW

[Rodrigo Vivi]

From: Shobhit Kumar 

Added eDP PSR enable functionality. This includes setting the PSR
configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
enabling PSR in the sink via DPCD register and finally enabling PSR on
the host. PSR works only in LPSP mode, so put the PIPE_DDI in DDIA
always on

This patch is heavily based on initial PSR code by Sateesh Kavuri but is
quite different in implementation. Makes use of VBT parsed data and also
the code has been cleaned up.

Credits-by: Sateesh Kavuri 
Signed-off-by: Shobhit Kumar 

v2: fix getting base.crtc from intel_dp and fix DDI_EDP_INPUT_A_ON entry
v3: Add eDP PSR registers here only when they are really used and use
HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder)

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h  |  24 ++
 drivers/gpu/drm/i915/intel_ddi.c |   6 +-
 drivers/gpu/drm/i915/intel_dp.c  | 172 +++
 drivers/gpu/drm/i915/intel_drv.h |   3 +
 4 files changed, 204 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 10732dc..6f87d5b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1563,6 +1563,30 @@
 #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
 #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)

+/* HSW eDP PSR registers */
+#define EDP_PSR_CTL0x64800
+#define   EDP_PSR_ENABLE   (1<<31)
+#define   EDP_PSR_LINK_DISABLE (0<<27)
+#define   EDP_PSR_LINK_STANDBY (1<<27)
+#define   EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
+#define   EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES  (0<<25)
+#define   EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES  (1<<25)
+#define   EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES  (2<<25)
+#define   EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES  (3<<25)
+#define   EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
+#define   EDP_PSR_SKIP_AUX_EXIT(1<<12)
+#define   EDP_PSR_TP1_TP2_SEL  (0<<11)
+#define   EDP_PSR_TP1_TP3_SEL  (1<<11)
+#define   EDP_PSR_TP2_TP3_TIME_500us   (0<<8)
+#define   EDP_PSR_TP2_TP3_TIME_100us   (1<<8)
+#define   EDP_PSR_TP2_TP3_TIME_2500us  (2<<8)
+#define   EDP_PSR_TP2_TP3_TIME_0us (3<<8)
+#define   EDP_PSR_TP1_TIME_500us   (0<<4)
+#define   EDP_PSR_TP1_TIME_100us   (1<<4)
+#define   EDP_PSR_TP1_TIME_2500us  (2<<4)
+#define   EDP_PSR_TP1_TIME_0us (3<<4)
+#define   EDP_PSR_IDLE_FRAME_SHIFT 0
+
 #define EDP_PSR_AUX_CTL0x64810
 #define EDP_PSR_AUX_DATA1  0x64814
 #define EDP_PSR_AUX_DATA2  0x64818
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2e904a5..feb7a4a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -985,9 +985,13 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
temp |= TRANS_DDI_PHSYNC;

if (cpu_transcoder == TRANSCODER_EDP) {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
switch (pipe) {
case PIPE_A:
-   temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+   if (intel_dp->psr_dpcd[0] & 0x1)
+   temp |= TRANS_DDI_EDP_INPUT_A_ON;
+   else
+   temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
break;
case PIPE_B:
temp |= TRANS_DDI_EDP_INPUT_B_ONOFF;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fe83e05..d136890 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp 
*intel_dp)
return intel_dig_port->base.base.dev;
 }

+static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+
+   return intel_dig_port->base.base.crtc;
+}
+
 static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
 {
return enc_to_intel_dp(_attached_encoder(connector)->base);
@@ -1489,6 +1496,171 @@ static void intel_edp_psr_setup(struct intel_dp 
*intel_dp)
intel_dp->psr_setup = 1;
 }

+static bool
+intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   return (I915_READ(EDP_PSR_CTL) & (1<<31)) ? true : false;
+}
+
+
+static void
+intel_edp_psr_enable_src(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   uint32_t max_sleep_time = 0x1f;
+   uint32_t 

[PATCH 6/9] drm/i915: VBT Parsing for the PSR Feature Block for HSW

[Rodrigo Vivi]

From: Shobhit Kumar 

Parse and store useful information in i915_dev_private

Signed-off-by: Shobhit Kumar 

v2: Add to new vbt struct and call them psr_*

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h   |  7 +++
 drivers/gpu/drm/i915/intel_bios.c | 30 ++
 drivers/gpu/drm/i915/intel_bios.h | 20 +++-
 3 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e22f6bd..b5f1842 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -689,6 +689,13 @@ struct intel_vbt_data {
int edp_bpp;
struct edp_power_seq edp_pps;

+   /* eDP PSR*/
+   u8 psr_full_link_state;
+   u8 psr_wait_lines;
+   u8 psr_idle_frames;
+   u16 psr_wakeup_tp1;
+   u16 psr_wakeup_tp2_tp3;
+
int crt_ddc_pin;

int child_dev_num;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index e145151..2a3fa8b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -381,6 +381,35 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
}
 }

+
+static void
+parse_edp_psr(struct drm_i915_private *dev_priv, struct bdb_header *bdb)
+{
+   struct bdb_psr_features *psr;
+   struct bdb_lvds_options *lvds_opts;
+   int index = 0;
+   lvds_opts = find_section(bdb, BDB_LVDS_OPTIONS);
+   if (!lvds_opts) {
+   DRM_DEBUG_KMS("No LVDS Options block found.\n");
+   return;
+   }
+
+   index = lvds_opts->panel_type;
+
+   psr = find_section(bdb, BDB_PSR_FEATURES);
+   if (!psr) {
+   DRM_DEBUG_KMS("No PSR feature block found.\n");
+   return;
+   }
+
+   dev_priv->vbt.psr_full_link_state = psr[index].link_disable;
+   dev_priv->vbt.psr_wait_lines = psr[index].wait_lines;
+   dev_priv->vbt.psr_idle_frames = psr[index].idle_frames;
+   dev_priv->vbt.psr_wakeup_tp1 = psr[index].wakeup_tp1;
+   dev_priv->vbt.psr_wakeup_tp2_tp3 = psr[index].wakeup_tp2;
+}
+
+
 static void
 parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
  struct bdb_header *bdb)
@@ -740,6 +769,7 @@ intel_parse_bios(struct drm_device *dev)
parse_device_mapping(dev_priv, bdb);
parse_driver_features(dev_priv, bdb);
parse_edp(dev_priv, bdb);
+   parse_edp_psr(dev_priv, bdb);

if (bios)
pci_unmap_rom(pdev, bios);
diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 36e57f9..c1d39de 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -80,7 +80,7 @@ struct vbios_data {
 #define BDB_EXT_MMIO_REGS6
 #define BDB_SWF_IO   7
 #define BDB_SWF_MMIO 8
-#define BDB_DOT_CLOCK_TABLE  9
+#define BDB_PSR_FEATURES 9
 #define BDB_MODE_REMOVAL_TABLE  10
 #define BDB_CHILD_DEVICE_TABLE  11
 #define BDB_DRIVER_FEATURES 12
@@ -263,6 +263,24 @@ struct bdb_lvds_options {
u8 rsvd4;
 } __attribute__((packed));

+struct bdb_psr_features {
+   /* psr_enable byte */
+   u8 link_disable:1;
+   u8 require_aux:1;
+   u8 rsvd1:6;
+
+   /* panel wait times */
+   u8 idle_frames:4;
+   u8 wait_lines:3;
+   u8 rsvd2:1;
+
+   /* TP1 wakeup time */
+   u16 wakeup_tp1;
+
+   /* TP2 wakeup time */
+   u16 wakeup_tp2;
+} __attribute__((packed));
+
 /* LFP pointer table contains entries to the struct below */
 struct bdb_lvds_lfp_data_ptr {
u16 fp_timing_offset; /* offsets are from start of bdb */
-- 
1.7.11.7

[PATCH 5/9] drm/i915: Setup EDP PSR AUX Registers

[Rodrigo Vivi]

From: Shobhit Kumar 

Signed-off-by: Shobhit Kumar 

v2: Created aux_clock_divider function to avoid duplicated code.
Unfortunatelly dp_aux_ch and psr_aux_ch aren't so similar to reuse full 
code.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h  | 13 ++
 drivers/gpu/drm/i915/intel_dp.c  | 89 +++-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 83 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7bb3134..10732dc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1563,6 +1563,19 @@
 #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
 #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)

+#define EDP_PSR_AUX_CTL0x64810
+#define EDP_PSR_AUX_DATA1  0x64814
+#define EDP_PSR_AUX_DATA2  0x64818
+#define EDP_PSR_AUX_DATA3  0x6481c
+#define EDP_PSR_AUX_DATA4  0x64820
+#define EDP_PSR_AUX_DATA5  0x64824
+#define EDP_PSR_STATUS_CTL 0x64840
+#define   EDP_PSR_STATUS_MASK  (7<<29)
+#define EDP_PSR_PERF_CNT   0x64844
+#define EDP_PSR_DEBUG_CTL  0x64860
+#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
+#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+
 /* VGA port control */
 #define ADPA   0x61100
 #define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aeb0ef1..fe83e05 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -364,6 +364,34 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool 
has_aux_irq)
return status;
 }

+static uint32_t get_aux_clock_divider(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   /* The clock divider is based off the hrawclk,
+* and would like to run at 2MHz. So, take the
+* hrawclk value and divide by 2 and use that
+*
+* Note that PCH attached eDP panels should use a 125MHz input
+* clock divider.
+*/
+   if (is_cpu_edp(intel_dp)) {
+   if (HAS_DDI(dev))
+   return intel_ddi_get_cdclk_freq(dev_priv) >> 1;
+   else if (IS_VALLEYVIEW(dev))
+   return 100;
+   else if (IS_GEN6(dev) || IS_GEN7(dev))
+   return 200; /* SNB & IVB eDP input clock at 400Mhz */
+   else
+   return 225; /* eDP input clock at 450Mhz */
+   } else if (HAS_PCH_SPLIT(dev))
+   return DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
+   else
+   return intel_hrawclk(dev) / 2;
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
uint8_t *send, int send_bytes,
@@ -411,26 +439,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}

intel_dp_check_edp(intel_dp);
-   /* The clock divider is based off the hrawclk,
-* and would like to run at 2MHz. So, take the
-* hrawclk value and divide by 2 and use that
-*
-* Note that PCH attached eDP panels should use a 125MHz input
-* clock divider.
-*/
-   if (is_cpu_edp(intel_dp)) {
-   if (HAS_DDI(dev))
-   aux_clock_divider = intel_ddi_get_cdclk_freq(dev_priv) 
>> 1;
-   else if (IS_VALLEYVIEW(dev))
-   aux_clock_divider = 100;
-   else if (IS_GEN6(dev) || IS_GEN7(dev))
-   aux_clock_divider = 200; /* SNB & IVB eDP input clock 
at 400Mhz */
-   else
-   aux_clock_divider = 225; /* eDP input clock at 450Mhz */
-   } else if (HAS_PCH_SPLIT(dev))
-   aux_clock_divider = DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
-   else
-   aux_clock_divider = intel_hrawclk(dev) / 2;
+   aux_clock_divider = get_aux_clock_divider(intel_dp);

if (IS_GEN6(dev))
precharge = 3;
@@ -1440,6 +1449,46 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
return (is_edp(intel_dp) && (intel_dp->psr_dpcd[0] & 0x1));
 }

+static void intel_edp_psr_setup(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   uint32_t aux_clock_divider;
+   int precharge = 0x3;
+   int msg_size = 5;   /* Header(4) + Message(1) */
+
+   /* No need to setup if already done as these setting are persistent
+* until power states are entered */
+   if (intel_dp->psr_setup)
+   return;
+
+   /* Setup AUX registers */
+   /* Write command on DPCD 

[PATCH 4/9] drm/i915: Read the EDP DPCD and PSR Capability

[Rodrigo Vivi]

From: Shobhit Kumar 

Signed-off-by: Shobhit Kumar 

v2: reuse of just created is_edp_psr and put it at right place.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c  | 12 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cbd3236..aeb0ef1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1435,6 +1435,11 @@ static void intel_post_disable_dp(struct intel_encoder 
*encoder)
}
 }

+static bool is_edp_psr(struct intel_dp *intel_dp)
+{
+   return (is_edp(intel_dp) && (intel_dp->psr_dpcd[0] & 0x1));
+}
+
 static void intel_enable_dp(struct intel_encoder *encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
@@ -2111,6 +2116,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */

+   /* Check if the panel supports PSR */
+   memset(intel_dp->psr_dpcd, 0, EDP_PSR_RECEIVER_CAP_SIZE);
+   intel_dp_aux_native_read_retry(intel_dp, DP_PSR_SUPPORT,
+  intel_dp->psr_dpcd,
+  sizeof(intel_dp->psr_dpcd));
+   if (is_edp_psr(intel_dp))
+   DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
  DP_DWN_STRM_PORT_PRESENT))
return true; /* native DP sink */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index aeff0d1..d4b3bac 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -371,6 +371,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+   uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
-- 
1.7.11.7

[PATCH 3/9] drm/i915: Added SDP and VSC structures for handling PSR for eDP

[Rodrigo Vivi]

From: Shobhit Kumar 

Signed-off-by: Sateesh Kavuri 

v2: Modified and corrected the structures to be more in line for
kernel coding guidelines and rebased the code on Paulo's DP patchset

Signed-off-by: Shobhit Kumar 

v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE
v4: moving them to include/drm/drm_dp_helper.h and also already
icluding EDP_PSR_RECEIVER_CAP_SIZE to add everything needed
for PSR at once at drm_dp_helper.h

Signed-off-by: Rodrigo Vivi 
---
 include/drm/drm_dp_helper.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e8e1417..e9b7c4b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -343,12 +343,41 @@ u8 drm_dp_get_adjust_request_pre_emphasis(u8 
link_status[DP_LINK_STATUS_SIZE],
  int lane);

 #define DP_RECEIVER_CAP_SIZE   0xf
+#define EDP_PSR_RECEIVER_CAP_SIZE  2
+
 void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);

 u8 drm_dp_link_rate_to_bw_code(int link_rate);
 int drm_dp_bw_code_to_link_rate(u8 link_bw);

+/* SDP header as per eDP 1.3 spec, section 3.6 */
+struct edp_sdp_header {
+   u8 id;
+   u8 type;
+   u8 revision : 5;/* Bits 0:4 */
+   u8 rsvd1: 3;/* Bits 5:7 */
+   u8 valid_payload_bytes : 5; /* Bits 0:4 */
+   u8 rsvd2   : 3; /* Bits 5:7 */
+} __attribute__((packed));
+
+/* SDP VSC header as per eDP 1.3 spec, section 3.6 */
+struct edp_vsc_psr {
+   struct edp_sdp_header sdp_header;
+   u8 unused;
+   u8 psr_state  : 1;  /* Bit 0 */
+   u8 update_rfb : 1;  /* Bit 1 */
+   u8 valid_crc  : 1;  /* Bit 2 */
+   u8 reserved1  : 5;  /* Bits 3:7 */
+   u8 crc_r_lower;
+   u8 crc_r_higher;
+   u8 crc_g_lower;
+   u8 crc_g_higher;
+   u8 crc_b_lower;
+   u8 crc_b_higher;
+   u8 reserved2[24];
+} __attribute__((packed));
+
 static inline int
 drm_dp_max_link_rate(u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-- 
1.7.11.7

[PATCH 2/9] drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe

[Rodrigo Vivi]

While old platforms had 3 transcoders and 3 pipes (1:1), HSW has 4 transcoders 
and 3 pipes. To avoid future mistakes transcoders must be used here instead of 
pipes even though it is working right now by coincidence.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h   | 16 
 drivers/gpu/drm/i915/intel_hdmi.c | 12 ++--
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2521617..7bb3134 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3742,14 +3742,14 @@
 #define HSW_VIDEO_DIP_VSC_ECC_B0x61344
 #define HSW_VIDEO_DIP_GCP_B0x61210

-#define HSW_TVIDEO_DIP_CTL(pipe) \
-_PIPE(pipe, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B)
-#define HSW_TVIDEO_DIP_AVI_DATA(pipe) \
-_PIPE(pipe, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B)
-#define HSW_TVIDEO_DIP_SPD_DATA(pipe) \
-_PIPE(pipe, HSW_VIDEO_DIP_SPD_DATA_A, HSW_VIDEO_DIP_SPD_DATA_B)
-#define HSW_TVIDEO_DIP_GCP(pipe) \
-   _PIPE(pipe, HSW_VIDEO_DIP_GCP_A, HSW_VIDEO_DIP_GCP_B)
+#define HSW_TVIDEO_DIP_CTL(trans) \
+_TRANSCODER(trans, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B)
+#define HSW_TVIDEO_DIP_AVI_DATA(trans) \
+_TRANSCODER(trans, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B)
+#define HSW_TVIDEO_DIP_SPD_DATA(trans) \
+_TRANSCODER(trans, HSW_VIDEO_DIP_SPD_DATA_A, HSW_VIDEO_DIP_SPD_DATA_B)
+#define HSW_TVIDEO_DIP_GCP(trans) \
+   _TRANSCODER(trans, HSW_VIDEO_DIP_GCP_A, HSW_VIDEO_DIP_GCP_B)

 #define _TRANS_HTOTAL_B  0xe1000
 #define _TRANS_HBLANK_B  0xe1004
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index d53b731..ab95e05 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -120,13 +120,13 @@ static u32 hsw_infoframe_enable(struct dip_infoframe 
*frame)
}
 }

-static u32 hsw_infoframe_data_reg(struct dip_infoframe *frame, enum pipe pipe)
+static u32 hsw_infoframe_data_reg(struct dip_infoframe *frame, enum transcoder 
cpu_transcoder)
 {
switch (frame->type) {
case DIP_TYPE_AVI:
-   return HSW_TVIDEO_DIP_AVI_DATA(pipe);
+   return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder);
case DIP_TYPE_SPD:
-   return HSW_TVIDEO_DIP_SPD_DATA(pipe);
+   return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder);
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
return 0;
@@ -293,8 +293,8 @@ static void hsw_write_infoframe(struct drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
-   u32 ctl_reg = HSW_TVIDEO_DIP_CTL(intel_crtc->pipe);
-   u32 data_reg = hsw_infoframe_data_reg(frame, intel_crtc->pipe);
+   u32 ctl_reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder);
+   u32 data_reg = hsw_infoframe_data_reg(frame, 
intel_crtc->cpu_transcoder);
unsigned int i, len = DIP_HEADER_SIZE + frame->len;
u32 val = I915_READ(ctl_reg);

@@ -566,7 +566,7 @@ static void hsw_set_infoframes(struct drm_encoder *encoder,
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
-   u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->pipe);
+   u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder);
u32 val = I915_READ(reg);

assert_hdmi_port_disabled(intel_hdmi);
-- 
1.7.11.7

[PATCH 1/9] drm/i915: Organize VBT stuff inside drm_i915_private

[Rodrigo Vivi]

drm_i915_private is getting bigger and bigger when adding new vbt stuff.
So, the better way of getting drm_i915_private organized is to create an 
special structure for vbt stuff.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_dma.c  |  8 +--
 drivers/gpu/drm/i915/i915_drv.h  | 56 +++--
 drivers/gpu/drm/i915/intel_bios.c| 96 ++--
 drivers/gpu/drm/i915/intel_crt.c |  4 +-
 drivers/gpu/drm/i915/intel_display.c | 16 +++---
 drivers/gpu/drm/i915/intel_dp.c  | 12 ++---
 drivers/gpu/drm/i915/intel_lvds.c| 20 
 drivers/gpu/drm/i915/intel_sdvo.c|  6 +--
 drivers/gpu/drm/i915/intel_tv.c  |  8 +--
 9 files changed, 116 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f70178..e43711f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1714,10 +1714,10 @@ int i915_driver_unload(struct drm_device *dev)
 * free the memory space allocated for the child device
 * config parsed from VBT
 */
-   if (dev_priv->child_dev && dev_priv->child_dev_num) {
-   kfree(dev_priv->child_dev);
-   dev_priv->child_dev = NULL;
-   dev_priv->child_dev_num = 0;
+   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
+   kfree(dev_priv->vbt.child_dev);
+   dev_priv->vbt.child_dev = NULL;
+   dev_priv->vbt.child_dev_num = 0;
}

vga_switcheroo_unregister_client(dev->pdev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3189034..e22f6bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,36 @@ struct intel_l3_parity {
struct work_struct error_work;
 };

+struct intel_vbt_data {
+   struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
+   struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
+
+   /* Feature bits */
+   unsigned int int_tv_support:1;
+   unsigned int lvds_dither:1;
+   unsigned int lvds_vbt:1;
+   unsigned int int_crt_support:1;
+   unsigned int lvds_use_ssc:1;
+   unsigned int display_clock_mode:1;
+   int lvds_ssc_freq;
+   unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
+
+   /* eDP */
+   int edp_rate;
+   int edp_lanes;
+   int edp_preemphasis;
+   int edp_vswing;
+   bool edp_initialized;
+   bool edp_support;
+   int edp_bpp;
+   struct edp_power_seq edp_pps;
+
+   int crt_ddc_pin;
+
+   int child_dev_num;
+   struct child_device_config *child_dev;
+};
+
 typedef struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -745,6 +775,7 @@ typedef struct drm_i915_private {
struct intel_fbc_work *fbc_work;

struct intel_opregion opregion;
+   struct intel_vbt_data vbt;

/* overlay */
struct intel_overlay *overlay;
@@ -753,32 +784,9 @@ typedef struct drm_i915_private {
/* LVDS info */
int backlight_level;  /* restore backlight to this value */
bool backlight_enabled;
-   struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
-   struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */

-   /* Feature bits from the VBIOS */
-   unsigned int int_tv_support:1;
-   unsigned int lvds_dither:1;
-   unsigned int lvds_vbt:1;
-   unsigned int int_crt_support:1;
-   unsigned int lvds_use_ssc:1;
-   unsigned int display_clock_mode:1;
-   int lvds_ssc_freq;
-   unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
-   struct {
-   int rate;
-   int lanes;
-   int preemphasis;
-   int vswing;
-
-   bool initialized;
-   bool support;
-   int bpp;
-   struct edp_power_seq pps;
-   } edp;
bool no_aux_handshake;

-   int crt_ddc_pin;
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
@@ -928,8 +936,6 @@ typedef struct drm_i915_private {
/* indicates the reduced downclock for LVDS*/
int lvds_downclock;
u16 orig_clock;
-   int child_dev_num;
-   struct child_device_config *child_dev;

bool mchbar_need_disable;

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 55ffba1..e145151 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -212,7 +212,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
if (!lvds_options)
return;

-   

[PATCH 0/9] Enable eDP PSR functionality at HSW - v2

[Rodrigo Vivi]

PSR is an eDP feature that allows power saving even with static image at eDP 
screen.

v2: Main differences in this v2:
- Created vbt struct to get i915 dev_priv more organized and to avoid adding 
more stuff into it.
- migrated hsw macros to use transcoder instead of pipes than I could address 
eDP
- remove patch that was only adding edp psr registers and added them on demand

v1:
Shobit Kumar has implemented this patch series some time ago, but had no eDP 
panel with PSR capability to test them.

I could test and verify that this series fully identify PSR capability and 
enables it at HSW.
I also verified that it saves from 0.5-1W but only when in blank screen. It 
seems it is not really entering in sleeping mode with static image at eDP 
screen yet.

Please accept this series as the first part of PSR enabling while we continue 
working to improve its functionality.

Rodrigo Vivi (3):
  drm/i915: Organize VBT stuff inside drm_i915_private
  drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe
  drm/i915: Hook PSR functionality

Shobhit Kumar (6):
  drm/i915: Added SDP and VSC structures for handling PSR for eDP
  drm/i915: Read the EDP DPCD and PSR Capability
  drm/i915: Setup EDP PSR AUX Registers
  drm/i915: VBT Parsing for the PSR Feature Block for HSW
  drm/i915: Enable/Disable PSR on HSW
  drm/i915: Added debugfs support for PSR Status

 drivers/gpu/drm/i915/i915_debugfs.c  |  34 +
 drivers/gpu/drm/i915/i915_dma.c  |   8 +-
 drivers/gpu/drm/i915/i915_drv.h  |  63 +---
 drivers/gpu/drm/i915/i915_reg.h  |  53 ++-
 drivers/gpu/drm/i915/intel_bios.c| 126 ++--
 drivers/gpu/drm/i915/intel_bios.h|  20 ++-
 drivers/gpu/drm/i915/intel_crt.c |   4 +-
 drivers/gpu/drm/i915/intel_ddi.c |   8 +-
 drivers/gpu/drm/i915/intel_display.c |  16 +-
 drivers/gpu/drm/i915/intel_dp.c  | 285 +++
 drivers/gpu/drm/i915/intel_drv.h |   5 +
 drivers/gpu/drm/i915/intel_hdmi.c|  12 +-
 drivers/gpu/drm/i915/intel_lvds.c|  20 +--
 drivers/gpu/drm/i915/intel_sdvo.c|   6 +-
 drivers/gpu/drm/i915/intel_tv.c  |   8 +-
 include/drm/drm_dp_helper.h  |  29 
 16 files changed, 551 insertions(+), 146 deletions(-)

-- 
1.7.11.7

[PATCH 1/2] drm/exynos: add support for dt based search to exynos4 hdmi

[Inki Dae]

Hi Rahul,

Could you add descriptions to dt document file? For this, you can
refer to the below link,
https://patchwork.kernel.org/patch/1948061/

Thanks,
Inki Dae

2013/1/25 Rahul Sharma :
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_ddc.c | 2 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c| 6 ++
>  drivers/gpu/drm/exynos/exynos_hdmiphy.c | 2 ++
>  3 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
> b/drivers/gpu/drm/exynos/exynos_ddc.c
> index 4e9b5ba..7680809 100644
> --- a/drivers/gpu/drm/exynos/exynos_ddc.c
> +++ b/drivers/gpu/drm/exynos/exynos_ddc.c
> @@ -53,6 +53,8 @@ static struct of_device_id hdmiddc_match_types[] = {
> {
> .compatible = "samsung,exynos5-hdmiddc",
> }, {
> +   .compatible = "samsung,exynos4-hdmiddc",
> +   }, {
> /* end node */
> }
>  };
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index fbab3c4..202b65f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2418,6 +2418,12 @@ static struct platform_device_id hdmi_driver_types[] = 
> {
>  #ifdef CONFIG_OF
>  static struct of_device_id hdmi_match_types[] = {
> {
> +   .compatible = "samsung,exynos4-hdmi",
> +   .data   = (void *)HDMI_TYPE13,
> +   }, {
> +   .compatible = "samsung,exynos4-hdmi14",
> +   .data   = (void *)HDMI_TYPE14,
> +   }, {
> .compatible = "samsung,exynos5-hdmi",
> .data   = (void *)HDMI_TYPE14,
> }, {
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c 
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index ea49d13..2e33f90 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -51,6 +51,8 @@ static struct of_device_id hdmiphy_match_types[] = {
> {
> .compatible = "samsung,exynos5-hdmiphy",
> }, {
> +   .compatible = "samsung,exynos4-hdmiphy",
> +   }, {
> /* end node */
> }
>  };
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/exynos: Get HDMI version from device tree

[Inki Dae]

2013/1/30 Sean Paul :
> On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren  
> wrote:
>> On 01/08/2013 01:16 PM, Sean Paul wrote:
>>> Add a property to the hdmi node so we can specify the HDMI version in
>>> the device tree instead of just defaulting to v1.4 with the existence of
>>> the dt node.
>>
>> I guess this seems OK to me if required, although I'd certainly like to
>> see someone familiar with the Exynos HW confirm whether this should be
>> driven purely by DT compatible value for the HDMI IP block instead though.
>
> +inki
>
> Inki, does this seem reasonable to you?
>

Looks good to me. At least it's better than old one. I'll apply it if
there is no any opinion. And one more thing, Exynos hdmi controller
has no version info register so we need such thing. But in case of
Mixer controller, it has the version info register so we could support
all mixer controllers of Exynos SoC checking that register. So if you
are planning on such thing for Mixer also then I'd recommend you to
consider checking that register.

Thanks,
Inki Dae

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

radeon modeset crashes on A4-3400 HD6410D

[Alex Deucher]

On Tue, Jan 29, 2013 at 1:09 PM, Mikko Tiihonen  
wrote:
> Hi,
>
> I have a A4-3400 CPU that I bought half a year ago. I've tried once month,
> but  Fedora has never succeeded in booting in graphical mode.
>
> Some time ago a finally built some custom kernels to figure out why. I
> created a bug to Fedora bug, but it has not progressed.
>
> Analysis:
> The radeon module startup fails with division by zero in
> r6xx_remap_render_backend because the first RB is not enabled and the code
> assuming that enabled RBs must be all the first ones of the valid range.
>
>
> Longer version:
>
> In r600.c:r6xx_remap_render_backend
>
> The function contains only one divide:
>
> u32 r6xx_remap_render_backend(struct radeon_device *rdev,
>   u32 tiling_pipe_num,
>   u32 max_rb_num,
>   u32 total_max_rb_num,
>   u32 disabled_rb_mask)
> {
> u32 rendering_pipe_num, rb_num_width, req_rb_num;
> ...
> /* mask out the RBs that don't exist on that asic */
> disabled_rb_mask |= (0xff << max_rb_num) & 0xff;
>
> rendering_pipe_num = 1 << tiling_pipe_num;
> req_rb_num = total_max_rb_num -
> r600_count_pipe_bits(disabled_rb_mask);
> BUG_ON(rendering_pipe_num < req_rb_num);
>
> pipe_rb_ratio = rendering_pipe_num / req_rb_num;
>
> I added a printk to see what actual parameters are passed in:
>
> tiling_pipe_num=2, max_rb_num=1, total_max_rb_num=8, disabled_rb_mask=253
>
> Using those to calculate the divide by zero comes from:
>
> disabled_rb_mask |= 254; -> 255
> req_rb_num = 8 - 8;
>
>
> Quick fix for stable kernel series:
>
> The attached fix activates only in the division by zero case and instead of
> failing uses the given disabled_rb_mask. This is guaranteed to be regression
> free and actually allows me to load the radeon driver successfully. It does
> help with cards that currently work, but for which some usable RBs are
> disabled due to the eager masking.
>
>
> Proper fix would propably be to find out think why the disabled_rb_mask is
> masked the way it is, were there bugs in other places for which it is a
> workaround. I can see two possible modifictions:
> 1) only mask bits exceeding total_max_rb_num instead of the max_rb_num since
> the one enabled RB on A4-3400 can propably be any one of the 8 possible
> values.
> 2) or activate the current code only if there are more than max_rb_num zero
> bits in the given disabled_rb_mask

Looks good.  I've gone ahead and applied your patch for safety sake
and I also added a patch to set up the RBs correctly on your board.
Please test the attached patches.

Thanks!

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-protect-against-div-by-0-in-backend-setup.patch
Type: text/x-patch
Size: 1480 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a3d49f5b/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-backend-map-setup-on-1-RB-sumo-boards.patch
Type: text/x-patch
Size: 1682 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a3d49f5b/attachment-0001.bin>

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #9 from Michel D?nzer  ---
(In reply to comment #8)
> Would it be good for me to bisect Mesa?

If Mesa commit 6532eb17baff6e61b427f29e076883f8941ae664 (where code depending
on DRM minor 26 was first introduced) doesn't leak, yes please.

BTW, does setting the environment variable R600_HYPERZ=0 for the leaking
process(es) work around the problem?


> The testing I have done so far was assuming the problem was in the kernel,
> [...]

The fact that the memory is reclaimed on process exit makes that unlikely.

-- 
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/20130130/c8235d78/attachment.html>

[Bug 60073] [bisected] Bad rendering in Path of Exile

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

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

Alex Deucher  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=59690

-- 
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/20130130/c7fca45a/attachment.html>

[PATCH 4/5] drm/tegra: Implement VBLANK support

[Daniel Vetter]

On Wed, Jan 30, 2013 at 9:34 AM, Thierry Reding
 wrote:
> On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote:
>> On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding
>>  wrote:
>> > Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
>> > special in this case because it doesn't use the generic IRQ support
>> > provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one
>> > interrupt handler for each display controller.
>> >
>> > While at it, clean up the way that interrupts are enabled to ensure
>> > that the VBLANK interrupt only gets enabled when required.
>> >
>> > Signed-off-by: Thierry Reding 
>> > ---
>>
>> Sorry Thierry, but is this a useful feature? Are applications really
>> making use of it? Because it means that that an IRQ will have to
>> trigger every 16.67ms when it is taken, which means the device can't
>> sleep. (probably OK because it should go back to idle when the app
>> lets go of the vblank). But worse, for one-shot panels there is no
>> continuous vblank. I've been doing weird hacks to run a timer when the
>> smart panel is idle to trick applications into thinking they have a
>> vblank pulse. But really I think the whole feature of a vblank pulse
>> is pretty lame and I wish it would die. Were you going to use it for
>> something specific, or just adding it for completeness?
>
> This is mainly added for completeness. I know that on Tegra we can do a
> lot better by using syncpoints, but applications such as Weston (in
> general applications that use the generic DRM API) rely on this to sync
> rendering with VBLANK.
>
> I don't think there's another way to achieve the same thing. And as you
> already mentioned, this is only enabled when an application actively
> uses it, in which case the device won't sleep anyway.

I think driving animations with the vblank signal is nice, but we
kinda only need that with the pageflip support. Unfortunately the
current drm code is a bit a mess in that area, so pageflips force you
to enable the vblank interrupt for otherwise the timestamp'ed pageflip
completion events won't work.

Recent intel hw has pageflip timestamp registers, so we don't really
need that. And I guess other hw is similar. So we probably should
clean up and untangle the infrastructure a bit around the drm vblank
support code.

Another issue is that the vblank ioctl itself doesn't deal with
modeset crtc ids, so adding a new interface for that would be good.
Otoh most kms clients don't really use it, but only care about
pageflips.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 60073] [bisected] Bad rendering in Path of Exile

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

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

--- Comment #4 from Wojciech Pyczak  ---
Created attachment 73929
  --> https://bugs.freedesktop.org/attachment.cgi?id=73929=edit
In-game screenshot (bad rendering)

-- 
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/20130130/84b0944b/attachment.html>

[Bug 60073] [bisected] Bad rendering in Path of Exile

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

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

--- Comment #3 from Wojciech Pyczak  ---
Created attachment 73928
  --> https://bugs.freedesktop.org/attachment.cgi?id=73928=edit
In-game screenshot

-- 
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/20130130/1e9f7ad8/attachment.html>

[Bug 60073] [bisected] Bad rendering in Path of Exile

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

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

--- Comment #2 from Wojciech Pyczak  ---
Created attachment 73927
  --> https://bugs.freedesktop.org/attachment.cgi?id=73927=edit
Login screen (bad rendering)

-- 
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/20130130/424d74f7/attachment.html>

[Bug 60073] [bisected] Bad rendering in Path of Exile

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

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

--- Comment #1 from Wojciech Pyczak  ---
Created attachment 73926
  --> https://bugs.freedesktop.org/attachment.cgi?id=73926=edit
Login screen

-- 
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/20130130/77c91b6f/attachment.html>

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

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

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

--- Comment #8 from Dave Witbrodt  ---
(In reply to comment #7)
> This is indeed more likely an issue in Mesa than in the kernel. The commit
> you bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause
> the Mesa code to use different code paths.

In my two attempted manual reverts, I didn't know what effect the code in
radeon_drv.c actually had.  When looking at later DRM changes (after the one
identified by the bisection) I saw that the value of KMS_DRIVER_MINOR was
incremented further, so I thought I should leave the value unchanged.


> Does current Mesa Git still leak?

After updating/merging to the current HEAD (commit 02b6da1e of Jan. 29), I
built new Mesa packages and installed them.

I am currently relying the last kernel from my local tree which does not leak,
so I rebooted to the kernel I had built that is most current with the upstream
DRM changes:  stable 3.7.4 + many commits from drm-next/drm-fixes up to commit
014b3440 of Jan. 21 in drm-fixes.

Yes, it still leaks.


Would it be good for me to bisect Mesa?  I would use my most up-to-date kernel,
try to find an older version of Mesa which does not leak, and then identify the
first patch to Mesa which causes the leaking.

The testing I have done so far was assuming the problem was in the kernel, but
I was planning to look at Mesa as well.  I decided to report the bug before
continuing, hoping for some guidance from the experts.  If there really is a
memory leak caused by the kernel DRI, then I would like to help get it fixed
before 3.8 is released; or, if there is a problem in Mesa I would like to help
get it fixed for 9.1.

-- 
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/20130130/a62882a7/attachment-0001.html>

[Bug 60073] New: [bisected] Bad rendering in Path of Exile

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

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

  Priority: medium
Bug ID: 60073
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [bisected] Bad rendering in Path of Exile
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: nissarin at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Hardware: Radeon 6850

Software: 64bit Gentoo, game running via Wine (32bit), git versions of libdrm,
xf86-video-ati, kernel version 3.7(ish) and latest 3.8 rc + drm-next branch

The issue is affecting light effects, spell effects, etc. (see screenshots).

Bisecting leads to this commit:
commit 3b51d71c8544ee198008bbf3545bf3def6e9e77f
Author: Jordan Justen 
Date:   Fri Dec 28 11:00:50 2012 -0800

copyteximage: check that sRGB usage is valid for GLES3 / GL

Reviewed-by: Ian Romanick 
Signed-off-by: Jordan Justen 


There is already one bug report mentioning this commit [1], not sure if it's
the same issue.

Besides PoE, I also encontered similar problem in StarCraft2, I didn't checked
if it's the same problem, text/fonts on the loading screen shows the same
"corruption", however the game also hangs the GPU, so bisecting it might be a
bit problematic.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=59690

-- 
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/20130130/a530ed2a/attachment-0001.html>

[git pull] fbcon locking fixes.

[Daniel Vetter]

On Mon, Jan 28, 2013 at 1:45 PM, Maarten Lankhorst
 wrote:
>> There was a path going into set_con2fb_path if an fb driver was
>> already registered, I just pushed the locking out further on anyone
>> going in there.
>>
>> it boots on my EFI macbook here.
>>
> I cherry picked those patches to my tree, and the full series no longer 
> triggers a lockdep warning.
> It also no longer locks up during modprobing or vga-switcheroo either.
>
> Tested-by: Maarten Lankhorst 

QA reported spurious failures in some kms_flip tests and lockdep
splats, somehow both are fixed with the locking. I'm a bit confused
how these issues could cause failures in the flip tests, but alas:

Tested-by: Lu Hua  (for all three patches).
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd

[Sachin Kamat]

Hi Vikas,

Changelog mentioning differences between v1 and v2 is generally
preferred as it will help the reviewers.

On 30 January 2013 12:00, Vikas Sajjan  wrote:
> This patch adds display-timing node parsing to drm fimd, this depends on
> the display helper patchset at
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
>
> It also adds pinctrl support for drm fimd.
>
> patch is based on branch "exynos-drm-next" at
> http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> Is tested on Exynos5250 and Exynos4412 by applying dependent patches available
> at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
>
> Vikas Sajjan (1):
>   video: drm: exynos: Adds display-timing node parsing using video
> helper function
>
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 
> +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With warm regards,
Sachin

[PATCH 5/5] drm/tegra: Implement page-flipping support

[Thierry Reding]

On Wed, Jan 30, 2013 at 12:14:36PM +0100, Thierry Reding wrote:
> On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrj?l? wrote:
> > On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote:
> > > On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
> > > > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
> > > >  wrote:
> > > > > drm_events_release() should be enough to clean up the events, but I
> > > > > suspect the reason why Laurent put that code in was that the drm_crtc
> > > > > private data still has a reference to the event and needs to clear it.
> > > > > Otherwise the next page flip won't be scheduled because .page_flip()
> > > > > would return -EBUSY.
> > > > 
> > > > Hm, indeed we seem to have a nice bug in most drivers there :(
> > > 
> > > I think I may just recently have run into this bug on Intel hardware.
> > > Although perhaps I just used this wrongly.
> > > 
> > > Just for the fun of it I wanted to implement Conway's Game of Life on
> > > top of DRM/KMS. So I use two dumb buffer objects to alternately render
> > > to. Then I wanted to use page-flipping to synchronize with VBLANK.
> > > 
> > > So the sequence is basically:
> > > 
> > >   while (!done) {
> > >   grid_tick(grid);
> > >   grid_draw(grid, screen);
> > >   screen_flip(screen);
> > >   grid_swap(grid);
> > >   }
> > > 
> > > Where screen_flip() chooses the framebuffer and passes it to
> > > drmModePageFlip() like so:
> > > 
> > >   int fb = screen->fb[screen->current];
> > > 
> > >   drmModePageFlip(screen->fd, screen->crtc, fb,
> > >   DRM_MODE_PAGE_FLIP_EVENT, screen);
> > > 
> > > This runs for about 3 seconds and then hangs, so the display is no
> > > longer updated. I've also verified that the same happens on Radeon.
> > > But maybe I am mistaken and this isn't the proper programming sequence?
> > 
> > You asked for page flip events. Do you actually handle them in your code?
> 
> Duh. No I wasn't =) I suppose some queue must be running full if the
> event isn't handled by calling drmHandleEvent(). Okay, this now works
> properly with page-flipping.

Just in case anybody's interested, the code is here:

https://gitorious.org/thierryreding/kmslife

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

[PATCH 2/7] mutex: add support for reservation style locks

[Maarten Lankhorst]

Op 30-01-13 02:07, Rob Clark schreef:
> On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
>  wrote:
> Hi Maarten,
>
> This is a nice looking extension to avoid re-implementing a mutex in
> TTM/reservation code..  ofc, probably someone more familiar with mutex
> code should probably review, but probably a bit of explanation about
> what and why would be helpful.
>
>> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
>>   Lock a buffer with a reservation_id set. reservation_id must not be set to 
>> 0,
>>   since this is a special value that means no reservation_id.
>>
>>   Normally if reservation_id is not set, or is older than the reservation_id 
>> that's
>>   currently set on the mutex, the behavior will be to wait normally.
>>
>>   However, if  the reservation_id is newer than the current reservation_id, 
>> -EAGAIN
>>   will be returned, and this function must unreserve all other mutexes and 
>> then redo
>>   a blocking lock with normal mutex calls to prevent a deadlock, then call
>>   mutex_locked_set_reservation on successful locking to set the 
>> reservation_id inside
>>   the lock.
> It might be a bit more clear to write up how this works from the
> perspective of the user of ticket_mutex, separately from the internal
> implementation first, and then how it works internally?  Ie, the
> mutex_set_reservation_fastpath() call is internal to the
> implementation of ticket_mutex, but -EAGAIN is something the caller of
> ticket_mutex shall deal with.  This might give a clearer picture of
> how TTM / reservation uses this to prevent deadlock, so those less
> familiar with TTM could better understand.
>
> Well, here is an attempt to start a write-up, which should perhaps
> eventually be folded into Documentation/ticket-mutex-design.txt.  But
> hopefully a better explanation of the problem and the solution will
> encourage some review of the ticket_mutex changes.
>
> ==
> Basic problem statement:
> - --- -
> GPU's do operations that commonly involve many buffers.  Those buffers
> can be shared across contexts/processes, exist in different memory
> domains (for example VRAM vs system memory), and so on.  And with
> PRIME / dmabuf, they can even be shared across devices.  So there are
> a handful of situations where the driver needs to wait for buffers to
> become ready.  If you think about this in terms of waiting on a buffer
> mutex for it to become available, this presents a problem because
> there is no way to guarantee that buffers appear in a execbuf/batch in
> the same order in all contexts.  That is directly under control of
> userspace, and a result of the sequence of GL calls that an
> application makes.  Which results in the potential for deadlock.  The
> problem gets more complex when you consider that the kernel may need
> to migrate the buffer(s) into VRAM before the GPU operates on the
> buffer(s), which main in turn require evicting some other buffers (and
> you don't want to evict other buffers which are already queued up to
> the GPU), but for a simplified understanding of the problem you can
> ignore this.
>
> The algorithm that TTM came up with for dealing with this problem is
> quite simple.  For each group of buffers (execbuf) that need to be
> locked, the caller would be assigned a unique reservation_id, from a
> global counter.  In case of deadlock in the process of locking all the
> buffers associated with a execbuf, the one with the lowest
> reservation_id wins, and the one with the higher reservation_id
> unlocks all of the buffers that it has already locked, and then tries
> again.
>
> Originally TTM implemented this algorithm on top of an event-queue and
> atomic-ops, but Maarten Lankhorst realized that by merging this with
> the mutex code we could take advantage of the existing mutex fast-path
> code and result in a simpler solution, and so ticket_mutex was born.
> (Well, there where also some additional complexities with the original
> implementation when you start adding in cross-device buffer sharing
> for PRIME.. Maarten could probably better explain.)
>
> How it is used:
> --- -- -- -
>
> A very simplified version:
>
>   int submit_execbuf(execbuf)
>   {
>   /* acquiring locks, before queuing up to GPU: */
>   seqno = assign_global_seqno();
You also need to make a 'lock' type for seqno, and lock it for lockdep purposes.
This will be a virtual lock that will only exist in lockdep, but it's needed 
for proper lockdep annotation.

See reservation_ticket_init/fini. It's also important that seqno must not be 0, 
ever.


>   retry:
>   for (buf in execbuf->buffers) {
>   ret = mutex_reserve_lock(>lock, seqno);
The lockdep class for this lock must be the same for all reservations, and for 
maximum lockdep usability
you want all the buf->lock lockdep class for all objects across all devices to 
be the same too.

The __ticket_mutex_init in reservation_object_init does just that for you. :-)

>   

[PATCH 5/5] drm/tegra: Implement page-flipping support

[Thierry Reding]

On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrj?l? wrote:
> On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote:
> > On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
> > >  wrote:
> > > > drm_events_release() should be enough to clean up the events, but I
> > > > suspect the reason why Laurent put that code in was that the drm_crtc
> > > > private data still has a reference to the event and needs to clear it.
> > > > Otherwise the next page flip won't be scheduled because .page_flip()
> > > > would return -EBUSY.
> > > 
> > > Hm, indeed we seem to have a nice bug in most drivers there :(
> > 
> > I think I may just recently have run into this bug on Intel hardware.
> > Although perhaps I just used this wrongly.
> > 
> > Just for the fun of it I wanted to implement Conway's Game of Life on
> > top of DRM/KMS. So I use two dumb buffer objects to alternately render
> > to. Then I wanted to use page-flipping to synchronize with VBLANK.
> > 
> > So the sequence is basically:
> > 
> > while (!done) {
> > grid_tick(grid);
> > grid_draw(grid, screen);
> > screen_flip(screen);
> > grid_swap(grid);
> > }
> > 
> > Where screen_flip() chooses the framebuffer and passes it to
> > drmModePageFlip() like so:
> > 
> > int fb = screen->fb[screen->current];
> > 
> > drmModePageFlip(screen->fd, screen->crtc, fb,
> > DRM_MODE_PAGE_FLIP_EVENT, screen);
> > 
> > This runs for about 3 seconds and then hangs, so the display is no
> > longer updated. I've also verified that the same happens on Radeon.
> > But maybe I am mistaken and this isn't the proper programming sequence?
> 
> You asked for page flip events. Do you actually handle them in your code?

Duh. No I wasn't =) I suppose some queue must be running full if the
event isn't handled by calling drmHandleEvent(). Okay, this now works
properly with page-flipping.

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

[PATCH 2/7] mutex: add support for reservation style locks

[Daniel Vetter]

On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark  wrote:
> ==
> Basic problem statement:
> - --- -
> GPU's do operations that commonly involve many buffers.  Those buffers
> can be shared across contexts/processes, exist in different memory
> domains (for example VRAM vs system memory), and so on.  And with
> PRIME / dmabuf, they can even be shared across devices.  So there are
> a handful of situations where the driver needs to wait for buffers to
> become ready.  If you think about this in terms of waiting on a buffer
> mutex for it to become available, this presents a problem because
> there is no way to guarantee that buffers appear in a execbuf/batch in
> the same order in all contexts.  That is directly under control of
> userspace, and a result of the sequence of GL calls that an
> application makes.  Which results in the potential for deadlock.  The
> problem gets more complex when you consider that the kernel may need
> to migrate the buffer(s) into VRAM before the GPU operates on the
> buffer(s), which main in turn require evicting some other buffers (and
> you don't want to evict other buffers which are already queued up to
> the GPU), but for a simplified understanding of the problem you can
> ignore this.
>
> The algorithm that TTM came up with for dealing with this problem is
> quite simple.  For each group of buffers (execbuf) that need to be
> locked, the caller would be assigned a unique reservation_id, from a
> global counter.  In case of deadlock in the process of locking all the
> buffers associated with a execbuf, the one with the lowest
> reservation_id wins, and the one with the higher reservation_id
> unlocks all of the buffers that it has already locked, and then tries
> again.
>
> Originally TTM implemented this algorithm on top of an event-queue and
> atomic-ops, but Maarten Lankhorst realized that by merging this with
> the mutex code we could take advantage of the existing mutex fast-path
> code and result in a simpler solution, and so ticket_mutex was born.
> (Well, there where also some additional complexities with the original
> implementation when you start adding in cross-device buffer sharing
> for PRIME.. Maarten could probably better explain.)

I think the motivational writeup above is really nice, but the example
code below is a bit wrong

> How it is used:
> --- -- -- -
>
> A very simplified version:
>
>   int submit_execbuf(execbuf)
>   {
>   /* acquiring locks, before queuing up to GPU: */
>   seqno = assign_global_seqno();
>   retry:
>   for (buf in execbuf->buffers) {
>   ret = mutex_reserve_lock(>lock, seqno);
>   switch (ret) {
>   case 0:
>   /* we got the lock */
>   break;
>   case -EAGAIN:
>   /* someone with a lower seqno, so unreserve and try again: */
>   for (buf2 in reverse order starting before buf in
> execbuf->buffers)
>   mutex_unreserve_unlock(>lock);
>   goto retry;
>   default:
>   goto err;
>   }
>   }
>
>   /* now everything is good to go, submit job to GPU: */
>   ...
>   }
>
>   int finish_execbuf(execbuf)
>   {
>   /* when GPU is finished: */
>   for (buf in execbuf->buffers)
>   mutex_unreserve_unlock(>lock);
>   }
> ==

Since gpu command submission is all asnyc (hopefully at least) we
don't unlock once it completes, but right away after the commands are
submitted. Otherwise you wouldn't be able to submit new execbufs using
the same buffer objects (and besides, holding locks while going back
out to userspace is evil).

The trick is to add a fence object for async operation (essentially a
waitqueue on steriods to support gpu->gpu direct signalling). And
updating fences for a given execbuf needs to happen atomically for all
buffers, for otherwise userspace could trick the kernel into creating
a circular fence chain. This wouldn't deadlock the kernel, since
everything is async, but it'll nicely deadlock the gpus involved.
Hence why we need ticketing locks to get dma_buf fences off the
ground.

Maybe wait for Maarten's feedback, then update your motivational blurb a bit?

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

[PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function

[Vikas Sajjan]

This patch adds display-timing node parsing using video helper function

Signed-off-by: Leela Krishna Amudala 
Signed-off-by: Vikas Sajjan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..94729ed 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+   struct fb_videomode *fbmode;
+   struct device *disp_dev = >dev;
+   struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;

DRM_DEBUG_KMS("%s\n", __FILE__);

-   pdata = pdev->dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, "no platform data specified\n");
+   if (pdev->dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR("memory allocation for pdata failed\n");
+   return -ENOMEM;
+   }
+
+   fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+   if (!fbmode) {
+   DRM_ERROR("memory allocation for fbmode failed\n");
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(disp_dev->of_node, fbmode, -1);
+   if (ret) {
+   DRM_ERROR("failed to get fb_videomode\n");
+   return -EINVAL;
+   }
+   pdata->panel.timing = (struct fb_videomode) *fbmode;
+
+   } else {
+   pdata = pdev->dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR("no platform data specified\n");
+   return -EINVAL;
+   }
+   }
+
+   pctrl = devm_pinctrl_get_select_default(dev);
+   if (IS_ERR(pctrl)) {
+   DRM_ERROR("no pinctrl data provided.\n");
return -EINVAL;
}

-- 
1.7.9.5

[PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd

[Vikas Sajjan]

This patch adds display-timing node parsing to drm fimd, this depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

It also adds pinctrl support for drm fimd.

patch is based on branch "exynos-drm-next" at
http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Is tested on Exynos5250 and Exynos4412 by applying dependent patches available
at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

Vikas Sajjan (1):
  video: drm: exynos: Adds display-timing node parsing using video
helper function

 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

-- 
1.7.9.5

[PATCH 5/5] drm/tegra: Implement page-flipping support

[Ville Syrjälä]

On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote:
> On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
> >  wrote:
> > > drm_events_release() should be enough to clean up the events, but I
> > > suspect the reason why Laurent put that code in was that the drm_crtc
> > > private data still has a reference to the event and needs to clear it.
> > > Otherwise the next page flip won't be scheduled because .page_flip()
> > > would return -EBUSY.
> > 
> > Hm, indeed we seem to have a nice bug in most drivers there :(
> 
> I think I may just recently have run into this bug on Intel hardware.
> Although perhaps I just used this wrongly.
> 
> Just for the fun of it I wanted to implement Conway's Game of Life on
> top of DRM/KMS. So I use two dumb buffer objects to alternately render
> to. Then I wanted to use page-flipping to synchronize with VBLANK.
> 
> So the sequence is basically:
> 
>   while (!done) {
>   grid_tick(grid);
>   grid_draw(grid, screen);
>   screen_flip(screen);
>   grid_swap(grid);
>   }
> 
> Where screen_flip() chooses the framebuffer and passes it to
> drmModePageFlip() like so:
> 
>   int fb = screen->fb[screen->current];
> 
>   drmModePageFlip(screen->fd, screen->crtc, fb,
>   DRM_MODE_PAGE_FLIP_EVENT, screen);
> 
> This runs for about 3 seconds and then hangs, so the display is no
> longer updated. I've also verified that the same happens on Radeon.
> But maybe I am mistaken and this isn't the proper programming sequence?

You asked for page flip events. Do you actually handle them in your code?

-- 
Ville Syrj?l?
Intel OTC

A patch referencing this bug report has been merged...

[Jani Nikula]

Hi Florian, all -

First, thanks for your work on adding the bugzilla comments when patches
referencing bugs get merged. I find it useful.

Recently however there was a comment about a commit referencing a commit
referencing the bug report. Turns out the comment was missing one level
of indirection, it was really about a commit referencing a commit
referencing a commit referencing the bug [1].

Do we really need go that far, or is that a bug in your scripts? I think
three levels of indirection is more noise than signal; two might be
still be okay. What do others think?

BR,
Jani.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56

[PATCH 0/1] Adds display-timing node parsing to exynos drm fimd

[Leela Krishna Amudala]

Hello Sean,
This patch set will be abandoned and your comments will be addressed
in reply to
http://lists.freedesktop.org/archives/dri-devel/2013-January/034080.html

Thanks,
Leela Krishna Amudala.

On Tue, Jan 29, 2013 at 1:42 PM, Leela Krishna Amudala
 wrote:
> This patch adds display-timing node parsing to drm fimd, this depends on
> the display helper patchset at
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
>
> Patch is based on branch "exynos-drm-next" at
> http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/
>
> It is tested on Exynos5250 and Exynos4412 board by applying dependent patches 
> available at
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
>
> Leela Krishna Amudala (1):
>   video: drm: exynos: Adds display-timing node parsing using video
> helper function
>
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function

[Sean Paul]

On Wed, Jan 30, 2013 at 1:30 AM, Vikas Sajjan  
wrote:
> This patch adds display-timing node parsing using video helper function
>
> Signed-off-by: Leela Krishna Amudala 
> Signed-off-by: Vikas Sajjan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 
> +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..94729ed 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device 
> *pdev)
> struct exynos_drm_subdrv *subdrv;
> struct exynos_drm_fimd_pdata *pdata;
> struct exynos_drm_panel_info *panel;
> +   struct fb_videomode *fbmode;
> +   struct device *disp_dev = >dev;

Isn't this the same as dev (maybe I'm missing some dependent patch)?

> +   struct pinctrl *pctrl;
> struct resource *res;
> int win;
> int ret = -EINVAL;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> -   pdata = pdev->dev.platform_data;
> -   if (!pdata) {
> -   dev_err(dev, "no platform data specified\n");
> +   if (pdev->dev.of_node) {
> +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> +   if (!pdata) {
> +   DRM_ERROR("memory allocation for pdata failed\n");
> +   return -ENOMEM;
> +   }
> +
> +   fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
> +   if (!fbmode) {
> +   DRM_ERROR("memory allocation for fbmode failed\n");
> +   return -ENOMEM;
> +   }
> +
> +   ret = of_get_fb_videomode(disp_dev->of_node, fbmode, -1);
> +   if (ret) {
> +   DRM_ERROR("failed to get fb_videomode\n");
> +   return -EINVAL;
> +   }
> +   pdata->panel.timing = (struct fb_videomode) *fbmode;
> +
> +   } else {
> +   pdata = pdev->dev.platform_data;
> +   if (!pdata) {
> +   DRM_ERROR("no platform data specified\n");
> +   return -EINVAL;
> +   }
> +   }
> +
> +   pctrl = devm_pinctrl_get_select_default(dev);
> +   if (IS_ERR(pctrl)) {

Will this work for exynos5? AFAICT, there's no pinctrl setup for it.

Sean

> +   DRM_ERROR("no pinctrl data provided.\n");
> return -EINVAL;
> }
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/tegra: Implement page-flipping support

[Thierry Reding]

On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
> On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
>  wrote:
> > drm_events_release() should be enough to clean up the events, but I
> > suspect the reason why Laurent put that code in was that the drm_crtc
> > private data still has a reference to the event and needs to clear it.
> > Otherwise the next page flip won't be scheduled because .page_flip()
> > would return -EBUSY.
> 
> Hm, indeed we seem to have a nice bug in most drivers there :(

I think I may just recently have run into this bug on Intel hardware.
Although perhaps I just used this wrongly.

Just for the fun of it I wanted to implement Conway's Game of Life on
top of DRM/KMS. So I use two dumb buffer objects to alternately render
to. Then I wanted to use page-flipping to synchronize with VBLANK.

So the sequence is basically:

while (!done) {
grid_tick(grid);
grid_draw(grid, screen);
screen_flip(screen);
grid_swap(grid);
}

Where screen_flip() chooses the framebuffer and passes it to
drmModePageFlip() like so:

int fb = screen->fb[screen->current];

drmModePageFlip(screen->fd, screen->crtc, fb,
DRM_MODE_PAGE_FLIP_EVENT, screen);

This runs for about 3 seconds and then hangs, so the display is no
longer updated. I've also verified that the same happens on Radeon.
But maybe I am mistaken and this isn't the proper programming sequence?

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

[PATCH] drm: avoid "mono_time_offset may be used uninitialized"

[Stephen Warren]

On 01/29/2013 05:09 PM, Stephen Warren wrote:
> From: Stephen Warren 
> 
> Silence the following:
> drivers/gpu/drm/drm_irq.c: In function 
> 'drm_calc_vbltimestamp_from_scanoutpos':
> drivers/gpu/drm/drm_irq.c:583:24: warning: 'mono_time_offset.tv64' may be 
> used uninitialized in this function

FYI, I found that I see this warning with gcc-4.5.3, but not with
gcc-4.7.2 or gcc-4.6.3. Hence, you might decide you don't care about
this patch.

[PATCH 4/5] drm/tegra: Implement VBLANK support

[Thierry Reding]

On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote:
> On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding
>  wrote:
> > Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
> > special in this case because it doesn't use the generic IRQ support
> > provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one
> > interrupt handler for each display controller.
> >
> > While at it, clean up the way that interrupts are enabled to ensure
> > that the VBLANK interrupt only gets enabled when required.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> 
> Sorry Thierry, but is this a useful feature? Are applications really
> making use of it? Because it means that that an IRQ will have to
> trigger every 16.67ms when it is taken, which means the device can't
> sleep. (probably OK because it should go back to idle when the app
> lets go of the vblank). But worse, for one-shot panels there is no
> continuous vblank. I've been doing weird hacks to run a timer when the
> smart panel is idle to trick applications into thinking they have a
> vblank pulse. But really I think the whole feature of a vblank pulse
> is pretty lame and I wish it would die. Were you going to use it for
> something specific, or just adding it for completeness?

This is mainly added for completeness. I know that on Tegra we can do a
lot better by using syncpoints, but applications such as Weston (in
general applications that use the generic DRM API) rely on this to sync
rendering with VBLANK.

I don't think there's another way to achieve the same thing. And as you
already mentioned, this is only enabled when an application actively
uses it, in which case the device won't sleep anyway.

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

[Bug 58667] Random crashes on CAYMAN

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

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

--- Comment #44 from Thomas Rohloff  ---
And it crashed again, too. :(

-- 
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/20130130/2afca0da/attachment.html>

[Bug 58667] Random crashes on CAYMAN

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

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

--- Comment #43 from Thomas Rohloff  ---
And again I was to fast with this. I started another game and the dmesg spam
was there again.

-- 
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/20130130/ac5e1c67/attachment.html>

[Bug 58667] Random crashes on CAYMAN

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

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

--- Comment #42 from Thomas Rohloff  ---
I updated m kernel to 3.8-rc5 and mesa to
http://cgit.freedesktop.org/mesa/mesa/commit/?id=952e6e9f3b0eb179f67345f00e5a7f1dbaa7bdd5
(can't go higher cause of https://bugs.freedesktop.org/show_bug.cgi?id=60038 )
+ disabled huge pages in the kernel and now things are different. First of the
message spam seems to be gone completely and second the GPU doesn't crash
anymore. At one time the image froze but switching to console and back solved
this.

I'll look if it continues like that and later on re-enable huge pages to see
what happens then.

-- 
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/20130130/ea577b9a/attachment.html>

[PATCH 2/7] mutex: add support for reservation style locks

[Rob Clark]

On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter  wrote:
> On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark  wrote:
>> ==
>> Basic problem statement:
>> - --- -
>> GPU's do operations that commonly involve many buffers.  Those buffers
>> can be shared across contexts/processes, exist in different memory
>> domains (for example VRAM vs system memory), and so on.  And with
>> PRIME / dmabuf, they can even be shared across devices.  So there are
>> a handful of situations where the driver needs to wait for buffers to
>> become ready.  If you think about this in terms of waiting on a buffer
>> mutex for it to become available, this presents a problem because
>> there is no way to guarantee that buffers appear in a execbuf/batch in
>> the same order in all contexts.  That is directly under control of
>> userspace, and a result of the sequence of GL calls that an
>> application makes.  Which results in the potential for deadlock.  The
>> problem gets more complex when you consider that the kernel may need
>> to migrate the buffer(s) into VRAM before the GPU operates on the
>> buffer(s), which main in turn require evicting some other buffers (and
>> you don't want to evict other buffers which are already queued up to
>> the GPU), but for a simplified understanding of the problem you can
>> ignore this.
>>
>> The algorithm that TTM came up with for dealing with this problem is
>> quite simple.  For each group of buffers (execbuf) that need to be
>> locked, the caller would be assigned a unique reservation_id, from a
>> global counter.  In case of deadlock in the process of locking all the
>> buffers associated with a execbuf, the one with the lowest
>> reservation_id wins, and the one with the higher reservation_id
>> unlocks all of the buffers that it has already locked, and then tries
>> again.
>>
>> Originally TTM implemented this algorithm on top of an event-queue and
>> atomic-ops, but Maarten Lankhorst realized that by merging this with
>> the mutex code we could take advantage of the existing mutex fast-path
>> code and result in a simpler solution, and so ticket_mutex was born.
>> (Well, there where also some additional complexities with the original
>> implementation when you start adding in cross-device buffer sharing
>> for PRIME.. Maarten could probably better explain.)
>
> I think the motivational writeup above is really nice, but the example
> code below is a bit wrong
>
>> How it is used:
>> --- -- -- -
>>
>> A very simplified version:
>>
>>   int submit_execbuf(execbuf)
>>   {
>>   /* acquiring locks, before queuing up to GPU: */
>>   seqno = assign_global_seqno();
>>   retry:
>>   for (buf in execbuf->buffers) {
>>   ret = mutex_reserve_lock(>lock, seqno);
>>   switch (ret) {
>>   case 0:
>>   /* we got the lock */
>>   break;
>>   case -EAGAIN:
>>   /* someone with a lower seqno, so unreserve and try again: */
>>   for (buf2 in reverse order starting before buf in
>> execbuf->buffers)
>>   mutex_unreserve_unlock(>lock);
>>   goto retry;
>>   default:
>>   goto err;
>>   }
>>   }
>>
>>   /* now everything is good to go, submit job to GPU: */
>>   ...
>>   }
>>
>>   int finish_execbuf(execbuf)
>>   {
>>   /* when GPU is finished: */
>>   for (buf in execbuf->buffers)
>>   mutex_unreserve_unlock(>lock);
>>   }
>> ==
>
> Since gpu command submission is all asnyc (hopefully at least) we
> don't unlock once it completes, but right away after the commands are
> submitted. Otherwise you wouldn't be able to submit new execbufs using
> the same buffer objects (and besides, holding locks while going back
> out to userspace is evil).

right.. but I was trying to simplify the explanation for non-gpu
folk.. maybe that was an over-simplification ;-)

BR,
-R

> The trick is to add a fence object for async operation (essentially a
> waitqueue on steriods to support gpu->gpu direct signalling). And
> updating fences for a given execbuf needs to happen atomically for all
> buffers, for otherwise userspace could trick the kernel into creating
> a circular fence chain. This wouldn't deadlock the kernel, since
> everything is async, but it'll nicely deadlock the gpus involved.
> Hence why we need ticketing locks to get dma_buf fences off the
> ground.
>
> Maybe wait for Maarten's feedback, then update your motivational blurb a bit?
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

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

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


D. Hugh Redelmeier  changed:

   What|Removed |Added

 CC||hugh at mimosa.com




--- Comment #5 from D. Hugh Redelmeier   2013-01-30 
03:15:26 ---
For what it is worth (probably not much), I'm getting this message on Fedora 17
x86-64 with all updates.  Fedora kernel 3.7.3-101.fc17.x86_64.  Standard Gnome
desktop.  The video card is an ATI Radeon HD 3600 XT

Symptoms:

- with a lot of windows on desktop, sometimes creating a new window yields an
illegible window with horizontal striations.  It doesn't exactly stay within
boundaries but doesn't take over whole screen.

- When I look at the dock (if that's what it is called in Gnome 3, the image of
the application has striations too

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

- /var/log/Xorg.0.log shows a bunch of messages like these:
[ 97766.969] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x6e5f750]
[ 97767.076] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x6e5f750] width 2560 pitch 10240 (/4 2560)
[ 97773.012] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x97ce6d0]
[ 97773.112] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x97ce6d0] width 2560 pitch 10240 (/4 2560)
[ 97773.117] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0xb91b610]
[ 97773.213] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0xb91b610] width 2560 pitch 10240 (/4 2560)
[ 97773.217] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x6a33d50]
[ 97773.313] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x6a33d50] width 2560 pitch 10240 (/4 2560)
[ 97773.319] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0xb91b610]
[ 97773.414] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0xb91b610] width 2560 pitch 10240 (/4 2560)
[ 97773.420] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x97ce5b0]
[ 97773.514] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x97ce5b0] width 2560 pitch 10240 (/4 2560)
[ 9.063] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x928f370]
[ 9.142] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x928f370] width 2560 pitch 10240 (/4 2560)
[ 9.925] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x8be3b80]
[ 9.945] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x8be3b80] width 2560 pitch 10240 (/4 2560)
[ 97778.781] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x97d9520]
[ 97778.798] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x97d9520] width 2560 pitch 10240 (/4 2560)
[ 97780.516] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x8bf1aa0]
[ 97780.520] (II) RADEON(0): radeon_dri2_flip_event_handler:1069
fevent[0x8bf1aa0] width 2560 pitch 10240 (/4 2560)

- I can close the window and get back to using the desktop.  But once this has
happened, it will happen again quite a lot.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

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

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





--- Comment #20 from Fernando Chaves   2013-01-30 
02:08:38 ---
Well...

Same thing with EFI boot. Video still slow.

I think I should use a VGA card for a while (or forever).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

from LCA request, intel, radeon and exynos fixes, nothing too major or 
wierd, one dmar fix and a radeon cursor corruption, along with misc exynos 
fixes.

Dave.

The following changes since commit 014b34409fb2015f63663b6cafdf557fdf289628:

  ttm: on move memory failure don't leave a node dangling (2013-01-21 13:45:23 
+1000)

are available in the git repository at:

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

for you to fetch changes up to 483674325f64a37c7696edb12ce6ad3e535421bc:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel (2013-01-26 18:17:39 +1000)



Arnd Bergmann (2):
  drm/exynos: don't include plat/gpio-cfg.h
  drm/exynos: fimd and ipp are broken on multiplatform

Chris Wilson (2):
  drm/i915: Disable AsyncFlip performance optimisations
  drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline 
waits

Daniel Vetter (2):
  iommu/intel: disable DMAR for g4x integrated gfx
  drm/i915: dump UTS_RELEASE into the error_state

Dave Airlie (3):
  Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux 
into drm-next
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-next
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel

Ilija Hadzic (1):
  drm/radeon: fix a rare case of double kfree

Inki Dae (2):
  drm/exynos: free sg object if dma_map_sg is failed
  drm/exynos: consider DMA_NONE flag to dmabuf import

Jerome Glisse (1):
  drm/radeon: fix cursor corruption on DCE6 and newer

Michel D?nzer (1):
  drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.

Rahul Sharma (1):
  drm/exynos: let drm handle edid allocations

Sachin Kamat (4):
  drm/exynos: Make g2d_userptr_get_dma_addr static
  drm/exynos: Make ipp_handle_cmd_work static
  drm/exynos: Add missing static specifiers in exynos_drm_rotator.c
  drm/exynos: Make 'drm_hdmi_get_edid' static

Sean Paul (2):
  drm/exynos: Replace mdelay with usleep_range
  drm/exynos: Remove "internal" interrupt handling

Seung-Woo Kim (1):
  drm/exynos: added validation of edid for vidi connection

Shirish S (1):
  drm/exynos: add check for the device power status

xueminsu (1):
  radeon_display: Use pointer return error codes

 drivers/gpu/drm/exynos/Kconfig|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |  33 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|  24 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   9 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  26 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 121 --
 drivers/gpu/drm/exynos/exynos_mixer.c |   9 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   2 +
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  24 +++--
 drivers/gpu/drm/radeon/ni.c   |   8 +-
 drivers/gpu/drm/radeon/r600.c |   8 +-
 drivers/gpu/drm/radeon/radeon_cs.c|   2 +
 drivers/gpu/drm/radeon/radeon_cursor.c|   3 +-
 drivers/gpu/drm/radeon/radeon_display.c   |   2 +-
 drivers/iommu/intel-iommu.c   |  21 +++--
 21 files changed, 155 insertions(+), 158 deletions(-)

[Bug 58667] Random crashes on CAYMAN

[bugzilla-daemon]

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

--- Comment #42 from Thomas Rohloff v10la...@myway.de ---
I updated m kernel to 3.8-rc5 and mesa to
http://cgit.freedesktop.org/mesa/mesa/commit/?id=952e6e9f3b0eb179f67345f00e5a7f1dbaa7bdd5
(can't go higher cause of https://bugs.freedesktop.org/show_bug.cgi?id=60038 )
+ disabled huge pages in the kernel and now things are different. First of the
message spam seems to be gone completely and second the GPU doesn't crash
anymore. At one time the image froze but switching to console and back solved
this.

I'll look if it continues like that and later on re-enable huge pages to see
what happens then.

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

Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D

[Inki Dae]

2013/1/25 Sachin Kamat sachin.ka...@linaro.org:
 From: Ajay Kumar ajaykumar...@samsung.com

 This patch adds device tree match table for Exynos G2D controller.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  drivers/gpu/drm/exynos/exynos_drm_g2d.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
 b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 index ddcfb5d..d24b170 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 @@ -19,6 +19,7 @@
  #include linux/workqueue.h
  #include linux/dma-mapping.h
  #include linux/dma-attrs.h
 +#include linux/of.h

  #include drm/drmP.h
  #include drm/exynos_drm.h
 @@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev)

  static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);

 +#ifdef CONFIG_OF
 +static const struct of_device_id exynos_g2d_match[] = {
 +   { .compatible = samsung,g2d-v41 },

not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d
driver shoud support for all Exynos SoCs. How about using
samsung,exynos5-g2d instead and adding a new property 'version' to
identify ip version more surely? With this, we could know which SoC
and its g2d ip version. The version property could have '0x14' or
others. And please add descriptions to dt document.

 +   {},
 +};
 +MODULE_DEVICE_TABLE(of, exynos_g2d_match);
 +#endif
 +
  struct platform_driver g2d_driver = {
 .probe  = g2d_probe,
 .remove = g2d_remove,
 @@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = {
 .name   = s5p-g2d,
 .owner  = THIS_MODULE,
 .pm = g2d_pm_ops,
 +   .of_match_table = of_match_ptr(exynos_g2d_match),
 },
  };
 --
 1.7.4.1

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

A patch referencing this bug report has been merged...

[Jani Nikula]

Hi Florian, all -

First, thanks for your work on adding the bugzilla comments when patches
referencing bugs get merged. I find it useful.

Recently however there was a comment about a commit referencing a commit
referencing the bug report. Turns out the comment was missing one level
of indirection, it was really about a commit referencing a commit
referencing a commit referencing the bug [1].

Do we really need go that far, or is that a bug in your scripts? I think
three levels of indirection is more noise than signal; two might be
still be okay. What do others think?

BR,
Jani.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58667] Random crashes on CAYMAN

[bugzilla-daemon]

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

--- Comment #43 from Thomas Rohloff v10la...@myway.de ---
And again I was to fast with this. I started another game and the dmesg spam
was there again.

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

Re: 3.8-rc2: lockdep warning in nouveau driver

[Peter Hurley]

On Wed, 2013-01-09 at 12:45 +0100, Arend van Spriel wrote:
 Maybe this one is already known, but I did not find a post about it. So
 here it is.
 
 Regards,
 Arend

[snip]

 [9.589986] =
 [9.595365] [ INFO: possible recursive locking detected ]
 [9.600745] 3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1 Not tainted
 [9.607248] -
 [9.612626] modprobe/163 is trying to acquire lock:
 [9.617486]  (subdev-mutex){+.+.+.}, at: [f8929c12]
 nv50_fb_vram_new+0x92/0x230 [nouveau]
 [9.626052]
 [9.626052] but task is already holding lock:
 [9.631865]  (subdev-mutex){+.+.+.}, at: [f8936505]
 nv50_disp_data_ctor+0x55/0xc0 [nouveau]
 [9.640593]
 [9.640593] other info that might help us debug this:
 [9.647096]  Possible unsafe locking scenario:
 [9.647096]
 [9.652995]CPU0
 [9.655430]
 [9.657867]   lock(subdev-mutex);
 [9.661365]   lock(subdev-mutex);
 [9.664863]
 [9.664863]  *** DEADLOCK ***
 [9.664863]
 [9.670762]  May be due to missing lock nesting notation

Same.

[5.995881] =
[5.995886] [ INFO: possible recursive locking detected ]
[5.995892] 3.8.0-next-20130125+ttypatch-xeon+lockdep #20130125+ttypatch Not 
tainted
[5.995898] -
[5.995904] modprobe/275 is trying to acquire lock:
[5.995909]  (subdev-mutex){+.+.+.}, at: [a00d10b8] 
nouveau_instobj_create_+0x48/0x90 [nouveau]
[5.995955] 
[5.995955] but task is already holding lock:
[5.995961]  (subdev-mutex){+.+.+.}, at: [a00da3b5] 
nv50_disp_data_ctor+0x65/0xd0 [nouveau]
[5.995989] 
[5.995989] other info that might help us debug this:
[5.995995]  Possible unsafe locking scenario:
[5.995995] 
[5.996001]CPU0
[5.996004]
[5.996005]   lock(subdev-mutex);
[5.996005]   lock(subdev-mutex);
[5.996005] 
[5.996005]  *** DEADLOCK ***

Regards,
Peter Hurley



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

Re: [PATCH] x86, efi: remove attribute check from setup_efi_pci

[Matt Fleming]

On Tue, 2013-01-29 at 17:52 +0100, Maarten Lankhorst wrote:
 It looks like the original commit that copied the rom contents from efi 
 always copied
 the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
 (x86, efi: correct precedence of operators in setup_efi_pci) broke that.
 
 This resulted in macbook pro's no longer finding the rom images, and thus not 
 being able to use the radeon card any more.
 
 The solution is to just remove the check for now, and always copy the rom if 
 available.
 
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

Applied, thanks!

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

radeon modeset crashes on A4-3400 HD6410D

[Mikko Tiihonen]

Hi,

I have a A4-3400 CPU that I bought half a year ago. I've tried once month,
but  Fedora has never succeeded in booting in graphical mode.

Some time ago a finally built some custom kernels to figure out why. I
created a bug to Fedora
bughttps://bugzilla.redhat.com/show_bug.cgi?id=892233,
but it has not progressed.

Analysis:
The radeon module startup fails with division by zero in
r6xx_remap_render_backend because the first RB is not enabled and the code
assuming that enabled RBs must be all the first ones of the valid range.


Longer version:

In r600.c:r6xx_remap_render_backend

The function contains only one divide:

u32 r6xx_remap_render_backend(struct radeon_device *rdev,
  u32 tiling_pipe_num,
  u32 max_rb_num,
  u32 total_max_rb_num,
  u32 disabled_rb_mask)
{
u32 rendering_pipe_num, rb_num_width, req_rb_num;
...
/* mask out the RBs that don't exist on that asic */
disabled_rb_mask |= (0xff  max_rb_num)  0xff;

rendering_pipe_num = 1  tiling_pipe_num;
req_rb_num = total_max_rb_num - r600_count_pipe_bits(disabled_rb_mask);
BUG_ON(rendering_pipe_num  req_rb_num);

pipe_rb_ratio = rendering_pipe_num / req_rb_num;

I added a printk to see what actual parameters are passed in:

tiling_pipe_num=2, max_rb_num=1, total_max_rb_num=8, disabled_rb_mask=253

Using those to calculate the divide by zero comes from:
disabled_rb_mask |= 254; - 255
req_rb_num = 8 - 8;


Quick fix for stable kernel series:

The attached fix activates only in the division by zero case and instead of
failing uses the given disabled_rb_mask. This is guaranteed to be
regression free and actually allows me to load the radeon driver
successfully. It does help with cards that currently work, but for which
some usable RBs are disabled due to the eager masking.


Proper fix would propably be to find out think why the disabled_rb_mask is
masked the way it is, were there bugs in other places for which it is a
workaround. I can see two possible modifictions:
1) only mask bits exceeding total_max_rb_num instead of the
max_rb_numsince the one enabled RB on A4-3400 can propably be any one
of the 8
possible values.
2) or activate the current code only if there are more than max_rb_num zero
bits in the given disabled_rb_mask


-Mikko


r600-division-by-zero.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos: Get HDMI version from device tree

[Sylwester Nawrocki]

Hi,

On 01/08/2013 11:56 PM, Stephen Warren wrote:

On 01/08/2013 01:16 PM, Sean Paul wrote:

Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.


I guess this seems OK to me if required, although I'd certainly like to
see someone familiar with the Exynos HW confirm whether this should be
driven purely by DT compatible value for the HDMI IP block instead though.


I think the supported HDMI standard is something that could well be derived
from the compatible property. The IP supporting v1.3 and v1.4 will be
significantly different, so this would anyway already need to be reflected
in the compatible property. The only issue I see here is that people tend
to make the compatible string overly generic, so it is hardly usable for
anything but matching an IP with its driver. For instance for exynos5 we
have now (Documentation/devicetree/bindings/drm/exynos/hdmi.txt):

compatible = samsung,exynos5-hdmi;

For Exynos4 series there were already some patches proposed [1], but I 
believe

this isn't a clean solution. Instead of things like:

compatible = samsung,exynos4-hdmi13;
compatible = samsung,exynos4-hdmi14;

I would much more like to see the SoC version embedded in the compatible
string, e.g.

compatible = samsung,exynos4210-hdmi; /* among others it carries an
  information this IP supports
  HDMI v1.3 */  

compatible = samsung,exynos4212-hdmi; /* HDMI v1.4, IIRC */

[1] http://www.spinics.net/lists/linux-samsung-soc/msg15289.html

--

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

[PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd

[Vikas Sajjan]

This patch adds display-timing node parsing to drm fimd, this depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

It also adds pinctrl support for drm fimd.

patch is based on branch exynos-drm-next at
http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Is tested on Exynos5250 and Exynos4412 by applying dependent patches available
at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

Vikas Sajjan (1):
  video: drm: exynos: Adds display-timing node parsing using video
helper function

 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

-- 
1.7.9.5

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

[PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function

[Vikas Sajjan]

This patch adds display-timing node parsing using video helper function

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..94729ed 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
 #include linux/clk.h
 #include linux/of_device.h
 #include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
 
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
@@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+   struct fb_videomode *fbmode;
+   struct device *disp_dev = pdev-dev;
+   struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
-   pdata = pdev-dev.platform_data;
-   if (!pdata) {
-   dev_err(dev, no platform data specified\n);
+   if (pdev-dev.of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   DRM_ERROR(memory allocation for pdata failed\n);
+   return -ENOMEM;
+   }
+
+   fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+   if (!fbmode) {
+   DRM_ERROR(memory allocation for fbmode failed\n);
+   return -ENOMEM;
+   }
+
+   ret = of_get_fb_videomode(disp_dev-of_node, fbmode, -1);
+   if (ret) {
+   DRM_ERROR(failed to get fb_videomode\n);
+   return -EINVAL;
+   }
+   pdata-panel.timing = (struct fb_videomode) *fbmode;
+
+   } else {
+   pdata = pdev-dev.platform_data;
+   if (!pdata) {
+   DRM_ERROR(no platform data specified\n);
+   return -EINVAL;
+   }
+   }
+
+   pctrl = devm_pinctrl_get_select_default(dev);
+   if (IS_ERR(pctrl)) {
+   DRM_ERROR(no pinctrl data provided.\n);
return -EINVAL;
}
 
-- 
1.7.9.5

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

Re: [PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd

[Sachin Kamat]

Hi Vikas,

Changelog mentioning differences between v1 and v2 is generally
preferred as it will help the reviewers.

On 30 January 2013 12:00, Vikas Sajjan vikas.saj...@linaro.org wrote:
 This patch adds display-timing node parsing to drm fimd, this depends on
 the display helper patchset at
 http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

 It also adds pinctrl support for drm fimd.

 patch is based on branch exynos-drm-next at
 http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

 Is tested on Exynos5250 and Exynos4412 by applying dependent patches available
 at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html

 Vikas Sajjan (1):
   video: drm: exynos: Adds display-timing node parsing using video
 helper function

  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 
 +++---
  1 file changed, 35 insertions(+), 3 deletions(-)

 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58667] Random crashes on CAYMAN

[bugzilla-daemon]

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

--- Comment #44 from Thomas Rohloff v10la...@myway.de ---
And it crashed again, too. :(

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

Re: [PATCH 5/5] drm/tegra: Implement page-flipping support

[Thierry Reding]

On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
 On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
 thierry.red...@avionic-design.de wrote:
  drm_events_release() should be enough to clean up the events, but I
  suspect the reason why Laurent put that code in was that the drm_crtc
  private data still has a reference to the event and needs to clear it.
  Otherwise the next page flip won't be scheduled because .page_flip()
  would return -EBUSY.
 
 Hm, indeed we seem to have a nice bug in most drivers there :(

I think I may just recently have run into this bug on Intel hardware.
Although perhaps I just used this wrongly.

Just for the fun of it I wanted to implement Conway's Game of Life on
top of DRM/KMS. So I use two dumb buffer objects to alternately render
to. Then I wanted to use page-flipping to synchronize with VBLANK.

So the sequence is basically:

while (!done) {
grid_tick(grid);
grid_draw(grid, screen);
screen_flip(screen);
grid_swap(grid);
}

Where screen_flip() chooses the framebuffer and passes it to
drmModePageFlip() like so:

int fb = screen-fb[screen-current];

drmModePageFlip(screen-fd, screen-crtc, fb,
DRM_MODE_PAGE_FLIP_EVENT, screen);

This runs for about 3 seconds and then hangs, so the display is no
longer updated. I've also verified that the same happens on Radeon.
But maybe I am mistaken and this isn't the proper programming sequence?

Thierry


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

Re: [PATCH 5/5] drm/tegra: Implement page-flipping support

[Ville Syrjälä]

On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote:
 On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
  On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
  thierry.red...@avionic-design.de wrote:
   drm_events_release() should be enough to clean up the events, but I
   suspect the reason why Laurent put that code in was that the drm_crtc
   private data still has a reference to the event and needs to clear it.
   Otherwise the next page flip won't be scheduled because .page_flip()
   would return -EBUSY.
  
  Hm, indeed we seem to have a nice bug in most drivers there :(
 
 I think I may just recently have run into this bug on Intel hardware.
 Although perhaps I just used this wrongly.
 
 Just for the fun of it I wanted to implement Conway's Game of Life on
 top of DRM/KMS. So I use two dumb buffer objects to alternately render
 to. Then I wanted to use page-flipping to synchronize with VBLANK.
 
 So the sequence is basically:
 
   while (!done) {
   grid_tick(grid);
   grid_draw(grid, screen);
   screen_flip(screen);
   grid_swap(grid);
   }
 
 Where screen_flip() chooses the framebuffer and passes it to
 drmModePageFlip() like so:
 
   int fb = screen-fb[screen-current];
 
   drmModePageFlip(screen-fd, screen-crtc, fb,
   DRM_MODE_PAGE_FLIP_EVENT, screen);
 
 This runs for about 3 seconds and then hangs, so the display is no
 longer updated. I've also verified that the same happens on Radeon.
 But maybe I am mistaken and this isn't the proper programming sequence?

You asked for page flip events. Do you actually handle them in your code?

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

Re: [PATCH 2/7] mutex: add support for reservation style locks

[Daniel Vetter]

On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark robdcl...@gmail.com wrote:
 ==
 Basic problem statement:
 - --- -
 GPU's do operations that commonly involve many buffers.  Those buffers
 can be shared across contexts/processes, exist in different memory
 domains (for example VRAM vs system memory), and so on.  And with
 PRIME / dmabuf, they can even be shared across devices.  So there are
 a handful of situations where the driver needs to wait for buffers to
 become ready.  If you think about this in terms of waiting on a buffer
 mutex for it to become available, this presents a problem because
 there is no way to guarantee that buffers appear in a execbuf/batch in
 the same order in all contexts.  That is directly under control of
 userspace, and a result of the sequence of GL calls that an
 application makes.  Which results in the potential for deadlock.  The
 problem gets more complex when you consider that the kernel may need
 to migrate the buffer(s) into VRAM before the GPU operates on the
 buffer(s), which main in turn require evicting some other buffers (and
 you don't want to evict other buffers which are already queued up to
 the GPU), but for a simplified understanding of the problem you can
 ignore this.

 The algorithm that TTM came up with for dealing with this problem is
 quite simple.  For each group of buffers (execbuf) that need to be
 locked, the caller would be assigned a unique reservation_id, from a
 global counter.  In case of deadlock in the process of locking all the
 buffers associated with a execbuf, the one with the lowest
 reservation_id wins, and the one with the higher reservation_id
 unlocks all of the buffers that it has already locked, and then tries
 again.

 Originally TTM implemented this algorithm on top of an event-queue and
 atomic-ops, but Maarten Lankhorst realized that by merging this with
 the mutex code we could take advantage of the existing mutex fast-path
 code and result in a simpler solution, and so ticket_mutex was born.
 (Well, there where also some additional complexities with the original
 implementation when you start adding in cross-device buffer sharing
 for PRIME.. Maarten could probably better explain.)

I think the motivational writeup above is really nice, but the example
code below is a bit wrong

 How it is used:
 --- -- -- -

 A very simplified version:

   int submit_execbuf(execbuf)
   {
   /* acquiring locks, before queuing up to GPU: */
   seqno = assign_global_seqno();
   retry:
   for (buf in execbuf-buffers) {
   ret = mutex_reserve_lock(buf-lock, seqno);
   switch (ret) {
   case 0:
   /* we got the lock */
   break;
   case -EAGAIN:
   /* someone with a lower seqno, so unreserve and try again: */
   for (buf2 in reverse order starting before buf in
 execbuf-buffers)
   mutex_unreserve_unlock(buf2-lock);
   goto retry;
   default:
   goto err;
   }
   }

   /* now everything is good to go, submit job to GPU: */
   ...
   }

   int finish_execbuf(execbuf)
   {
   /* when GPU is finished: */
   for (buf in execbuf-buffers)
   mutex_unreserve_unlock(buf-lock);
   }
 ==

Since gpu command submission is all asnyc (hopefully at least) we
don't unlock once it completes, but right away after the commands are
submitted. Otherwise you wouldn't be able to submit new execbufs using
the same buffer objects (and besides, holding locks while going back
out to userspace is evil).

The trick is to add a fence object for async operation (essentially a
waitqueue on steriods to support gpu-gpu direct signalling). And
updating fences for a given execbuf needs to happen atomically for all
buffers, for otherwise userspace could trick the kernel into creating
a circular fence chain. This wouldn't deadlock the kernel, since
everything is async, but it'll nicely deadlock the gpus involved.
Hence why we need ticketing locks to get dma_buf fences off the
ground.

Maybe wait for Maarten's feedback, then update your motivational blurb a bit?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/tegra: Implement page-flipping support

[Thierry Reding]

On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrjälä wrote:
 On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote:
  On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
   On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
   thierry.red...@avionic-design.de wrote:
drm_events_release() should be enough to clean up the events, but I
suspect the reason why Laurent put that code in was that the drm_crtc
private data still has a reference to the event and needs to clear it.
Otherwise the next page flip won't be scheduled because .page_flip()
would return -EBUSY.
   
   Hm, indeed we seem to have a nice bug in most drivers there :(
  
  I think I may just recently have run into this bug on Intel hardware.
  Although perhaps I just used this wrongly.
  
  Just for the fun of it I wanted to implement Conway's Game of Life on
  top of DRM/KMS. So I use two dumb buffer objects to alternately render
  to. Then I wanted to use page-flipping to synchronize with VBLANK.
  
  So the sequence is basically:
  
  while (!done) {
  grid_tick(grid);
  grid_draw(grid, screen);
  screen_flip(screen);
  grid_swap(grid);
  }
  
  Where screen_flip() chooses the framebuffer and passes it to
  drmModePageFlip() like so:
  
  int fb = screen-fb[screen-current];
  
  drmModePageFlip(screen-fd, screen-crtc, fb,
  DRM_MODE_PAGE_FLIP_EVENT, screen);
  
  This runs for about 3 seconds and then hangs, so the display is no
  longer updated. I've also verified that the same happens on Radeon.
  But maybe I am mistaken and this isn't the proper programming sequence?
 
 You asked for page flip events. Do you actually handle them in your code?

Duh. No I wasn't =) I suppose some queue must be running full if the
event isn't handled by calling drmHandleEvent(). Okay, this now works
properly with page-flipping.

Thanks.
Thierry


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

Re: [PATCH 2/7] mutex: add support for reservation style locks

[Maarten Lankhorst]

Op 30-01-13 02:07, Rob Clark schreef:
 On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
 m.b.lankho...@gmail.com wrote:
 Hi Maarten,

 This is a nice looking extension to avoid re-implementing a mutex in
 TTM/reservation code..  ofc, probably someone more familiar with mutex
 code should probably review, but probably a bit of explanation about
 what and why would be helpful.

 mutex_reserve_lock, and mutex_reserve_lock_interruptible:
   Lock a buffer with a reservation_id set. reservation_id must not be set to 
 0,
   since this is a special value that means no reservation_id.

   Normally if reservation_id is not set, or is older than the reservation_id 
 that's
   currently set on the mutex, the behavior will be to wait normally.

   However, if  the reservation_id is newer than the current reservation_id, 
 -EAGAIN
   will be returned, and this function must unreserve all other mutexes and 
 then redo
   a blocking lock with normal mutex calls to prevent a deadlock, then call
   mutex_locked_set_reservation on successful locking to set the 
 reservation_id inside
   the lock.
 It might be a bit more clear to write up how this works from the
 perspective of the user of ticket_mutex, separately from the internal
 implementation first, and then how it works internally?  Ie, the
 mutex_set_reservation_fastpath() call is internal to the
 implementation of ticket_mutex, but -EAGAIN is something the caller of
 ticket_mutex shall deal with.  This might give a clearer picture of
 how TTM / reservation uses this to prevent deadlock, so those less
 familiar with TTM could better understand.

 Well, here is an attempt to start a write-up, which should perhaps
 eventually be folded into Documentation/ticket-mutex-design.txt.  But
 hopefully a better explanation of the problem and the solution will
 encourage some review of the ticket_mutex changes.

 ==
 Basic problem statement:
 - --- -
 GPU's do operations that commonly involve many buffers.  Those buffers
 can be shared across contexts/processes, exist in different memory
 domains (for example VRAM vs system memory), and so on.  And with
 PRIME / dmabuf, they can even be shared across devices.  So there are
 a handful of situations where the driver needs to wait for buffers to
 become ready.  If you think about this in terms of waiting on a buffer
 mutex for it to become available, this presents a problem because
 there is no way to guarantee that buffers appear in a execbuf/batch in
 the same order in all contexts.  That is directly under control of
 userspace, and a result of the sequence of GL calls that an
 application makes.  Which results in the potential for deadlock.  The
 problem gets more complex when you consider that the kernel may need
 to migrate the buffer(s) into VRAM before the GPU operates on the
 buffer(s), which main in turn require evicting some other buffers (and
 you don't want to evict other buffers which are already queued up to
 the GPU), but for a simplified understanding of the problem you can
 ignore this.

 The algorithm that TTM came up with for dealing with this problem is
 quite simple.  For each group of buffers (execbuf) that need to be
 locked, the caller would be assigned a unique reservation_id, from a
 global counter.  In case of deadlock in the process of locking all the
 buffers associated with a execbuf, the one with the lowest
 reservation_id wins, and the one with the higher reservation_id
 unlocks all of the buffers that it has already locked, and then tries
 again.

 Originally TTM implemented this algorithm on top of an event-queue and
 atomic-ops, but Maarten Lankhorst realized that by merging this with
 the mutex code we could take advantage of the existing mutex fast-path
 code and result in a simpler solution, and so ticket_mutex was born.
 (Well, there where also some additional complexities with the original
 implementation when you start adding in cross-device buffer sharing
 for PRIME.. Maarten could probably better explain.)

 How it is used:
 --- -- -- -

 A very simplified version:

   int submit_execbuf(execbuf)
   {
   /* acquiring locks, before queuing up to GPU: */
   seqno = assign_global_seqno();
You also need to make a 'lock' type for seqno, and lock it for lockdep purposes.
This will be a virtual lock that will only exist in lockdep, but it's needed 
for proper lockdep annotation.

See reservation_ticket_init/fini. It's also important that seqno must not be 0, 
ever.


   retry:
   for (buf in execbuf-buffers) {
   ret = mutex_reserve_lock(buf-lock, seqno);
The lockdep class for this lock must be the same for all reservations, and for 
maximum lockdep usability
you want all the buf-lock lockdep class for all objects across all devices to 
be the same too.

The __ticket_mutex_init in reservation_object_init does just that for you. :-)

   switch (ret) {
   case 0:
   /* we got the lock */
   

Re: [PATCH 5/5] drm/tegra: Implement page-flipping support

[Thierry Reding]

On Wed, Jan 30, 2013 at 12:14:36PM +0100, Thierry Reding wrote:
 On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrjälä wrote:
  On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote:
   On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote:
On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 drm_events_release() should be enough to clean up the events, but I
 suspect the reason why Laurent put that code in was that the drm_crtc
 private data still has a reference to the event and needs to clear it.
 Otherwise the next page flip won't be scheduled because .page_flip()
 would return -EBUSY.

Hm, indeed we seem to have a nice bug in most drivers there :(
   
   I think I may just recently have run into this bug on Intel hardware.
   Although perhaps I just used this wrongly.
   
   Just for the fun of it I wanted to implement Conway's Game of Life on
   top of DRM/KMS. So I use two dumb buffer objects to alternately render
   to. Then I wanted to use page-flipping to synchronize with VBLANK.
   
   So the sequence is basically:
   
 while (!done) {
 grid_tick(grid);
 grid_draw(grid, screen);
 screen_flip(screen);
 grid_swap(grid);
 }
   
   Where screen_flip() chooses the framebuffer and passes it to
   drmModePageFlip() like so:
   
 int fb = screen-fb[screen-current];
   
 drmModePageFlip(screen-fd, screen-crtc, fb,
 DRM_MODE_PAGE_FLIP_EVENT, screen);
   
   This runs for about 3 seconds and then hangs, so the display is no
   longer updated. I've also verified that the same happens on Radeon.
   But maybe I am mistaken and this isn't the proper programming sequence?
  
  You asked for page flip events. Do you actually handle them in your code?
 
 Duh. No I wasn't =) I suppose some queue must be running full if the
 event isn't handled by calling drmHandleEvent(). Okay, this now works
 properly with page-flipping.

Just in case anybody's interested, the code is here:

https://gitorious.org/thierryreding/kmslife

Thierry


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

Re: [PATCH 2/7] mutex: add support for reservation style locks

[Rob Clark]

On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark robdcl...@gmail.com wrote:
 ==
 Basic problem statement:
 - --- -
 GPU's do operations that commonly involve many buffers.  Those buffers
 can be shared across contexts/processes, exist in different memory
 domains (for example VRAM vs system memory), and so on.  And with
 PRIME / dmabuf, they can even be shared across devices.  So there are
 a handful of situations where the driver needs to wait for buffers to
 become ready.  If you think about this in terms of waiting on a buffer
 mutex for it to become available, this presents a problem because
 there is no way to guarantee that buffers appear in a execbuf/batch in
 the same order in all contexts.  That is directly under control of
 userspace, and a result of the sequence of GL calls that an
 application makes.  Which results in the potential for deadlock.  The
 problem gets more complex when you consider that the kernel may need
 to migrate the buffer(s) into VRAM before the GPU operates on the
 buffer(s), which main in turn require evicting some other buffers (and
 you don't want to evict other buffers which are already queued up to
 the GPU), but for a simplified understanding of the problem you can
 ignore this.

 The algorithm that TTM came up with for dealing with this problem is
 quite simple.  For each group of buffers (execbuf) that need to be
 locked, the caller would be assigned a unique reservation_id, from a
 global counter.  In case of deadlock in the process of locking all the
 buffers associated with a execbuf, the one with the lowest
 reservation_id wins, and the one with the higher reservation_id
 unlocks all of the buffers that it has already locked, and then tries
 again.

 Originally TTM implemented this algorithm on top of an event-queue and
 atomic-ops, but Maarten Lankhorst realized that by merging this with
 the mutex code we could take advantage of the existing mutex fast-path
 code and result in a simpler solution, and so ticket_mutex was born.
 (Well, there where also some additional complexities with the original
 implementation when you start adding in cross-device buffer sharing
 for PRIME.. Maarten could probably better explain.)

 I think the motivational writeup above is really nice, but the example
 code below is a bit wrong

 How it is used:
 --- -- -- -

 A very simplified version:

   int submit_execbuf(execbuf)
   {
   /* acquiring locks, before queuing up to GPU: */
   seqno = assign_global_seqno();
   retry:
   for (buf in execbuf-buffers) {
   ret = mutex_reserve_lock(buf-lock, seqno);
   switch (ret) {
   case 0:
   /* we got the lock */
   break;
   case -EAGAIN:
   /* someone with a lower seqno, so unreserve and try again: */
   for (buf2 in reverse order starting before buf in
 execbuf-buffers)
   mutex_unreserve_unlock(buf2-lock);
   goto retry;
   default:
   goto err;
   }
   }

   /* now everything is good to go, submit job to GPU: */
   ...
   }

   int finish_execbuf(execbuf)
   {
   /* when GPU is finished: */
   for (buf in execbuf-buffers)
   mutex_unreserve_unlock(buf-lock);
   }
 ==

 Since gpu command submission is all asnyc (hopefully at least) we
 don't unlock once it completes, but right away after the commands are
 submitted. Otherwise you wouldn't be able to submit new execbufs using
 the same buffer objects (and besides, holding locks while going back
 out to userspace is evil).

right.. but I was trying to simplify the explanation for non-gpu
folk.. maybe that was an over-simplification ;-)

BR,
-R

 The trick is to add a fence object for async operation (essentially a
 waitqueue on steriods to support gpu-gpu direct signalling). And
 updating fences for a given execbuf needs to happen atomically for all
 buffers, for otherwise userspace could trick the kernel into creating
 a circular fence chain. This wouldn't deadlock the kernel, since
 everything is async, but it'll nicely deadlock the gpus involved.
 Hence why we need ticketing locks to get dma_buf fences off the
 ground.

 Maybe wait for Maarten's feedback, then update your motivational blurb a bit?

 Cheers, Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] fbcon locking fixes.

[Daniel Vetter]

On Mon, Jan 28, 2013 at 1:45 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 There was a path going into set_con2fb_path if an fb driver was
 already registered, I just pushed the locking out further on anyone
 going in there.

 it boots on my EFI macbook here.

 I cherry picked those patches to my tree, and the full series no longer 
 triggers a lockdep warning.
 It also no longer locks up during modprobing or vga-switcheroo either.

 Tested-by: Maarten Lankhorst maarten.lankho...@canonical.com

QA reported spurious failures in some kms_flip tests and lockdep
splats, somehow both are fixed with the locking. I'm a bit confused
how these issues could cause failures in the flip tests, but alas:

Tested-by: Lu Hua huax...@intel.com (for all three patches).
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/tegra: Implement VBLANK support

[Daniel Vetter]

On Wed, Jan 30, 2013 at 9:34 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote:
 On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding
 thierry.red...@avionic-design.de wrote:
  Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
  special in this case because it doesn't use the generic IRQ support
  provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one
  interrupt handler for each display controller.
 
  While at it, clean up the way that interrupts are enabled to ensure
  that the VBLANK interrupt only gets enabled when required.
 
  Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
  ---

 Sorry Thierry, but is this a useful feature? Are applications really
 making use of it? Because it means that that an IRQ will have to
 trigger every 16.67ms when it is taken, which means the device can't
 sleep. (probably OK because it should go back to idle when the app
 lets go of the vblank). But worse, for one-shot panels there is no
 continuous vblank. I've been doing weird hacks to run a timer when the
 smart panel is idle to trick applications into thinking they have a
 vblank pulse. But really I think the whole feature of a vblank pulse
 is pretty lame and I wish it would die. Were you going to use it for
 something specific, or just adding it for completeness?

 This is mainly added for completeness. I know that on Tegra we can do a
 lot better by using syncpoints, but applications such as Weston (in
 general applications that use the generic DRM API) rely on this to sync
 rendering with VBLANK.

 I don't think there's another way to achieve the same thing. And as you
 already mentioned, this is only enabled when an application actively
 uses it, in which case the device won't sleep anyway.

I think driving animations with the vblank signal is nice, but we
kinda only need that with the pageflip support. Unfortunately the
current drm code is a bit a mess in that area, so pageflips force you
to enable the vblank interrupt for otherwise the timestamp'ed pageflip
completion events won't work.

Recent intel hw has pageflip timestamp registers, so we don't really
need that. And I guess other hw is similar. So we probably should
clean up and untangle the infrastructure a bit around the drm vblank
support code.

Another issue is that the vblank ioctl itself doesn't deal with
modeset crtc ids, so adding a new interface for that would be good.
Otoh most kms clients don't really use it, but only care about
pageflips.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #8 from Dave Witbrodt dawit...@sbcglobal.net ---
(In reply to comment #7)
 This is indeed more likely an issue in Mesa than in the kernel. The commit
 you bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause
 the Mesa code to use different code paths.

In my two attempted manual reverts, I didn't know what effect the code in
radeon_drv.c actually had.  When looking at later DRM changes (after the one
identified by the bisection) I saw that the value of KMS_DRIVER_MINOR was
incremented further, so I thought I should leave the value unchanged.


 Does current Mesa Git still leak?

After updating/merging to the current HEAD (commit 02b6da1e of Jan. 29), I
built new Mesa packages and installed them.

I am currently relying the last kernel from my local tree which does not leak,
so I rebooted to the kernel I had built that is most current with the upstream
DRM changes:  stable 3.7.4 + many commits from drm-next/drm-fixes up to commit
014b3440 of Jan. 21 in drm-fixes.

Yes, it still leaks.


Would it be good for me to bisect Mesa?  I would use my most up-to-date kernel,
try to find an older version of Mesa which does not leak, and then identify the
first patch to Mesa which causes the leaking.

The testing I have done so far was assuming the problem was in the kernel, but
I was planning to look at Mesa as well.  I decided to report the bug before
continuing, hoping for some guidance from the experts.  If there really is a
memory leak caused by the kernel DRI, then I would like to help get it fixed
before 3.8 is released; or, if there is a problem in Mesa I would like to help
get it fixed for 9.1.

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

[Bug 60073] New: [bisected] Bad rendering in Path of Exile

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 60073
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [bisected] Bad rendering in Path of Exile
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: nissa...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Hardware: Radeon 6850

Software: 64bit Gentoo, game running via Wine (32bit), git versions of libdrm,
xf86-video-ati, kernel version 3.7(ish) and latest 3.8 rc + drm-next branch

The issue is affecting light effects, spell effects, etc. (see screenshots).

Bisecting leads to this commit:
commit 3b51d71c8544ee198008bbf3545bf3def6e9e77f
Author: Jordan Justen jordan.l.jus...@intel.com
Date:   Fri Dec 28 11:00:50 2012 -0800

copyteximage: check that sRGB usage is valid for GLES3 / GL

Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com


There is already one bug report mentioning this commit [1], not sure if it's
the same issue.

Besides PoE, I also encontered similar problem in StarCraft2, I didn't checked
if it's the same problem, text/fonts on the loading screen shows the same
corruption, however the game also hangs the GPU, so bisecting it might be a
bit problematic.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=59690

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

[Bug 60073] [bisected] Bad rendering in Path of Exile

[bugzilla-daemon]

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

--- Comment #1 from Wojciech Pyczak nissa...@gmail.com ---
Created attachment 73926
  -- https://bugs.freedesktop.org/attachment.cgi?id=73926action=edit
Login screen

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

[Bug 60073] [bisected] Bad rendering in Path of Exile

[bugzilla-daemon]

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

--- Comment #2 from Wojciech Pyczak nissa...@gmail.com ---
Created attachment 73927
  -- https://bugs.freedesktop.org/attachment.cgi?id=73927action=edit
Login screen (bad rendering)

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

[Bug 60073] [bisected] Bad rendering in Path of Exile

[bugzilla-daemon]

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

--- Comment #3 from Wojciech Pyczak nissa...@gmail.com ---
Created attachment 73928
  -- https://bugs.freedesktop.org/attachment.cgi?id=73928action=edit
In-game screenshot

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

[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon]

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

--- Comment #9 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #8)
 Would it be good for me to bisect Mesa?

If Mesa commit 6532eb17baff6e61b427f29e076883f8941ae664 (where code depending
on DRM minor 26 was first introduced) doesn't leak, yes please.

BTW, does setting the environment variable R600_HYPERZ=0 for the leaking
process(es) work around the problem?


 The testing I have done so far was assuming the problem was in the kernel,
 [...]

The fact that the memory is reclaimed on process exit makes that unlikely.

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

[RFC PATCH 0/4] Common Display Framework-TF

[Tomasz Figa]

Hi,

After pretty long time of trying to adapt Exynos-specific DSI display support
to Common Display Framework I'm ready to show some preliminary RFC patches.
This series shows some ideas for CDF that came to my mind during my work,
some changes based on comments received by Tomi's edition of CDF and also
preliminarys version of Exynos DSI (video source part only, still with some
FIXMEs) and Samsung S6E8AX0 DSI panel drivers.

It is heavily based on Tomi's work which can be found here:
http://thread.gmane.org/gmane.comp.video.dri.devel/78227

The code might be a bit hacky in places, as I wanted to get it to a kind
of complete and working state first. However I hope that some of the ideas
might useful for further works.

So, here comes the TF edition of Common Clock Framework.


Changes done to Tomi's edition of CDF:

 - Replaced set_operation_mode, set_pixel_format and set_size video source
   operations with get_params display entity operation, as it was originally
   in Laurent's version.

   We have discussed this matter on the mailing list
   and decided that it would be better to have the source ask the sink for
   its parameter structure and do whatever appropriate with it.

 - Defined a preliminary set of DSI bus parameters.

   Following parameters are defined:

   1. Pixel format used for video data transmission.
   2. Mode flags (several bit flags ORed together):
 a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command mode),
following DSI_MODE_VIDEO_* flags are relevant only if this flag is set.
b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data
c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed
   to sync events)
d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode
   detection
e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets
f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area
g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area
h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area
 i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data
 j) DSI_MODE_EOT_PACKET - entity needs EoT packets
   3. Bit (serial) clock frequency in HS mode.
   4. Escape mode clock frequency.
   5. Mask of used data lanes (each bit represents single lane).
   6. Command allow area in video mode - amount of lines after transmitting
  video data when generic commands are accepted.

   Feel free to suggest anything missing or wrong, as the list of
   parameters is based merely on what was used in original Exynos MIPI
   DSIM driver.

 - Redesigned source-entity matching.

   Now each source has name string and integer id and each entity has
   source name and source id. In addition, they can have of_node specified,
   which is used for Device Tree-based matching.

   The matching procedure is as follows:

   1. Matching takes place when display entity registers.
 a) If there is of_node specified for the entity then video-source
phandle of this node is being parsed and list of registered sources
is traversed in search of a source with of_node received from
parsing the phandle.
 b) Otherwise the matching key is a pair of source name and id.
   2. If no matching source is found, display_entity_register returns
  -EPROBE_DEFER error which causes the entity driver to defer its
  probe until the source registers.
   3. Otherwise an optional bind operation of video source is called,
  sink field of source and source field of entity are set and the
  matching ends successfully.

 - Some initial concept of source-entity cross-locking.

   Only video source is protected at the moment, as I still have to think
   a bit about locking the entity in a way where removing it by user request
   is still possible.

 - Dropped any panels and chips that I can't test.

   They are irrelevant for this series, so there is no point in including them.

 - Added Exynos DSI video source driver.

   This is a new driver for the DSI controller found in Exynos SoCs. It still
   needs some work, but in current state can be considered an example of DSI
   video source implementation for my version of CDF.

 - Added Samsung S6E8AX0 DSI panel driver.

   This is the old Exynos-specific driver, just migrated to CDF and with
   some hacks to provide control over entity state to userspace using
   lcd device. However it can be used to demonstrate video source ops in use.

Feel free to comment as much as you can.

Tomasz Figa (4):
  video: add display-core
  video: add makefile  kconfig
  video: display: Add exynos-dsi video source driver
  video: display: Add Samsung s6e8ax0 display panel driver

 drivers/video/Kconfig |1 +
 drivers/video/Makefile|1 +
 drivers/video/display/Kconfig |   16 +
 

[RFC PATCH 3/4] video: display: Add exynos-dsi video source driver

[Tomasz Figa]

This patch adds new driver for DSI master block available in Samsung
Exynos SoCs. The driver is designed and written specifically for Common
Display Framework.

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/video/display/Kconfig |3 +
 drivers/video/display/Makefile|1 +
 drivers/video/display/source-exynos_dsi.c | 1313 +
 include/video/exynos_dsi.h|   41 +
 4 files changed, 1358 insertions(+)
 create mode 100644 drivers/video/display/source-exynos_dsi.c
 create mode 100644 include/video/exynos_dsi.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 477192d..b14527a 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -6,5 +6,8 @@ menuconfig DISPLAY_CORE
 if DISPLAY_CORE
 
 
+config DISPLAY_SOURCE_EXYNOS_DSI
+   tristate Samsung SoC MIPI DSI Master
+
 
 endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index bd93496..40a283a 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o
diff --git a/drivers/video/display/source-exynos_dsi.c 
b/drivers/video/display/source-exynos_dsi.c
new file mode 100644
index 000..30b15bf
--- /dev/null
+++ b/drivers/video/display/source-exynos_dsi.c
@@ -0,0 +1,1313 @@
+/*
+ * Samsung SoC MIPI DSI Master driver.
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd
+ *
+ * Contacts: Tomasz Figa t.f...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/clk.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/fb.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/memory.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
+#include linux/spinlock.h
+#include linux/videomode.h
+#include linux/wait.h
+
+#include video/display.h
+#include video/exynos_dsi.h
+#include video/mipi_display.h
+
+#define DSIM_STATUS_REG0x0 /* Status register */
+#define DSIM_SWRST_REG 0x4 /* Software reset register */
+#define DSIM_CLKCTRL_REG   0x8 /* Clock control register */
+#define DSIM_TIMEOUT_REG   0xc /* Time out register */
+#define DSIM_CONFIG_REG0x10/* Configuration register */
+#define DSIM_ESCMODE_REG   0x14/* Escape mode register */
+
+/* Main display image resolution register */
+#define DSIM_MDRESOL_REG   0x18
+#define DSIM_MVPORCH_REG   0x1c/* Main display Vporch register */
+#define DSIM_MHPORCH_REG   0x20/* Main display Hporch register */
+#define DSIM_MSYNC_REG 0x24/* Main display sync area register */
+
+/* Sub display image resolution register */
+#define DSIM_SDRESOL_REG   0x28
+#define DSIM_INTSRC_REG0x2c/* Interrupt source register */
+#define DSIM_INTMSK_REG0x30/* Interrupt mask register */
+#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register 
*/
+#define DSIM_PAYLOAD_REG   0x38/* Payload FIFO register */
+#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */
+#define DSIM_FIFOTHLD_REG  0x40/* FIFO threshold level register */
+#define DSIM_FIFOCTRL_REG  0x44/* FIFO status and control register */
+
+/* FIFO memory AC characteristic register */
+#define DSIM_PLLCTRL_REG   0x4c/* PLL control register */
+#define DSIM_PLLTMR_REG0x50/* PLL timer register */
+#define DSIM_PHYACCHR_REG  0x54/* D-PHY AC characteristic register */
+#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+
+/* DSIM_STATUS */
+#define DSIM_STOP_STATE_DAT(x) (((x)  0xf)  0)
+#define DSIM_STOP_STATE_CLK(1  8)
+#define DSIM_TX_READY_HS_CLK   (1  10)
+#define DSIM_PLL_STABLE(1  31)
+
+/* DSIM_SWRST */
+#define DSIM_FUNCRST   (1  16)
+#define DSIM_SWRST (1  0)
+
+/* DSIM_TIMEOUT */
+#define DSIM_LPDR_TOUT(x)  ((x)  0)
+#define DSIM_BTA_TOUT(x)   ((x)  16)
+
+/* DSIM_CLKCTRL */
+#define DSIM_ESC_PRESCALER(x)  (((x)  0x)  0)
+#define DSIM_ESC_PRESCALER_MASK(0x  0)
+#define DSIM_LANE_ESC_CLK_EN_CLK   (1  19)
+#define DSIM_LANE_ESC_CLK_EN_DATA(x)   (((x)  0xf)  20)
+#define DSIM_LANE_ESC_CLK_EN_DATA_MASK (0xf  20)
+#define DSIM_BYTE_CLKEN(1  24)
+#define 

[RFC PATCH 4/4] video: display: Add Samsung s6e8ax0 display panel driver

[Tomasz Figa]

This patch adds Common Display Framework driver for Samsung s6e8ax0
MIPI DSI display panel.

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/video/display/Kconfig |3 +
 drivers/video/display/Makefile|1 +
 drivers/video/display/panel-s6e8ax0.c | 1027 +
 include/video/panel-s6e8ax0.h |   41 ++
 4 files changed, 1072 insertions(+)
 create mode 100644 drivers/video/display/panel-s6e8ax0.c
 create mode 100644 include/video/panel-s6e8ax0.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index b14527a..f19ec04 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -5,6 +5,9 @@ menuconfig DISPLAY_CORE
 
 if DISPLAY_CORE
 
+config DISPLAY_PANEL_S6E8AX0
+   tristate S6E8AX0 DSI video mode panel
+   select OF_VIDEOMODE
 
 config DISPLAY_SOURCE_EXYNOS_DSI
tristate Samsung SoC MIPI DSI Master
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 40a283a..0f7fdc2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_S6E8AX0) += panel-s6e8ax0.o
 obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o
diff --git a/drivers/video/display/panel-s6e8ax0.c 
b/drivers/video/display/panel-s6e8ax0.c
new file mode 100644
index 000..4c09fe2
--- /dev/null
+++ b/drivers/video/display/panel-s6e8ax0.c
@@ -0,0 +1,1027 @@
+/* linux/drivers/video/exynos/s6e8ax0.c
+ *
+ * MIPI-DSI based s6e8ax0 AMOLED lcd 4.65 inch panel driver.
+ *
+ * Inki Dae, inki@samsung.com
+ * Donghwa Lee, dh09@samsung.com
+ * Tomasz Figa, t.f...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/mutex.h
+#include linux/wait.h
+#include linux/ctype.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/irq.h
+#include linux/interrupt.h
+
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/lcd.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/of_videomode.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/backlight.h
+#include linux/regulator/consumer.h
+
+#include video/display.h
+#include video/mipi_display.h
+#include video/panel-s6e8ax0.h
+
+#define LDI_MTP_LENGTH 24
+#define DSIM_PM_STABLE_TIME10
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 24
+#define GAMMA_TABLE_COUNT  26
+
+struct s6e8ax0 {
+   struct display_entity entity;
+   struct device *dev;
+
+   struct s6e8ax0_platform_data *pdata;
+   struct backlight_device *bd;
+   struct lcd_device *ld;
+   struct regulator_bulk_data supplies[2];
+
+   bool enabled;
+   unsigned int id;
+   unsigned int gamma;
+   unsigned int acl_enable;
+   unsigned int cur_acl;
+   int power;
+
+   unsigned int reset_gpio;
+};
+
+#define to_panel(p)container_of(p, struct s6e8ax0, entity)
+
+static const unsigned char s6e8ax0_22_gamma_30[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
+   0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
+   0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
+};
+
+static const unsigned char s6e8ax0_22_gamma_50[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xe8, 0x1f, 0xf7, 0xad, 0xc0,
+   0xb5, 0xc4, 0xdc, 0xc4, 0x9e, 0xc6, 0x9c, 0xbb, 0xd8, 0xbb,
+   0x00, 0x70, 0x00, 0x68, 0x00, 0x86,
+};
+
+static const unsigned char s6e8ax0_22_gamma_60[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xde, 0x1f, 0xef, 0xad, 0xc4,
+   0xb3, 0xc3, 0xdd, 0xc4, 0x9e, 0xc6, 0x9c, 0xbc, 0xd6, 0xba,
+   0x00, 0x75, 0x00, 0x6e, 0x00, 0x8d,
+};
+
+static const unsigned char s6e8ax0_22_gamma_70[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xd8, 0x1f, 0xe7, 0xaf, 0xc8,
+   0xb4, 0xc4, 0xdd, 0xc3, 0x9d, 0xc6, 0x9c, 0xbb, 0xd6, 0xb9,
+   0x00, 0x7a, 0x00, 0x72, 0x00, 0x93,
+};
+
+static const unsigned char s6e8ax0_22_gamma_80[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xc9, 0x1f, 0xde, 0xae, 0xc9,
+   0xb1, 0xc3, 0xdd, 0xc2, 0x9d, 0xc5, 0x9b, 0xbc, 0xd6, 0xbb,
+   0x00, 0x7f, 0x00, 0x77, 0x00, 0x99,
+};
+
+static const unsigned char s6e8ax0_22_gamma_90[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xc7, 0x1f, 0xd9, 0xb0, 0xcc,
+   0xb2, 0xc3, 0xdc, 0xc1, 0x9c, 0xc6, 0x9c, 0xbc, 0xd4, 0xb9,
+   0x00, 0x83, 0x00, 0x7b, 0x00, 0x9e,
+};
+
+static const unsigned char s6e8ax0_22_gamma_100[] = {
+   0xfa, 0x01, 0x60, 0x10, 0x60, 0xbd, 0x80, 0xcd, 0xba, 0xce,
+   0xb3, 0xc4, 0xde, 0xc3, 0x9c, 0xc4, 0x9, 0xb8, 0xd3, 0xb6,
+   0x00, 0x88, 0x00, 0x80, 0x00, 0xa5,
+};
+
+static const unsigned char 

Re: [PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function

[Sean Paul]

On Wed, Jan 30, 2013 at 1:30 AM, Vikas Sajjan vikas.saj...@linaro.org wrote:
 This patch adds display-timing node parsing using video helper function

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   38 
 +++---
  1 file changed, 35 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index bf0d9ba..94729ed 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -19,6 +19,7 @@
  #include linux/clk.h
  #include linux/of_device.h
  #include linux/pm_runtime.h
 +#include linux/pinctrl/consumer.h

  #include video/samsung_fimd.h
  #include drm/exynos_drm.h
 @@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device 
 *pdev)
 struct exynos_drm_subdrv *subdrv;
 struct exynos_drm_fimd_pdata *pdata;
 struct exynos_drm_panel_info *panel;
 +   struct fb_videomode *fbmode;
 +   struct device *disp_dev = pdev-dev;

Isn't this the same as dev (maybe I'm missing some dependent patch)?

 +   struct pinctrl *pctrl;
 struct resource *res;
 int win;
 int ret = -EINVAL;

 DRM_DEBUG_KMS(%s\n, __FILE__);

 -   pdata = pdev-dev.platform_data;
 -   if (!pdata) {
 -   dev_err(dev, no platform data specified\n);
 +   if (pdev-dev.of_node) {
 +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
 +   if (!pdata) {
 +   DRM_ERROR(memory allocation for pdata failed\n);
 +   return -ENOMEM;
 +   }
 +
 +   fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
 +   if (!fbmode) {
 +   DRM_ERROR(memory allocation for fbmode failed\n);
 +   return -ENOMEM;
 +   }
 +
 +   ret = of_get_fb_videomode(disp_dev-of_node, fbmode, -1);
 +   if (ret) {
 +   DRM_ERROR(failed to get fb_videomode\n);
 +   return -EINVAL;
 +   }
 +   pdata-panel.timing = (struct fb_videomode) *fbmode;
 +
 +   } else {
 +   pdata = pdev-dev.platform_data;
 +   if (!pdata) {
 +   DRM_ERROR(no platform data specified\n);
 +   return -EINVAL;
 +   }
 +   }
 +
 +   pctrl = devm_pinctrl_get_select_default(dev);
 +   if (IS_ERR(pctrl)) {

Will this work for exynos5? AFAICT, there's no pinctrl setup for it.

Sean

 +   DRM_ERROR(no pinctrl data provided.\n);
 return -EINVAL;
 }

 --
 1.7.9.5

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

[ANNOUNCE] xf86-video-ati 7.1.0

[Maarten Lankhorst]

If I learned anything from the libdrm mess that was 2.4.41 (sorry about that!),
it is that people check things like md5sums, imo which should really no longer 
be
included in the release announcements. :-)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alex Deucher (5):
  bump verion post release
  radeon: add new SI pci id
  radeon: fix ring count in R300PrepareTexturedVideo
  exa/Xv: fix coordinate limits on AVIVO IGPs
  radeon/r200: program RE_WIDTH_HEIGHT properly

Dave Airlie (1):
  radeon: fix damage reporting for slave pixmaps

Ilija Hadzic (3):
  video: add option to include disabled CRTCs in best CRTC search
  DRI2: change signature of radeon_dri2_drawable_crtc
  DRI2: limit the swap rate when CRTC is in DPMS-off state

Jerome Glisse (2):
  radeon: avoid segfault when pixmap exceed GPU capabilities
  radeon: avoid copying over itself ddx fb

Maarten Lankhorst (1):
  radeon: bump version for release

Michel Dänzer (11):
  Remove dead code flagged by gcc -Wunused-but-set-variable.
  Remove unused local variable 'path'.
  Remove local variables total_size_bytes.
  Remove dead option definitions.
  glamor: Release the drawable after passing to glamor_push_pixels
  glamor: Enable full 2D acceleration for SI as well.
  Drop support for X servers older than 1.7.
  DRI2: Properly use buffer depth passed in by client.
  DRI2/r[345]xx: 16 bit depth buffers use square micro tiling.
  Make CRTC shadow pixmaps usable by glamor.
  Make radeon_glamor_create_textured_pixmap() return TRUE without 
USE_GLAMOR.

git tag: xf86-video-ati-7.1.0

http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.bz2
MD5:  a799371aa8a64ac8f9535963d5135e9a  xf86-video-ati-7.1.0.tar.bz2
SHA1: f94730e5ffc5f75fa3126579bed0222fe8330653  xf86-video-ati-7.1.0.tar.bz2
SHA256: c8ae44051fcb331625217f98c09a3aa69f493052b69d62c03f41fed0bfe610cd  
xf86-video-ati-7.1.0.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.gz
MD5:  8a2694537b1fc6ff85b2aee1c00a0eb9  xf86-video-ati-7.1.0.tar.gz
SHA1: 88b94a7503e813f8a12066dbda8d9642934f5a08  xf86-video-ati-7.1.0.tar.gz
SHA256: 187230127739de179118e54205dd5c17fdb1e04cfbee1f9a63fde0030f39fcb0  
xf86-video-ati-7.1.0.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJRCUcZAAoJEP5VjHKmcBPDDVsP/RrdCI07QVxDANrNqKiUlScI
B7kMYcB4phNn/SiFKElrxikpdrHddHtRdnXs4RzG+0gb6CVGDD48xY1MZNrJRBEY
Lm+g1IKXU2w1LMqj9q3dMasNe73Msws5iRMy31n5NtVNNehcneibLR8Na7vkc30t
bAsCP6Z0kOtrlxbVsEvUbQw4JIWQIBSzWflB1hqsWQKbLEGKC9TUKWNr+ZnoPBCm
5dPYSe/vrTeaC2RvdYGsyMLcyO4D2g67uvDmRvAlE9/VWj7eTLS8QAIy2kSliHbJ
7z2F+VDRjbBYGhIsa7neWzsdA85guSFhQj5+ToLcBNn9YXSxP7MWKJ0fPoaWPTxG
wroTd14/HOCwH7a0w34SdHyB+kblTu9iOVi+DWsJ7YHs5yg/HGeB1c10OtejaZH5
cLiM4Wq1TNUuzX+DFq4JHdOwX9KM8pqyy7yPOvLOik1B7gbljmP6bJEv7NUnhNdT
cY7WOgmvlNcbuY41YI6gY8XMjP4OyEC2cK+za6THEiLL+foj3CpdBcacnMopGTbs
E4HgmzG+wXX1QBXe1y7iNz5B+y/dGNMJsM9yv2POoDZ2OTpnBczOmzGq2lJ7oxGA
/6P66eiKt1NH4CGvojzqTbTc2gJ+KQtmSJtVt2+l+m/iwHInaGbgEtAbCDVK833Y
R7KTbofGO9xkOAwBFRZr
=AnY7
-END PGP SIGNATURE-

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

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

[bugzilla-daemon]

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


Jérôme Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 CC||gli...@freedesktop.org




--- Comment #6 from Jérôme Glisse gli...@freedesktop.org  2013-01-30 17:22:36 
---
It's not completely a kernel bug. It's userspace asking insane things to
kernel.

This mesa patch should avoid the issue most of the time :
http://people.freedesktop.org/~glisse/0001-r600g-add-cs-memory-usage-accounting-and-limit-it.patch

If you are using a recent mesa with gnome you will probably want this cogl
patch too :
http://people.freedesktop.org/~glisse/0001-glx-do-not-use-multisample-visual-config-for-front-o.patch

And for kernel i am working on better handling of memory fragmentation.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2

[bugzilla-daemon]

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

--- Comment #4 from Jerome Glisse gli...@freedesktop.org ---
Please update mesa again a bunch of fixes were push. Make sure you have up to :
e1598cb642334c809e6ec219d793e7bc85a213de

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

[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #6)
 * with echo 2  /sys/module/drm/parameters/debug nothing special in dmesg

Hmm, so maybe the EBUSY error is coming from this code in
drm_mode_page_flip_ioctl():

if (crtc-fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
 * yet discovered.
 */
ret = -EBUSY;
goto out;
}


What does xrandr --current say when the problem occurs? After that, does
running xrandr without arguments make any difference?

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