[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

Bug ID: 89619
   Summary: Chrome crashes in 64 bit r600 driver while running
google maps
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jrpstonecarver at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Sorry folks, I am new to this and will do my best.

I first reported this bug to Google. They got all the data here:

https://code.google.com/p/chromium/issues/detail?id=467821

and told me that this is a bug in the r600 driver.

Back in December I updated from 32 bit Ubuntu 12.04 to 64 bit Ubuntu 14.04 and
have had major stability issues with Chrome ever since, particularly while
using Google Maps.

This URL

https://www.google.com/maps/place/Los+Gatos,+CA+95033/@37.1893925,-121.9894751,11z/data=!4m2!3m1!1s0x808e39d2fbec72d9:0x4b03e7246671be9b

was the first time I've managed to capture something that crashes chrome
reliably, however.

At their suggestion I tried running chrome with --disable-gpu and at least with
a simple test the problem went away.

I think these drivers are the default in Ubuntu now, but they seem to be
causing me a lot of grief.

You can pickup what Google got from the crash report Chrome sent to them from
the bug listed above.

And for the time being I will figure out how to run with --disable-gpu on all
the time to see if that avoids my issue.

Failing that I guess it's time to figure out how to go back to ATI's drivers.

If there is additional data I can provide somehow, I am happy to try. I'm no
wizard, but I will follow instructions and get whatever you need if possible.

Thanks.

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

[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

--- Comment #1 from Ilia Mirkin  ---
>From the chrome bug report

Driver vendorMesa
Driver version10.1.3

10.1 was released over a year ago. A lot of bugs have been fixed since then.
Can you try a more recent version? 10.5.1 was released recently.

-- 
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/20150318/066a35ba/attachment.html>

[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

--- Comment #2 from Jeff Powell  ---
(In reply to Ilia Mirkin from comment #1)
> From the chrome bug report
> 
> Driver vendor Mesa
> Driver version10.1.3
> 
> 10.1 was released over a year ago. A lot of bugs have been fixed since then.
> Can you try a more recent version? 10.5.1 was released recently.

To be brutally honest, I'm not sure. 14.04 is an LTS release that is supposed
to be supported for 2 years at least, and possibly 5. And it is using the
default driver that Ubuntu makes available, not one of my particular choice. If
Ubuntu supplied an update I would pick it up, but I don't normally install my
own device drivers.

If that is the only choice, I can try to figure it out, but it would be far
better if Ubuntu provided updates via the usual distribution path, at least
IMHO.

Alternately, if you can point me at a good sent of instructions for how to do
this, you could save me some time.

-- 
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/20150318/6ea44f94/attachment.html>

[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

--- Comment #3 from Ilia Mirkin  ---
(In reply to Jeff Powell from comment #2)
> (In reply to Ilia Mirkin from comment #1)
> > From the chrome bug report
> > 
> > Driver vendor   Mesa
> > Driver version  10.1.3
> > 
> > 10.1 was released over a year ago. A lot of bugs have been fixed since then.
> > Can you try a more recent version? 10.5.1 was released recently.
> 
> To be brutally honest, I'm not sure. 14.04 is an LTS release that is
> supposed to be supported for 2 years at least, and possibly 5. And it is
> using the default driver that Ubuntu makes available, not one of my
> particular choice. If Ubuntu supplied an update I would pick it up, but I
> don't normally install my own device drivers.

I see. Well, the way LTS generally works is "if it worked before, it'll keep
working, but you get security/etc updates". It didn't work for you before, so
that strategy won't work too well for you.

> 
> If that is the only choice, I can try to figure it out, but it would be far
> better if Ubuntu provided updates via the usual distribution path, at least
> IMHO.
> 
> Alternately, if you can point me at a good sent of instructions for how to
> do this, you could save me some time.

I'm not particularly knowledgeable on Ubuntu. "oibaf ppa" is something I've
heard said in connection to Ubuntu and easier availability of pre-packaged
mesa.  A quick search turns up

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

which makes claims about supporting Ubuntu 14.04. Hope this helps.

-- 
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/20150318/8d80f486/attachment.html>

[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

--- Comment #4 from Jeff Powell  ---
Thanks. I'm running out of time today, but I'll check that out tomorrow and see
what I can learn. Gotta be a way to do 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/20150318/3cbef8ac/attachment.html>

[PATCH libdrm 0/5] Yet another round of Android build cleanups

[Chih-Wei Huang]

2015-03-18 7:30 GMT+08:00 Emil Velikov :
>
> As pointed out by Chih-Wei, Android's LOCAL_COPY_HEADERS{,_TO} has been
> depreciated for quite some time.
>
> Although it was a convenient way of getting things done (no more
> hard-coding the location of drm) it seems that there is another more
> appropriate (and cleaner) solution. Namely:
> Annotate the includes as "exported" and as the user selects the library
> for linking, the build will automatically add the includes.
>
> Big thanks to Chih-Wei for the patience and persistence explaining the
> whole shebang. This series is mostly based on his patch in the
> Android-x86 tree, with some extra bits from your truly :-)
>
> Chih-Wei,
>
> I've tested this a few times already, although having someone with
> experience in the whole thing will be appreciated.

Thank you for the effort to clean it up.
The patches looks good to me.

I would suggest to remove all the use of LIBDRM_TOP.
Do you want me to submit a patch?

[PATCH libdrm 0/5] Yet another round of Android build cleanups

[Emil Velikov]

On 18 March 2015 at 01:19, Chih-Wei Huang  wrote:
> 2015-03-18 7:30 GMT+08:00 Emil Velikov :
>>
>> As pointed out by Chih-Wei, Android's LOCAL_COPY_HEADERS{,_TO} has been
>> depreciated for quite some time.
>>
>> Although it was a convenient way of getting things done (no more
>> hard-coding the location of drm) it seems that there is another more
>> appropriate (and cleaner) solution. Namely:
>> Annotate the includes as "exported" and as the user selects the library
>> for linking, the build will automatically add the includes.
>>
>> Big thanks to Chih-Wei for the patience and persistence explaining the
>> whole shebang. This series is mostly based on his patch in the
>> Android-x86 tree, with some extra bits from your truly :-)
>>
>> Chih-Wei,
>>
>> I've tested this a few times already, although having someone with
>> experience in the whole thing will be appreciated.
>
> Thank you for the effort to clean it up.
> The patches looks good to me.
>
> I would suggest to remove all the use of LIBDRM_TOP.
> Do you want me to submit a patch?
Hmm I'm not sure that things will work correctly if we directly
substitute LIBDRM_TOP with LOCAL_PATH within the following.

mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))

Can you send a patch over ?

Thanks
Emil

[PATCH libdrm 3/5] android: remove ${srcdir} from the includes

[Chih-Wei Huang]

2015年3月18日 上午7:30 於 "Emil Velikov"  
寫道：
>
> Already implicitly handled by the compiler.

Actually it's not handled by the compiler, but by the Android build system.
It automatically adds  $(LOCAL_PATH), $(intermediate), ... to the include
paths.

> Signed-off-by: Emil Velikov 
> ---
>  freedreno/Android.mk | 3 ---
>  intel/Android.mk | 1 -
>  nouveau/Android.mk   | 3 ---
>  radeon/Android.mk| 3 ---
>  4 files changed, 10 deletions(-)
>
> diff --git a/freedreno/Android.mk b/freedreno/Android.mk
> index d6c19fe..9031d61 100644
> --- a/freedreno/Android.mk
> +++ b/freedreno/Android.mk
> @@ -12,9 +12,6 @@ LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_SRC_FILES := $(LIBDRM_FREEDRENO_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
> -LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/freedreno
> -
>  LOCAL_CFLAGS := \
> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>
> diff --git a/intel/Android.mk b/intel/Android.mk
> index 8a30fb5..7397110 100644
> --- a/intel/Android.mk
> +++ b/intel/Android.mk
> @@ -34,7 +34,6 @@ LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
>  LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/intel \
> external/libpciaccess/include
>
>  LOCAL_CFLAGS := \
> diff --git a/nouveau/Android.mk b/nouveau/Android.mk
> index 6c46f6c..5bc325c 100644
> --- a/nouveau/Android.mk
> +++ b/nouveau/Android.mk
> @@ -12,9 +12,6 @@ LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_SRC_FILES := $(LIBDRM_NOUVEAU_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
> -LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/nouveau
> -
>  LOCAL_CFLAGS := \
> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>
> diff --git a/radeon/Android.mk b/radeon/Android.mk
> index d9192b6..f12e631 100644
> --- a/radeon/Android.mk
> +++ b/radeon/Android.mk
> @@ -12,9 +12,6 @@ LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_SRC_FILES := $(LIBDRM_RADEON_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
> -LOCAL_C_INCLUDES := \
> -   $(LIBDRM_TOP)/radeon
> -
>  LOCAL_CFLAGS := \
> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>
> --
> 2.1.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150318/37ad9e48/attachment.html>

[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

--- Comment #5 from Michel Dänzer  ---
We'll need at least a proper backtrace of the crash with debugging symbols for
r600_dri.so and libgallium.so.0.0.0.

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

[PATCH v2 RESEND 0/4] Fix power domains handling on exynos542x

[Kukjin Kim]

On 03/12/15 22:37, Andrzej Hajda wrote:
> Hi Kukjin,
> 
Hi,

> This is resend of my patchset with added (Reviewed|Tested)-by tags and 
> removed RFC
> prefix.
> 
> Exynos chipsets since 542x have asynchronous bridges connecting different IPs.
> These bridges should be operational during power domain switching, ie 
> associated
> clocks cannot be gated.
> This patchset adds binding to provide such clocks per power domain and adds 
> code
> which enables them during domain on/off operation.
> 
> This patchset fixes power domain issues with disp1 domain and HDMI (some of 
> them)
> on Odroid XU3:
> - disp1 power domain can be turned off,
> - no more "imprecise external abort" faults.
> 
> The patchset is based on samsung-fixes-dt tag from kgene/linux-samsung.
> 
> It was successfully tested on OdroidXU3.
> 
Thanks, applied whole this series.

- Kukjin

> Andrzej Hajda (4):
>   arm/exynos: add asynchronous bridge clock bindings
>   arm/exynos/pm_domains: add support for async-bridge clocks
>   ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain
>   ARM: dts: exynos5420: add async-bridge clocks to gsc power domain
> 
>  .../bindings/arm/exynos/power_domain.txt   |  3 +++
>  arch/arm/boot/dts/exynos5420.dtsi  |  8 +--
>  arch/arm/mach-exynos/pm_domains.c  | 27 
> ++
>  3 files changed, 32 insertions(+), 6 deletions(-)

[PATCH] drm: Return current vblank value for drmWaitVBlank queries

[Michel Dänzer]

On 18.03.2015 00:44, Chris Wilson wrote:
> When userspace queries the current vblank for the CRTC, we can reply
> with the cached value (using atomic reads to serialise with the vblank
> interrupt as necessary) without having to touch registers. In the
> instant disable case, this saves us from enabling/disabling the vblank
> around every query, greatly reducing the number of registers read and
> written.
> 
> Signed-off-by: Chris Wilson 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: Laurent Pinchart 
> Cc: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_irq.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8a34476570a..6c4570082b65 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1585,7 +1585,18 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>   if (crtc >= dev->num_crtcs)
>   return -EINVAL;
>  
> - vblank = &dev->vblank[crtc];
> + /* Fast-path the query for the current value (without an event)
> +  * to avoid having to enable/disable the vblank interrupts.
> +  */
> + if ((vblwait->request.type & (_DRM_VBLANK_TYPES_MASK | 
> _DRM_VBLANK_FLAGS_MASK)) == _DRM_VBLANK_RELATIVE &&
> + vblwait->request.sequence == 0) {
> + struct timeval now;
> +
> + vblwait->reply.sequence = drm_vblank_count_and_time(dev, crtc, 
> &now);
> + vblwait->reply.tval_sec = now.tv_sec;
> + vblwait->reply.tval_usec = now.tv_usec;
> + return 0;
> + }

drm_vblank_count_and_time() doesn't return the correct sequence number
while the vblank interrupt is disabled, does it? It returns the sequence
number from the last time vblank_disable_and_save() was called (when the
vblank interrupt was disabled). That's why drm_vblank_get() is needed here.


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

[PATCH] drm: Return current vblank value for drmWaitVBlank queries

[Michel Dänzer]

On 18.03.2015 11:53, Michel Dänzer wrote:
> On 18.03.2015 00:44, Chris Wilson wrote:
>> When userspace queries the current vblank for the CRTC, we can reply
>> with the cached value (using atomic reads to serialise with the vblank
>> interrupt as necessary) without having to touch registers. In the
>> instant disable case, this saves us from enabling/disabling the vblank
>> around every query, greatly reducing the number of registers read and
>> written.
>>
>> Signed-off-by: Chris Wilson 
>> Cc: Imre Deak 
>> Cc: Daniel Vetter 
>> Cc: Ville Syrjälä 
>> Cc: Laurent Pinchart 
>> Cc: Dave Airlie 
>> ---
>>  drivers/gpu/drm/drm_irq.c | 15 ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index c8a34476570a..6c4570082b65 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -1585,7 +1585,18 @@ int drm_wait_vblank(struct drm_device *dev, void 
>> *data,
>>  if (crtc >= dev->num_crtcs)
>>  return -EINVAL;
>>  
>> -vblank = &dev->vblank[crtc];
>> +/* Fast-path the query for the current value (without an event)
>> + * to avoid having to enable/disable the vblank interrupts.
>> + */
>> +if ((vblwait->request.type & (_DRM_VBLANK_TYPES_MASK | 
>> _DRM_VBLANK_FLAGS_MASK)) == _DRM_VBLANK_RELATIVE &&
>> +vblwait->request.sequence == 0) {
>> +struct timeval now;
>> +
>> +vblwait->reply.sequence = drm_vblank_count_and_time(dev, crtc, 
>> &now);
>> +vblwait->reply.tval_sec = now.tv_sec;
>> +vblwait->reply.tval_usec = now.tv_usec;
>> +return 0;
>> +}
> 
> drm_vblank_count_and_time() doesn't return the correct sequence number
> while the vblank interrupt is disabled, does it? It returns the sequence
> number from the last time vblank_disable_and_save() was called (when the
> vblank interrupt was disabled). That's why drm_vblank_get() is needed here.

It might be possible to avoid drm_vblank_get() and use
drm_update_vblank_count() before (or in) drm_vblank_count_and_time()
instead when the vblank interrupt is disabled, but then you'd first need
to make it safe to call drm_update_vblank_count() several times while
the vblank interrupt is disabled, by making it update vblank->last at least.


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

4.0-rc4 strangeness: who crossed my 9's?! on thinkpad x60

[Pavel Machek]

Hi!

> Dave just sent out the pull request with the fix for this:
> 
> commit 046d669c62f37323ef0329c41d83a03c06b2087d
> Author: Krzysztof Kolasa 
> Date:   Sun Mar 15 20:22:36 2015 +0100
> 
> [PATCH] drm/mm: Fix support 4 GiB and larger ranges
> 

Thanks, have it, no hangups so far.

But now, I have another strangeness.

All the 9's in mate-terminals have thin black line on them. IOW I'm
having my fonts corrupted, and it is the first time I seen something
like this.

I was even trying to physically clean my screen :-).

Any ideas?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 3/4] drm/msm: Initial add DSI connector support

[Archit Taneja]

Hi,

On 03/14/2015 04:54 AM, Hai Li wrote:
> This change adds the DSI connector support in msm drm driver.
>
> Signed-off-by: Hai Li 
> ---
>   drivers/gpu/drm/msm/Kconfig   |   11 +
>   drivers/gpu/drm/msm/Makefile  |4 +
>   drivers/gpu/drm/msm/dsi/dsi.c |  203 
>   drivers/gpu/drm/msm/dsi/dsi.h |  115 ++
>   drivers/gpu/drm/msm/dsi/dsi_host.c| 1997 
> +
>   drivers/gpu/drm/msm/dsi/dsi_manager.c |  706 
>   drivers/gpu/drm/msm/dsi/dsi_phy.c |  352 ++
>   drivers/gpu/drm/msm/msm_drv.h |   20 +
>   8 files changed, 3408 insertions(+)
>   create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
>   create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
>   create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
>   create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
>   create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c
>
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index 1e6a907..5ba5631 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
> Compile in support for logging register reads/writes in a format
> that can be parsed by envytools demsm tool.  If enabled, register
> logging can be switched on via msm.reglog=y module param.
> +
> +config DRM_MSM_DSI
> + bool "Enable DSI support in MSM DRM driver"
> + depends on DRM_MSM
> + select DRM_PANEL
> + select DRM_MIPI_DSI
> + default y
> + help
> +   Choose this option if you have a need for MIPI DSI connector
> +   support.
> +
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 674a132..5c144cc 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -50,5 +50,9 @@ msm-y := \
>
>   msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
>   msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
> +msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
> + dsi/dsi_host.o \
> + dsi/dsi_manager.o \
> + dsi/dsi_phy.o
>
>   obj-$(CONFIG_DRM_MSM)   += msm.o
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> new file mode 100644
> index 000..de77260
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -0,0 +1,203 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "dsi.h"
> +
> +int msm_dsi_modeset_init(struct msm_drm_sub_dev *base, struct drm_device 
> *dev)
> +{
> + struct msm_dsi *msm_dsi = container_of(base, struct msm_dsi, base);
> + struct msm_drm_private *priv = dev->dev_private;
> + int ret, i;
> +
> + if (WARN_ON((base->num_encoders != MSM_DSI_ENCODER_NUM) ||
> + !base->encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
> + !base->encoders[MSM_DSI_CMD_ENCODER_ID]))
> + return -EINVAL;
> +
> + msm_dsi->dev = dev;
> +
> + ret = msm_dsi_host_modeset_init(msm_dsi->host, dev);
> + if (ret) {
> + dev_err(dev->dev, "failed to modeset init host: %d\n", ret);
> + goto fail;
> + }
> +
> + msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
> + if (IS_ERR(msm_dsi->bridge)) {
> + ret = PTR_ERR(msm_dsi->bridge);
> + dev_err(dev->dev, "failed to create dsi bridge: %d\n", ret);
> + msm_dsi->bridge = NULL;
> + goto fail;
> + }
> +
> + msm_dsi->connector = msm_dsi_manager_connector_init(msm_dsi->id);
> + if (IS_ERR(msm_dsi->connector)) {
> + ret = PTR_ERR(msm_dsi->connector);
> + dev_err(dev->dev, "failed to create dsi connector: %d\n", ret);
> + msm_dsi->connector = NULL;
> + goto fail;
> + }
> +
> + for (i = 0; i < base->num_encoders; i++)
> + base->encoders[i]->bridge = msm_dsi->bridge;
> +
> + priv->bridges[priv->num_bridges++]   = msm_dsi->bridge;
> + priv->connectors[priv->num_connectors++] = msm_dsi->connector;
> +
> + return 0;
> +fail:
> + if (msm_dsi) {
> + /* bridge/connector are normally destroyed by drm: */
> + if (msm_dsi->bridge) {
> + msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
> + msm_dsi->bridge = NULL;
> + }
> + if (msm_dsi->connector) {
> + msm_dsi->connector->funcs->destroy(msm_dsi->connector)

[PATCH v2 2/6] of: add helper for getting endpoint node of specific identifiers

[Hyungwon Hwang]

When there are multiple ports or multiple endpoints in a port, they have to be
distinguished by the value of reg property. It is common. The drivers can get
the specific endpoint in the specific port via this function. Now the drivers
have to implement this code in themselves or have to force the order of dt nodes
to get the right node.

Signed-off-by: Hyungwon Hwang 
Acked-by: Rob Herring 
---
 drivers/of/base.c| 33 +
 include/linux/of_graph.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 36536b6..d7fa99d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2155,6 +2155,39 @@ struct device_node *of_graph_get_next_endpoint(const 
struct device_node *parent,
 EXPORT_SYMBOL(of_graph_get_next_endpoint);

 /**
+ * of_graph_get_endpoint_by_regs() - get endpoint node of specific identifiers
+ * @parent: pointer to the parent device node
+ * @port_reg: identifier (value of reg property) of the parent port node
+ * @reg: identifier (value of reg property) of the endpoint node
+ *
+ * Return: An 'endpoint' node pointer which is identified by reg and at the 
same
+ * is the child of a port node identified by port_reg. reg and port_reg are
+ * ignored when they are -1.
+ */
+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg)
+{
+   struct of_endpoint endpoint;
+   struct device_node *node, *prev_node = NULL;
+
+   while (1) {
+   node = of_graph_get_next_endpoint(parent, prev_node);
+   of_node_put(prev_node);
+   if (!node)
+   break;
+
+   of_graph_parse_endpoint(node, &endpoint);
+   if (((port_reg == -1) || (endpoint.port == port_reg)) &&
+   ((reg == -1) || (endpoint.id == reg)))
+   return node;
+
+   prev_node = node;
+   }
+
+   return NULL;
+}
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e859eb7 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -31,6 +31,8 @@ int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -49,6 +51,12 @@ static inline struct device_node *of_graph_get_next_endpoint(
return NULL;
 }

+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1

[PATCH v2 0/6] Add drivers for Exynos5433 display

[Hyungwon Hwang]

This patchset is based on the git(branch name: exynos-drm-next) which is
maintained by Inki Dae.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

This patchset adds 2 new device drivers, decon and mic, and adds support for
Exynos5433 mipi dsi. To enable display in a Exynos5433 board, decon(display
controller), MIC(Mobile image compressor), mipi dsi, and panel have to be turned
on. This patchset contains support for 3 drivers for SoC level devices.

Changes for v2:
- change config, file, and variable names of decon to represnt exynos5433
instead of exynos to distinguish them from exynos7 decon
- change the initialization order of decon to make it initialized in order like
FIMD or exynos7 decon
- make mic driver to be registered by exynos drm driver instead as a module
driver
- change the description of mic driver in documentation
- add module author at the top of the source file removing MODULE_OWNER,
MODULE_DESCRIPTION, MODULE_LICENSE
- change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
Hyungwon Hwang by the previous author's will

Hyungwon Hwang (5):
  of: add helper for getting endpoint node of specific identifiers
  drm/exynos: mic: add MIC driver
  drm/exynos: dsi: add support for Exynos5433 SoC
  drm/exynos: dsi: add support for MIC driver as a bridge
  drm/exynos: dsi: do not set TE GPIO direction by input

Joonyoung Shim (1):
  drm/exynos: add Exynos5433 decon driver

 .../devicetree/bindings/video/exynos-mic.txt   |  49 ++
 .../devicetree/bindings/video/exynos5433-decon.txt |  65 +++
 .../devicetree/bindings/video/exynos_dsim.txt  |  24 +-
 drivers/gpu/drm/exynos/Kconfig |  14 +-
 drivers/gpu/drm/exynos/Makefile|   2 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 543 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   6 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 459 +++--
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 481 ++
 drivers/gpu/drm/exynos/regs-exynos5433-decon.h | 163 +++
 drivers/of/base.c  |  33 ++
 include/linux/of_graph.h   |   8 +
 13 files changed, 1703 insertions(+), 146 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c
 create mode 100644 drivers/gpu/drm/exynos/regs-exynos5433-decon.h

--
1.9.1

[PATCH v2 5/6] drm/exynos: dsi: add support for MIC driver as a bridge

[Hyungwon Hwang]

MIC must be initilized by MIPI DSI when it is being bound.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 77236ad..e385d24 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -280,6 +281,7 @@ struct exynos_dsi {
struct list_head transfer_list;

struct exynos_dsi_driver_data *driver_data;
+   struct device_node *bridge_node;
 };

 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1787,7 +1789,22 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)

ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
 &dsi->esc_clk_rate);
+   if (ret < 0)
+   goto end;
+
+   of_node_put(ep);
+
+   ep = of_graph_get_next_endpoint(node, NULL);
+   if (!ep) {
+   ret = -ENXIO;
+   goto end;
+   }

+   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+   if (!dsi->bridge_node) {
+   ret = -ENXIO;
+   goto end;
+   }
 end:
of_node_put(ep);

@@ -1800,6 +1817,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
struct exynos_drm_display *display = dev_get_drvdata(dev);
struct exynos_dsi *dsi = display_to_dsi(display);
struct drm_device *drm_dev = data;
+   struct drm_bridge *bridge;
int ret;

ret = exynos_drm_create_enc_conn(drm_dev, display);
@@ -1809,6 +1827,12 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
return ret;
}

+   bridge = of_drm_find_bridge(dsi->bridge_node);
+   if (bridge) {
+   display->encoder->bridge = bridge;
+   drm_bridge_attach(drm_dev, bridge);
+   }
+
return mipi_dsi_host_register(&dsi->dsi_host);
 }

-- 
1.9.1

[PATCH v2 6/6] drm/exynos: dsi: do not set TE GPIO direction by input

[Hyungwon Hwang]

On some board, TE GPIO should be configured properly thoughout pinctrl driver
as an wakeup interrupt. So this gpio should be configurable in the board's DT,
not being requested as a input pin.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e385d24..58e0620 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1324,15 +1324,15 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi)
goto out;
}

-   ret = gpio_request_one(dsi->te_gpio, GPIOF_IN, "te_gpio");
+   ret = gpio_request(dsi->te_gpio, "te_gpio");
if (ret) {
dev_err(dsi->dev, "gpio request failed with %d\n", ret);
goto out;
}

te_gpio_irq = gpio_to_irq(dsi->te_gpio);
-
irq_set_status_flags(te_gpio_irq, IRQ_NOAUTOEN);
+
ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
IRQF_TRIGGER_RISING, "TE", dsi);
if (ret) {
-- 
1.9.1

[PATCH v2 1/6] drm/exynos: add Exynos5433 decon driver

[Hyungwon Hwang]

From: Joonyoung Shim 

DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
change file names and variable names of decon to represnt exynos5433 instead of
exynos to distinguish them from exynos7 decon
 .../devicetree/bindings/video/exynos5433-decon.txt |  65 +++
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 543 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/regs-exynos5433-decon.h | 163 +++
 7 files changed, 782 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 create mode 100644 drivers/gpu/drm/exynos/regs-exynos5433-decon.h

diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
new file mode 100644
index 000..377afbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-decon";
+- reg: physical base address and length of the DECON registers set.
+- interrupts: should contain a list of all DECON IP block interrupts in the
+ order: VSYNC, LCD_SYSTEM. The interrupt specifier format
+ depends on the interrupt controller used.
+- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
+  in the same order as they were listed in the interrupts
+  property.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+  "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+  "sclk_decon_eclk"
+- ports: contains a port which is connected to mic node. address-cells and
+size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the mic
+   node. The reg value muset be 0.
+- i80-if-timings: specify whether the panel which is connected to decon uses
+ i80 lcd interface or mipi video interface. This node contains
+ no timing information as that of fimd does. Because there is
+ no register in decon to specify i80 interface timing value,
+ it is not needed, but make it remain to use same kind of node
+ in fimd and exynos7 decon.
+
+Example:
+SoC specific DT entry:
+decon: decon at 1380 {
+   compatible = "samsung,exynos5433-decon";
+   reg = <0x1380 0x2104>;
+   clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>,
+   <&cmu_disp CLK_ACLK_XIU_DECON0X>,
+   <&cmu_disp CLK_PCLK_SMMU_DECON0X>,
+   <&cmu_disp CLK_SCLK_DECON_VCLK>,
+   <&cmu_disp CLK_SCLK_DECON_ECLK>;
+   clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x",
+   "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk";
+   interrupt-names = "vsync", "lcd_sys";
+   interrupts = <0 202 0>, <0 203 0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <&mic_to_decon>;
+   };
+   };
+   };
+};
+
+Board specific DT entry:
+&decon {
+   i80-if-timings {
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index a5e7461..e15cc2e 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,6 +24,12 @@ config DRM_EXYNOS_FIMD
help
  Choose this option if you want to use Exynos FIMD for DRM.

+config DRM_EXYNOS5433_DECON
+   bool "Exynos5433 DRM DECON"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos5433 DECON for DRM.
+
 config DRM_EXYNOS7_DECON
bool "Exynos DRM DECON"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index cc90679..fbd084d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/

[PATCH v2 4/6] drm/exynos: dsi: add support for Exynos5433 SoC

[Hyungwon Hwang]

This patch adds support for Exynos5433. The goal is achieved by
1. Getting the address of registers from driver data
2. Getting the fixed value for registers from driver data
3. Getting different number of clocks using driver data
4. Getting max frequency of pixel clock from driver data

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
- change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
Hyungwon Hwang by the previous author's will
 .../devicetree/bindings/video/exynos_dsim.txt  |  24 +-
 drivers/gpu/drm/exynos/Kconfig |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 431 ++---
 3 files changed, 313 insertions(+), 144 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index ca2b4aa..fea7718 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -6,6 +6,7 @@ Required properties:
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
*/
+   "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
@@ -30,10 +31,19 @@ Video interfaces:
   Device node can contain video interface port nodes according to [2].
   The following are properties specific to those nodes:

-  port node:
-- reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port;
+  port node inbound:
+- reg: (required) must be 0.
+  port node outbound:
+- reg: (required) must be 1.

-  endpoint node of DSI port (reg = 1):
+  endpoint node connected from mic node (reg = 0):
+- remote-endpoint: specifies the endpoint in mic node. This node is 
required
+  for Exynos5433 mipi dsi. So mic can access to panel node
+  thoughout this dsi node.
+  endpoint node connected to panel node (reg = 1):
+- remote-endpoint: specifies the endpoint in panel node. This node is
+  required in all kinds of exynos mipi dsi to represent
+  the connection between mipi dsi and panel.
 - samsung,burst-clock-frequency: specifies DSI frequency in high-speed 
burst
   mode
 - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
@@ -72,7 +82,15 @@ Example:
#address-cells = <1>;
#size-cells = <0>;

+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <&mic_to_decon>;
+   };
+   };
+
port at 1 {
+   reg = <1>;
dsi_ep: endpoint {
reg = <0>;
samsung,burst-clock-frequency = 
<5>;
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index a796175..eb35a21 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -47,7 +47,7 @@ config DRM_EXYNOS_DPI

 config DRM_EXYNOS_DSI
bool "EXYNOS DRM MIPI-DSI driver support"
-   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON)
+   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || 
DRM_EXYNOS7_DECON)
select DRM_MIPI_DSI
select DRM_PANEL
default n
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 05fe93d..77236ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -33,38 +33,6 @@
 /* returns true iff both arguments logically differs */
 #define NEQV(a, b) (!(a) ^ !(b))

-#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 DSI

[PATCH v2 3/6] drm/exynos: mic: add MIC driver

[Hyungwon Hwang]

MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.

Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
- make mic driver to be registered by exynos drm driver instead as a module 
 |  
-
driver  
 |  
-
- change the description of mic driver in documentation
- add module author at the top of the source file removing MODULE_OWNER,
MODULE_DESCRIPTION, MODULE_LICENSE
 .../devicetree/bindings/video/exynos-mic.txt   |  49 +++
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 481 +
 6 files changed, 541 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c

diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt 
b/Documentation/devicetree/bindings/video/exynos-mic.txt
new file mode 100644
index 000..006d072
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-mic.txt
@@ -0,0 +1,49 @@
+Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC)
+
+MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is
+not capable to transfer high resoltuion frame data as decon can send. MIC
+solves this problem by compressing the frame data by 1/2 before it is 
transfered
+through mipi dsi. The compressed frame data must be uncompressed in the panel
+PCB.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-mic".
+- reg: physical base address and length of the MIC registers set and system
+   register of mic.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0".
+- ports: contains a port which is connected to decon node and dsi node.
+address-cells and size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the
+   decon node or dsi node. The reg value must be 0 and 1 respectively.
+
+Example:
+SoC specific DT entry:
+mic: mic at 1393 {
+   compatible = "samsung,exynos5433-mic";
+   reg = <0x1393 0x48 0x13B8 0x1010>;
+   clocks = <&cmu_disp CLK_PCLK_MIC0>,
+  <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>;
+   clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   mic_to_decon: endpoint {
+   remote-endpoint = <&decon_to_mic>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   mic_to_dsi: endpoint {
+   remote-endpoint = <&dsi_to_mic>;
+   };
+   };
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index e15cc2e..a796175 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -103,3 +103,9 @@ config DRM_EXYNOS_GSC
depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use Exynos GSC for DRM.
+
+config DRM_EXYNOS_MIC
+   bool "Exynos DRM MIC"
+   depends on (DRM_EXYNOS && DRM_EXYNOS5433_DECON)
+   help
+ Choose this option if you want to use Exynos MIC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index fbd084d..7de0b10 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -22,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+= exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
inde

[patch] drm/i915: memory leak in __i915_gem_vma_create()

[Dan Carpenter]

In the original code then if WARN_ON(i915_is_ggtt(vm) != !!ggtt_view)
was true then we leak "vma".  Presumably that doesn't happen often but
static checkers complain and this bug is easy to fix.

Fixes: c3bbb6f2825d ('drm/i915: Do not use ggtt_view with (aliasing) PPGTT')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f1b9ea6..cbf013f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2340,12 +2340,13 @@ __i915_gem_vma_create(struct drm_i915_gem_object *obj,
  struct i915_address_space *vm,
  const struct i915_ggtt_view *ggtt_view)
 {
-   struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
-   if (vma == NULL)
-   return ERR_PTR(-ENOMEM);
+   struct i915_vma *vma;

if (WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
return ERR_PTR(-EINVAL);
+   vma = kzalloc(sizeof(*vma), GFP_KERNEL);
+   if (vma == NULL)
+   return ERR_PTR(-ENOMEM);

INIT_LIST_HEAD(&vma->vma_link);
INIT_LIST_HEAD(&vma->mm_list);

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

[Jani Nikula]

On Wed, 18 Mar 2015, Steven Rostedt  wrote:
> On Tue, 17 Mar 2015 08:53:21 +0100
> Daniel Vetter  wrote:
>
>> Can you please cherry pick 42a7b088127f (\"drm/i915: Make sure the primary
>> plane is enabled before reading out the fb state\") from -next to 4.0-rc
>> to test whether this is indeed the difference in ducttape?
>
> I cherry-picked that patch and the warning does go away.

Cherry-picked to drm-intel-fixes to queue it to v4.0-rc. Thanks for the
report and testing.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[GIT PULL] drm: sti: convert driver to atomic modeset

[Benjamin Gaignard]

Hello Dave,

Can I ask you to mmerge this pull request into drm-next ?

The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:

  Merge tag 'topic/drm-misc-2015-03-10' of
git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11
12:15:06 +1000)

are available in the git repository at:


  http://git.linaro.org/people/benjamin.gaignard/kernel.git drm-st-next-atomic

for you to fetch changes up to 7995bbee3f00a4a6ce6a01d4de404e5b896773df:

  drm: sti: convert driver to atomic modeset (2015-03-17 11:22:14 +0100)


Benjamin Gaignard (1):
  drm: sti: convert driver to atomic modeset

 drivers/gpu/drm/sti/sti_drm_crtc.c  | 85 ++---
 drivers/gpu/drm/sti/sti_drm_drv.c   |  5 +++
 drivers/gpu/drm/sti/sti_drm_plane.c | 45 ++--
 drivers/gpu/drm/sti/sti_dvo.c   |  4 ++
 drivers/gpu/drm/sti/sti_hda.c   |  4 ++
 drivers/gpu/drm/sti/sti_hdmi.c  |  4 ++
 6 files changed, 92 insertions(+), 55 deletions(-)

Regards,
Benjamin

[patch] drm/i915: memory leak in __i915_gem_vma_create()

[Jani Nikula]

On Wed, 18 Mar 2015, Dan Carpenter  wrote:
> In the original code then if WARN_ON(i915_is_ggtt(vm) != !!ggtt_view)
> was true then we leak "vma".  Presumably that doesn't happen often but
> static checkers complain and this bug is easy to fix.
>
> Fixes: c3bbb6f2825d ('drm/i915: Do not use ggtt_view with (aliasing) PPGTT')
> Signed-off-by: Dan Carpenter 

Reviewed-by: Jani Nikula 

>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index f1b9ea6..cbf013f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2340,12 +2340,13 @@ __i915_gem_vma_create(struct drm_i915_gem_object *obj,
> struct i915_address_space *vm,
> const struct i915_ggtt_view *ggtt_view)
>  {
> - struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> - if (vma == NULL)
> - return ERR_PTR(-ENOMEM);
> + struct i915_vma *vma;
>  
>   if (WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
>   return ERR_PTR(-EINVAL);
> + vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> + if (vma == NULL)
> + return ERR_PTR(-ENOMEM);
>  
>   INIT_LIST_HEAD(&vma->vma_link);
>   INIT_LIST_HEAD(&vma->mm_list);

-- 
Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [patch] drm/i915: memory leak in __i915_gem_vma_create()

[Daniel Vetter]

On Wed, Mar 18, 2015 at 10:36:45AM +0200, Jani Nikula wrote:
> On Wed, 18 Mar 2015, Dan Carpenter  wrote:
> > In the original code then if WARN_ON(i915_is_ggtt(vm) != !!ggtt_view)
> > was true then we leak "vma".  Presumably that doesn't happen often but
> > static checkers complain and this bug is easy to fix.
> >
> > Fixes: c3bbb6f2825d ('drm/i915: Do not use ggtt_view with (aliasing) PPGTT')
> > Signed-off-by: Dan Carpenter 
> 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel

> 
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index f1b9ea6..cbf013f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2340,12 +2340,13 @@ __i915_gem_vma_create(struct drm_i915_gem_object 
> > *obj,
> >   struct i915_address_space *vm,
> >   const struct i915_ggtt_view *ggtt_view)
> >  {
> > -   struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> > -   if (vma == NULL)
> > -   return ERR_PTR(-ENOMEM);
> > +   struct i915_vma *vma;
> >  
> > if (WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
> > return ERR_PTR(-EINVAL);
> > +   vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> > +   if (vma == NULL)
> > +   return ERR_PTR(-ENOMEM);
> >  
> > INIT_LIST_HEAD(&vma->vma_link);
> > INIT_LIST_HEAD(&vma->mm_list);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: Return current vblank value for drmWaitVBlank queries

[Chris Wilson]

On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote:
> drm_vblank_count_and_time() doesn't return the correct sequence number
> while the vblank interrupt is disabled, does it? It returns the sequence
> number from the last time vblank_disable_and_save() was called (when the
> vblank interrupt was disabled). That's why drm_vblank_get() is needed here.

Ville enlightened me as well. I thought the value was cooked so that
time did not pass whilst the IRQ was disabled. Hopefully, I can impress
upon the Intel folks, at least, that enabling/disabling the interrupts
just to read the current hw counter is interesting to say the least and
sits at the top of the profiles when benchmarking Present.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v2] drm/i915: gen4: work around hang during hibernation

[Paul Bolle]

Imre Deak schreef op ma 02-03-2015 om 13:04 [+0200]:
> Bjørn reported that his machine hang during hibernation and eventually
> bisected the problem to the following commit:
> 
> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> Author: Imre Deak 
> Date:   Thu Oct 23 19:23:26 2014 +0300
> 
> drm/i915: add poweroff_late handler
> 
> The problem seems to be that after the kernel puts the device into D3
> the BIOS still tries to access it, or otherwise assumes that it's in D0.
> This is clearly bogus, since ACPI mandates that devices are put into D3
> by the OSPM if they are not wake-up sources. In the future we want to
> unify more of the driver's runtime and system suspend paths, for example
> by skipping all the system suspend/hibernation hooks if the device is
> runtime suspended already. Accordingly for all other platforms the goal
> is still to properly power down the device during hibernation.
> 
> v2:
> - Another GEN4 Lenovo laptop had the same issue, while platforms from
>   other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
>   to work fine. Based on this apply the workaround on all GEN4 Lenovo
>   platforms.
> - add code comment about failing platforms (Ville)

The outdated ThinkPad X41 that I torture by running rc's showed
identical symptoms, also since v3.19-rc1. It uses a gen3 chipset (it has
a 915GM, I think, but I keep forgetting details like that).

I did everything wrong to get this fixed (1: hope this gets magically
fixed; 2: bisect it myself, thinking every now and then that I know
better than git bisect which commit to choose; 3: finally grep lkml). So
here I am late to the show.

> Reference: 
> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
> Reported-and-bisected-by: Bjørn Mork 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 30 +-
>  1 file changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4badb23..ff3662f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -637,7 +637,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>   return 0;
>  }
>  
> -static int i915_drm_suspend_late(struct drm_device *drm_dev)
> +static int i915_drm_suspend_late(struct drm_device *drm_dev, bool 
> hibernation)
>  {
>   struct drm_i915_private *dev_priv = drm_dev->dev_private;
>   int ret;
> @@ -651,7 +651,17 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev)
>   }
>  
>   pci_disable_device(drm_dev->pdev);
> - pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> + /*
> +  * During hibernation on some GEN4 platforms the BIOS may try to access
> +  * the device even though it's already in D3 and hang the machine. So
> +  * leave the device in D0 on those platforms and hope the BIOS will
> +  * power down the device properly. Platforms where this was seen:
> +  * Lenovo Thinkpad X301, X61s
> +  */
> + if (!(hibernation &&
> +   drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> +   INTEL_INFO(dev_priv)->gen == 4))
> + pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>  
>   return 0;
>  }

I'll paste a DRAFT patch that fixes this for that X41 at the end of the
message. The patch is rather ugly. Should we perhaps try a quirk table
or something like that?


Paul Bolle

>8
Subject: [PATCH] drm/i915: work around hang during hibernation on gen3 too

Commit ab3be73fa7b4 ("drm/i915: gen4: work around hang during
hibernation") was targetted at gen4 platforms shipped by Lenovo. The
same problem can also be seen on a Lenovo ThinkPad X41. Expand the test
to catch that system too.

Sadly, this system still uses IBM's subsystem vendor id. So we end up
with a rather unpleasant test. Use the IS_GEN3() and IS_GEN4() macros to
lessen the pain a bit.

Not-yet-signed-off-by: Paul Bolle 
---
 drivers/gpu/drm/i915/i915_drv.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc6ea53d2b81..3a07164f5860 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
 * the device even though it's already in D3 and hang the machine. So
 * leave the device in D0 on those platforms and hope the BIOS will
 * power down the device properly. Platforms where this was seen:
-* Lenovo Thinkpad X301, X61s
+* Lenovo Thinkpad X301, X61s, X41
 */
if (!(hibernation &&
- drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
- INTEL_INFO(dev_priv)->gen == 4))
+ (drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO ||
+  drm_dev->pdev->subsystem_vendor == PCI_SUBVENDOR_ID_IBM)

[PATCH v2 4/6] drm/exynos: dsi: add support for Exynos5433 SoC

[Daniel Stone]

Hi,

On 18 March 2015 at 08:16, Hyungwon Hwang  wrote:
> +#define REG(dsi, reg)  ((dsi)->reg_base + dsi->driver_data->regs[(reg)])

This seems like a good change in general, but please split it up: it
makes bisection much easier if you have one patch which adds no
functionality and should have exactly the same behaviour, and then
another patch which introduces your changes.

> @@ -431,15 +579,11 @@ static unsigned long exynos_dsi_set_pll(struct 
> exynos_dsi *dsi,
> u16 m;
> u32 reg;
>
> -   clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
> -
> -   fin = clk_get_rate(dsi->pll_clk);
> -   if (!fin) {
> -   dev_err(dsi->dev, "failed to get PLL clock frequency\n");
> -   return 0;
> -   }
> -
> -   dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
> +   /*
> +* The input PLL clock for MIPI DSI in Exynos5433 seems to be fixed
> +* by OSC CLK.
> +*/
> +   fin = 24 * MHZ;

Er, is this always true on other platforms as well? Shouldn't this be
a part of the DeviceTree description?

> @@ -509,7 +656,7 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
> dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu, esc_clk = %lu\n",
> hs_clk, byte_clk, esc_clk);
>
> -   reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
> +   reg = readl(REG(dsi, DSIM_CLKCTRL_REG));

Instead of this readl(REG()) pattern you have everywhere, maybe it
would be easier to introduce a dsi_read_reg(dsi, reg_enum_value)
helper, and the same for write_reg.

> @@ -1720,18 +1873,16 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
> return -EPROBE_DEFER;
> }
>
> -   dsi->pll_clk = devm_clk_get(dev, "pll_clk");
> -   if (IS_ERR(dsi->pll_clk)) {
> -   dev_info(dev, "failed to get dsi pll input clock\n");
> -   ret = PTR_ERR(dsi->pll_clk);
> -   goto err_del_component;
> -   }
> -
> -   dsi->bus_clk = devm_clk_get(dev, "bus_clk");
> -   if (IS_ERR(dsi->bus_clk)) {
> -   dev_info(dev, "failed to get dsi bus clock\n");
> -   ret = PTR_ERR(dsi->bus_clk);
> -   goto err_del_component;
> +   dsi->clks = devm_kzalloc(dev,
> +   sizeof(*dsi->clks) * 
> dsi->driver_data->num_clks,
> +   GFP_KERNEL);
> +   for (i = 0; i < dsi->driver_data->num_clks; i++) {
> +   dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
> +   if (IS_ERR(dsi->clks[i])) {
> +   dev_info(dev, "failed to get dsi pll input clock\n");

This error message seems wrong; it should contain the name of the
actual failing clock.

Cheers,
Daniel

[PATCH] drm: sti: convert driver to atomic modeset

[Daniel Vetter]

On Wed, Mar 11, 2015 at 03:25:18PM +0100, Benjamin Gaignard wrote:
> This patch does the minimum to make sti driver use atomic helpers.
> No big bang, only adapt some functions to new call order.
> 
> Later it will allow to clean the mess around sti_mixer_* functions
> which are use either in plane and crtc.
> 
> Signed-off-by: Benjamin Gaignard 

Seems to be incomplete - you don't switch over the legacy entry points to
atomic helpers for plane update/disable, connector->dpms and page_flip.
-Daniel

> ---
>  drivers/gpu/drm/sti/sti_compositor.c |  3 --
>  drivers/gpu/drm/sti/sti_drm_crtc.c   | 85 
> ++--
>  drivers/gpu/drm/sti/sti_drm_drv.c|  5 +++
>  drivers/gpu/drm/sti/sti_drm_plane.c  | 45 +--
>  drivers/gpu/drm/sti/sti_dvo.c|  4 ++
>  drivers/gpu/drm/sti/sti_hda.c|  4 ++
>  drivers/gpu/drm/sti/sti_hdmi.c   |  4 ++
>  7 files changed, 92 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
> b/drivers/gpu/drm/sti/sti_compositor.c
> index 43215d3..9b2cc40 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.c
> +++ b/drivers/gpu/drm/sti/sti_compositor.c
> @@ -104,9 +104,6 @@ static int sti_compositor_bind(struct device *dev, struct 
> device *master,
>   enum sti_layer_type type = desc & STI_LAYER_TYPE_MASK;
>   enum drm_plane_type plane_type = DRM_PLANE_TYPE_OVERLAY;
>  
> - if (crtc < compo->nb_mixers)
> - plane_type = DRM_PLANE_TYPE_PRIMARY;
> -
>   switch (type) {
>   case STI_CUR:
>   cursor = sti_drm_plane_init(drm_dev,
> diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c 
> b/drivers/gpu/drm/sti/sti_drm_crtc.c
> index e6f6ef7..67a175b 100644
> --- a/drivers/gpu/drm/sti/sti_drm_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_drm_crtc.c
> @@ -9,6 +9,8 @@
>  #include 
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -77,22 +79,18 @@ static bool sti_drm_crtc_mode_fixup(struct drm_crtc *crtc,
>  }
>  
>  static int
> -sti_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode, int x, int y,
> -   struct drm_framebuffer *old_fb)
> +sti_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode)
>  {
>   struct sti_mixer *mixer = to_sti_mixer(crtc);
>   struct device *dev = mixer->dev;
>   struct sti_compositor *compo = dev_get_drvdata(dev);
> - struct sti_layer *layer;
>   struct clk *clk;
>   int rate = mode->clock * 1000;
>   int res;
> - unsigned int w, h;
>  
> - DRM_DEBUG_KMS("CRTC:%d (%s) fb:%d mode:%d (%s)\n",
> + DRM_DEBUG_KMS("CRTC:%d (%s) mode:%d (%s)\n",
> crtc->base.id, sti_mixer_to_str(mixer),
> -   crtc->primary->fb->base.id, mode->base.id, mode->name);
> +   mode->base.id, mode->name);
>  
>   DRM_DEBUG_KMS("%d %d %d %d %d %d %d %d %d %d 0x%x 0x%x\n",
> mode->vrefresh, mode->clock,
> @@ -122,35 +120,13 @@ sti_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
>   sti_vtg_set_config(mixer->id == STI_MIXER_MAIN ?
>   compo->vtg_main : compo->vtg_aux, &crtc->mode);
>  
> - /* a GDP is reserved to the CRTC FB */
> - layer = to_sti_layer(crtc->primary);
> - if (!layer) {
> - DRM_ERROR("Can not find GDP0)\n");
> - return -EINVAL;
> - }
> -
> - /* copy the mode data adjusted by mode_fixup() into crtc->mode
> -  * so that hardware can be set to proper mode
> -  */
> - memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
> -
> - res = sti_mixer_set_layer_depth(mixer, layer);
> - if (res) {
> - DRM_ERROR("Can not set layer depth\n");
> - return -EINVAL;
> - }
>   res = sti_mixer_active_video_area(mixer, &crtc->mode);
>   if (res) {
>   DRM_ERROR("Can not set active video area\n");
>   return -EINVAL;
>   }
>  
> - w = crtc->primary->fb->width - x;
> - h = crtc->primary->fb->height - y;
> -
> - return sti_layer_prepare(layer, crtc,
> - crtc->primary->fb, &crtc->mode,
> - mixer->id, 0, 0, w, h, x, y, w, h);
> + return res;
>  }
>  
>  static int sti_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> @@ -195,7 +171,6 @@ static void sti_drm_crtc_disable(struct drm_crtc *crtc)
>   struct sti_mixer *mixer = to_sti_mixer(crtc);
>   struct device *dev = mixer->dev;
>   struct sti_compositor *compo = dev_get_drvdata(dev);
> - struct sti_layer *layer;
>  
>   if (!mixer->enabled)
>   return;
> @@ -205,24 +180,6 @@ static void sti_drm_crtc_disable(struct drm_crtc *crtc)
>   /* Disable Background */
>   sti_mixer_set_background_status(mi

[PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x

[Jyri Sarha]

I think the patches 1-5 are ready for merging. See the details below.

I moved the "drm/tilcdc: Decrement refcount of ep-node from
of_graph_get_next_endpoint" to last in the set and I think it can be
dropped. The "of: Decrement refcount of previous endpoint in
of_graph_get_next_endpoint" is eventually going to be merged and
before that leaking of two of-node refcount increments each time the
module is loaded is not that serious. The of-nodes live forever anyway.

The merge of the dts patch can be delayed until the next merger
window. The DRM_TILCDC_SLAVE_COMPAT should keep the bbb HDMI
operational until then.

Changes since v2 version of the patch-set:
- use obj-y in Makefle for tilcdc subdir in:
  "drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT"
- move to last:
  "drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint"

Changes since first version of the patch-set:
- Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
- Add separate: 
  drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
- Reduce info-level spam
- Use component_master_add_with_match()
- Be more explicit about tda998x being the only supported external encoder

Remove tilcdc slave support and connect to tda998x trough its
component DRM API. For dtb backward compatibility the code creates at
boot time a DT overlay based on the earlier binding. The overlay
conforms to the new graph based binding.

The first patch is just a bugfix and can be applied or dropped
independently.

Jyri Sarha (7):
  drm/tilcdc: Fix module unloading
  drm/tilcdc: Remove tilcdc slave support for tda998x driver
  drm/tilcdc: Add support for external tda998x encoder
  drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
support
  drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
  ARM: dts: am335x-boneblack: Use new binding for HDMI
  drm/tilcdc: Decrement refcount of ep-node from
of_graph_get_next_endpoint

 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 arch/arm/boot/dts/am335x-boneblack.dts |  20 +-
 drivers/gpu/drm/Makefile   |   2 +-
 drivers/gpu/drm/tilcdc/Kconfig |  13 +
 drivers/gpu/drm/tilcdc/Makefile|   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  36 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  89 +++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 105 ++
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 270 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 
 15 files changed, 633 insertions(+), 490 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts

-- 
1.9.1

[PATCH v3 6/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Jyri Sarha]

Use new binding for the external tda19988 HDMI encoder.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@

 &lcdc {
status = "okay";
+   port {
+   lcdc_0: endpoint at 0 {
+   remote-endpoint = <&hdmi_0>;
+   };
+   };
 };

-/ {
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <&i2c0>;
+&i2c0 {
+   tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
-   status = "okay";
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <&lcdc_0>;
+   };
+   };
};
 };

-- 
1.9.1

[PATCH v3 7/7] drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint

[Jyri Sarha]

This patch should be dropped/reverterd if/after "of: Decrement refcount
of previous endpoint in of_graph_get_next_endpoint" patch has been
merged.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 61f8aee..1dd6c20 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -83,6 +83,7 @@ int tilcdc_get_external_components(struct device *dev,
struct device_node *node;

node = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
if (!node && !of_device_is_available(node)) {
of_node_put(node);
continue;
-- 
1.9.1

[PATCH v6 03/12] drm/panel: add support for Samsung LTN140AT29 panel

[Tomeu Vizoso]

From: Stéphane Marchesin 

This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.

Signed-off-by: Stéphane Marchesin 
[tomeu.vizoso at collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso 
Acked-by: Stephen Warren 
Reviewed-by: Alexandre Courbot 
---
 .../bindings/panel/samsung,ltn140at29-301.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt 
b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
new file mode 100644
index 000..e7f969d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
@@ -0,0 +1,7 @@
+Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
+
+Required properties:
+- compatible: should be "samsung,ltn140at29-301"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 39806c3..2da2285 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -779,6 +779,29 @@ static const struct panel_desc samsung_ltn101nt05 = {
},
 };

+static const struct drm_display_mode samsung_ltn140at29_301_mode = {
+   .clock = 76300,
+   .hdisplay = 1366,
+   .hsync_start = 1366 + 64,
+   .hsync_end = 1366 + 64 + 48,
+   .htotal = 1366 + 64 + 48 + 128,
+   .vdisplay = 768,
+   .vsync_start = 768 + 2,
+   .vsync_end = 768 + 2 + 5,
+   .vtotal = 768 + 2 + 5 + 17,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc samsung_ltn140at29_301 = {
+   .modes = &samsung_ltn140at29_301_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 320,
+   .height = 187,
+   },
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "auo,b101aw03",
@@ -841,6 +864,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "samsung,ltn101nt05",
.data = &samsung_ltn101nt05,
}, {
+   .compatible = "samsung,ltn140at29-301",
+   .data = &samsung_ltn140at29_301,
+   }, {
/* sentinel */
}
 };
-- 
2.1.0

[PATCH v3 3/7] drm/tilcdc: Add support for external tda998x encoder

[Jyri Sarha]

Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The current
implementation supports only tda998x encoder.

I got the idea and some lines of code from Jean-Francois Moine's
"drm/tilcdc: Change the interface with the tda998x driver"-patch.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 drivers/gpu/drm/tilcdc/Makefile|   1 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  33 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  76 ---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   4 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 104 +
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 +
 7 files changed, 256 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.

+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+   binding follows Documentation/devicetree/bindings/graph.txt and
+   suppors a single port with a single endpoint.
+
 Example:

fb: fb at 4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
+
+   port {
+   lcdc_0: endpoint at 0 {
+   remote-endpoint = <&hdmi_0>;
+   };
+   };
+   };
+
+   tda19988: tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+
+   pinctrl-names = "default", "off";
+   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+   pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <&lcdc_0>;
+   };
+   };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+   tilcdc_external.o \
tilcdc_drv.o

 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {

/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+   /* Only set if an external encoder is connected */
+   bool simulate_vesa_sync;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   if (!tilcdc_crtc->simulate_vesa_sync)
+   return true;
+
+   /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+   adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+   adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+   adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+   } else {
+   adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+   }
+
return true;
 }

@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc->info = info;
 }

+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+   bool simulate_vesa_sync)
+{
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   tilcdc_crtc->simulate_vesa_sync = simulate_vesa_sync;
+}
+
 void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
diff --git a/driver

[PATCH v3 1/7] drm/tilcdc: Fix module unloading

[Jyri Sarha]

Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
 }

+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);

-   WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
+   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);

drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
-- 
1.9.1

[PATCH v3 2/7] drm/tilcdc: Remove tilcdc slave support for tda998x driver

[Jyri Sarha]

Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 drivers/gpu/drm/tilcdc/Makefile|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  13 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 6 files changed, 470 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
-   muxing properly for pins that connect to TFP410 device
-
-Example:
-
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <&i2c0>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
-   };
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
-   tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 095fca9..0f1e099 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,13 +20,11 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
 #include "tilcdc_panel.h"

 #include "drm_fb_helper.h"

 static LIST_HEAD(module_list);
-static bool slave_probing;

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(&mod->list);
 }

-void tilcdc_slave_probedefer(bool defered)
-{
-   slave_probing = defered;
-}
-
 static struct of_device_id tilcdc_of_match[];

 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}

-   /* defer probing if slave is in deferred probing */
-   if (slave_probing == true)
-   return -EPROBE_DEFER;
-
return drm_platform_init(&tilcdc_driver, pdev);
 }

@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
 {
DBG("init");
tilcdc_tfp410_init();
-   tilcdc_slave_init();
tilcdc_panel_init();
return platform_driver_register(&tilcdc_platform_driver);
 }
@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
DBG("fini");
platform_driver_unregister(&tilcdc_platform_driver);
tilcdc_panel_fini();
-   tilcdc_slave_fini();
tilcdc_tfp410_fini();
 }

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7596c14..6336512 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);

 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
deleted file mode 100644
index 3775fd4..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ /dev/null
@@ -1,411 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark 
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have r

[PATCH v3 4/7] drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti, tilcdc, slave binding support

[Jyri Sarha]

Adds a CONFIG_DRM_TILCDC_SLAVE_COMPAT module for "ti,tilcdc,slave"
node conversion. The implementation is in tilcdc_slave_compat.c and it
uses tilcdc_slave_compat.dts as a basis for creating a DTS
overlay. The DTS overlay adds an external tda998x encoder to tilcdc
that corresponds to the old tda998x based slave encoder.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/Kconfig |  13 ++
 drivers/gpu/drm/tilcdc/Makefile|   3 +
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 270 +
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 +++
 4 files changed, 358 insertions(+)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 8394a0b..7e1e72b 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,3 +1,15 @@
+config DRM_TILCDC_SLAVE_COMPAT
+   bool "Support device tree blobs using TI LCDC Slave binding"
+   depends on DRM_TILCDC
+   default y
+   select OF_RESOLVE
+   select OF_OVERLAY
+   help
+ Choose this option if you need a kernel that is compatible
+ with device tree blobs using the obsolete "ti,tilcdc,slave"
+ binding. If you find "ti,tilcdc,slave"-string from your DTB,
+ you probably need this. Otherwise you do not.
+
 config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM && HAVE_DMA_ATTRS
@@ -8,6 +20,7 @@ config DRM_TILCDC
select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
select BACKLIGHT_LCD_SUPPORT
+   select DRM_TILCDC_INIT
help
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index e1f738b..deeca48 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,9 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
 endif

+obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \
+tilcdc_slave_compat.dtb.o
+
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
new file mode 100644
index 000..cc9572d
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha 
+ *
+ * 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.
+ *
+ */
+
+/*
+ * To support the old "ti,tilcdc,slave" binding the binding has to be
+ * transformed to the new external encoder binding.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct kfree_table {
+   int total;
+   int num;
+   void **table;
+};
+
+static int __init kfree_table_init(struct kfree_table *kft)
+{
+   kft->total = 32;
+   kft->num = 0;
+   kft->table = kmalloc(kft->total * sizeof(*kft->table),
+GFP_KERNEL);
+   if (!kft->table)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static int __init kfree_table_add(struct kfree_table *kft, void *p)
+{
+   if (kft->num == kft->total) {
+   void **old = kft->table;
+
+   kft->total *= 2;
+   kft->table = krealloc(old, kft->total * sizeof(*kft->table),
+ GFP_KERNEL);
+   if (!kft->table) {
+   kft->table = old;
+   kfree(p);
+   return -ENOMEM;
+   }
+   }
+   kft->table[kft->num++] = p;
+   return 0;
+}
+
+static void __init kfree_table_free(struct kfree_table *kft)
+{
+   int i;
+
+   for (i = 0; i < kft->num; i++)
+   kfree(kft->table[i]);
+
+   kfree(kft->table);
+}
+
+static
+struct property * __init tilcdc_prop_dup(const struct property *prop,
+struct kfree_table *kft)
+{
+   struct property *nprop;
+
+   nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
+   if (!nprop || kfree_table_add(kft, nprop))
+   return NULL;
+
+   nprop->name = kstrdup(prop->name, GFP_KERNEL);
+   if (!nprop->name || kfree_table_add(kft, nprop->name))
+   return NULL;
+
+   nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL);
+   if (!nprop->value || kfree_table_add(kft, nprop->value))
+   return NULL;
+
+   nprop->length = prop->length;
+
+   return nprop;
+}
+
+static void __init tilcdc_copy_props(struct device_node *from,

[PATCH v3 5/7] drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT

[Jyri Sarha]

If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is
built as module.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..c93ca0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -59,7 +59,7 @@ obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
-obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
+obj-y  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/
-- 
1.9.1

[PATCH v6 00/12] Improvements to Tegra-based Chromebook support

[Tomeu Vizoso]

v6: * Added Acked-by and Reviewed-By tags
* Rebased on top of 4.0-rc1
* Added patch that marks the WiFi card as powered during suspend

v5: * Moved to use gpio-restart for reboots, had to make tegra_pmc_restart
a notification handler

v4: * Added support for the system reset GPIO, for proper reboots
* Moved out changes to ASOC to their own series, as requested by Mark
Brown
* Added patch to reset the SOR, to make sure it's in a known state
* Changed nvidia,model property of the sound nodes to GoogleNyanBig
and GoogleNyanBlaze so they can be told apart in userspace

v3: * Added bindings for the LTN140AT29 panel
* Removed the delay in pwrseq, as what was actually needed was to add
a dependency on the power supplies of the host
* Uses the pinmux for the Blaze as generated by tegra-pinmux-scripts
* Uses the pinmux for the Big as in the last patch from Simon Glass

Hello,

this series adds support for the Tegra-based HP Chromebook 14 (aka nyan
blaze), which is very similar to the Acer Chromebook 13 (aka nyan big).
Because they both include tegra124-nyan.dtsi, some improvements to Blaze
support have also benefitted the Big. I have tested that USB2, the panels,
HDMI, the trackpad, Wifi and sound work on both.

The leaf DTs contain the whole pinmux configuration as generated by
tegra-pinmux-scripts. I chose to not put the common configuration in the
common dtsi so we can paste the output as is and be sure that the kernel
doesn't diverge from the canonical data.

These patches are based on top of 4.0-rc1.

http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=nyan-v6

Regards,

Tomeu

David Riley (1):
  soc/tegra: pmc: move to using a restart handler

Stéphane Marchesin (1):
  drm/panel: add support for Samsung LTN140AT29 panel

Tomeu Vizoso (10):
  ARM: tegra: Change model of sound card in Nyan Big
  ARM: tegra: Move out nyan-generic parts out from the nyan-big DT
  ARM: tegra: Add DTS for the nyan-blaze board
  ARM: tegra: Add node for trackpad in Nyan boards
  ARM: tegra: Use pwrseq-simple for the wifi in Nyan
  ARM: tegra: Use the generated pinmux data
  ARM: tegra: Set spi-max-frequency property to flash node
  drm/tegra: Reset the SOR on probe
  ARM: tegra: Add gpio-restart node
  ARM: tegra: The WiFi card is kept powered during suspend

 .../bindings/panel/samsung,ltn140at29-301.txt  |7 +
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/tegra124-nyan-big.dts| 2119 +++-
 arch/arm/boot/dts/tegra124-nyan-blaze.dts  | 1332 
 arch/arm/boot/dts/tegra124-nyan.dtsi   |  695 +++
 arch/arm/mach-tegra/tegra.c|1 -
 drivers/gpu/drm/panel/panel-simple.c   |   26 +
 drivers/gpu/drm/tegra/sor.c|   14 +
 drivers/soc/tegra/pmc.c|   31 +-
 9 files changed, 3254 insertions(+), 972 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt
 create mode 100644 arch/arm/boot/dts/tegra124-nyan-blaze.dts
 create mode 100644 arch/arm/boot/dts/tegra124-nyan.dtsi

-- 
2.1.0

[PATCH v6 09/12] drm/tegra: Reset the SOR on probe

[Tomeu Vizoso]

As there isn't a way for the firmware on the Nyan chromebooks to hand
over the display to the kernel.

Signed-off-by: Tomeu Vizoso 
Acked-by: Stephen Warren 
Reviewed-by: Alexandre Courbot 
---
 drivers/gpu/drm/tegra/sor.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 2afe478..e6caacc 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1458,6 +1458,20 @@ static int tegra_sor_probe(struct platform_device *pdev)

mutex_init(&sor->lock);

+   err = reset_control_assert(sor->rst);
+   if (err < 0) {
+   dev_err(&pdev->dev, "failed to assert SOR reset: %d\n", err);
+   return err;
+   }
+
+   msleep(20);
+
+   err = reset_control_deassert(sor->rst);
+   if (err < 0) {
+   dev_err(&pdev->dev, "failed to deassert SOR reset: %d\n", err);
+   return err;
+   }
+
err = host1x_client_register(&sor->client);
if (err < 0) {
dev_err(&pdev->dev, "failed to register host1x client: %d\n",
-- 
2.1.0

[GIT PULL] drm: sti: convert driver to atomic modeset

[Daniel Vetter]

On Wed, Mar 18, 2015 at 09:33:25AM +0100, Benjamin Gaignard wrote:
> Hello Dave,
> 
> Can I ask you to mmerge this pull request into drm-next ?
> 
> The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:
> 
>   Merge tag 'topic/drm-misc-2015-03-10' of
> git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11
> 12:15:06 +1000)
> 
> are available in the git repository at:
> 
> 
>   http://git.linaro.org/people/benjamin.gaignard/kernel.git drm-st-next-atomic
> 
> for you to fetch changes up to 7995bbee3f00a4a6ce6a01d4de404e5b896773df:
> 
>   drm: sti: convert driver to atomic modeset (2015-03-17 11:22:14 +0100)

Took a quick look at this, seemed like a fairly incomplete conversion ...
-Daniel

> 
> 
> Benjamin Gaignard (1):
>   drm: sti: convert driver to atomic modeset
> 
>  drivers/gpu/drm/sti/sti_drm_crtc.c  | 85 
> ++---
>  drivers/gpu/drm/sti/sti_drm_drv.c   |  5 +++
>  drivers/gpu/drm/sti/sti_drm_plane.c | 45 ++--
>  drivers/gpu/drm/sti/sti_dvo.c   |  4 ++
>  drivers/gpu/drm/sti/sti_hda.c   |  4 ++
>  drivers/gpu/drm/sti/sti_hdmi.c  |  4 ++
>  6 files changed, 92 insertions(+), 55 deletions(-)
> 
> Regards,
> Benjamin
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Another drm-misch pull request. Mostly the fbdev sizes deconfusion series
from Rob, everything else is small stuff all over. And the large i2c over
aux transfers patch, too.

Cheers, Daniel


The following changes since commit 7eb5f302bbe78b88da8b2008c502c1975e75db05:

  drm: Check in setcrtc if the primary plane supports the fb pixel format 
(2015-03-10 09:59:36 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-03-18

for you to fetch changes up to 522cf91f30cb0102fd5cb6e8979d45b6151cdcfc:

  drm: check that planes types are correct while initializing CRTC (2015-03-17 
14:03:04 +0100)


Benjamin Gaignard (1):
  drm: check that planes types are correct while initializing CRTC

Daniel Vetter (1):
  drm/plane-helper: Fixup mismerge

John Hunter (2):
  drm: Fix some typo mistake of the annotations
  drm: change connector to tmp_connector

Rob Clark (7):
  drm/fb: document drm_fb_helper_surface_size
  drm/atomic: minor kerneldoc typo fix
  drm/cma: use correct fb width/height
  drm/exynos: use correct fb width/height
  drm/rockchip: use correct fb width/height
  drm/fb: small cleanup
  drm/fb: handle tiled connectors better

Scott Wood (1):
  drm: %pF is only for function pointers

Simon Farnsworth (1):
  drm/dp: Use large transactions for I2C over AUX

Ville Syrjälä (2):
  drm/atomic: Constify a bunch of functions pointer structs
  drm: Silence sparse warnings

 drivers/gpu/drm/drm_atomic_helper.c   | 50 +-
 drivers/gpu/drm/drm_bridge.c  |  2 +-
 drivers/gpu/drm/drm_crtc.c|  3 ++
 drivers/gpu/drm/drm_dp_helper.c   | 76 ---
 drivers/gpu/drm/drm_drv.c |  2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c   |  2 +-
 drivers/gpu/drm/drm_fb_helper.c   | 48 -
 drivers/gpu/drm/drm_info.c|  1 +
 drivers/gpu/drm/drm_ioc32.c   |  2 +-
 drivers/gpu/drm/drm_pci.c |  1 +
 drivers/gpu/drm/drm_plane_helper.c| 11 ++--
 drivers/gpu/drm/drm_vm.c  |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  5 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  2 +-
 include/drm/drm_crtc.h|  2 +-
 include/drm/drm_dp_helper.h   |  5 ++
 include/drm/drm_fb_helper.h   | 19 +++
 17 files changed, 163 insertions(+), 69 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH libdrm] autotools: remove ${srcdir} from the includes

[Emil Velikov]

On 17/03/15 23:17, Emil Velikov wrote:
> Already implicitly handled by the compiler.
> 
s/compiler/build system/

> Signed-off-by: Emil Velikov 
> ---
> Inspired while cleaning up the very same includes in the Android build.
> 
> -Emil
> 
>  exynos/Makefile.am| 1 -
>  freedreno/Makefile.am | 1 -
>  intel/Makefile.am | 1 -
>  nouveau/Makefile.am   | 1 -
>  omap/Makefile.am  | 1 -
>  radeon/Makefile.am| 1 -
>  6 files changed, 6 deletions(-)
> 
> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
> index 35bc71f..a9da0ff 100644
> --- a/exynos/Makefile.am
> +++ b/exynos/Makefile.am
> @@ -2,7 +2,6 @@ AM_CFLAGS = \
>   $(WARN_CFLAGS) \
>   $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
> - -I$(top_srcdir)/exynos \
>   $(PTHREADSTUBS_CFLAGS) \
>   -I$(top_srcdir)/include/drm
>  
> diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
> index 4482afe..407ab70 100644
> --- a/freedreno/Makefile.am
> +++ b/freedreno/Makefile.am
> @@ -5,7 +5,6 @@ AM_CFLAGS = \
>   $(WARN_CFLAGS) \
>   $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
> - -I$(top_srcdir)/freedreno \
>   $(PTHREADSTUBS_CFLAGS) \
>   -I$(top_srcdir)/include/drm
>  
> diff --git a/intel/Makefile.am b/intel/Makefile.am
> index ca4ed84..22a45f0 100644
> --- a/intel/Makefile.am
> +++ b/intel/Makefile.am
> @@ -28,7 +28,6 @@ AM_CFLAGS = \
>   $(WARN_CFLAGS) \
>   $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
> - -I$(top_srcdir)/intel \
>   $(PTHREADSTUBS_CFLAGS) \
>   $(PCIACCESS_CFLAGS) \
>   $(VALGRIND_CFLAGS) \
> diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
> index 7543e43..1ca235d 100644
> --- a/nouveau/Makefile.am
> +++ b/nouveau/Makefile.am
> @@ -4,7 +4,6 @@ AM_CFLAGS = \
>   $(WARN_CFLAGS) \
>   $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
> - -I$(top_srcdir)/nouveau \
>   $(PTHREADSTUBS_CFLAGS) \
>   -I$(top_srcdir)/include/drm \
>   -DDEBUG
> diff --git a/omap/Makefile.am b/omap/Makefile.am
> index 0778bdd..d6f5298 100644
> --- a/omap/Makefile.am
> +++ b/omap/Makefile.am
> @@ -2,7 +2,6 @@ AM_CFLAGS = \
>   $(WARN_CFLAGS) \
>   $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
> - -I$(top_srcdir)/omap \
>   $(PTHREADSTUBS_CFLAGS) \
>   -I$(top_srcdir)/include/drm
>  
> diff --git a/radeon/Makefile.am b/radeon/Makefile.am
> index 4575065..5cca394 100644
> --- a/radeon/Makefile.am
> +++ b/radeon/Makefile.am
> @@ -28,7 +28,6 @@ AM_CFLAGS = \
>   $(WARN_CFLAGS) \
>   $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
> - -I$(top_srcdir)/radeon \
>   $(PTHREADSTUBS_CFLAGS) \
>   -I$(top_srcdir)/include/drm
>  
> 

[PATCH libdrm 3/5] android: remove ${srcdir} from the includes

[Emil Velikov]

On 18/03/15 01:49, Chih-Wei Huang wrote:
> 2015年3月18日 上午7:30 於 "Emil Velikov"  > 寫道：
>>
>> Already implicitly handled by the compiler.
> 
> Actually it's not handled by the compiler, but by the Android build
> system. It automatically adds  $(LOCAL_PATH), $(intermediate), ... to
> the include paths.
> 
Indeed. Same goes for the Automake build. Unless there are bigger fish
to fry, will update it before pushing.

Thanks for spotting this thinko.
Emil

[PATCH v2] drm/i915: gen4: work around hang during hibernation

[Ville Syrjälä]

On Wed, Mar 18, 2015 at 10:37:16AM +0100, Paul Bolle wrote:
> Imre Deak schreef op ma 02-03-2015 om 13:04 [+0200]:
> > Bjørn reported that his machine hang during hibernation and eventually
> > bisected the problem to the following commit:
> > 
> > commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> > Author: Imre Deak 
> > Date:   Thu Oct 23 19:23:26 2014 +0300
> > 
> > drm/i915: add poweroff_late handler
> > 
> > The problem seems to be that after the kernel puts the device into D3
> > the BIOS still tries to access it, or otherwise assumes that it's in D0.
> > This is clearly bogus, since ACPI mandates that devices are put into D3
> > by the OSPM if they are not wake-up sources. In the future we want to
> > unify more of the driver's runtime and system suspend paths, for example
> > by skipping all the system suspend/hibernation hooks if the device is
> > runtime suspended already. Accordingly for all other platforms the goal
> > is still to properly power down the device during hibernation.
> > 
> > v2:
> > - Another GEN4 Lenovo laptop had the same issue, while platforms from
> >   other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
> >   to work fine. Based on this apply the workaround on all GEN4 Lenovo
> >   platforms.
> > - add code comment about failing platforms (Ville)
> 
> The outdated ThinkPad X41 that I torture by running rc's showed
> identical symptoms, also since v3.19-rc1. It uses a gen3 chipset (it has
> a 915GM, I think, but I keep forgetting details like that).
> 
> I did everything wrong to get this fixed (1: hope this gets magically
> fixed; 2: bisect it myself, thinking every now and then that I know
> better than git bisect which commit to choose; 3: finally grep lkml). So
> here I am late to the show.
> 
> > Reference: 
> > http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
> > Reported-and-bisected-by: Bjørn Mork 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 30 +-
> >  1 file changed, 25 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 4badb23..ff3662f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -637,7 +637,7 @@ static int i915_drm_suspend(struct drm_device *dev)
> > return 0;
> >  }
> >  
> > -static int i915_drm_suspend_late(struct drm_device *drm_dev)
> > +static int i915_drm_suspend_late(struct drm_device *drm_dev, bool 
> > hibernation)
> >  {
> > struct drm_i915_private *dev_priv = drm_dev->dev_private;
> > int ret;
> > @@ -651,7 +651,17 @@ static int i915_drm_suspend_late(struct drm_device 
> > *drm_dev)
> > }
> >  
> > pci_disable_device(drm_dev->pdev);
> > -   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> > +   /*
> > +* During hibernation on some GEN4 platforms the BIOS may try to access
> > +* the device even though it's already in D3 and hang the machine. So
> > +* leave the device in D0 on those platforms and hope the BIOS will
> > +* power down the device properly. Platforms where this was seen:
> > +* Lenovo Thinkpad X301, X61s
> > +*/
> > +   if (!(hibernation &&
> > + drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> > + INTEL_INFO(dev_priv)->gen == 4))
> > +   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> >  
> > return 0;
> >  }
> 
> I'll paste a DRAFT patch that fixes this for that X41 at the end of the
> message. The patch is rather ugly. Should we perhaps try a quirk table
> or something like that?
> 
> 
> Paul Bolle
> 
> >8
> Subject: [PATCH] drm/i915: work around hang during hibernation on gen3 too
> 
> Commit ab3be73fa7b4 ("drm/i915: gen4: work around hang during
> hibernation") was targetted at gen4 platforms shipped by Lenovo. The
> same problem can also be seen on a Lenovo ThinkPad X41. Expand the test
> to catch that system too.
> 
> Sadly, this system still uses IBM's subsystem vendor id. So we end up
> with a rather unpleasant test. Use the IS_GEN3() and IS_GEN4() macros to
> lessen the pain a bit.

We had another bug report which showed similar problems on something
as recent as SNB:
https://bugzilla.kernel.org/show_bug.cgi?id=94241
So I guess we really want to make the check 'gen < 7'.

My IVB X1 Carbon doesn't need this quirk, so hopefully that indicates
the Lenovo BIOSen became more sane for gen7+.

> 
> Not-yet-signed-off-by: Paul Bolle 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index cc6ea53d2b81..3a07164f5860 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev, bool hibernation)
>* the device even though it's already in D3 and ha

[PATCH v2 3/5] gpu: ipu-v3: Register scaler platform device

[Philipp Zabel]

This patch registers the scaler device using the IC post-processing task,
to be handled by a mem2mem scaler driver.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 67bab5c..cf89692 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1026,6 +1026,8 @@ static const struct ipu_platform_reg client_reg[] = {
},
.reg_offset = IPU_CM_CSI1_REG_OFS,
.name = "imx-ipuv3-camera",
+   }, {
+   .name = "imx-ipuv3-scaler",
},
 };

-- 
2.1.4

[PATCH v2 1/5] gpu: ipu-v3: Add missing IDMAC channel names

[Philipp Zabel]

This patch adds the remaining missing IDMAC channel names: all VDIC channels
for deinterlacing and combining, the separate alpha channels for the MEM->IC
and MEM->DC ASYNC channels, and the DC read / command / output mask channels.

Signed-off-by: Philipp Zabel 
---
 include/video/imx-ipu-v3.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 73390c1..459508e 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -96,20 +96,34 @@ enum ipu_channel_irq {
 #define IPUV3_CHANNEL_CSI2  2
 #define IPUV3_CHANNEL_CSI3  3
 #define IPUV3_CHANNEL_VDI_MEM_IC_VF 5
+#define IPUV3_CHANNEL_MEM_VDI_PREV  8
+#define IPUV3_CHANNEL_MEM_VDI_CUR   9
+#define IPUV3_CHANNEL_MEM_VDI_NEXT 10
 #define IPUV3_CHANNEL_MEM_IC_PP11
 #define IPUV3_CHANNEL_MEM_IC_PRP_VF12
+#define IPUV3_CHANNEL_VDI_MEM_RECENT   13
 #define IPUV3_CHANNEL_G_MEM_IC_PRP_VF  14
 #define IPUV3_CHANNEL_G_MEM_IC_PP  15
+#define IPUV3_CHANNEL_G_MEM_IC_PRP_VF_ALPHA17
+#define IPUV3_CHANNEL_G_MEM_IC_PP_ALPHA18
+#define IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB_ALPHA19
 #define IPUV3_CHANNEL_IC_PRP_ENC_MEM   20
 #define IPUV3_CHANNEL_IC_PRP_VF_MEM21
 #define IPUV3_CHANNEL_IC_PP_MEM22
 #define IPUV3_CHANNEL_MEM_BG_SYNC  23
 #define IPUV3_CHANNEL_MEM_BG_ASYNC 24
+#define IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB  25
+#define IPUV3_CHANNEL_MEM_VDI_PLANE3_COMB  26
 #define IPUV3_CHANNEL_MEM_FG_SYNC  27
 #define IPUV3_CHANNEL_MEM_DC_SYNC  28
 #define IPUV3_CHANNEL_MEM_FG_ASYNC 29
 #define IPUV3_CHANNEL_MEM_FG_SYNC_ALPHA31
+#define IPUV3_CHANNEL_MEM_FG_ASYNC_ALPHA   33
+#define IPUV3_CHANNEL_DC_MEM_READ  40
 #define IPUV3_CHANNEL_MEM_DC_ASYNC 41
+#define IPUV3_CHANNEL_MEM_DC_COMMAND   42
+#define IPUV3_CHANNEL_MEM_DC_COMMAND2  43
+#define IPUV3_CHANNEL_MEM_DC_OUTPUT_MASK   44
 #define IPUV3_CHANNEL_MEM_ROT_ENC  45
 #define IPUV3_CHANNEL_MEM_ROT_VF   46
 #define IPUV3_CHANNEL_MEM_ROT_PP   47
@@ -117,6 +131,7 @@ enum ipu_channel_irq {
 #define IPUV3_CHANNEL_ROT_VF_MEM   49
 #define IPUV3_CHANNEL_ROT_PP_MEM   50
 #define IPUV3_CHANNEL_MEM_BG_SYNC_ALPHA51
+#define IPUV3_CHANNEL_MEM_BG_ASYNC_ALPHA   52

 int ipu_map_irq(struct ipu_soc *ipu, int irq);
 int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
-- 
2.1.4

[PATCH v2 4/5] [media] imx-ipu: Add ipu media common code

[Philipp Zabel]

From: Sascha Hauer 

Add video4linux API routines common to drivers for units that
accept or provide video data via the i.MX IPU IDMAC channels,
such as scaler or deinterlacer drivers.

Signed-off-by: Sascha Hauer 
Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/Kconfig   |   2 +
 drivers/media/platform/Makefile  |   1 +
 drivers/media/platform/imx/Kconfig   |   2 +
 drivers/media/platform/imx/Makefile  |   1 +
 drivers/media/platform/imx/imx-ipu.c | 313 +++
 drivers/media/platform/imx/imx-ipu.h |  35 
 6 files changed, 354 insertions(+)
 create mode 100644 drivers/media/platform/imx/Kconfig
 create mode 100644 drivers/media/platform/imx/Makefile
 create mode 100644 drivers/media/platform/imx/imx-ipu.c
 create mode 100644 drivers/media/platform/imx/imx-ipu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d9b872b..650a9a6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -29,6 +29,8 @@ config VIDEO_VIA_CAMERA

 source "drivers/media/platform/davinci/Kconfig"

+source "drivers/media/platform/imx/Kconfig"
+
 source "drivers/media/platform/omap/Kconfig"

 source "drivers/media/platform/blackfin/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 3ec1547..2e35581 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_SOC_CAMERA)  += soc_camera/

 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/

+obj-y  += imx/
 obj-y  += omap/

 obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/imx/Kconfig 
b/drivers/media/platform/imx/Kconfig
new file mode 100644
index 000..a90c973
--- /dev/null
+++ b/drivers/media/platform/imx/Kconfig
@@ -0,0 +1,2 @@
+config VIDEO_IMX_IPU_COMMON
+   tristate
diff --git a/drivers/media/platform/imx/Makefile 
b/drivers/media/platform/imx/Makefile
new file mode 100644
index 000..5de119c
--- /dev/null
+++ b/drivers/media/platform/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_IMX_IPU_COMMON) += imx-ipu.o
diff --git a/drivers/media/platform/imx/imx-ipu.c 
b/drivers/media/platform/imx/imx-ipu.c
new file mode 100644
index 000..c1b8637
--- /dev/null
+++ b/drivers/media/platform/imx/imx-ipu.c
@@ -0,0 +1,313 @@
+/*
+ * i.MX IPUv3 common v4l2 support
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-ipu.h"
+
+static struct ipu_fmt ipu_fmt_yuv[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_YUV420,
+   .name = "YUV 4:2:0 planar, YCbCr",
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_YVU420,
+   .name = "YUV 4:2:0 planar, YCrCb",
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_YUV422P,
+   .name = "YUV 4:2:2 planar, YCbCr",
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_NV12,
+   .name = "YUV 4:2:0 partial interleaved, YCbCr",
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_UYVY,
+   .name = "4:2:2, packed, UYVY",
+   .bytes_per_pixel = 2,
+   }, {
+   .fourcc = V4L2_PIX_FMT_YUYV,
+   .name = "4:2:2, packed, YUYV",
+   .bytes_per_pixel = 2,
+   },
+};
+
+static struct ipu_fmt ipu_fmt_rgb[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_RGB32,
+   .name = "RGB888",
+   .bytes_per_pixel = 4,
+   }, {
+   .fourcc = V4L2_PIX_FMT_RGB24,
+   .name = "RGB24",
+   .bytes_per_pixel = 3,
+   }, {
+   .fourcc = V4L2_PIX_FMT_BGR24,
+   .name = "BGR24",
+   .bytes_per_pixel = 3,
+   }, {
+   .fourcc = V4L2_PIX_FMT_RGB565,
+   .name = "RGB565",
+   .bytes_per_pixel = 2,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_BGR32,
+   .name = "BGR888",
+   .bytes_per_pixel = 4,
+   },
+};
+
+struct ipu_fmt *ipu_find_fmt_yuv(unsigned int pixelformat)
+{
+   struct ipu_fmt *fmt;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ipu_fmt_yuv); i++) {
+   fmt = &ipu_fmt_yuv[i];
+   if (fmt->fourcc == pixelformat)
+  

[PATCH v2 5/5] [media] imx-ipu: Add i.MX IPUv3 scaler driver

[Philipp Zabel]

From: Sascha Hauer 

This patch adds support for hardware accelerated scaling and color
space conversion between memory buffers using the IPUv3 IC.
Since the maximum output size of the IC unit is 1024x1024 pixels, multiple
IC tasks with overlapping tiles are used internally to scale and convert
larger frames.

The IC operates with a burst size of at least 8 pixels. Depending on the
frame width and scaling factor, up to 7 junk pixels may be written after
the end of the frame. The sizeimage is increased accordingly.

Signed-off-by: Sascha Hauer 
Signed-off-by: Michael Olbrich 
Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Removed removal of deinterlacer support left-overs
---
 drivers/media/platform/imx/Kconfig  |   9 +
 drivers/media/platform/imx/Makefile |   1 +
 drivers/media/platform/imx/imx-ipu-scaler.c | 869 
 drivers/media/platform/imx/imx-ipu.c|   2 +-
 drivers/media/platform/imx/imx-ipu.h|   1 +
 5 files changed, 881 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c

diff --git a/drivers/media/platform/imx/Kconfig 
b/drivers/media/platform/imx/Kconfig
index a90c973..4694367 100644
--- a/drivers/media/platform/imx/Kconfig
+++ b/drivers/media/platform/imx/Kconfig
@@ -1,2 +1,11 @@
 config VIDEO_IMX_IPU_COMMON
tristate
+
+config VIDEO_IMX_IPU_SCALER
+   tristate "i.MX5/6 IPUv3 based image scaler driver"
+   depends on VIDEO_DEV && IMX_IPUV3_CORE
+   select VIDEOBUF2_DMA_CONTIG
+   select VIDEO_IMX_IPU_COMMON
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a v4l2 scaler video driver for the IPUv3 on i.MX5/6.
diff --git a/drivers/media/platform/imx/Makefile 
b/drivers/media/platform/imx/Makefile
index 5de119c..f20aa0b 100644
--- a/drivers/media/platform/imx/Makefile
+++ b/drivers/media/platform/imx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_IMX_IPU_COMMON) += imx-ipu.o
+obj-$(CONFIG_VIDEO_IMX_IPU_SCALER) += imx-ipu-scaler.o
diff --git a/drivers/media/platform/imx/imx-ipu-scaler.c 
b/drivers/media/platform/imx/imx-ipu-scaler.c
new file mode 100644
index 000..9cf8a70
--- /dev/null
+++ b/drivers/media/platform/imx/imx-ipu-scaler.c
@@ -0,0 +1,869 @@
+/*
+ * i.MX IPUv3 scaler driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * based on the mem2mem test driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-ipu.h"
+
+#define MIN_W 32
+#define MIN_H 32
+#define MAX_W 4096
+#define MAX_H 4096
+#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
+
+/* Flags that indicate a format can be used for capture/output */
+#define MEM2MEM_CAPTURE(1 << 0)
+#define MEM2MEM_OUTPUT (1 << 1)
+
+#define MEM2MEM_NAME   "imx-ipuv3-scale"
+
+/* Per queue */
+#define MEM2MEM_DEF_NUM_BUFS   VIDEO_MAX_FRAME
+/* In bytes, per queue */
+#define MEM2MEM_VID_MEM_LIMIT  (64 * 1024 * 1024)
+
+#define fh_to_ctx(__fh)container_of(__fh, struct ipu_scale_ctx, fh)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct ipu_scale_dev {
+   struct v4l2_device  v4l2_dev;
+   struct video_device *vfd;
+   struct device   *dev;
+   struct ipu_soc  *ipu;
+
+   atomic_tnum_inst;
+   spinlock_t  irqlock;
+
+   struct v4l2_m2m_dev *m2m_dev;
+   struct mutexdev_mutex;
+};
+
+/* Per-queue, driver-specific private data */
+struct ipu_scale_q_data {
+   struct v4l2_pix_format  cur_fmt;
+   struct v4l2_rectrect;
+};
+
+struct ipu_scale_ctx {
+   struct ipu_scale_dev*ipu_scaler;
+
+   struct v4l2_fh  fh;
+   struct vb2_alloc_ctx*alloc_ctx;
+   struct ipu_scale_q_data q_data[2];
+   struct work_struct  work;
+   struct completion   completion;
+   struct work_struct  skip_run;
+   int error;
+   int aborting;
+   enum ipu_image_scale_ctrl ctrl;
+   struct image_convert_ctx *icc;
+   int num_tiles;
+};
+
+static struct ipu_scale_q_data *get_q_data(struct ipu_scale_ctx *ctx,
+  enum v4l2_buf_type type)
+{
+   switch (type) {
+   case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+   return &ctx->q_data[V4L2_M2M_SRC];
+   case V4L2_

[PATCH v2 0/5] i.MX5/6 mem2mem scaler

[Philipp Zabel]

Hi,

this series uses the IPU IC post-processing task, to implement
a mem2mem device for scaling and colorspace conversion. The first
version had a fixup applied to the wrong patch.

Changes since v1:
 - Removed deinterlacer support left-overs

regards
Philipp

Philipp Zabel (3):
  gpu: ipu-v3: Add missing IDMAC channel names
  gpu: ipu-v3: Add mem2mem image conversion support to IC
  gpu: ipu-v3: Register scaler platform device

Sascha Hauer (2):
  [media] imx-ipu: Add ipu media common code
  [media] imx-ipu: Add i.MX IPUv3 scaler driver

 drivers/gpu/ipu-v3/ipu-common.c |   2 +
 drivers/gpu/ipu-v3/ipu-ic.c | 787 -
 drivers/media/platform/Kconfig  |   2 +
 drivers/media/platform/Makefile |   1 +
 drivers/media/platform/imx/Kconfig  |  11 +
 drivers/media/platform/imx/Makefile |   2 +
 drivers/media/platform/imx/imx-ipu-scaler.c | 869 
 drivers/media/platform/imx/imx-ipu.c| 313 ++
 drivers/media/platform/imx/imx-ipu.h|  36 ++
 include/video/imx-ipu-v3.h  |  49 +-
 10 files changed, 2055 insertions(+), 17 deletions(-)
 create mode 100644 drivers/media/platform/imx/Kconfig
 create mode 100644 drivers/media/platform/imx/Makefile
 create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c
 create mode 100644 drivers/media/platform/imx/imx-ipu.c
 create mode 100644 drivers/media/platform/imx/imx-ipu.h

-- 
2.1.4

[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC

[Philipp Zabel]

This patch adds support for mem2mem scaling and colorspace conversion
using the IC module's post-processing task.

Scaling images larger than 1024x1024 is supported by tiling over multiple
IC scaling runs. Since the IDMAC and IC units have interesting and different
alignment limitations for buffer base addresses (left edges) and burst size
(row lengths), depending on input and output pixel formats, the tile rectangles
and scaling coefficients are chosen to minimize distortion. Due to possible
overlap, the tiles have to be rendered right to left and bottom to top.
Up to 7 pixels (depending on frame sizes and scaling factor) have to be
available after the end of the frame if the width is not burst size aligned.
The tiling code has a parameter to optionally round frame sizes up or down
and avoid overdraw in compositing scenarios.

Signed-off-by: Sascha Hauer 
Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Removed deinterlacer support left-overs
---
 drivers/gpu/ipu-v3/ipu-ic.c | 787 +++-
 include/video/imx-ipu-v3.h  |  34 +-
 2 files changed, 804 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index ad75588..984f68f 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "ipu-prv.h"
@@ -96,6 +97,15 @@ struct ic_task_bitfields {
u32 ic_cmb_galpha_bit;
 };

+struct ic_task_channels {
+   u8 in;
+   u8 out;
+   u8 rot_in;
+   u8 rot_out;
+   u8 in_prev;
+   u8 in_next;
+};
+
 static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
[IC_TASK_ENCODER] = {
.rsc = IC_PRP_ENC_RSC,
@@ -138,12 +148,53 @@ static const struct ic_task_bitfields 
ic_task_bit[IC_NUM_TASKS] = {
},
 };

+static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
+   [IC_TASK_ENCODER] = {
+   .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
+   .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+   .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
+   .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
+   },
+   [IC_TASK_VIEWFINDER] = {
+   .in = IPUV3_CHANNEL_MEM_VDI_CUR,
+   .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+   .rot_in = IPUV3_CHANNEL_MEM_ROT_VF,
+   .rot_out = IPUV3_CHANNEL_ROT_VF_MEM,
+   .in_prev = IPUV3_CHANNEL_MEM_VDI_PREV,
+   .in_next = IPUV3_CHANNEL_MEM_VDI_NEXT,
+   },
+   [IC_TASK_POST_PROCESSOR] = {
+   .in = IPUV3_CHANNEL_MEM_IC_PP,
+   .out = IPUV3_CHANNEL_IC_PP_MEM,
+   .rot_in = IPUV3_CHANNEL_MEM_ROT_PP,
+   .rot_out = IPUV3_CHANNEL_ROT_PP_MEM,
+   },
+};
+
+struct image_convert_ctx {
+   void (*complete)(void *ctx, int err);
+   void *complete_context;
+
+   struct list_head list;
+   struct ipu_image in;
+   struct ipu_image in_n;
+   struct ipu_image in_p;
+   struct ipu_image out;
+
+   void *freep;
+
+   bool rotate:1;
+
+   u32 rsc;
+};
+
 struct ipu_ic_priv;

 struct ipu_ic {
enum ipu_ic_task task;
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
+   const struct ic_task_channels *ch;

enum ipu_color_space in_cs, g_in_cs;
enum ipu_color_space out_cs;
@@ -152,6 +203,19 @@ struct ipu_ic {
bool in_use;

struct ipu_ic_priv *priv;
+
+   struct ipuv3_channel *input_channel_p;
+   struct ipuv3_channel *input_channel;
+   struct ipuv3_channel *input_channel_n;
+   struct ipuv3_channel *output_channel;
+   struct ipuv3_channel *rotation_input_channel;
+   struct ipuv3_channel *rotation_output_channel;
+
+   struct list_head image_list;
+
+   struct workqueue_struct *workqueue;
+   struct work_struct work;
+   struct completion complete;
 };

 struct ipu_ic_priv {
@@ -168,7 +232,8 @@ static inline u32 ipu_ic_read(struct ipu_ic *ic, unsigned 
offset)
return readl(ic->priv->base + offset);
 }

-static inline void ipu_ic_write(struct ipu_ic *ic, u32 value, unsigned offset)
+static inline void ipu_ic_write(struct ipu_ic *ic, u32 value,
+   unsigned offset)
 {
writel(value, ic->priv->base + offset);
 }
@@ -446,32 +511,35 @@ int ipu_ic_task_init(struct ipu_ic *ic,
 int in_width, int in_height,
 int out_width, int out_height,
 enum ipu_color_space in_cs,
-enum ipu_color_space out_cs)
+enum ipu_color_space out_cs,
+u32 rsc)
 {
struct ipu_ic_priv *priv = ic->priv;
-   u32 reg, downsize_coeff, resize_coeff;
+   u32 downsize_coeff, resize_coeff;
unsigned long flags;
int ret = 0;

-   /* Setup vertical resizing */
-   ret = c

[Intel-gfx] [PATCH 1/5] drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/

[Jani Nikula]

On Fri, 13 Mar 2015, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
> spec.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/tegra/dpaux.c | 2 +-
>  include/drm/drm_dp_helper.h   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index d6b55e3..b1617af 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -152,7 +152,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux 
> *aux,
>  
>   break;
>  
> - case DP_AUX_I2C_STATUS:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
>   if (msg->request & DP_AUX_I2C_MOT)
>   value |= DPAUX_DP_AUXCTL_CMD_MOT_RQ;
>   else
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 523f04c..27301f5 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -46,7 +46,7 @@
>  
>  #define DP_AUX_I2C_WRITE 0x0
>  #define DP_AUX_I2C_READ  0x1
> -#define DP_AUX_I2C_STATUS0x2
> +#define DP_AUX_I2C_WRITE_STATUS_UPDATE   0x2
>  #define DP_AUX_I2C_MOT   0x4
>  #define DP_AUX_NATIVE_WRITE  0x8
>  #define DP_AUX_NATIVE_READ   0x9
> -- 
> 2.0.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [PATCH 2/5] drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE

[Jani Nikula]

On Fri, 13 Mar 2015, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> When we get an i2c defer or short ack for i2c-over-aux write we need
> to switch to WRITE_STATUS_UPDATE to poll for the completion of the
> original request.
>
> i915 doesn't try to interpret wht request type apart from separating
> reads from writes, and so we should be able to treat this the same as
> a normal i2c write.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

Probably needs a refresh due to context change due to my short writes
patch though.

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 33d5877..aed5f26 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -956,6 +956,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   switch (msg->request & ~DP_AUX_I2C_MOT) {
>   case DP_AUX_NATIVE_WRITE:
>   case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
>   txsize = msg->size ? HEADER_SIZE + msg->size : 
> BARE_ADDRESS_SIZE;
>   rxsize = 1;
>  
> -- 
> 2.0.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 5/5] drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests

[Jani Nikula]

On Fri, 13 Mar 2015, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
> supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
> when we continue to poll for the completion of the request.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 41 
> +
>  1 file changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index d5368ea..4db81a6 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -422,6 +422,25 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
> *adapter)
>  I2C_FUNC_10BIT_ADDR;
>  }
>  
> +static void drm_dp_i2c_msg_set_request(struct drm_dp_aux_msg *msg,
> +const struct i2c_msg *i2c_msg)
> +{
> + msg->request = (i2c_msg->flags & I2C_M_RD) ?
> + DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
> + msg->request |= DP_AUX_I2C_MOT;
> +}
> +
> +static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
> +{
> + /*
> +  * In case of i2c defer or short i2c ack reply to a write,
> +  * we need to switch to WRITE_STATUS_UPDATE to drain the
> +  * rest of the message
> +  */
> + if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE)
> + msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;

This only works because DP_AUX_I2C_WRITE == 0, and it may not be obvious
to the casual reader that DP_AUX_I2C_WRITE_STATUS_UPDATE is a
replacement not an addition to DP_AUX_I2C_WRITE.

Whether you fix that or not, this is

Reviewed-by: Jani Nikula 



> +}
> +
>  /*
>   * Transfer a single I2C-over-AUX message and handle various error 
> conditions,
>   * retrying the transaction as appropriate.  It is assumed that the
> @@ -490,6 +509,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>* Both native ACK and I2C ACK replies received. We
>* can assume the transfer was successful.
>*/
> + if (ret != msg->size)
> + drm_dp_i2c_msg_write_status_update(msg);
>   return ret;
>  
>   case DP_AUX_I2C_REPLY_NACK:
> @@ -501,6 +522,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   DRM_DEBUG_KMS("I2C defer\n");
>   aux->i2c_defer_count++;
>   usleep_range(400, 500);
> + drm_dp_i2c_msg_write_status_update(msg);
>   continue;
>  
>   default:
> @@ -566,10 +588,7 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>  
>   for (i = 0; i < num; i++) {
>   msg.address = msgs[i].addr;
> - msg.request = (msgs[i].flags & I2C_M_RD) ?
> - DP_AUX_I2C_READ :
> - DP_AUX_I2C_WRITE;
> - msg.request |= DP_AUX_I2C_MOT;
> + drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
>   /* Send a bare address packet to start the transaction.
>* Zero sized messages specify an address only (bare
>* address) transaction.
> @@ -577,6 +596,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>   msg.buffer = NULL;
>   msg.size = 0;
>   err = drm_dp_i2c_do_msg(aux, &msg);
> +
> + /*
> +  * Reset msg.request in case in case it got
> +  * changed into a WRITE_STATUS_UPDATE.
> +  */
> + drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
> +
>   if (err < 0)
>   break;
>   /* We want each transaction to be as large as possible, but
> @@ -589,6 +615,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>   msg.size = min(transfer_size, msgs[i].len - j);
>  
>   err = drm_dp_i2c_drain_msg(aux, &msg);
> +
> + /*
> +  * Reset msg.request in case in case it got
> +  * changed into a WRITE_STATUS_UPDATE.
> +  */
> + drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
> +
>   if (err < 0)
>   break;
>   transfer_size = err;
> -- 
> 2.0.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2 1/6] drm/exynos: add Exynos5433 decon driver

[Daniel Stone]

Hi,
Some feedback comments - most of these are not unique to your 5433
DECON driver but endemic throughout Exynos, so I don't blame you for
them - but they should be fixed anyway.

On 18 March 2015 at 08:16, Hyungwon Hwang  wrote:
> +static void decon_dpms_on(struct exynos_decon *decon)
> +{
> +   int ret;
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
> +   ret = clk_prepare_enable(decon->clks[i]);
> +   if (ret < 0)
> +   goto err;
> +   }
> +
> +   set_bit(BIT_CLKS_ENABLED, &decon->enabled);

Do you really not even need to set a control register?

> +static void decon_commit(struct exynos_drm_crtc *crtc)
> +{
> +   struct exynos_decon *decon = crtc->ctx;
> +   struct drm_display_mode *mode = &crtc->base.mode;
> +   u32 val;
> +
> +   /* enable clock gate */
> +   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
> +   writel(val, decon->addr + DECON_CMU);
> +
> +   /* lcd on and use command if */
> +   val = VIDOUT_LCD_ON;
> +   if (decon->i80_if)
> +   val |= VIDOUT_COMMAND_IF;
> +   else
> +   val |= VIDOUT_RGB_IF;
> +   writel(val, decon->addr + DECON_VIDOUTCON0);

This seems much more likely to be DPMS, no?

> +   [...]
> +   /* enable output and display signal */
> +   val = VIDCON0_ENVID | VIDCON0_ENVID_F;
> +   writel(val, decon->addr + DECON_VIDCON0);

As does this.

Have you tested DPMS on/off, without enabling/disabling the CRTC
first? Does it work?

> +static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
> +  struct exynos_drm_plane *plane)
> +{
> +   struct exynos_decon *decon = crtc->ctx;
> +   struct decon_reg_data *reg_data;
> +   unsigned int bytes_per_pixel = plane->bpp >> 3;
> +   unsigned int val_h;
> +   unsigned int val_l;
> +   unsigned int win;
> +   dma_addr_t addr;
> +   u32 val = 0;
> +
> +   if (!plane) {
> +   DRM_ERROR("plane is NULL\n");
> +   return;
> +   }
> +
> +   win = plane->zpos;
> +   if (win == DEFAULT_ZPOS)
> +   win = 0;
> +
> +   if (win < 0 || win >= 5)
> +   return;

It would be nice to have a #define for the largest-supported window number.

> +   reg_data = &decon->reg_data[win];
> +
> +   switch (plane->pixel_format) {
> +   case DRM_FORMAT_XRGB1555:
> +   val |= WINCONx_BPPMODE_16BPP_I1555;
> +   val |= WINCONx_HAWSWP_F;
> +   val |= WINCONx_BURSTLEN_16WORD;
> +   break;
> +   case DRM_FORMAT_RGB565:
> +   val |= WINCONx_BPPMODE_16BPP_565;
> +   val |= WINCONx_HAWSWP_F;
> +   val |= WINCONx_BURSTLEN_16WORD;
> +   break;
> +   case DRM_FORMAT_XRGB:
> +   val |= WINCONx_BPPMODE_24BPP_888;
> +   val |= WINCONx_WSWP_F;
> +   val |= WINCONx_BURSTLEN_16WORD;
> +   break;
> +   case DRM_FORMAT_ARGB:
> +   val |= WINCONx_BPPMODE_32BPP_A;
> +   val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | 
> WINCONx_ALPHA_SEL_F;
> +   val |= WINCONx_BURSTLEN_16WORD;
> +   break;
> +   default:

Please remove the 'default' case. If you get here with a format you
don't know how to configure, then it is a bug and should be fixed: the
plane should never advertise a format that it cannot support.

> +   val |= WINCONx_BPPMODE_24BPP_888;
> +   val |= WINCONx_WSWP_F;
> +   val |= WINCONx_BURSTLEN_16WORD;
> +   break;
> +   }
> +
> +   reg_data->wincon = val;
> +   reg_data->vidosd_a = COORDINATE_X(plane->crtc_x) |
> +   COORDINATE_Y(plane->crtc_y);
> +   reg_data->vidosd_b =
> +   COORDINATE_X(plane->crtc_x + plane->crtc_width - 1) |
> +   COORDINATE_Y(plane->crtc_y + plane->crtc_height - 1);
> +   reg_data->vidosd_c = VIDOSD_Wx_ALPHA_R_F(0x0) |
> +   VIDOSD_Wx_ALPHA_G_F(0x0) |
> +   VIDOSD_Wx_ALPHA_B_F(0x0);
> +   reg_data->vidosd_d = VIDOSD_Wx_ALPHA_R_F(0x0) |
> +   VIDOSD_Wx_ALPHA_G_F(0x0) |
> +   VIDOSD_Wx_ALPHA_B_F(0x0);
> +
> +   addr = plane->dma_addr[0];
> +   addr += plane->fb_width * plane->fb_y * bytes_per_pixel;

Replace plane->fb_width * bytes_per_pixel by plane->fb_pitch please,
and set plane->fb_pitch from exynos_drm_plane->pitch. See this patch:
https://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg42861.html

You should be able to test this case, either by making a specialised
userspace program which has a larger pitch with garbage values in the
padding (see 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa473780(v=vs.85).aspx),
or by testing a resolution where width*b

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #235 from Tom Guder  ---
Hello,

i get random freezes only in dota2. Other OpenGL applications run well.
Archlinux, 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64
GNU/Linux

[11008.894953] radeon :02:00.0: GPU fault detected: 147 0x000c4402
[11008.894956] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0010
[11008.894958] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C044002
[11008.894959] VM fault (0x02, vmid 6) at page 1048576, read from TC (68)
[11008.894961] radeon :02:00.0: GPU fault detected: 147 0x058c4801
[11008.894962] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x000AA85A
[11008.894963] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C0C8002
[11008.894964] VM fault (0x02, vmid 6) at page 698458, read from TC (200)
[11019.062287] radeon :02:00.0: ring 4 stalled for more than 1msec
[11019.062291] radeon :02:00.0: GPU lockup (current fence id
0x00013609 last fence id 0x0001360a on ring 4)
[11019.062312] radeon :02:00.0: failed to get a new IB (-35)
[11019.062315] [drm:radeon_cs_ib_fill] *ERROR* Failed to get ib !
[11019.556350] radeon :02:00.0: Saved 780 dwords of commands on ring 0.
. 
. 
. 

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

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #236 from Tom Guder  ---
Same with kernel 3.14.35-1-lts. Dota2 crashes everytimes within one minute
spectating a game and freezes the screen and keyboard. Networking works.

Bests
Tom

[  129.619475] radeon :02:00.0: GPU fault detected: 147 0x000a4401
[  129.619479] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0100
[  129.619480] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0A044001
[  129.619482] VM fault (0x01, vmid 5) at page 16777216, read from TC (68)
[  129.619484] radeon :02:00.0: GPU fault detected: 146 0x020a440c
[  129.619485] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  129.619486] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x

-- 
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/20150318/ca128b69/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #237 from Marti Raudsepp  ---
(In reply to Tom Guder from comment #235)
> i get random freezes only in dota2. Other OpenGL applications run well.

Please report a separate bug for your exact circumstances. This one is being
ignored by developers because there are many different causes.

-- 
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/20150318/c95eee18/attachment.html>

[Bug 89659] GPU Hangs with dota2

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

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

Bug ID: 89659
   Summary: GPU Hangs with dota2
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: kontakt at ib-guder.de

Created attachment 114442
  --> https://bugs.freedesktop.org/attachment.cgi?id=114442&action=edit
dmesg after a crash

Hello,

I get reproducible GPU hangs often within one minute spectating a game in
dota2. Other OpenGL applications runs without hangs. The screen stays black,
the keyboard doesn't work after a crash. Networking via ssh works.

Archlinux 64bit
Mesa: 10.5.1
Linux: 3.18.6 and 3.14.53

Thank you and best wishes
Tom Guder

-- 
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/20150318/5de56894/attachment.html>

Fwd: [PATCH 0/5] drm/dp: i2c-over-aux short write support

[Alex Deucher]

fwd to the list.


-- Forwarded message --
From: Alex Deucher 
Date: Mon, Mar 16, 2015 at 9:49 AM
Subject: Re: [PATCH 0/5] drm/dp: i2c-over-aux short write support
To: Ville Syrjälä 


On Fri, Mar 13, 2015 at 12:13 PM,   wrote:
> From: Ville Syrjälä 
>
> This series tries to implement support for short i2c-over-aux writes.
>
> I did notice that my monitor (HP ZR24w) does support DDC/CI so I was
> able to do some writes, but I only saw native defers instead of i2c
> defers/short acks. So I've not actually been able to test this.
>
> Another complication with DDC/CI seems to be that the monitor doesn't
> seem to like the default 100kHz bus speed. I had to drop it to 10kHz
> to make it reliable (my dongle supports bus speed control fortunately).
> Currently we have no standard way to configure the bus speed AFAICS,
> so at least with this monitor DDC/CI is a bit useless.
>
> I tried to fix up radeon and tegra too. gma500 I left alone since it's
> not using dp i2c helper.
>
> Ville Syrjälä (5):
>   drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
>   drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
>   drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
>   drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
>   drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE
> requests

Patches 1, 3, 5 are:
Acked-by: Alex Deucher 


>
>  drivers/gpu/drm/drm_dp_helper.c  | 42 
> 
>  drivers/gpu/drm/i915/intel_dp.c  |  1 +
>  drivers/gpu/drm/radeon/atombios_dp.c |  1 +
>  drivers/gpu/drm/tegra/dpaux.c|  3 ++-
>  include/drm/drm_dp_helper.h  |  2 +-
>  5 files changed, 43 insertions(+), 6 deletions(-)
>
> --
> 2.0.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 87796] radeonsi 120Hz graphic glitches

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

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

--- Comment #22 from Alex Deucher  ---
(In reply to Andreas Gihr from comment #21)
> I'm still having this issue.

Does it still happen with the patches applied?

-- 
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/20150318/aa644599/attachment.html>

[Bug 87796] radeonsi 120Hz graphic glitches

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

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

--- Comment #23 from Andreas Gihr  ---
I'm using the newest kernel from git. 
It said: Reversed (or previously applied) patch detected!

-- 
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/20150318/7844a8c3/attachment-0001.html>

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   Some urgent regression fixes to booting failures Exynos DRM occured.

   Summary:
   - Fix two urgent null pointer dereference bugs in case of enabling
 or disabling IOMMU. There was two cases to these issues.
 One is that plane->crtc is accessed by exynos_disable_plane()
 when device tree binding is broken so device driver tries
 to release, which means that the mode set operation isn't invoked yet
 so plane->crtc is still NULL and exynos_disable_plane() will access
 NULL pointer. This issue is fixed by checking if the plane->crtc
 is NULL or not in exynos_disable_plane()

 Other is that fimd_wait_for_vblank() is called to avoid from page fault
 with IOMMU before the ctx object is created. At this time,
 fimd_wait_for_vblank() tries to access ctx->crtc but the ctx->crtc
 is still NULL because exynos_drm_crtc_create() isn't called yet.
 This issue is fixed by creating a crtc object and setting it to
 ctx->crtc prior to fimd_wait_for_vblank() call.

 For more details, you can refer to below an e-mail thread,
 http://www.spinics.net/lists/linux-samsung-soc/msg42436.html

   - Remove unnecessary file not used and fix trivial issues.

   Plese, kindly let me know if there is any problem.


Thanks,
Inki Dae


The following changes since commit 046d669c62f37323ef0329c41d83a03c06b2087d:

  [PATCH] drm/mm: Fix support 4 GiB and larger ranges (2015-03-16 06:28:50 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-fixes

for you to fetch changes up to cdbfca890714c14cafb6f65cab89b3e3ffad876f:

  drm/exynos: fix the initialization order in FIMD (2015-03-18 20:41:19 +0900)


Andrzej Hajda (1):
  drm/exynos: remove unused files

Charles Keepax (1):
  drm/exynos: Check for NULL dereference of crtc

Dan Carpenter (1):
  drm/exynos: IS_ERR() vs NULL bug

Hyungwon Hwang (1):
  drm/exynos: fix the initialization order in FIMD

Inki Dae (1):
  drm/exynos: fix typo config name correctly.

 drivers/gpu/drm/exynos/Kconfig|2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|4 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |  245 -
 drivers/gpu/drm/exynos/exynos_drm_connector.h |   20 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   29 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
 6 files changed, 15 insertions(+), 287 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.h

[PATCH] drm: Return current vblank value for drmWaitVBlank queries

[Mario Kleiner]

On 03/18/2015 10:30 AM, Chris Wilson wrote:
> On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote:
>> drm_vblank_count_and_time() doesn't return the correct sequence number
>> while the vblank interrupt is disabled, does it? It returns the sequence
>> number from the last time vblank_disable_and_save() was called (when the
>> vblank interrupt was disabled). That's why drm_vblank_get() is needed here.
>
> Ville enlightened me as well. I thought the value was cooked so that
> time did not pass whilst the IRQ was disabled. Hopefully, I can impress
> upon the Intel folks, at least, that enabling/disabling the interrupts
> just to read the current hw counter is interesting to say the least and
> sits at the top of the profiles when benchmarking Present.
> -Chris
>

drm_wait_vblank() not only gets the counter but also the corresponding 
vblank timestamp. Counters are recalculated in vblank_disable_and_save() 
for irq off, then in the vblank irq on path, and every refresh in 
drm_handle_vblank at vblank irq time.

The timestamps can be recalculated at any time iff the driver supports 
high precision timestamping, which currently intel kms, radeon kms, and 
nouveau kms do. But for other parts, like most SoC's, afaik you only get 
a valid timestamp by sampling system time in the vblank irq handler, so 
there you'd have a problem.

There are also some races around the enable/disable path which require a 
lot of care and exact knowledge of when each hardware fires its vblanks, 
updates its hardware counters etc. to get rid of them. Ville did that - 
successfully as far as my tests go - for Intel kms, but other drivers 
would be less forgiving.

Our current method is to:

a) Only disable vblank irqs after a default idle period of 5 seconds, so 
we don't get races frequent/likely enough to cause problems for clients. 
And we save the overhead for all the vblank irq on/off.

b) On drivers which have high precision timestamping and have been 
carefully checked to be race free (== intel kms only atm.) we have 
instant disable, so things like blinking cursors don't keep vblank irq 
on forever.

If b) causes so much overhead, maybe we could change the "instant 
disable" into a "disable after a very short time", e.g., lowering the 
timeout from 5000 msecs to 2-3 video refresh durations ~ 50 msecs? That 
would still disable vblank irqs for power saving if the desktop is 
really idle, but avoid on/off storms for the various drm_wait_vblank's 
that happen when preparing a swap.

-mario

[Bug 87796] radeonsi 120Hz graphic glitches

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

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

--- Comment #24 from Alex Deucher  ---
Created attachment 114443
  --> https://bugs.freedesktop.org/attachment.cgi?id=114443&action=edit
possible fix

Does this patch on top of latest git help?

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

[PATCH] drm/omap: tiler: add hibernation callback

[Rob Clark]

On Wed, Feb 25, 2015 at 1:08 PM,   wrote:
> From: Grygorii Strashko 
>
> Setting a dev_pm_ops resume callback but not a set of
> hibernation handler means that pm function will not be
> called upon hibernation.
> Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
> assigns the suspend and hibernation handlers and move
> omap_dmm_resume under CONFIG_PM_SLEEP to avoid build warnings.
>
> Signed-off-by: Grygorii Strashko 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 56c6055..afb8cfc 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -941,7 +941,7 @@ error:
>  }
>  #endif
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
>  static int omap_dmm_resume(struct device *dev)
>  {
> struct tcm_area area;
> @@ -965,12 +965,10 @@ static int omap_dmm_resume(struct device *dev)
>
> return 0;
>  }
> -
> -static const struct dev_pm_ops omap_dmm_pm_ops = {
> -   .resume = omap_dmm_resume,
> -};
>  #endif
>
> +SIMPLE_DEV_PM_OPS(omap_dmm_pm_ops, NULL, omap_dmm_resume);
> +
>  #if defined(CONFIG_OF)
>  static const struct of_device_id dmm_of_match[] = {
> { .compatible = "ti,omap4-dmm", },
> @@ -986,9 +984,7 @@ struct platform_driver omap_dmm_driver = {
> .owner = THIS_MODULE,
> .name = DMM_DRIVER_NAME,
> .of_match_table = of_match_ptr(dmm_of_match),
> -#ifdef CONFIG_PM
> .pm = &omap_dmm_pm_ops,
> -#endif
> },
>  };
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] drm/i915: gen4: work around hang during hibernation

[Paul Bolle]

On Wed, 2015-03-18 at 12:22 +0200, Ville Syrjälä wrote:
> We had another bug report which showed similar problems on something
> as recent as SNB:
> https://bugzilla.kernel.org/show_bug.cgi?id=94241
> So I guess we really want to make the check 'gen < 7'.
> 
> My IVB X1 Carbon doesn't need this quirk, so hopefully that indicates
> the Lenovo BIOSen became more sane for gen7+.

On the other hand my ThinkPad X220 has vendor:device ids 8086:0126,
which makes it a gen6 device (assuming I parsed the various preprocessor
defines in include/drm/i915_pciids.h and drivers/gpu/drm/i915/i915_drv.c
correctly). That laptop is now running v3.19.1 and never hit this issue.


Paul Bolle

[pull] radeon drm-fixes-4.0

[Alex Deucher]

Hi Dave,

Just one fix for stable.

The following changes since commit 046d669c62f37323ef0329c41d83a03c06b2087d:

  [PATCH] drm/mm: Fix support 4 GiB and larger ranges (2015-03-16 06:28:50 
+1000)

are available in the git repository at:

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

for you to fetch changes up to a239118a24b3bf9089751068e431dfb63dc4168b:

  drm/radeon: drop ttm two ended allocation (2015-03-18 09:53:40 -0400)


Alex Deucher (1):
  drm/radeon: drop ttm two ended allocation

 drivers/gpu/drm/radeon/radeon_object.c | 11 ---
 1 file changed, 11 deletions(-)

[PATCH] intel: Export total subslice and EU counts

[Damien Lespiau]

On Mon, Mar 02, 2015 at 03:39:27PM -0800, jeff.mcgee at intel.com wrote:
> From: Jeff McGee 

2 small details, but otherwise:

Reviewed-by: Damien Lespiau 


> Update kernel interface with new I915_GETPARAM ioctl entries for
> subslice total and EU total. Add a wrapping function for each
> parameter. Userspace drivers need these values when constructing
> GPGPU commands. This kernel query method is intended to replace
> the PCI ID-based tables that userspace drivers currently maintain.
> The kernel driver can employ fuse register reads as needed to
> ensure the most accurate determination of GT config attributes.
> This first became important with Cherryview in which the config
> could differ between devices with the same PCI ID.
> 
> The kernel detection of these values is device-specific. Userspace
> drivers should continue to maintain ID-based tables for older
> devices which return ENODEV when using this query.

This should probably part of some comment near the API entry point.

> 
> For: VIZ-4636
> Signed-off-by: Jeff McGee 
> ---
>  include/drm/i915_drm.h   |  2 ++
>  intel/intel_bufmgr.h |  4 
>  intel/intel_bufmgr_gem.c | 31 +++
>  3 files changed, 37 insertions(+)
> 
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index 15dd01d..e34f5b2 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -340,6 +340,8 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
>  #define I915_PARAM_HAS_WT 27
>  #define I915_PARAM_CMD_PARSER_VERSION 28
> +#define I915_PARAM_SUBSLICE_TOTAL 32
> +#define I915_PARAM_EU_TOTAL   33
>  
>  typedef struct drm_i915_getparam {
>   int param;
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index be83a56..4b2472e 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

But you don't seem to use bool or _Bool in the rest of the patch?

>  struct drm_clip_rect;
>  
> @@ -264,6 +265,9 @@ int drm_intel_get_reset_stats(drm_intel_context *ctx,
> uint32_t *active,
> uint32_t *pending);
>  
> +int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
> +int drm_intel_get_eu_total(int fd, unsigned int *eu_total);
> +
>  /** @{ Compatibility defines to keep old code building despite the symbol 
> rename
>   * from dri_* to drm_intel_*
>   */
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 78875fd..2d77f32 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -3292,6 +3292,37 @@ drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
>   return ret;
>  }
>  
> +drm_public int
> +drm_intel_get_subslice_total(int fd, unsigned int *subslice_total)
> +{
> + drm_i915_getparam_t gp;
> + int ret;
> +
> + memclear(gp);
> + gp.value = (int*)subslice_total;
> + gp.param = I915_PARAM_SUBSLICE_TOTAL;
> + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
> + if (ret)
> + return -errno;
> +
> + return 0;
> +}
> +
> +drm_public int
> +drm_intel_get_eu_total(int fd, unsigned int *eu_total)
> +{
> + drm_i915_getparam_t gp;
> + int ret;
> +
> + memclear(gp);
> + gp.value = (int*)eu_total;
> + gp.param = I915_PARAM_EU_TOTAL;
> + ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
> + if (ret)
> + return -errno;
> +
> + return 0;
> +}
>  
>  /**
>   * Annotate the given bo for use in aub dumping.
> -- 
> 2.3.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 1/2 v2] intel: Export total subslice and EU counts

[Damien Lespiau]

On Mon, Mar 09, 2015 at 04:13:03PM -0700, jeff.mcgee at intel.com wrote:
> From: Jeff McGee 
> 
> Update kernel interface with new I915_GETPARAM ioctl entries for
> subslice total and EU total. Add a wrapping function for each
> parameter. Userspace drivers need these values when constructing
> GPGPU commands. This kernel query method is intended to replace
> the PCI ID-based tables that userspace drivers currently maintain.
> The kernel driver can employ fuse register reads as needed to
> ensure the most accurate determination of GT config attributes.
> This first became important with Cherryview in which the config
> could differ between devices with the same PCI ID.
> 
> The kernel detection of these values is device-specific. Userspace
> drivers should continue to maintain ID-based tables for older
> devices which return ENODEV when using this query.
> 
> v2: remove unnecessary include of  and increment the
> I915_GETPARAM indices to match updated kernel patch.
> 
> For: VIZ-4636
> Signed-off-by: Jeff McGee 

Pushed to libdrm.

-- 
Damien

[PATCH libdrm 1/1] tests/exynos: Fix warnings

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 tests/exynos/exynos_fimg2d_test.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index e7d9b72..dfb34ac 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -183,7 +183,7 @@ static struct exynos_bo *exynos_create_buffer(struct 
exynos_device *dev,

 /* Allocate buffer and fill it with checkerboard pattern, where the tiles *
  * have a random color. The caller has to free the buffer.*/
-void *create_checkerboard_pattern(unsigned int num_tiles_x,
+static void *create_checkerboard_pattern(unsigned int num_tiles_x,
unsigned int num_tiles_y, 
unsigned int tile_size)
 {
unsigned int *buf;
@@ -573,6 +573,7 @@ static int g2d_checkerboard_test(struct exynos_device *dev,
src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
src_img.user_ptr[0].size = img_w * img_h * 4;
break;
+   case G2D_IMGBUF_COLOR:
default:
ret = -EFAULT;
goto fail;
-- 
2.1.0

[Bug 89431] Monitor is deactivated after DPMS activates

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

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

--- Comment #9 from rob at emanuele.us ---
That patch hasn't fix the issue but has changed the behavior.  Now the main
screen blanks, then the other two.  After that all the screens come back which
is a change as before the main screen would never return.  The screens do not
stay in powersave for more than a fraction of a second.  In some events, the
windows in the main screen get moved to the other screens but it is not
consistent.

-- 
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/20150318/68505298/attachment.html>

[PATCH libdrm v2 8/8] Fix unused function warnings

[Jan Vesely]

v2: Remove the handler function instead of commenting out
split debugmsg function removal to a separate patch

Signed-off-by: Jan Vesely 
---
 tests/drmstat.c | 13 -
 xf86drm.c   |  2 ++
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/tests/drmstat.c b/tests/drmstat.c
index c6ff1ff..c800ebb 100644
--- a/tests/drmstat.c
+++ b/tests/drmstat.c
@@ -81,11 +81,6 @@ static void getversion(int fd)
printf( "No driver available\n" );
 }
 }
-   
-void handler(int fd, void *oldctx, void *newctx)
-{
-printf("Got fd %d\n", fd);
-}

 static void process_sigio(char *device)
 {
@@ -97,7 +92,6 @@ static void process_sigio(char *device)
 }

 sigio_fd = fd;
-/*  drmInstallSIGIOHandler(fd, handler); */
 for (;;) sleep(60);
 }

@@ -427,11 +421,4 @@ int main(int argc, char **argv)
 return r; 
 }

-void DRM_PRINTFLIKE(4, 0)
-xf86VDrvMsgVerb(int scrnIndex, int type, int verb, const char *format,
-va_list args)
-{
-   vfprintf(stderr, format, args);
-}
-
 int xf86ConfigDRI[10];
diff --git a/xf86drm.c b/xf86drm.c
index 5032f35..a309d57 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -277,6 +277,7 @@ static int drmMatchBusID(const char *id1, const char *id2, 
int pci_domain_ok)
  * If any other failure happened then it will output error mesage using
  * drmMsg() call.
  */
+#if !defined(UDEV)
 static int chown_check_return(const char *path, uid_t owner, gid_t group)
 {
int rv;
@@ -292,6 +293,7 @@ static int chown_check_return(const char *path, uid_t 
owner, gid_t group)
path, errno, strerror(errno));
return -1;
 }
+#endif

 /**
  * Open the DRM device, creating it if necessary.
-- 
2.1.0

[PATCH libdrm 9/8] Remove drmSetDebugMsgFunction and related infrastructure

[Jan Vesely]

Not used anywhere

Signed-off-by: Jan Vesely 
---
 xf86drm.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index a309d57..ab472ea 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -114,11 +114,6 @@ drmDebugPrint(const char *format, va_list ap)
 return vfprintf(stderr, format, ap);
 }

-typedef int DRM_PRINTFLIKE(1, 0) (*debug_msg_func_t)(const char *format,
-va_list ap);
-
-static debug_msg_func_t drm_debug_print = drmDebugPrint;
-
 void
 drmMsg(const char *format, ...)
 {
@@ -130,18 +125,12 @@ drmMsg(const char *format, ...)
if (drm_server_info) {
  drm_server_info->debug_print(format,ap);
} else {
- drm_debug_print(format, ap);
+ drmDebugPrint(format, ap);
}
va_end(ap);
 }
 }

-void
-drmSetDebugMsgFunction(debug_msg_func_t debug_msg_ptr)
-{
-drm_debug_print = debug_msg_ptr;
-}
-
 static void *drmHashTable = NULL; /* Context switch callbacks */

 void *drmGetHashTable(void)
-- 
2.1.0

[Bug 87796] radeonsi 120Hz graphic glitches

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

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

--- Comment #25 from Andreas Gihr  ---
It didn't help.

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

[PATCH libdrm 1/1] tests/exynos: Fix warnings

[Tobias Jakobi]

Hello Jan,

Jan Vesely wrote:
> Signed-off-by: Jan Vesely 
> ---
>  tests/exynos/exynos_fimg2d_test.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/exynos/exynos_fimg2d_test.c 
> b/tests/exynos/exynos_fimg2d_test.c
> index e7d9b72..dfb34ac 100644
> --- a/tests/exynos/exynos_fimg2d_test.c
> +++ b/tests/exynos/exynos_fimg2d_test.c
> @@ -183,7 +183,7 @@ static struct exynos_bo *exynos_create_buffer(struct 
> exynos_device *dev,
>  
>  /* Allocate buffer and fill it with checkerboard pattern, where the tiles *
>   * have a random color. The caller has to free the buffer.*/
> -void *create_checkerboard_pattern(unsigned int num_tiles_x,
> +static void *create_checkerboard_pattern(unsigned int num_tiles_x,
>   unsigned int num_tiles_y, 
> unsigned int tile_size)
>  {
>   unsigned int *buf;
Good catch with the missing static!


> @@ -573,6 +573,7 @@ static int g2d_checkerboard_test(struct exynos_device 
> *dev,
>   src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
>   src_img.user_ptr[0].size = img_w * img_h * 4;
>   break;
> + case G2D_IMGBUF_COLOR:
>   default:
>   ret = -EFAULT;
>   goto fail;
> 
Hmm, I don't see the reason why this label should be added to the switch
statement?

With best wishes,
Tobias

[PATCH libdrm 1/1] tests/exynos: Fix warnings

[Jan Vesely]

On Wed, 2015-03-18 at 20:23 +0100, Tobias Jakobi wrote:
> Hello Jan,
> 
> Jan Vesely wrote:
> > Signed-off-by: Jan Vesely 
> > ---
> >  tests/exynos/exynos_fimg2d_test.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/exynos/exynos_fimg2d_test.c 
> > b/tests/exynos/exynos_fimg2d_test.c
> > index e7d9b72..dfb34ac 100644
> > --- a/tests/exynos/exynos_fimg2d_test.c
> > +++ b/tests/exynos/exynos_fimg2d_test.c
> > @@ -183,7 +183,7 @@ static struct exynos_bo *exynos_create_buffer(struct 
> > exynos_device *dev,
> >  
> >  /* Allocate buffer and fill it with checkerboard pattern, where the tiles *
> >   * have a random color. The caller has to free the buffer.
> > */
> > -void *create_checkerboard_pattern(unsigned int num_tiles_x,
> > +static void *create_checkerboard_pattern(unsigned int num_tiles_x,
> > unsigned int num_tiles_y, 
> > unsigned int tile_size)
> >  {
> > unsigned int *buf;
> Good catch with the missing static!
> 
> 
> > @@ -573,6 +573,7 @@ static int g2d_checkerboard_test(struct exynos_device 
> > *dev,
> > src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
> > src_img.user_ptr[0].size = img_w * img_h * 4;
> > break;
> > +   case G2D_IMGBUF_COLOR:
> > default:
> > ret = -EFAULT;
> > goto fail;
> > 
> Hmm, I don't see the reason why this label should be added to the switch
> statement?

This is mostly to appease the compiler. -Wswitch-enum warns about
missing enumeration cases even if default is present. On the other hand
it also warns against branches that use values outside of the
enumeration (which might be useful).

Emil, any thoughts about possibly dropping this warning? I think more
people will scratch their heads if unused enumeration values need to be
added to default branch.


jan

> 
> With best wishes,
> Tobias
> 

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150318/55227cc4/attachment.sig>

[PATCH libdrm 1/1] tests/exynos: Fix warnings

[Tobias Jakobi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jan Vesely wrote:
>> 
>>> @@ -573,6 +573,7 @@ static int g2d_checkerboard_test(struct
>>> exynos_device *dev, src_img.user_ptr[0].userptr = (unsigned
>>> long)checkerboard; src_img.user_ptr[0].size = img_w * img_h *
>>> 4; break; + case G2D_IMGBUF_COLOR: default: ret = -EFAULT; goto
>>> fail;
>>> 
>> Hmm, I don't see the reason why this label should be added to the
>> switch statement?
> 
> This is mostly to appease the compiler. -Wswitch-enum warns about 
> missing enumeration cases even if default is present. On the other
> hand it also warns against branches that use values outside of the 
> enumeration (which might be useful).
Ah, that makes sense. I guess adding the label is a good thing then!

With best wishes,
Tobias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlUJ3UYACgkQ6bCODwikBXd6xgCdG4sZERoY6KalhPn6AhyoxfbO
8EQAnRrCZrPXN/fjqwZT4X6a/7wLofeJ
=C/FO
-END PGP SIGNATURE-

[PATCH 3/4] drm/msm: Initial add DSI connector support

[h...@codeaurora.org]

Hi Archit,

Thanks for your comments. Please see my response for some comments below.
Comments without response will be addressed in patch version 2. I will
wait for other comments if any to push patch V2.

>> +static int dsi_gpio_init(struct msm_dsi_host *msm_host)
>> +{
>> +int ret;
>> +
>> +msm_host->disp_en_gpio = devm_gpiod_get(&msm_host->pdev->dev,
>> +"disp-enable");
>> +if (IS_ERR(msm_host->disp_en_gpio)) {
>> +pr_warn("%s: cannot get disp-enable-gpios %ld\n",
>> +__func__, PTR_ERR(msm_host->disp_en_gpio));
>> +msm_host->disp_en_gpio = NULL;
>> +}
>> +if (msm_host->disp_en_gpio) {
>> +ret = gpiod_direction_output(msm_host->disp_en_gpio, 0);
>> +if (ret) {
>> +pr_err("cannot set dir to disp-en-gpios %d\n", ret);
>> +return ret;
>> +}
>> +}
>> +
>> +msm_host->te_gpio = devm_gpiod_get(&msm_host->pdev->dev, "disp-te");
>> +if (IS_ERR(msm_host->te_gpio)) {
>> +pr_warn("%s: cannot get disp-te-gpios %ld\n",
>> +__func__, PTR_ERR(msm_host->te_gpio));
>
> Video mode panels won't have te_gpio, we could probably make this
> pr_debug()
>
>> +msm_host->te_gpio = NULL;
>> +}
>> +
>> +if (msm_host->te_gpio) {
>> +ret = gpiod_direction_input(msm_host->te_gpio);
>> +if (ret) {
>> +pr_err("%s: cannot set dir to disp-te-gpios, %d\n",
>> +__func__, ret);
>> +return ret;
>> +}
>> +}
>
> These gpios currently need to be declared under the dsi DT node. Even if
> these are controlled via the dsi host, the gpios should still come under
> the panel DT node.
>
> We shout get the panel's of_node here and look for these.
>

>> +static void dsi_sw_reset(struct msm_dsi_host *msm_host)
>> +{
>> +dsi_write(msm_host, REG_DSI_CLK_CTRL,
>> +DSI_CLK_CTRL_AHBS_HCLK_ON | DSI_CLK_CTRL_AHBM_SCLK_ON |
>> +DSI_CLK_CTRL_PCLK_ON | DSI_CLK_CTRL_DSICLK_ON |
>> +DSI_CLK_CTRL_BYTECLK_ON | DSI_CLK_CTRL_ESCCLK_ON |
>> +DSI_CLK_CTRL_FORCE_ON_DYN_AHBM_HCLK);
>
> The same 7 bits seem to be set elsewhere, maybe make this a macro
> DSI_ENABLE_CLKS or something similar?
>

>> +int msm_dsi_host_init(struct msm_dsi *msm_dsi)
>> +{
>> +struct msm_dsi_host *msm_host = NULL;
>> +struct platform_device *pdev = msm_dsi->pdev;
>> +int ret = 0;
>> +
>> +msm_host = devm_kzalloc(&pdev->dev, sizeof(*msm_host), GFP_KERNEL);
>> +if (!msm_host) {
>> +pr_err("%s: FAILED: cannot alloc dsi host\n",
>> +   __func__);
>> +ret = -ENOMEM;
>> +goto fail;
>> +}
>> +
>> +ret = of_property_read_u32(pdev->dev.of_node,
>> +"cell-index", &msm_host->id);
>
> retrieving the instance number of a peripheral via a DT property like
> 'cell-index' has been debated quite a bit in the past. I suppose it's
> not the best thing to do.
>
> However, since the DSI instances in MDSS aren't completely identical(one
> acts a master and other slave in dual dsi mode), maybe we can get away
> with having a property like "qcom,dsi-master;", and that can be further
> used to identify whether this node is DSI_0 or DSI_1
>

2 DSIs are not always master-slave mode. It is possible that a single
panel is connected to any of the hosts, or 2 panels are controlled
independently. If 'cell-index' is not allowed to specify the instance
number, i would prefer to have a simple property like
"qcom,dsi-host-index".

>> +int msm_dsi_host_register(struct mipi_dsi_host *host, bool check_defer)
>> +{
>> +struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
>> +struct device_node *node;
>> +int ret;
>> +
>> +/* Register mipi dsi host */
>> +if (!msm_host->registered) {
>> +host->dev = &msm_host->pdev->dev;
>> +host->ops = &dsi_host_ops;
>> +ret = mipi_dsi_host_register(host);
>> +if (ret)
>> +return ret;
>> +
>> +msm_host->registered = true;
>> +
>> +/* If the panel driver has not been probed after host register,
>> + * we should defer the host's probe.
>> + * It makes sure panel is connected when fbcon detects
>> + * connector status and gets the proper display mode to
>> + * create framebuffer.
>> + */
>> +if (check_defer) {
>> +node = of_parse_phandle(msm_host->pdev->dev.of_node,
>> +"qcom,panel", 0);
>> +if (node) {
>> +if (!of_drm_find_panel(node))
>> +return -EPROBE_DEFER;
>> +}
>> +}
>> +}
>
> We might have to defer probe multiple times before anot

[Bug 87796] radeonsi 120Hz graphic glitches

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #114443|0   |1
is obsolete||

--- Comment #26 from Alex Deucher  ---
Created attachment 114452
  --> https://bugs.freedesktop.org/attachment.cgi?id=114452&action=edit
possible fix

Does this patch against latest git help?

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

[Bug 89619] Chrome crashes in 64 bit r600 driver while running google maps

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

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

--- Comment #6 from Roland Scheidegger  ---
Ubuntu also ships updated mesa drivers as part of the hwe stacks, honestly I
don't know why they don't offer them as some kind of update with the
update-manager tool (if you'd download 14.04 lts now, you'd get the new version
automatically), so you have to install it manually.
https://wiki.ubuntu.com/Kernel/LTSEnablementStack
It won't be quite cutting edge but still quite a bit newer (10.3.2 in fact).

-- 
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/20150318/9422d330/attachment-0001.html>

[PATCH] radeon: Update Kaveri MEC firmware to #396

[Kyle McMartin]

On Sat, Mar 14, 2015 at 12:51:19AM +0200, Oded Gabbay wrote:
> This patch updates the Kaveri MEC firmware to #396 (from #391).
> The MEC firmware is mainly used for amdkfd - AMD's HSA Linux kernel driver.
> 
> Signed-off-by: Oded Gabbay 

applied, thanks.

[PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver

[Stefan Agner]

Hi Jianwei,

Normally, for the second and higher iteration of a patchset, developers
add the version to the subject (e.g. PATCH v2). You can use the
--reroll-count option when creating the patches with git format-patch.

On 2015-03-13 10:44, Jianwei Wang wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on Freescale SoCs.
> 
> 2D-ACE is a Freescale display controller. It provide an hardware
> cursor.
> 
> This is a simplified version, only a primary plane, a fb created for
> fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
> encoder is not in use.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
> 
> Changed in v2: 
> - Add atomic support
> - Modify bindings file
> - Rename node for compatibility
> - Move platform related code out for compatibility
> 
> Added in v1: 
> - Add support for DCU display controller on the Freescale LS102x SoCs.
> - Create a primary plane, a fb created for fbdev, a crtc, a connector
> for TFT LCD panel, an encoder.
> 
>  arch/arm/mach-imx/mach-ls1021a.c|  36 
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/fsl/Kconfig |  17 ++
>  drivers/gpu/drm/fsl/Makefile|   8 +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c | 203 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h |  28 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c  | 164 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h  |  26 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c   | 288 
> 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h   | 168 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c |  26 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c   |  42 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h   |  17 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c | 187 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h |  23 +++
>  include/linux/fsl/dcu.h |  22 +++
>  17 files changed, 1258 insertions(+)
>  create mode 100644 drivers/gpu/drm/fsl/Kconfig
>  create mode 100644 drivers/gpu/drm/fsl/Makefile
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
>  create mode 100644 include/linux/fsl/dcu.h
> 
> diff --git a/arch/arm/mach-imx/mach-ls1021a.c 
> b/arch/arm/mach-imx/mach-ls1021a.c
> index b89c858..4fb346d 100644
> --- a/arch/arm/mach-imx/mach-ls1021a.c
> +++ b/arch/arm/mach-imx/mach-ls1021a.c
> @@ -8,9 +8,44 @@
>   */
>  
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include "common.h"
>  
> +void dcu_pixclk_disable(void)
> +{
> + struct regmap *scfg_regmap;
> +
> + scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
> + if (IS_ERR(scfg_regmap)) {
> + pr_err("No syscfg phandle specified\n");
> + return;
> + }
> +
> + regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_DISABLE);
> +}
> +
> +void dcu_pixclk_enable(void)
> +{
> + struct regmap *scfg_regmap;
> +
> + scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
> + if (IS_ERR(scfg_regmap)) {
> + pr_err("No syscfg phandle specified\n");
> + return;
> + }
> +
> + regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_ENABLE);
> +}
> +
> +static void __init ls1021a_init_machine(void)
> +{
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> + dcu_pixclk_enable();
> +}

This change should be in a separate patch. However, I'm not convinced
that the current code is the right solution. You should try to avoid
calling from the driver directly into arch code.

I don't have access to the reference manual, hence I can't lookup that
module. But this register looks just like a clock gate...

On Vybrid, the Pixelclock is enabled through CCM_CSCDR3 and friends, and
the CCM module makes use of the common clock framework. In the end, the
clock is assigned to the nodes (e.g. DCU node in this case) and
requested during runtime. The framework makes sure the clock and the
relevant gates get enabled. See:
http://lxr.free-electrons.com/source/arch/arm/mach-imx/clk-vf610.c?v=3.12#L241

--
Stefan

>  static const char * const ls1021a_dt_compat[] __initconst = {
>   "fsl,l

[Intel-gfx] [patch] drm/i915: memory leak in __i915_gem_vma_create()

[Joonas Lahtinen]

On ke, 2015-03-18 at 09:41 +0100, Daniel Vetter wrote:
> On Wed, Mar 18, 2015 at 10:36:45AM +0200, Jani Nikula wrote:
> > On Wed, 18 Mar 2015, Dan Carpenter  wrote:
> > > In the original code then if WARN_ON(i915_is_ggtt(vm) != !!ggtt_view)
> > > was true then we leak "vma".  Presumably that doesn't happen often but
> > > static checkers complain and this bug is easy to fix.
> > >

Correct, it was originally BUG_ON and then relaxed down to a warning in
last series, so it slipped through. So it should practically be
impossible to happen, but suits well to make static checker happier.

Regards, Joonas

> > > Fixes: c3bbb6f2825d ('drm/i915: Do not use ggtt_view with (aliasing) 
> > > PPGTT')
> > > Signed-off-by: Dan Carpenter 
> > 
> > Reviewed-by: Jani Nikula 
> 
> Queued for -next, thanks for the patch.
> -Daniel
> 
> > 
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > index f1b9ea6..cbf013f 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > @@ -2340,12 +2340,13 @@ __i915_gem_vma_create(struct drm_i915_gem_object 
> > > *obj,
> > > struct i915_address_space *vm,
> > > const struct i915_ggtt_view *ggtt_view)
> > >  {
> > > - struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> > > - if (vma == NULL)
> > > - return ERR_PTR(-ENOMEM);
> > > + struct i915_vma *vma;
> > >  
> > >   if (WARN_ON(i915_is_ggtt(vm) != !!ggtt_view))
> > >   return ERR_PTR(-EINVAL);
> > > + vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> > > + if (vma == NULL)
> > > + return ERR_PTR(-ENOMEM);
> > >  
> > >   INIT_LIST_HEAD(&vma->vma_link);
> > >   INIT_LIST_HEAD(&vma->mm_list);
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

[PATCH] drm/omap: tiler: add hibernation callback

[grygorii.stras...@linaro.org]

Hi All,

On 02/25/2015 08:08 PM, grygorii.strashko at linaro.org wrote:
> From: Grygorii Strashko 
>
> Setting a dev_pm_ops resume callback but not a set of
> hibernation handler means that pm function will not be
> called upon hibernation.
> Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
> assigns the suspend and hibernation handlers and move
> omap_dmm_resume under CONFIG_PM_SLEEP to avoid build warnings.
>
> Signed-off-by: Grygorii Strashko 
> ---
>   drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 +++---
>   1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 56c6055..afb8cfc 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -941,7 +941,7 @@ error:
>   }
>   #endif
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
>   static int omap_dmm_resume(struct device *dev)
>   {
>   struct tcm_area area;
> @@ -965,12 +965,10 @@ static int omap_dmm_resume(struct device *dev)
>
>   return 0;
>   }
> -
> -static const struct dev_pm_ops omap_dmm_pm_ops = {
> - .resume = omap_dmm_resume,
> -};
>   #endif
>
> +SIMPLE_DEV_PM_OPS(omap_dmm_pm_ops, NULL, omap_dmm_resume);
> +
>   #if defined(CONFIG_OF)
>   static const struct of_device_id dmm_of_match[] = {
>   { .compatible = "ti,omap4-dmm", },
> @@ -986,9 +984,7 @@ struct platform_driver omap_dmm_driver = {
>   .owner = THIS_MODULE,
>   .name = DMM_DRIVER_NAME,
>   .of_match_table = of_match_ptr(dmm_of_match),
> -#ifdef CONFIG_PM
>   .pm = &omap_dmm_pm_ops,
> -#endif
>   },
>   };
>
>

Any comments on this?

-- 
regards,
-grygorii

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

[David Miller]

Use readb() and memcpy_fromio() accessors instead.

Signed-off-by: David S. Miller 

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 63ccb8f..d27e4cc 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -76,7 +76,7 @@ static bool igp_read_bios_from_vram(struct radeon_device 
*rdev)

 static bool radeon_read_bios(struct radeon_device *rdev)
 {
-   uint8_t __iomem *bios;
+   uint8_t __iomem *bios, val1, val2;
size_t size;

rdev->bios = NULL;
@@ -86,15 +86,19 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return false;
}

-   if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
+   val1 = readb(&bios[0]);
+   val2 = readb(&bios[1]);
+
+   if (size == 0 || val1 != 0x55 || val2 != 0xaa) {
pci_unmap_rom(rdev->pdev, bios);
return false;
}
-   rdev->bios = kmemdup(bios, size, GFP_KERNEL);
+   rdev->bios = kzalloc(size, GFP_KERNEL);
if (rdev->bios == NULL) {
pci_unmap_rom(rdev->pdev, bios);
return false;
}
+   memcpy_fromio(rdev->bios, bios, size);
pci_unmap_rom(rdev->pdev, bios);
return true;
 }