[PATCH V4 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

[Laxman Dewangan]

On Wednesday 11 May 2016 09:05 PM, Jon Hunter wrote:
> On 11/05/16 14:28, Laxman Dewangan wrote:
>> On Sunday 08 May 2016 05:43 PM, Jon Hunter wrote:
>>> On 06/05/16 16:32, Laxman Dewangan wrote:
 On Friday 06 May 2016 08:07 PM, Jon Hunter wrote:
> On 06/05/16 11:45, Laxman Dewangan wrote:
> +
> +/* Last entry */
> +TEGRA_IO_PAD_MAX,
> Nit should these be TEGRA_IO_PADS_xxx?
 Because this was name of single pad and hence I said TEGRA_IO_PAD_XXX.
>>> Aren't these used to set the voltage level and power state for the
>>> entire group of IOs? Confused :-(
>> One IO pad can have multiple IO pins.
>> IO Pad control the power state and voltage of all pins belongs to that
>> IO pad.
> Ugh ... I remember for xusb there was something similar we the Tegra
> docs used pad to imply multiple. However, in general pad == pin == ball
> or at least should.

when we say sddmc3 IO pads, we deal with all signal pins of sdmm3.

[PATCH] exynos: change the license to X11/MIT

[Emil Velikov]

Hi Inki, all,

On 10 May 2016 at 08:18, Inki Dae  wrote:
> This patch changes GPL license to X11/MIT.
>
As mentioned by Tobias, the commit messages should elaborate on the
summary - why the change is needed, how it's achieved.

Is this change due to my recent(ish) request on the topic of licenses,
because some distributions don't include GPL code or otherwise ?

In the first case, I was talking about the license miss-match between
the kernel and libdrm version of exynos_drm.h.
Whatever the reason, one should check with all contributors who
touched the files in question.

> Signed-off-by: Inki Dae 
> ---
>  exynos/exynos_fimg2d.c | 21 +
>  exynos/exynos_fimg2d.h | 21 +
>  exynos/fimg2d_reg.h| 21 +
>  tests/exynos/exynos_fimg2d_event.c | 27 +--
>  tests/exynos/exynos_fimg2d_perf.c  | 27 +--
>  tests/exynos/exynos_fimg2d_test.c  | 21 +
>  6 files changed, 102 insertions(+), 36 deletions(-)
>

$ git log  -- exynos/fimg2d_reg.h exynos/exynos_fimg2d.*
tests/exynos/exynos_fimg2d_* | grep ^Author | sort -u
Author: Daniel Kurtz 
Author: Emil Velikov 
Author: Inki Dae 
Author: Jan Vesely 
Author: Maarten Lankhorst  // check
with the linux kernel logs for alternative email
Author: Tobias Jakobi 

I doubt any of them will have objections, but still - do reach out for
confirmation. Personally I'm ok with either license, so
Acked-by: Emil Velikov 

Thanks
Emil

[PATCH] drm: mediatek: remove IOMMU_DMA select

[Arnd Bergmann]

On Wednesday 11 May 2016 22:11:07 Arnd Bergmann wrote:
> We get a harmless build warning when trying to use the mediatek
> DRM driver with IOMMU support disabled:
> 
> warning: (DRM_MEDIATEK) selects IOMMU_DMA which has unmet direct dependencies 
> (IOMMU_SUPPORT)
> 
> However, the IOMMU_DMA symbol is not meant to be used by drivers
> at all, and this driver doesn't seem to have a strict dependency
> on it other than using the mediatek IOMMU driver that does.
> 
> Since we also want to be able to do compile tests with the
> driver on other platforms, the IOMMU_DMA symbol should not
> be selected here.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> If someone has a better explanation about why the 'select' is here,
> let me know, it certainly seems out of place.

Sorry, I didn't mean to send this as a reply to "More build fixes for
omapdrm in current -next", I copied the wrong command line.

I'll resend it if necessary.

Arnd

[PATCH] drm: mediatek: remove IOMMU_DMA select

[Arnd Bergmann]

We get a harmless build warning when trying to use the mediatek
DRM driver with IOMMU support disabled:

warning: (DRM_MEDIATEK) selects IOMMU_DMA which has unmet direct dependencies 
(IOMMU_SUPPORT)

However, the IOMMU_DMA symbol is not meant to be used by drivers
at all, and this driver doesn't seem to have a strict dependency
on it other than using the mediatek IOMMU driver that does.

Since we also want to be able to do compile tests with the
driver on other platforms, the IOMMU_DMA symbol should not
be selected here.

Signed-off-by: Arnd Bergmann 
---
If someone has a better explanation about why the 'select' is here,
let me know, it certainly seems out of place.

 drivers/gpu/drm/mediatek/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 0c06a69d7f04..545973f6b743 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -7,7 +7,6 @@ config DRM_MEDIATEK
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
-   select IOMMU_DMA
select MEMORY
select MTK_SMI
help
-- 
2.7.0

[PATCH v2 6/6] drm: Add helper for simple display pipeline

[Noralf Trønnes]

Den 11.05.2016 21:10, skrev Paul Bolle:
> On wo, 2016-05-11 at 19:09 +0200, Daniel Vetter wrote:
>> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> +config DRM_SIMPLE_KMS_HELPER
>>> +   tristate
>>> +   depends on DRM
>>> +   select DRM_KMS_HELPER
>>> +   help
>>> + Helpers for very simple KMS drivers.
>> Personally not sold on piles of Kconfig knobs for tiny amounts of code
>> like this one. I'd just drop it. For a more elaborate argument see
>> http://sietch-tagr.blogspot.ch/2016/04/display-panels-are-not-special.html
>>
>> Note that almost all the other helpers do not have a Kconfig option, the
>> only real exception is the fbdev helpers. And those have a good reason:
>> They'd drag in all of fbdev, and that is actually a pile of code.
> Moreover, this adds a kconfig entry without a prompt. The entry also
> doesn't have a "default". And I didn't spot a patch adding a select for
> this symbol. So, based on just this series, I think that
> DRM_SIMPLE_KMS_HELPER can't actually be set.
>
> I didn't test this, so perhaps I missed something. Did I, Noralf?

It would have been selected in the tinydrm follow-up patchset, but
I'll do as Daniel suggests and add it to drm_kms_helper-y.

Noralf.

[PATCH v2 6/6] drm: Add helper for simple display pipeline

[Noralf Trønnes]

Den 11.05.2016 19:09, skrev Daniel Vetter:
> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:
>> Provides helper functions for drivers that have a simple display
>> pipeline. Plane, crtc and encoder are collapsed into one entity.
>>
>> Signed-off-by: Noralf Trønnes 
> Looks really nice, just a few suggestions for the kerneldoc. Would be
> awesome if we could get an ack on this from Jyri for tilcdc, but even
> without that I think I'll just pull in the next iteration. Still please cc
> him.
>
> Thanks, Daniel

Thanks for helping me with the docs.

[...]

>> +static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
>> +struct drm_plane_state *plane_state)
>> +{
>> +struct drm_rect src = {
>> +.x1 = plane_state->src_x,
>> +.y1 = plane_state->src_y,
>> +.x2 = plane_state->src_x + plane_state->src_w,
>> +.y2 = plane_state->src_y + plane_state->src_h,
>> +};
>> +struct drm_rect dest = {
>> +.x1 = plane_state->crtc_x,
>> +.y1 = plane_state->crtc_y,
>> +.x2 = plane_state->crtc_x + plane_state->crtc_w,
>> +.y2 = plane_state->crtc_y + plane_state->crtc_h,
>> +};
>> +struct drm_rect clip = { 0 };
>> +struct drm_simple_display_pipe *pipe;
>> +struct drm_crtc_state *crtc_state;
>> +bool visible;
>> +int ret;
>> +
>> +pipe = container_of(plane, struct drm_simple_display_pipe, plane);
>> +crtc_state = drm_atomic_get_existing_crtc_state(plane_state->state,
>> +>crtc);
>> +if (crtc_state->enable != !!plane_state->crtc)
>> +return -EINVAL; /* plane must match crtc enable state */
>> +
>> +if (!crtc_state->enable)
>> +return 0; /* nothing to check when disabling or disabled */
>> +
>> +clip.x2 = crtc_state->adjusted_mode.hdisplay;
>> +clip.y2 = crtc_state->adjusted_mode.vdisplay;
>> +ret = drm_plane_helper_check_update(plane, >crtc,
>> +plane_state->fb,
>> +, , ,
>> +DRM_PLANE_HELPER_NO_SCALING,
>> +DRM_PLANE_HELPER_NO_SCALING,
>> +false, true, );
>> +if (ret)
>> +return ret;
>> +
>> +if (!visible)
>> +return -EINVAL;
> I think the logic above looks correct now, but might be worth checking
> with your driver that it doesn't let something silly through. I.e. a small
> test app that tries to reposition the primary plane, or tries to disable
> it while the crtc is on. We should have that somewhere in libdrm I think.

I hacked libdrm tests/kms/kms-universal-planes to position the plane
at (1,1) which failed (I added some debug output to the driver):

[  885.906697] [drm:drm_atomic_set_fb_for_plane] Set [FB:25] for plane 
state b84aec40
[  885.906707] [drm:drm_atomic_check_only] checking b84aeec0
[  885.906738] [drm:drm_plane_helper_check_update] Plane must cover 
entire CRTC
[  885.906748] [drm:drm_rect_debug_print] dst: 319x239+1+1
[  885.906757] [drm:drm_rect_debug_print] clip: 320x240+0+0
[  885.906765] drm_simple_kms_plane_atomic_check: ret=-22, visible=1
[  885.906775] [drm:drm_atomic_helper_check_planes] [PLANE:19:plane-0] 
atomic driver check failed

Then I changed the test to pass 0 for fb id which also failed:

[ 3144.599790] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane 
state b87805c0
[ 3144.599799] [drm:drm_atomic_check_only] checking b8780d80
[ 3144.599816] [drm:drm_atomic_helper_check_planes] [PLANE:19:plane-0] 
atomic driver check failed


Noralf.

[GIT PULL] omapdrm changes for 4.7

[Emil Velikov]

On 10 May 2016 at 07:18, Tomi Valkeinen  wrote:
> Hi Emil,
>
> On 09/05/16 23:24, Emil Velikov wrote:
>> Hi Tomi,
>>
>> On 9 May 2016 at 10:18, Tomi Valkeinen  wrote:
>>> Hi Dave,
>>>
>>> Sorry for being so late with this pull request. It contains mostly
>>> small fixes to omapdrm, so I hope it can still make it.
>>>
>>>  Tomi
>>>
>>> The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
>>>
>>>   Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
>>> tags/omapdrm-4.7
>>>
>>> for you to fetch changes up to 193e0f3cbd0fe8a76fa115f0f52ffbc8892f46c8:
>>>
>>>   Revert "drm/omap: no need to select OMAP2_DSS" (2016-05-09 12:11:30 +0300)
>>>
>>> 
>>> omapdrm changes for v4.7
>>>
>>> * Add tilcdc and omapdrm maintainers to MAINTAINERS
>>> * Add reset-gpio and vcc-regulator support to panel-dpi
>>> * Small fixes to omapdrm
>>>
>>> 
>>> Jim Lodes (2):
>>>   OMAPDSS: HDMI5: Fix AVI infoframe
>>>   OMAPDSS: HDMI5: Change DDC timings
>>>
>>> Peter Ujfalusi (2):
>>>   drm/omap: Remove deprecated regulator_can_change_voltage() usage
>>>   Revert "drm/omap: no need to select OMAP2_DSS"
>>>
>>> Tomi Valkeinen (8):
>>>   drm/omap: Fix missing includes
>>>   drm/omap: remove unneeded gpio includes
>>>   drm/omap: remove unnecessary pitch round-up
>>>   drm/omap: remove align_pitch()
>>>   drm/omap: fix pitch round-up
>>>   drm/omap: fix OMAP4 hdmi_core_powerdown_disable()
>>>   MAINTAINERS: Add maintainer for OMAP DRM driver
>>>   MAINTAINERS: Add maintainer for TI LCDC DRM driver
>>>
>>> Uwe Kleine-König (3):
>>>   devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
>> I believe that this should be acked by Thierry.
>
> That panel-dpi is omapdrm specific panel-dpi, but yes, Thierry should've
> been included in the thread.
>
Ahh yes. I've wrongly assumed that the file covers the DRM 'flavour'
as it's listed alongside it with Thierry as maintainer. Silly me
should not blindly trust the MAINTAINERS file.

>>
>>>   drm/omap: panel-dpi: make (limited) use of a reset gpio
>>>   drm/omap: panel-dpi: implement support for a vcc regulator
>>>
>> /me mutters something about moving to drm panel as opposed to the omap one.
>>
>> It is on the TODO list, right ? I hope it's somewhere in the upper half of 
>> it.
>
> It's on the TODO list.
>
> I took these panel-dpi patches as they were for an already existing
> driver and looked trivial enough, but I haven't added new panel/encoder
> drivers for a while. In fact, I've been holding out from upstreaming a
> bunch of encoder/panel drivers from TI's kernel as they're omapdrm based.
>
> Moving to DRM encoders and panels is a huge change, and probably
> requires rewriting good part of omapdrm and omapdss drivers. And then
> porting all the encoder and panel drivers to DRM.
>
> So I'm not sure when I can start on that work, but even when I do, I
> expect it to take a rather long time. But I know my life would be easier
> after that change, so I very much like to make it happen.
>
Glad to hear that it's in the list.

>From my (never looked at the omapdrm code) POV, you might have easier
time approaching it from the other end.
Copy/create DRM bridge drivers and leave the omap ones round. Ideally
by that time people would have reworked things and nuked the DRM
encoders into orbit, at which point one can convert the omap ones and
finally slow and steadily convert omapdrm.
And finally kill the omap bridge/encoder drivers.

Just my 2c, as they say.

Regards,
Emil

[PATCH v2 6/6] drm: Add helper for simple display pipeline

[Paul Bolle]

On wo, 2016-05-11 at 19:09 +0200, Daniel Vetter wrote:
> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:

> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig

> > +config DRM_SIMPLE_KMS_HELPER
> > +   tristate
> > +   depends on DRM
> > +   select DRM_KMS_HELPER
> > +   help
> > + Helpers for very simple KMS drivers.
> 
> Personally not sold on piles of Kconfig knobs for tiny amounts of code
> like this one. I'd just drop it. For a more elaborate argument see
> http://sietch-tagr.blogspot.ch/2016/04/display-panels-are-not-special.html
> 
> Note that almost all the other helpers do not have a Kconfig option, the
> only real exception is the fbdev helpers. And those have a good reason:
> They'd drag in all of fbdev, and that is actually a pile of code.

Moreover, this adds a kconfig entry without a prompt. The entry also
doesn't have a "default". And I didn't spot a patch adding a select for
this symbol. So, based on just this series, I think that
DRM_SIMPLE_KMS_HELPER can't actually be set.

I didn't test this, so perhaps I missed something. Did I, Noralf?


Paul Bolle

[PATCH V4 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

[Jon Hunter]

On 11/05/16 18:22, Laxman Dewangan wrote:
> 
> On Wednesday 11 May 2016 09:05 PM, Jon Hunter wrote:
>> On 11/05/16 14:28, Laxman Dewangan wrote:
>>> On Sunday 08 May 2016 05:43 PM, Jon Hunter wrote:
 On 06/05/16 16:32, Laxman Dewangan wrote:
> On Friday 06 May 2016 08:07 PM, Jon Hunter wrote:
>> On 06/05/16 11:45, Laxman Dewangan wrote:
>> +
>> +/* Last entry */
>> +TEGRA_IO_PAD_MAX,
>> Nit should these be TEGRA_IO_PADS_xxx?
> Because this was name of single pad and hence I said TEGRA_IO_PAD_XXX.
 Aren't these used to set the voltage level and power state for the
 entire group of IOs? Confused :-(
>>> One IO pad can have multiple IO pins.
>>> IO Pad control the power state and voltage of all pins belongs to that
>>> IO pad.
>> Ugh ... I remember for xusb there was something similar we the Tegra
>> docs used pad to imply multiple. However, in general pad == pin == ball
>> or at least should.
> 
> when we say sddmc3 IO pads, we deal with all signal pins of sdmm3.

Right but now you are saying io-pads and not io-pad. Yes io-pads would
mean more than one, but IMO io-pad implies singular. Anyway, enough
bike-shedding ...

Jon

[Bug 95206] Display port bandwidth regression

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

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

--- Comment #11 from Alex Deucher  ---
Created attachment 123629
  --> https://bugs.freedesktop.org/attachment.cgi?id=123629=edit
possible fix

This patch should fix it.

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

[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics

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

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

--- Comment #10 from chico76  ---
Does anyone have any idea in wich kernel version the OLAND chip startet to
fail?
Maybe i can try to bisect the kernel if I new a version when it was working..

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

[PATCH] MAINTAINERS: add entry for the Sync File Framework

[Sumit Semwal]

Hi Gustavo,

On 11 May 2016 at 19:15, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> Add Gustavo as maintainer for the Sync File Framework. Sumit is
> co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
> tree as base.
>
> Cc: Sumit Semwal 
> Signed-off-by: Gustavo Padovan 

With the de-staging patches going through staging,  perhaps we should add an
Acked-by: Sumit Semwal 
and request Greg to take it via the same?
> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8c10b4c..0abc9c3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3677,6 +3677,16 @@ F:   include/linux/*fence.h
>  F: Documentation/dma-buf-sharing.txt
>  T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
>
> +SYNC FILE FRAMEWORK
> +M: Gustavo Padovan 
> +S: Maintained
> +L: linux-media at vger.kernel.org
> +L: dri-devel at lists.freedesktop.org
> +F: drivers/dma-buf/sync_file.c
> +F: include/linux/sync_file.h
> +F: Documentation/sync_file.txt
> +T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
> +
>  DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
>  M: Vinod Koul 
>  L: dmaengine at vger.kernel.org
> --
> 2.5.5
>

[GIT PULL 2nd] drm-hisilicon-next for 4.7

[Xinliang Liu]

Hi Dave,

This 2nd pull request includes 3 cleanup/fixes since last pull request for 4.7.

These patches are review here:
http://www.spinics.net/lists/dri-devel/msg106701.html
http://www.spinics.net/lists/dri-devel/msg106822.html

Please kindly let me know if there is any problem.

Best,
-xinliang

The following changes since commit 2e726dc4b4e2dd3ae3fe675f9d3af88a2d593ee1:

  Merge tag 'mediatek-drm-2016-05-09' of
git://git.pengutronix.de/git/pza/linux into drm-next (2016-05-10
15:01:47 +1000)

are available in the git repository at:

  git at github.com:xin3liang/linux.git drm-hisilicon-next

for you to fetch changes up to 1658437704d9f41eae2946774bdf2966245f:

  drm/hisilicon: Fix DRM_INFO printed issue (2016-05-11 19:05:36 +0800)


Daniel Vetter (1):
  drm/hisilicon: Use drm_connector_register_all

Xinliang Liu (2):
  drm/hisilicon: Make kirin_drm_unbind sufficient
  drm/hisilicon: Fix DRM_INFO printed issue

 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c|  3 ++-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38
+++---
 2 files changed, 9 insertions(+), 32 deletions(-)

[PATCH v2 6/6] drm: Add helper for simple display pipeline

[Daniel Vetter]

On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:
> Provides helper functions for drivers that have a simple display
> pipeline. Plane, crtc and encoder are collapsed into one entity.
> 
> Signed-off-by: Noralf Trønnes 

Looks really nice, just a few suggestions for the kerneldoc. Would be
awesome if we could get an ack on this from Jyri for tilcdc, but even
without that I think I'll just pull in the next iteration. Still please cc
him.

Thanks, Daniel

> ---
> 
> Changes since v1:
> - Add DOC header and add to gpu.tmpl
> - Fix docs: @funcs is optional, "negative error code",
>   "This hook is optional."
> - Add checks to drm_simple_kms_plane_atomic_check()
> 
>  Documentation/DocBook/gpu.tmpl  |   6 +
>  drivers/gpu/drm/Kconfig |   7 ++
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/drm_simple_kms_helper.c | 200 
> 
>  include/drm/drm_simple_kms_helper.h |  92 +++
>  5 files changed, 306 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
>  create mode 100644 include/drm/drm_simple_kms_helper.h
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 4a0c599..cf3f5a8 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
>  !Edrivers/gpu/drm/drm_panel.c
>  !Pdrivers/gpu/drm/drm_panel.c drm panel
>  
> +
> +  Simple KMS Helper Reference
> +!Iinclude/drm/drm_simple_kms_helper.h
> +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> +
>
> 
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 16e4c21..ff9f480 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -39,6 +39,13 @@ config DRM_KMS_HELPER
>   help
> CRTC helpers for KMS drivers.
> 
> +config DRM_SIMPLE_KMS_HELPER
> + tristate
> + depends on DRM
> + select DRM_KMS_HELPER
> + help
> +   Helpers for very simple KMS drivers.

Personally not sold on piles of Kconfig knobs for tiny amounts of code
like this one. I'd just drop it. For a more elaborate argument see

http://sietch-tagr.blogspot.ch/2016/04/display-panels-are-not-special.html

Note that almost all the other helpers do not have a Kconfig option, the
only real exception is the fbdev helpers. And those have a good reason:
They'd drag in all of fbdev, and that is actually a pile of code.

> +
>  config DRM_KMS_FB_HELPER
>   bool
>   depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 43c2abf..7e99923 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,6 +31,7 @@ drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += 
> drm_fb_cma_helper.o
>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> 
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> +obj-$(CONFIG_DRM_SIMPLE_KMS_HELPER) += drm_simple_kms_helper.o
> 
>  CFLAGS_drm_trace_points.o := -I$(src)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> new file mode 100644
> index 000..64bf0f2
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -0,0 +1,200 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * DOC: overview
> + *
> + * This helper library provides helpers for simple drivers.

"drivers for simple display hardware" is imo clearer.

> + *
> + * drm_simple_display_pipe_init() initializes a simple display pipeline
> + * consisting of a plane-crtc-encoder pipe coupled with a connector.

Hm, I think a bit more text here would be useful.

"drm_simple_display_pipe_init() initializes a simple display pipeline
which has only one full-screen scanout buffer feeding one output. The
pipeline is represented by struct _simple_display_pipe and binds
together _plane, _crtc and _encoder structures into one fixed
entity. Some flexibility for code reuse is provided through a separately
allocated _connector object and supporting optional _bridge
encoder drivers.

> + */
> +
> +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> + if (!pipe->funcs || !pipe->funcs->enable)
> + return;
> +
> + pipe->funcs->enable(pipe, 

[PATCH V4 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

[Laxman Dewangan]

On Sunday 08 May 2016 05:43 PM, Jon Hunter wrote:
> On 06/05/16 16:32, Laxman Dewangan wrote:
>> On Friday 06 May 2016 08:07 PM, Jon Hunter wrote:
>>> On 06/05/16 11:45, Laxman Dewangan wrote:
>>> +
>>> +/* Last entry */
>>> +TEGRA_IO_PAD_MAX,
>>> Nit should these be TEGRA_IO_PADS_xxx?
>> Because this was name of single pad and hence I said TEGRA_IO_PAD_XXX.
> Aren't these used to set the voltage level and power state for the
> entire group of IOs? Confused :-(

One IO pad can have multiple IO pins.
IO Pad control the power state and voltage of all pins belongs to that 
IO pad.


Now what should we say PADS or PAD here? TEGRA_IO_PAD_UART or 
TEGRA_IO_PADS_UART?


 +};
 +
 +/* tegra_io_pads_source_voltage: The voltage level of IO rails which
 source
 + * the IO pads.
 + */
 +enum tegra_io_pads_source_voltage {
 +TEGRA_IO_PADS_SOURCE_VOLTAGE_180UV,
 +TEGRA_IO_PADS_SOURCE_VOLTAGE_330UV,
 +};
>>> Nit I wonder if we can make this shorter ...
>>>
>>> enum tegra_io_pads_vconf {
>>>  TEGRA_IO_PADS_VCONF_1V8,
>>>  TEGRA_IO_PADS_VCONF_3V3,
>> This looks good but for voltage and current, unit is used uV/uV across
>> the system. So wanted to have same unit.
> Now it is an enum does it matter? Or maybe just have ...
>
> enum tegra_io_pads_vconf {
>   TEGRA_IO_PADS_180UV,
>   TEGRA_IO_PADS_330UV,
> };
>

OK, TEGRA_IO_PADS_VCONF_180UV and TEGRA_IO_PADS_VCONF_330UV.
Fine?

[PATCH v2 5/6] drm/atomic: Add drm_atomic_helper_best_encoder()

[Daniel Vetter]

On Wed, May 11, 2016 at 06:09:21PM +0200, Noralf Trønnes wrote:
> Add (struct drm_connector_helper_funcs *)->best_encoder callback helper
> for connectors that support exactly 1 encoder, statically determined at
> driver init time.
> 
> Signed-off-by: Noralf Trønnes 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 17 +
>  include/drm/drm_atomic_helper.h |  2 ++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 46a3201..43a0b3d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2483,6 +2483,23 @@ backoff:
>  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>  
>  /**
> + * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
> + *  ->best_encoder callback
> + * @connector: Connector control structure
> + *
> + * This is a _connector_helper_funcs ->best_encoder callback helper for
> + * connectors that support exactly 1 encoder, statically determined at driver
> + * init time.
> + */
> +struct drm_encoder *
> +drm_atomic_helper_best_encoder(struct drm_connector *connector)
> +{
> + WARN_ON(connector->encoder_ids[1]);
> + return drm_encoder_find(connector->dev, connector->encoder_ids[0]);
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
> +
> +/**
>   * DOC: atomic state reset and initialization
>   *
>   * Both the drm core and the atomic helpers assume that there is always the 
> full
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 0364287..ccca709 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -110,6 +110,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   uint32_t flags);
>  int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
>int mode);
> +struct drm_encoder *
> +drm_atomic_helper_best_encoder(struct drm_connector *connector);
>  
>  /* default implementations for state handling */
>  void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
> -- 
> 2.8.2
> 

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

[PATCH v2 4/6] drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs

[Daniel Vetter]

On Wed, May 11, 2016 at 06:09:20PM +0200, Noralf Trønnes wrote:
> Don't skip drm_bridge_*() calls if encoder->helper_private is NULL.
> 
> Signed-off-by: Noralf Trønnes 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 39 
> -
>  1 file changed, 17 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 027b227..46a3201 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -384,8 +384,6 @@ mode_fixup(struct drm_atomic_state *state)
>*/
>   encoder = conn_state->best_encoder;
>   funcs = encoder->helper_private;
> - if (!funcs)
> - continue;
>  
>   ret = drm_bridge_mode_fixup(encoder->bridge, _state->mode,
>   _state->adjusted_mode);
> @@ -394,7 +392,7 @@ mode_fixup(struct drm_atomic_state *state)
>   return -EINVAL;
>   }
>  
> - if (funcs->atomic_check) {
> + if (funcs && funcs->atomic_check) {
>   ret = funcs->atomic_check(encoder, crtc_state,
> conn_state);
>   if (ret) {
> @@ -402,7 +400,7 @@ mode_fixup(struct drm_atomic_state *state)
>encoder->base.id, 
> encoder->name);
>   return ret;
>   }
> - } else if (funcs->mode_fixup) {
> + } else if (funcs && funcs->mode_fixup) {
>   ret = funcs->mode_fixup(encoder, _state->mode,
>   _state->adjusted_mode);
>   if (!ret) {
> @@ -696,8 +694,6 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   continue;
>  
>   funcs = encoder->helper_private;
> - if (!funcs)
> - continue;
>  
>   DRM_DEBUG_ATOMIC("disabling [ENCODER:%d:%s]\n",
>encoder->base.id, encoder->name);
> @@ -709,12 +705,14 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   drm_bridge_disable(encoder->bridge);
>  
>   /* Right function depends upon target state. */
> - if (connector->state->crtc && funcs->prepare)
> - funcs->prepare(encoder);
> - else if (funcs->disable)
> - funcs->disable(encoder);
> - else if (funcs->dpms)
> - funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
> + if (funcs) {
> + if (connector->state->crtc && funcs->prepare)
> + funcs->prepare(encoder);
> + else if (funcs->disable)
> + funcs->disable(encoder);
> + else if (funcs->dpms)
> + funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
> + }
>  
>   drm_bridge_post_disable(encoder->bridge);
>   }
> @@ -861,9 +859,6 @@ crtc_set_mode(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>  
>   encoder = connector->state->best_encoder;
>   funcs = encoder->helper_private;
> - if (!funcs)
> - continue;
> -
>   new_crtc_state = connector->state->crtc->state;
>   mode = _crtc_state->mode;
>   adjusted_mode = _crtc_state->adjusted_mode;
> @@ -878,7 +873,7 @@ crtc_set_mode(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>* Each encoder has at most one connector (since we always steal
>* it away), so we won't call mode_set hooks twice.
>*/
> - if (funcs->mode_set)
> + if (funcs && funcs->mode_set)
>   funcs->mode_set(encoder, mode, adjusted_mode);
>  
>   drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
> @@ -969,8 +964,6 @@ void drm_atomic_helper_commit_modeset_enables(struct 
> drm_device *dev,
>  
>   encoder = connector->state->best_encoder;
>   funcs = encoder->helper_private;
> - if (!funcs)
> - continue;
>  
>   DRM_DEBUG_ATOMIC("enabling [ENCODER:%d:%s]\n",
>encoder->base.id, encoder->name);
> @@ -981,10 +974,12 @@ void drm_atomic_helper_commit_modeset_enables(struct 
> drm_device *dev,
>*/
>   drm_bridge_pre_enable(encoder->bridge);
>  
> - if (funcs->enable)
> - funcs->enable(encoder);
> - else if (funcs->commit)
> - funcs->commit(encoder);
> + if (funcs) {
> + if (funcs->enable)

[PATCH v2 2/6] drm/fb-cma-helper: Hook up to DocBook and fix some docs

[Daniel Vetter]

On Wed, May 11, 2016 at 06:09:18PM +0200, Noralf Trønnes wrote:
> Hook up fb_cma_helper to DocBook. Remove mention of
> CONFIG_FB_DEFERRED_IO in the docs, which was forgotten in the latest
> version of the deferred_io patch.
> Use & when referencing drm_mode_config_funcs in docs.
> 
> Signed-off-by: Noralf Trønnes 

First two patches applied to drm-misc, thanks.
-Daniel

> ---
>  Documentation/DocBook/gpu.tmpl  | 5 +
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 9dd48f7..4a0c599 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1617,6 +1617,11 @@ void intel_crt_init(struct drm_device *dev)
>  !Iinclude/drm/drm_fb_helper.h
>  
>  
> +  Framebuffer CMA Helper Functions Reference
> +!Pdrivers/gpu/drm/drm_fb_cma_helper.c framebuffer cma helper functions
> +!Edrivers/gpu/drm/drm_fb_cma_helper.c
> +
> +
>Display Port Helper Functions Reference
>  !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
>  !Iinclude/drm/drm_dp_helper.h
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 086f600..3165ac0 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -43,14 +43,12 @@ struct drm_fbdev_cma {
>   * Provides helper functions for creating a cma (contiguous memory allocator)
>   * backed framebuffer.
>   *
> - * drm_fb_cma_create() is used in the
> - * (struct drm_mode_config_funcs *)->fb_create callback function to create 
> the
> - * cma backed framebuffer.
> + * drm_fb_cma_create() is used in the _mode_config_funcs ->fb_create
> + * callback function to create a cma backed framebuffer.
>   *
>   * An fbdev framebuffer backed by cma is also available by calling
>   * drm_fbdev_cma_init(). drm_fbdev_cma_fini() tears it down.
> - * If CONFIG_FB_DEFERRED_IO is enabled and the callback
> - * (struct drm_framebuffer_funcs)->dirty is set, fb_deferred_io
> + * If the _framebuffer_funcs ->dirty callback is set, fb_deferred_io
>   * will be set up automatically. dirty() is called by
>   * drm_fb_helper_deferred_io() in process context (struct delayed_work).
>   *
> -- 
> 2.8.2
> 

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

[Bug 70711] Audio hdmi

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

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

--- Comment #17 from Alex Deucher  ---
The submitter needs to close it.

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

[Bug 70711] Audio hdmi

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

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

mirh  changed:

   What|Removed |Added

 CC||mirh at protonmail.ch

--- Comment #16 from mirh  ---
Couldn't this get closed?

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

[PATCH v2 6/6] drm: Add helper for simple display pipeline

[Noralf Trønnes]

Provides helper functions for drivers that have a simple display
pipeline. Plane, crtc and encoder are collapsed into one entity.

Signed-off-by: Noralf Trønnes 
---

Changes since v1:
- Add DOC header and add to gpu.tmpl
- Fix docs: @funcs is optional, "negative error code",
  "This hook is optional."
- Add checks to drm_simple_kms_plane_atomic_check()

 Documentation/DocBook/gpu.tmpl  |   6 +
 drivers/gpu/drm/Kconfig |   7 ++
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_simple_kms_helper.c | 200 
 include/drm/drm_simple_kms_helper.h |  92 +++
 5 files changed, 306 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
 create mode 100644 include/drm/drm_simple_kms_helper.h

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 4a0c599..cf3f5a8 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
 !Edrivers/gpu/drm/drm_panel.c
 !Pdrivers/gpu/drm/drm_panel.c drm panel
 
+
+  Simple KMS Helper Reference
+!Iinclude/drm/drm_simple_kms_helper.h
+!Edrivers/gpu/drm/drm_simple_kms_helper.c
+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
+
   

   
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 16e4c21..ff9f480 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -39,6 +39,13 @@ config DRM_KMS_HELPER
help
  CRTC helpers for KMS drivers.

+config DRM_SIMPLE_KMS_HELPER
+   tristate
+   depends on DRM
+   select DRM_KMS_HELPER
+   help
+ Helpers for very simple KMS drivers.
+
 config DRM_KMS_FB_HELPER
bool
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 43c2abf..7e99923 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += 
drm_fb_cma_helper.o
 drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o

 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
+obj-$(CONFIG_DRM_SIMPLE_KMS_HELPER) += drm_simple_kms_helper.o

 CFLAGS_drm_trace_points.o := -I$(src)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
new file mode 100644
index 000..64bf0f2
--- /dev/null
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * This helper library provides helpers for simple drivers.
+ *
+ * drm_simple_display_pipe_init() initializes a simple display pipeline
+ * consisting of a plane-crtc-encoder pipe coupled with a connector.
+ */
+
+static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->enable)
+   return;
+
+   pipe->funcs->enable(pipe, crtc->state);
+}
+
+static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->disable)
+   return;
+
+   pipe->funcs->disable(pipe);
+}
+
+static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
+   .disable = drm_simple_kms_crtc_disable,
+   .enable = drm_simple_kms_crtc_enable,
+};
+
+static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
+   .reset = drm_atomic_helper_crtc_reset,
+   .destroy = drm_crtc_cleanup,
+   .set_config = drm_atomic_helper_set_config,
+   .page_flip = drm_atomic_helper_page_flip,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *plane_state)
+{
+   struct drm_rect src = {
+   .x1 = plane_state->src_x,
+   .y1 = plane_state->src_y,
+   .x2 = plane_state->src_x + plane_state->src_w,
+   .y2 = plane_state->src_y + plane_state->src_h,
+   };
+   struct drm_rect dest = {
+   .x1 = plane_state->crtc_x,
+   .y1 = plane_state->crtc_y,
+   .x2 = 

[PATCH v2 5/6] drm/atomic: Add drm_atomic_helper_best_encoder()

[Noralf Trønnes]

Add (struct drm_connector_helper_funcs *)->best_encoder callback helper
for connectors that support exactly 1 encoder, statically determined at
driver init time.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_atomic_helper.c | 17 +
 include/drm/drm_atomic_helper.h |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 46a3201..43a0b3d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2483,6 +2483,23 @@ backoff:
 EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);

 /**
+ * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
+ *  ->best_encoder callback
+ * @connector: Connector control structure
+ *
+ * This is a _connector_helper_funcs ->best_encoder callback helper for
+ * connectors that support exactly 1 encoder, statically determined at driver
+ * init time.
+ */
+struct drm_encoder *
+drm_atomic_helper_best_encoder(struct drm_connector *connector)
+{
+   WARN_ON(connector->encoder_ids[1]);
+   return drm_encoder_find(connector->dev, connector->encoder_ids[0]);
+}
+EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
+
+/**
  * DOC: atomic state reset and initialization
  *
  * Both the drm core and the atomic helpers assume that there is always the 
full
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 0364287..ccca709 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -110,6 +110,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
uint32_t flags);
 int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
 int mode);
+struct drm_encoder *
+drm_atomic_helper_best_encoder(struct drm_connector *connector);

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

[PATCH v2 4/6] drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs

[Noralf Trønnes]

Don't skip drm_bridge_*() calls if encoder->helper_private is NULL.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_atomic_helper.c | 39 -
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 027b227..46a3201 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -384,8 +384,6 @@ mode_fixup(struct drm_atomic_state *state)
 */
encoder = conn_state->best_encoder;
funcs = encoder->helper_private;
-   if (!funcs)
-   continue;

ret = drm_bridge_mode_fixup(encoder->bridge, _state->mode,
_state->adjusted_mode);
@@ -394,7 +392,7 @@ mode_fixup(struct drm_atomic_state *state)
return -EINVAL;
}

-   if (funcs->atomic_check) {
+   if (funcs && funcs->atomic_check) {
ret = funcs->atomic_check(encoder, crtc_state,
  conn_state);
if (ret) {
@@ -402,7 +400,7 @@ mode_fixup(struct drm_atomic_state *state)
 encoder->base.id, 
encoder->name);
return ret;
}
-   } else if (funcs->mode_fixup) {
+   } else if (funcs && funcs->mode_fixup) {
ret = funcs->mode_fixup(encoder, _state->mode,
_state->adjusted_mode);
if (!ret) {
@@ -696,8 +694,6 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
continue;

funcs = encoder->helper_private;
-   if (!funcs)
-   continue;

DRM_DEBUG_ATOMIC("disabling [ENCODER:%d:%s]\n",
 encoder->base.id, encoder->name);
@@ -709,12 +705,14 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
drm_bridge_disable(encoder->bridge);

/* Right function depends upon target state. */
-   if (connector->state->crtc && funcs->prepare)
-   funcs->prepare(encoder);
-   else if (funcs->disable)
-   funcs->disable(encoder);
-   else if (funcs->dpms)
-   funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
+   if (funcs) {
+   if (connector->state->crtc && funcs->prepare)
+   funcs->prepare(encoder);
+   else if (funcs->disable)
+   funcs->disable(encoder);
+   else if (funcs->dpms)
+   funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
+   }

drm_bridge_post_disable(encoder->bridge);
}
@@ -861,9 +859,6 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)

encoder = connector->state->best_encoder;
funcs = encoder->helper_private;
-   if (!funcs)
-   continue;
-
new_crtc_state = connector->state->crtc->state;
mode = _crtc_state->mode;
adjusted_mode = _crtc_state->adjusted_mode;
@@ -878,7 +873,7 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)
 * Each encoder has at most one connector (since we always steal
 * it away), so we won't call mode_set hooks twice.
 */
-   if (funcs->mode_set)
+   if (funcs && funcs->mode_set)
funcs->mode_set(encoder, mode, adjusted_mode);

drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
@@ -969,8 +964,6 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,

encoder = connector->state->best_encoder;
funcs = encoder->helper_private;
-   if (!funcs)
-   continue;

DRM_DEBUG_ATOMIC("enabling [ENCODER:%d:%s]\n",
 encoder->base.id, encoder->name);
@@ -981,10 +974,12 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,
 */
drm_bridge_pre_enable(encoder->bridge);

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

[PATCH v2 3/6] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

[Noralf Trønnes]

Add drm_fb_cma_create_with_funcs() for drivers that need to set the
dirty() callback.

Cc: laurent.pinchart at ideasonboard.com
Signed-off-by: Noralf Trønnes 
---

Changes since v1:
- Expand docs

 drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
 include/drm/drm_fb_cma_helper.h |  3 +++
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 3165ac0..ede77c9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct 
drm_device *dev,
 }

 /**
- * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create callback 
function
+ * drm_fb_cma_create_with_funcs() - helper function for the
+ *  _mode_config_funcs ->fb_create
+ *  callback function
  *
- * If your hardware has special alignment or pitch requirements these should be
- * checked before calling this function.
+ * This can be used to set _framebuffer_funcs for drivers that need the
+ * dirty() callback. Use drm_fb_cma_create() if you don't need to change
+ * _framebuffer_funcs.
  */
-struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
-   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs)
 {
struct drm_fb_cma *fb_cma;
struct drm_gem_cma_object *objs[4];
@@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct drm_device 
*dev,
objs[i] = to_drm_gem_cma_obj(obj);
}

-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
+   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
if (IS_ERR(fb_cma)) {
ret = PTR_ERR(fb_cma);
goto err_gem_object_unreference;
@@ -215,6 +219,21 @@ err_gem_object_unreference:
drm_gem_object_unreference_unlocked([i]->base);
return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
+
+/**
+ * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback function
+ *
+ * If your hardware has special alignment or pitch requirements these should be
+ * checked before calling this function. Use drm_fb_cma_create_with_funcs() if
+ * you need to set _framebuffer_funcs ->dirty.
+ */
+struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
+   _fb_cma_funcs);
+}
 EXPORT_SYMBOL_GPL(drm_fb_cma_create);

 /**
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index c6d9c9c..1f9a8bc 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
 int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle);

+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs);
 struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

--
2.8.2

[PATCH v2 2/6] drm/fb-cma-helper: Hook up to DocBook and fix some docs

[Noralf Trønnes]

Hook up fb_cma_helper to DocBook. Remove mention of
CONFIG_FB_DEFERRED_IO in the docs, which was forgotten in the latest
version of the deferred_io patch.
Use & when referencing drm_mode_config_funcs in docs.

Signed-off-by: Noralf Trønnes 
---
 Documentation/DocBook/gpu.tmpl  | 5 +
 drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 9dd48f7..4a0c599 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1617,6 +1617,11 @@ void intel_crt_init(struct drm_device *dev)
 !Iinclude/drm/drm_fb_helper.h
 
 
+  Framebuffer CMA Helper Functions Reference
+!Pdrivers/gpu/drm/drm_fb_cma_helper.c framebuffer cma helper functions
+!Edrivers/gpu/drm/drm_fb_cma_helper.c
+
+
   Display Port Helper Functions Reference
 !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
 !Iinclude/drm/drm_dp_helper.h
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 086f600..3165ac0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -43,14 +43,12 @@ struct drm_fbdev_cma {
  * Provides helper functions for creating a cma (contiguous memory allocator)
  * backed framebuffer.
  *
- * drm_fb_cma_create() is used in the
- * (struct drm_mode_config_funcs *)->fb_create callback function to create the
- * cma backed framebuffer.
+ * drm_fb_cma_create() is used in the _mode_config_funcs ->fb_create
+ * callback function to create a cma backed framebuffer.
  *
  * An fbdev framebuffer backed by cma is also available by calling
  * drm_fbdev_cma_init(). drm_fbdev_cma_fini() tears it down.
- * If CONFIG_FB_DEFERRED_IO is enabled and the callback
- * (struct drm_framebuffer_funcs)->dirty is set, fb_deferred_io
+ * If the _framebuffer_funcs ->dirty callback is set, fb_deferred_io
  * will be set up automatically. dirty() is called by
  * drm_fb_helper_deferred_io() in process context (struct delayed_work).
  *
-- 
2.8.2

[PATCH v2 1/6] drm/fb-helper: Remove mention of CONFIG_FB_DEFERRED_IO in docs

[Noralf Trønnes]

This was forgotten to fixup in the latest version of the deferred_io
patch which made FB_DEFERRED_IO mandatory.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 385284b..e03f8ad 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -85,14 +85,14 @@ static LIST_HEAD(kernel_fb_helper_list);
  * should call drm_fb_helper_single_add_all_connectors() followed by
  * drm_fb_helper_initial_config().
  *
- * If CONFIG_FB_DEFERRED_IO is enabled and _framebuffer_funcs ->dirty is
- * set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit}
- * functions will accumulate changes and schedule _helper .dirty_work to run
- * right away. This worker then calls the dirty() function ensuring that it
- * will always run in process context since the fb_*() function could be
- * running in atomic context. If drm_fb_helper_deferred_io() is used as the
- * deferred_io callback it will also schedule dirty_work with the damage
- * collected from the mmap page writes.
+ * If _framebuffer_funcs ->dirty is set, the
+ * drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions will
+ * accumulate changes and schedule _fb_helper ->dirty_work to run right
+ * away. This worker then calls the dirty() function ensuring that it will
+ * always run in process context since the fb_*() function could be running in
+ * atomic context. If drm_fb_helper_deferred_io() is used as the deferred_io
+ * callback it will also schedule dirty_work with the damage collected from the
+ * mmap page writes.
  */

 /**
-- 
2.8.2

[PATCH v2 0/6] drm: Add various helpers for simple drivers

[Noralf Trønnes]

This patchset adds various helpers that was originally part of the
tinydrm patchset.

Essentially it adds 3 functions:
- drm_fb_cma_create_with_funcs()
  CMA backed framebuffer supporting a dirty() callback.
- drm_atomic_helper_best_encoder()
  (struct drm_connector_helper_funcs *)->best_encoder callback helper.
- drm_simple_display_pipe_init()
  Plane, crtc and encoder are collapsed into one entity.

Plus it has gained a couple of documentation patches since v1.

Changes since v1:
- Drop patch: drm/panel: Add helper for simple panel connector
- Add fb-helper and fb-cma-helper doc patches
- Add drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs
- Add drm_atomic_helper_best_encoder()
- drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  - Expand docs
- drm: Add helper for simple display pipeline
  - Add DOC header and add to gpu.tmpl
  - Fix docs: @funcs is optional, "negative error code",
"This hook is optional."
  - Add checks to drm_simple_kms_plane_atomic_check()

Noralf Trønnes (6):
  drm/fb-helper: Remove mention of CONFIG_FB_DEFERRED_IO in docs
  drm/fb-cma-helper: Hook up to DocBook and fix some docs
  drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  drm/atomic: Don't skip drm_bridge_*() calls if
!drm_encoder_helper_funcs
  drm/atomic: Add drm_atomic_helper_best_encoder()
  drm: Add helper for simple display pipeline

 Documentation/DocBook/gpu.tmpl  |  11 ++
 drivers/gpu/drm/Kconfig |   7 ++
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_atomic_helper.c |  56 +
 drivers/gpu/drm/drm_fb_cma_helper.c |  39 +--
 drivers/gpu/drm/drm_fb_helper.c |  16 +--
 drivers/gpu/drm/drm_simple_kms_helper.c | 200 
 include/drm/drm_atomic_helper.h |   2 +
 include/drm/drm_fb_cma_helper.h |   3 +
 include/drm/drm_simple_kms_helper.h |  92 +++
 10 files changed, 386 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
 create mode 100644 include/drm/drm_simple_kms_helper.h

--
2.8.2

[PATCH 3/3] drm/omap: include gpio/consumer.h where needed

[Arnd Bergmann]

A lot of the display drivers for OMAP use the gpio descriptor functions
that are only available in linux/gpio.h if GPIOLIB is enabled and
otherwise produce a build error:

drivers/gpu/drm/omapdrm/displays/encoder-opa362.c: In function 'opa362_enable':
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c:101:3: error: implicit 
declaration of function 'gpiod_set_value_cansleep' 
[-Werror=implicit-function-declaration]
drivers/gpu/drm/omapdrm/displays/panel-dpi.c: In function 
'panel_dpi_probe_pdata':
drivers/gpu/drm/omapdrm/displays/panel-dpi.c:189:23: error: implicit 
declaration of function 'gpio_to_desc' [-Werror=implicit-function-declaration]
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c: In function 
'sharp_ls_enable':
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c:120:3: error: 
implicit declaration of function 'gpiod_set_value_cansleep' 
[-Werror=implicit-function-declaration]

This replaces the existing linux/gpio.h with linux/gpio/consumer.h
where needed. In case of panel-lgphilips-lb035q02.c however, we
also have to include linux/gpio.h to get the definition of gpio_is_valid
and gpio_set_value_cansleep that are used for the non-DT case.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c   | 1 +
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c   | 2 +-
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c   | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 1 +
 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c  | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 2 +-
 10 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 225fd8d6ab31..667ca4a24ece 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -9,6 +9,7 @@
  * the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index 8c246c213e06..9594ff7a2b0c 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -14,7 +14,7 @@
  * the Free Software Foundation.
  */

-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index 2fd5602880a7..671806ca7d6a 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -9,7 +9,7 @@
  * the Free Software Foundation.
  */

-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index e780fd4f8b46..7c2331be8d15 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -9,7 +9,7 @@
  * the Free Software Foundation.
  */

-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 36485c2137ce..2b118071b5a1 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 458f77bc473d..ac680e1de603 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c 
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index 780cb263a318..38d2920a95e6 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 

 #include 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index 529a017602e4..4363fffc87e3 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -10,7 +10,7 @@
  */

 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git 

[PATCH] drm: mediatek: add COMMON_CLK dependency

[Philipp Zabel]

Am Mittwoch, den 11.05.2016, 14:34 +0200 schrieb Arnd Bergmann:
> On kernel builds without COMMON_CLK, the newly added mediatek drm
> driver fails to build:
> 
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c:130:16: error: field 'pll_hw' has 
> incomplete type
>   struct clk_hw pll_hw;
> ^~
> In file included from ../include/linux/clk.h:16:0,
>  from ../drivers/gpu/drm/mediatek/mtk_mipi_tx.c:14:
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c: In function 'mtk_mipi_tx_from_clk_hw':
> include/linux/kernel.h:831:48: error: initialization from incompatible 
> pointer type [-Werror=incompatible-pointer-types]
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^
> /drivers/gpu/drm/mediatek/mtk_mipi_tx.c:136:9: note: in expansion of macro 
> 'container_of'
>   return container_of(hw, struct mtk_mipi_tx, pll_hw);
>  ^~~~
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c: At top level:
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c:302:21: error: variable 
> 'mtk_mipi_tx_pll_ops' has initializer but incomplete type
>  static const struct clk_ops mtk_mipi_tx_pll_ops = {
> 
> This adds the required Kconfig dependency.
> 
> Signed-off-by: Arnd Bergmann 

Acked-by: Philipp Zabel 

regards
Philipp

[PATCH 2/3] drm/omap: include linux/of.h where needed

[Arnd Bergmann]

Some parts of the OMAP drm driver rely on implicit inclusion of
linux/of.h but fail in some configurations:

drivers/gpu/drm/omapdrm/dss/hdmi4.c: In function 'hdmi_probe_of':
drivers/gpu/drm/omapdrm/dss/hdmi4.c:564:2: error: implicit declaration of 
function 'of_node_put' [-Werror=implicit-function-declaration]
drivers/gpu/drm/omapdrm/dss/hdmi5.c: In function 'hdmi_probe_of':
drivers/gpu/drm/omapdrm/dss/hdmi5.c:590:2: error: implicit declaration of 
function 'of_node_put' [-Werror=implicit-function-declaration]

This adds an explicit #include statement to those files.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index f892ae157ff3..079bcfcbc8ef 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index a43f7b10e113..68ac2491d4b1 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.0

[PATCH 1/3] drm/omap: include linux/seq_file.h where needed

[Arnd Bergmann]

The omapdrm driver relies on this header to be included
implicitly, but this does not always work, and I get
this error in randconfig builds:

gpu/drm/omapdrm/dss/hdmi_phy.c: In function 'hdmi_phy_dump':
gpu/drm/omapdrm/dss/hdmi_phy.c:34:2: error: implicit declaration of function 
'seq_printf' [-Werror=implicit-function-declaration]
gpu/drm/omapdrm/dss/hdmi_wp.c: In function 'hdmi_wp_dump':
gpu/drm/omapdrm/dss/hdmi_wp.c:26:2: error: implicit declaration of function 
'seq_printf' [-Werror=implicit-function-declaration]
gpu/drm/omapdrm/dss/hdmi_pll.c: In function 'hdmi_pll_dump':
gpu/drm/omapdrm/dss/hdmi_pll.c:30:2: error: implicit declaration of function 
'seq_printf' [-Werror=implicit-function-declaration]

This adds the #include statements in all files that have
a seq_printf statement.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c   | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi_pll.c   | 1 +
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c| 1 +
 drivers/gpu/drm/omapdrm/omap_debugfs.c   | 2 ++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
 drivers/gpu/drm/omapdrm/omap_fb.c| 2 ++
 drivers/gpu/drm/omapdrm/omap_gem.c   | 1 +
 7 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
index 1f5d19c119ce..f98b750fc499 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "dss.h"
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
index 06e23a7c432c..f1015e8b8267 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index 13442b9052d1..055f62fca5dc 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "dss.h"
diff --git a/drivers/gpu/drm/omapdrm/omap_debugfs.c 
b/drivers/gpu/drm/omapdrm/omap_debugfs.c
index 6f5fc14fc015..479bf24050f8 100644
--- a/drivers/gpu/drm/omapdrm/omap_debugfs.c
+++ b/drivers/gpu/drm/omapdrm/omap_debugfs.c
@@ -17,6 +17,8 @@
  * this program.  If not, see .
  */

+#include 
+
 #include 
 #include 

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index de275a5be1db..4ceed7a9762f 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -27,6 +27,7 @@
 #include 
 #include  /* platform_device() */
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 610962396eb0..dce41e176a64 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -17,6 +17,8 @@
  * this program.  If not, see .
  */

+#include 
+
 #include 
 #include 

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 907154f5b67c..d2d879da6287 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */

+#include 
 #include 
 #include 
 #include 
-- 
2.7.0

More build fixes for omapdrm in current -next

[Arnd Bergmann]

A couple more errors showed up in linux-next in the last few
days, all because of missing header files. I have not seen these
before, and most configurations appear to be fine. There
must have been an implicit inclusion somewhere before that
just got removed, but I couldn't find it and doing the
explicit #include should always be better here.

Please apply for 4.7 to avoid regressing on randconfig builds.

Arnd

[PATCH 01/14] drm/amdgpu: fix wrong release of vmid owner

[Dave Airlie]

On 11 May 2016 at 17:46, Daniel Vetter  wrote:
> On Tue, May 10, 2016 at 10:21:53AM +0200, Christian König wrote:
>> Am 10.05.2016 um 07:05 schrieb Dave Airlie:
>> >On 9 May 2016 at 18:17, Daniel Vetter  wrote:
>> >>On Wed, May 04, 2016 at 02:26:42PM -0400, Alex Deucher wrote:
>> >>>From: Chunming Zhou 
>> >>>
>> >>>The release of the vmid owner was not handled
>> >>>correctly.  We need to take the lock and walk
>> >>>the lru list.
>> >>>
>> >>>Signed-off-by: Chunming Zhou 
>> >>>Reviewed-by: Alex Deucher 
>> >>>Reviewed-by: Monk Liu 
>> >>>Signed-off-by: Alex Deucher 
>> >>I know that it's super hard to get former proprietary driver teams to
>> >>stick their heads out on a public mailing lists. But imo being steward for
>> >>them is totally the worst case option you can pick long term. It means you
>> >>keep all the frustration of them not being fully in control (because
>> >>sometimes other people from outside the company jump in), never learning
>> >>how to driver the process themselves. And from the community pov it just
>> >>looks like code-drop over the wall. In my experience (I've been trying to
>> >>pull this off in public for almost 4 years now) trying to make exceptions
>> >>to get folks started just doesn't help anyone.
>> >>
>> >>Imo contributors need to fence for their patches themselves (with you
>> >>helping behind the scenes ofc) from the start.
>> >I'd prefer this as well, I'd also prefer at least people who do develop 
>> >upstream
>> >like Christian be set free to do so again, having patches spring on
>> >the lists fully
>> >formed isn't really great.
>>
>> Yeah, completely agree.
>>
>> I actually tried to work on the public list again. Especially since I'm
>> working on TTM improvements that would make things much easier.
>>
>> The problem is that then internal people started to complain that some
>> patches only got reviewed and merged upstream, but not internally.
>
> Here at intel there's no internal review for patches, except things which
> are embargoed. And even there the internal review is very often just a
> "you can split out this refactoring step, please submit that part to
> upstream directly".
>
>> >It would be also nice if there was more external discussion around
>> >design decisions etc,
>> >get the internal patch debate onto the mailing list.
>>
>> Yeah, again completely agree. Alex and I already spend a lot of effort
>> trying to explain the difference between releasing code to the public and
>> making code open source.
>>
>> >Because at this rate I've no idea about most of the design internals
>> >of the VM stuff,
>> >and I really think you guys can do a lot better.
>> >
>> >Maybe start setup another mailing list like intel-gfx for this, so
>> >it's a bit more private
>> >than dri-devel, but what is happening at the moment is worse than what
>> >used to happen.
>>
>> Yeah, that sounds like a good idea to me.
>
> One thing I do to force the isse, and it's a bit an asshole move, is to
> just not merge or review anything posted to internal lists that should go
> upstream. At least with repeat offenders, new people get 2-3 reminders how
> it's supposed to work. But once people realize that they're just wasting
> their own time, they tend to learn much faster ;-)
>
> The other thing I learned is that you'll not win any popularity contest as
> upstream maintainer trying to get a proprietary team to open up :(

My feeling is things haven't gotten any better, in fact they may have
gotten worse,
if Christian is having such problems.

At this point I'm guessing you are going to have to use a stick rather
than carrots
unfortunately.

Nobody seems like they want to work in the open without encouragment.

Dave.

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, final fixes for v4.6.

BR,
Jani.

The following changes since commit 4ea3959018d09edfa36a9e7b5ccdbd4ec4b99e49:

  drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW (2016-04-27 
10:57:00 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-05-11

for you to fetch changes up to 2700818ac9f935d8590715eecd7e8cadbca552b6:

  drm/i915: Bail out of pipe config compute loop on LPT (2016-05-10 10:42:08 
+0300)


Daniel Vetter (1):
  drm/i915: Bail out of pipe config compute loop on LPT

Imre Deak (1):
  drm/i915/bdw: Add missing delay during L3 SQC credit programming

Jani Nikula (1):
  drm/i915/lvds: separate border enable readout from panel fitter

Lyude (1):
  Revert "drm/i915: start adding dp mst audio"

Ville Syrjälä (1):
  drm/i915: Update CDCLK_FREQ register on BDW after changing cdclk frequency

 drivers/gpu/drm/i915/i915_debugfs.c  | 16 
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 drivers/gpu/drm/i915/intel_audio.c   |  9 +++--
 drivers/gpu/drm/i915/intel_crt.c |  8 +++-
 drivers/gpu/drm/i915/intel_ddi.c | 24 +---
 drivers/gpu/drm/i915/intel_display.c |  5 ++---
 drivers/gpu/drm/i915/intel_dp_mst.c  | 22 --
 drivers/gpu/drm/i915/intel_drv.h |  2 --
 drivers/gpu/drm/i915/intel_lvds.c|  4 
 drivers/gpu/drm/i915/intel_pm.c  |  6 ++
 10 files changed, 29 insertions(+), 69 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH V4 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

[Jon Hunter]

On 11/05/16 14:28, Laxman Dewangan wrote:
> On Sunday 08 May 2016 05:43 PM, Jon Hunter wrote:
>> On 06/05/16 16:32, Laxman Dewangan wrote:
>>> On Friday 06 May 2016 08:07 PM, Jon Hunter wrote:
 On 06/05/16 11:45, Laxman Dewangan wrote:
 +
 +/* Last entry */
 +TEGRA_IO_PAD_MAX,
 Nit should these be TEGRA_IO_PADS_xxx?
>>> Because this was name of single pad and hence I said TEGRA_IO_PAD_XXX.
>> Aren't these used to set the voltage level and power state for the
>> entire group of IOs? Confused :-(
> 
> One IO pad can have multiple IO pins.
> IO Pad control the power state and voltage of all pins belongs to that
> IO pad.

Ugh ... I remember for xusb there was something similar we the Tegra
docs used pad to imply multiple. However, in general pad == pin == ball
or at least should.

> Now what should we say PADS or PAD here? TEGRA_IO_PAD_UART or
> TEGRA_IO_PADS_UART?

Personally, I think pads and that is purely because it aligns with the
APIs. I think that the APIs names, tegra_io_pads_xxx() should be
consistent with the enum naming.

> +};
> +
> +/* tegra_io_pads_source_voltage: The voltage level of IO rails which
> source
> + * the IO pads.
> + */
> +enum tegra_io_pads_source_voltage {
> +TEGRA_IO_PADS_SOURCE_VOLTAGE_180UV,
> +TEGRA_IO_PADS_SOURCE_VOLTAGE_330UV,
> +};
 Nit I wonder if we can make this shorter ...

 enum tegra_io_pads_vconf {
  TEGRA_IO_PADS_VCONF_1V8,
  TEGRA_IO_PADS_VCONF_3V3,
>>> This looks good but for voltage and current, unit is used uV/uV across
>>> the system. So wanted to have same unit.
>> Now it is an enum does it matter? Or maybe just have ...
>>
>> enum tegra_io_pads_vconf {
>> TEGRA_IO_PADS_180UV,
>> TEGRA_IO_PADS_330UV,
>> };
>>
> 
> OK, TEGRA_IO_PADS_VCONF_180UV and TEGRA_IO_PADS_VCONF_330UV.
> Fine?

Fine :-)

Jon

[PATCH 1/4] drm: add generic zpos property

[Laurent Pinchart]

Hi Benjamin,

On Wednesday 11 May 2016 14:05:49 Benjamin Gaignard wrote:
> 2016-05-11 13:24 GMT+02:00 Laurent Pinchart:
> > On Wednesday 11 May 2016 12:25:05 Benjamin Gaignard wrote:
> >> This patch adds support for generic plane's zpos property property with
> >> well-defined semantics:
> >> - added zpos properties to plane and plane state structures
> >> - added helpers for normalizing zpos properties of given set of planes
> >> - well defined semantics: planes are sorted by zpos values and then plane
> >>   id value if zpos equals
> >> 
> >> Normalized zpos values are calculated automatically when generic
> >> muttable zpos property has been initialized. Drivers can simply use
> >> plane_state->normalized_zpos in their atomic_check and/or plane_update
> >> callbacks without any additional calls to DRM core.
> >> 
> >> Signed-off-by: Marek Szyprowski 
> >> 
> >> Compare to Marek's original patch zpos property is now specific to each
> >> plane and no more to the core.
> >> Normalize function take care of the range of per plane defined range
> >> before set normalized_zpos.
> >> 
> >> Signed-off-by: Benjamin Gaignard 
> >> 
> >> Cc: Inki Dae 
> >> Cc: Daniel Vetter 
> >> Cc: Ville Syrjala 
> >> Cc: Joonyoung Shim 
> >> Cc: Seung-Woo Kim 
> >> Cc: Andrzej Hajda 
> >> Cc: Krzysztof Kozlowski 
> >> Cc: Bartlomiej Zolnierkiewicz 
> >> Cc: Tobias Jakobi 
> >> Cc: Gustavo Padovan 
> >> Cc: vincent.abriou at st.com
> >> Cc: fabien.dessenne at st.com
> >> Cc: Laurent Pinchart 
> >> 
> >> ---
> >> 
> >>  Documentation/DocBook/gpu.tmpl  |  10 ++
> >>  drivers/gpu/drm/Makefile|   2 +-
> >>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
> >>  drivers/gpu/drm/drm_blend.c | 284 ++
> >>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
> >>  include/drm/drm_crtc.h  |  25 
> >>  6 files changed, 329 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/gpu/drm/drm_blend.c

[snip]

> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c index 997fd21..f10652f 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -32,6 +32,8 @@
> >> 
> >>  #include 
> >>  #include 
> >> 
> >> +#include "drm_crtc_internal.h"
> > 
> > drm_atomic_helper_normalize_zpos() is declared in , why do
> > you need to include drm_crtc_internal.h ?
> 
> drm_atomic_helper_normalize_zpos() is declared in drm_crtc_internal.h
> not into 

OK, I'll go back to bed -_-'

[snip]

> >> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >> new file mode 100644
> >> index 000..7017715
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/drm_blend.c
> >> @@ -0,0 +1,284 @@

[snip]

> >> +/**
> >> + * drm_plane_create_zpos_immutable_property - create immuttable zpos
> >> property
> >> + * @plane: drm plane
> >> + * @min: minimal possible value of zpos property
> >> + * @max: maximal possible value of zpos property
> >> + *
> >> + * This function initializes generic immutable zpos property and enables
> >> + * support for it in drm core. Using this property driver lets userspace
> >> + * to get the arrangement of the planes for blending operation and
> >> notifies + * it that the hardware (or driver) doesn't support changing
> >> of the planes'
> >> + * order.
> >> + *
> >> + * Returns:
> >> + * Zero on success, negative errno on failure.
> >> + */
> >> +int drm_plane_create_zpos_immutable_property(struct drm_plane *plane,
> >> +  unsigned int min, unsigned int
> >> max) +{
> >> + struct drm_property *prop;
> >> +
> >> + prop = drm_property_create_range(plane->dev,
> >> DRM_MODE_PROP_IMMUTABLE,
> >> +  "zpos", min, max);
> > 
> > Can two properties exist with the same name but different flags (immutable
> > and mutable) ? Or with different min/max values ? I don't expect min/max
> > to be different for every plane, so maybe a function that creates the
> > zpos property once with min/max values and a second one that attaches the
> > property to planes would be a better API.
> 
> Be able to have a per plane zpos property was a Ville request because
> all the planes may not have the same min/max zpos.

Which driver(s) need that feature ? Is it for the cursor plane only ? In that 
case I wonder if it would really make sense to create an immutable zpos 
property with a fixed high value for the cursor plane, versus not having a 
zpos property at all.

> The consequences of this design are that we can cache the property in
> drm_mode_config
> and we need to have helpers functions
> drm_plane_atomic_{set,get}_zpos_property to be able find
> the property attached to the drm_plane.

Can't you cache it in drm_plane instead then, and remove the loop from those 
two helpers ? You should even remove the helpers completely and handle the 
zpos property in drm_plane_atomic_[gs]et_property().

> >> + if (!prop)
> >> 

[PATCH v3 4/7] drm/i2c: adv7511: Create a MIPI DSI device

[Archit Taneja]

On 05/10/2016 02:08 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Tuesday 03 May 2016 12:27:38 Archit Taneja wrote:
>> On 04/22/2016 10:40 AM, Archit Taneja wrote:
>>> On 04/22/2016 03:59 AM, Laurent Pinchart wrote:
 On Wednesday 09 Mar 2016 16:27:15 Archit Taneja wrote:
> In order to pass DSI specific parameters to the DSI host, we need the
> driver to create a mipi_dsi_device DSI device that attaches to the
> host.
>
> Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
> device using this host. Finally, attach this device to the DSI host.
>
> Populate DT parameters (number of data lanes for now) that are required
> for DSI RX to work correctly. Hardcode few other parameters (rgb,
> embedded_sync) for now.
>
> Signed-off-by: Archit Taneja 

 This adds a hard dependency on CONFIG_DRM_MIPI_DSI, otherwise the
 kernel won't link. As the ADV7511 doesn't require DSI, could you make it
 optional with conditional compilation to avoid pulling in dead code ?
>>>
>>> You're right. The driver's Kconfig should at least select DRM_MIPI_DSI
>>> in the current state to make sure we don't break build.
>>>
>>> Do you suggest we create another config option for ADV7533, which
>>> selects DRM_MIPI_DSI and builds the ADV7533 parts? Or did you mean
>>> something else?
>>
>> Do you have any suggestions for this point? For the next revision, I've
>> just selected DRM_MIPI_DSI in the Kconfig to ensure build doesn't break.
>>
>> For this driver, to conditionally compile DRM_MIPI_DSI, it essentially
>> means we allow conditional support for ADV7533. I would imagine us
>> #ifdef-ing out the ADV7533 compatible string in the of_match_table. Is
>> this something we want to do?
>
> If it's not much trouble I think that would be useful to avoid bloating the
> kernel with unused features, yes. You might want to add stub functions to
> include/drm/drm_mipi_dsi.h when CONFIG_DRM_MIPI_DSI is not defined to avoid
> sprinkling the driver with lots of #ifdefs.

Yeah, I can do this. Now that there isn't a chance for it to get in the
4.7 merge window, there's plenty time.

Archit

>
> ---
>
> drivers/gpu/drm/i2c/adv7511.c | 130 +---
>   1 file changed, 123 insertions(+), 7 deletions(-)
>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

[PATCH] bochs: ignore device if there isn't enougth memory

[Gerd Hoffmann]

The qemu stdvga can be configured with a wide range of video memory,
from 1 MB to 256 MB (default is 16 MB).  In case it is configured
with only 1 or 2 MB it isn't really usable with bochsdrm, due to
depths other than 32bpp not being supported so that isn't enough
memory for a reasonable sized framebuffer.  So skip the device
and let vgacon or vesafb+fbcon handle the it.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index b332b4d3..6cf4b18 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -162,8 +162,15 @@ static int bochs_kick_out_firmware_fb(struct pci_dev *pdev)
 static int bochs_pci_probe(struct pci_dev *pdev,
   const struct pci_device_id *ent)
 {
+   unsigned long fbsize;
int ret;

+   fbsize = pci_resource_len(pdev, 0);
+   if (fbsize < 4 * 1024 * 1024) {
+   DRM_ERROR("less than 4 MB video memory, ignoring device\n");
+   return -ENOMEM;
+   }
+
ret = bochs_kick_out_firmware_fb(pdev);
if (ret)
return ret;
-- 
1.8.3.1

[PATCH 1/4] drm: add generic zpos property

[Daniel Vetter]

On Wed, May 11, 2016 at 12:25:05PM +0200, Benjamin Gaignard wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to plane and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> 
> Compare to Marek's original patch zpos property is now specific to each
> plane and no more to the core.
> Normalize function take care of the range of per plane defined range
> before set normalized_zpos.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Inki Dae 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Andrzej Hajda 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Tobias Jakobi 
> Cc: Gustavo Padovan 
> Cc: vincent.abriou at st.com
> Cc: fabien.dessenne at st.com
> Cc: Laurent Pinchart 
> 
> ---
>  Documentation/DocBook/gpu.tmpl  |  10 ++
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>  drivers/gpu/drm/drm_blend.c | 284 
> 
>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>  include/drm/drm_crtc.h  |  25 
>  6 files changed, 329 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 9dd48f7..0df6abb 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
>   the underlying hardware).
>   
>   
> +  "zpos" 
> + RANGE
> + Min= driver dependent, Max= driver dependent
> + Plane
> + Plane's 'z' position during blending operation (0 for 
> background, highest for frontmost).
> + If two planes assigned to same CRTC have equal zpos values, the 
> plane with higher plane
> + id is treated as closer to front. Can be IMMUTABLE if driver 
> doesn't support changing
> + planes' order. Exact value range is driver dependent.
> + 
> + 
>   i915
>   Generic
>   "Broadcast RGB"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2bd3e5a..df88253 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
> +drm-y   :=   drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 997fd21..f10652f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
> +
>  /**
>   * DOC: overview
>   *
> @@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   int i, ret = 0;
>  
> + ret = drm_atomic_helper_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> +
>   for_each_plane_in_state(state, plane, plane_state, i) {
>   const struct drm_plane_helper_funcs *funcs;
>  
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> new file mode 100644
> index 000..7017715
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -0,0 +1,284 @@
> +/*
> + * Copyright (C) 2016 Samsung Electronics Co.Ltd
> + * Authors:
> + *   Marek Szyprowski 
> + *
> + * DRM core plane blending related functions
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and 
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that 
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided 
> "as
> + * is" without express or implied warranty.
> + *
> + 

[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

[Stephen Boyd]

On 05/10, Priit Laes wrote:
> On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote:
> > On 05/09, Stephen Boyd wrote:
> > > 
> > > 
> > > Ok I applied this one to clk-next.
> > > 
> > And I squashed this in to silence the following checker warning.
> > 
> > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> > length array is used.
> > 
> > ---8<---
> > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> > b/drivers/clk/sunxi/clk-sun4i-display.c
> > index f02e250e64ed..f8ff6c4a5633 100644
> > --- a/drivers/clk/sunxi/clk-sun4i-display.c
> > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > @@ -107,7 +107,7 @@ static int sun4i_a10_display_reset_xlate(struct
> > reset_controller_dev *rcdev,
> >  static void __init sun4i_a10_display_init(struct device_node *node,
> >      const struct
> > sun4i_a10_display_clk_data *data)
> >  {
> > -   const char *parents[data->parents];
> > +   const char *parents[4];
> 
> This change breaks at least de_[bf]e clocks which have 3 clock parents.
> 

I just used the largest data->parents number, which was 4. How
does that break anything?

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

[PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

[Stephen Boyd]

On 05/10, Maxime Ripard wrote:
> Hi Stephen,
> 
> On Mon, May 09, 2016 at 03:39:24PM -0700, Stephen Boyd wrote:
> > On 05/09, Stephen Boyd wrote:
> > > 
> > > Ok I applied this one to clk-next.
> > > 
> > 
> > And I squashed this in to silence the following checker warning.
> > 
> > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> > length array is used.
> 
> Thanks, just out of curiosity, which checker are you talking about?
> sparse?
> 

I use sparse and smatch. I can't recall which one is complaining
here and technically smatch uses sparse underneath.

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

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Krzysztof Kozlowski]

On 05/11/2016 02:31 PM, Benjamin Gaignard wrote:
> From: Marek Szyprowski 
> 
> This patch replaces zpos property handling custom code in Exynos DRM
> driver with calls to generic DRM code.
> 
> Signed-off-by: Marek Szyprowski 

Your signed-off-by is missing.

Best regards,
Krzysztof

[PATCH] drm: mediatek: add COMMON_CLK dependency

[Arnd Bergmann]

On kernel builds without COMMON_CLK, the newly added mediatek drm
driver fails to build:

drivers/gpu/drm/mediatek/mtk_mipi_tx.c:130:16: error: field 'pll_hw' has 
incomplete type
  struct clk_hw pll_hw;
^~
In file included from ../include/linux/clk.h:16:0,
 from ../drivers/gpu/drm/mediatek/mtk_mipi_tx.c:14:
drivers/gpu/drm/mediatek/mtk_mipi_tx.c: In function 'mtk_mipi_tx_from_clk_hw':
include/linux/kernel.h:831:48: error: initialization from incompatible pointer 
type [-Werror=incompatible-pointer-types]
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
/drivers/gpu/drm/mediatek/mtk_mipi_tx.c:136:9: note: in expansion of macro 
'container_of'
  return container_of(hw, struct mtk_mipi_tx, pll_hw);
 ^~~~
drivers/gpu/drm/mediatek/mtk_mipi_tx.c: At top level:
drivers/gpu/drm/mediatek/mtk_mipi_tx.c:302:21: error: variable 
'mtk_mipi_tx_pll_ops' has initializer but incomplete type
 static const struct clk_ops mtk_mipi_tx_pll_ops = {

This adds the required Kconfig dependency.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/mediatek/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index eeefc971801a..0c06a69d7f04 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -2,6 +2,7 @@ config DRM_MEDIATEK
tristate "DRM Support for Mediatek SoCs"
depends on DRM
depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
+   depends on COMMON_CLK
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
select DRM_MIPI_DSI
-- 
2.7.0

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Benjamin Gaignard]

From: Marek Szyprowski 

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc33ec9..b34a7b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
-   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

struct device *dma_dev;
unsigned long da_start;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 50185ac..bbaf6d3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
-   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = _state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, >base);
-   copy->zpos = exynos_state->zpos;
return >base;
 }

@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_plane_state *exynos_state =
-   to_exynos_plane_state(state);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-   const struct exynos_drm_plane_config *config = exynos_plane->config;
-
-   if (property == dev_priv->plane_zpos_property &&
-   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
-   exynos_state->zpos = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
-   const struct exynos_drm_plane_state *exynos_state =
-   container_of(state, const struct exynos_drm_plane_state, base);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property)
-   *val = exynos_state->zpos;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
-   .atomic_set_property = exynos_drm_plane_atomic_set_property,
-   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private *dev_priv = dev->dev_private;
-   

[PATCH 1/4] drm: add generic zpos property

[Benjamin Gaignard]

From: Marek Szyprowski 

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 Documentation/DocBook/gpu.tmpl  |  10 ++
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_atomic_helper.c |   6 +
 drivers/gpu/drm/drm_blend.c | 283 
 drivers/gpu/drm/drm_crtc_internal.h |   3 +
 include/drm/drm_crtc.h  |  25 
 6 files changed, 328 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 9dd48f7..0df6abb 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
the underlying hardware).


+"zpos" 
+   RANGE
+   Min= driver dependent, Max= driver dependent
+   Plane
+   Plane's 'z' position during blending operation (0 for 
background, highest for frontmost).
+   If two planes assigned to same CRTC have equal zpos values, the 
plane with higher plane
+   id is treated as closer to front. Can be IMMUTABLE if driver 
doesn't support changing
+   planes' order. Exact value range is driver dependent.
+   
+   
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2bd3e5a..df88253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 997fd21..f10652f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
 #include 
 #include 

+#include "drm_crtc_internal.h"
+
 /**
  * DOC: overview
  *
@@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;

+   ret = drm_atomic_helper_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
new file mode 100644
index 000..a4d3b4c
--- /dev/null
+++ b/drivers/gpu/drm/drm_blend.c
@@ -0,0 +1,283 @@
+/*
+ * Copyright (C) 2016 Samsung Electronics Co.Ltd
+ * Authors:
+ * Marek Szyprowski 
+ *
+ * DRM core plane blending related functions
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL 

[PATCH 1/4] drm: add generic zpos property

[Laurent Pinchart]

Hi Benjamin,

Thank you for the patch.

I would have started working on this next week, thanks for beating me to it 
:-)

On Wednesday 11 May 2016 12:25:05 Benjamin Gaignard wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to plane and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> 
> Compare to Marek's original patch zpos property is now specific to each
> plane and no more to the core.
> Normalize function take care of the range of per plane defined range
> before set normalized_zpos.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Inki Dae 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Andrzej Hajda 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Tobias Jakobi 
> Cc: Gustavo Padovan 
> Cc: vincent.abriou at st.com
> Cc: fabien.dessenne at st.com
> Cc: Laurent Pinchart 
> 
> ---
>  Documentation/DocBook/gpu.tmpl  |  10 ++
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>  drivers/gpu/drm/drm_blend.c | 284 +
>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>  include/drm/drm_crtc.h  |  25 
>  6 files changed, 329 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 9dd48f7..0df6abb 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
>   the underlying hardware).
>   
>   
> +  "zpos" 
> + RANGE
> + Min= driver dependent, Max= driver dependent
> + Plane
> + Plane's 'z' position during blending operation (0 for
> background, highest for frontmost).
> + If two planes assigned to same CRTC have equal zpos values, the 
> plane
> with higher plane
> + id is treated as closer to front. Can be IMMUTABLE if driver 
> doesn't
> support changing
> + planes' order. Exact value range is driver dependent.
> + 
> + 
>   i915
>   Generic
>   "Broadcast RGB"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2bd3e5a..df88253 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the drm device driver.  This driver provides support for the
> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> 
> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
> +drm-y   :=   drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 997fd21..f10652f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
> 
> +#include "drm_crtc_internal.h"

drm_atomic_helper_normalize_zpos() is declared in , why do you 
need to include drm_crtc_internal.h ?

>  /**
>   * DOC: overview
>   *
> @@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   int i, ret = 0;
> 
> + ret = drm_atomic_helper_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> +
>   for_each_plane_in_state(state, plane, plane_state, i) {
>   const struct drm_plane_helper_funcs *funcs;
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> new file mode 100644
> index 000..7017715
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -0,0 +1,284 @@

[snip]

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Nitpicking, could you please keep header files alphabetically sorted ? It 
helps locating and avoiding duplicates.

> +#include "drm_internal.h"
> +
> +#define MAX(a, b) (((a) > (b)) ? (a) : (b))

linux/kernel.h has max and max_t, is there really a need for a new macro ?

> +/**
> + * drm_plane_atomic_set_zpos_property - set plane zpos property
> + * @plane: drm plane
> + * @state: drm plane state
> + * @property: must be the zpos property associated to the plane
> + * @val: zpos value to be set
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Krzysztof Kozlowski]

On 05/11/2016 02:09 PM, Benjamin Gaignard wrote:
> I haven't double check but I had to do changes into the original patch
> so I guess that "from" field comes the new commit.
> 
> I will manually edit the commit for v2,

Git keeps original author untouched. You have to manually change the
author to remove the original one (or use non-standard way of applying
patches). If you use Git, just stick to typical workflow - git am, git
commit --amend --signoff, git format-patch, etc.

Best regards,
Krzysztof

[PATCH 23/23] drm: omapdrm: Remove buffer synchronization support

[Tomi Valkeinen]

On 26/04/16 23:35, Laurent Pinchart wrote:
> The omapdrm driver uses a custom API to synchronize with the SGX GPU.
> This is unusable as such in the mainline kernel as the API is only
> partially implemented and requires additional out-of-tree patches.
> Furthermore, as no SGX driver is available in the mainline kernel, the
> API can't be considered as a stable mainline API.
> 
> Remove buffer synchronization support to prepare for its replacement by
> an implementation based on standard fences and reservation objects.

I thought one thing the OMAP_GEM_CPU_PREP/FINI ioctls were supposed to
do it cache flushing, if the buffer is OMAP_BO_CACHED. I don't think
that works, though, which might be considered as an omapdrm bug.

Also, if an app is using the prep/fini ioctls at the moment, even if it
doesn't exactly require flushing (or any kind of synchronization), after
this patch the app might fail. So even if we remove all the code behind,
perhaps we should leave no-op ioctls.

 Tomi

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

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Benjamin Gaignard]

I haven't double check but I had to do changes into the original patch
so I guess that "from" field comes the new commit.

I will manually edit the commit for v2,

thanks

2016-05-11 13:54 GMT+02:00 Krzysztof Kozlowski :
> On 05/11/2016 12:25 PM, Benjamin Gaignard wrote:
>> This patch replaces zpos property handling custom code in Exynos DRM
>> driver with calls to generic DRM code.
>>
>> Signed-off-by: Marek Szyprowski 
>
> Ekhm? From=Benjamin, SoB=Marek... why did you change the author?
>
> Best regards,
> Krzysztof



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[PATCH] drm/amdgpu: Encapsulate some VM table update parameters (v2)

[Alex Deucher]

From: Harish Kasiviswanathan 

Bundle some VM table parameters into amdgpu_vm_update_params structure,
so that number of function parameters can be reduced. Only structural
change, no logic change.

v2: agd: squash in fix from Harish

Signed-off-by: Harish Kasiviswanathan 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 111 ++---
 1 file changed, 62 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ea708cb..9f36ed3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -53,6 +53,18 @@
 /* Special value that no flush is necessary */
 #define AMDGPU_VM_NO_FLUSH (~0ll)

+/* Local structure. Encapsulate some VM table update parameters to reduce
+ * the number of function parameters
+ */
+struct amdgpu_vm_update_params {
+   /* address where to copy page table entries from */
+   uint64_t src;
+   /* DMA addresses to use for mapping */
+   dma_addr_t *pages_addr;
+   /* indirect buffer to fill with commands */
+   struct amdgpu_ib *ib;
+};
+
 /**
  * amdgpu_vm_num_pde - return the number of page directory entries
  *
@@ -389,9 +401,7 @@ struct amdgpu_bo_va *amdgpu_vm_bo_find(struct amdgpu_vm *vm,
  * amdgpu_vm_update_pages - helper to call the right asic function
  *
  * @adev: amdgpu_device pointer
- * @src: address where to copy page table entries from
- * @pages_addr: DMA addresses to use for mapping
- * @ib: indirect buffer to fill with commands
+ * @vm_update_params: see amdgpu_vm_update_params definition
  * @pe: addr of the page entry
  * @addr: dst addr to write into pe
  * @count: number of page entries to update
@@ -402,29 +412,29 @@ struct amdgpu_bo_va *amdgpu_vm_bo_find(struct amdgpu_vm 
*vm,
  * to setup the page table using the DMA.
  */
 static void amdgpu_vm_update_pages(struct amdgpu_device *adev,
-  uint64_t src,
-  dma_addr_t *pages_addr,
-  struct amdgpu_ib *ib,
+  struct amdgpu_vm_update_params
+   *vm_update_params,
   uint64_t pe, uint64_t addr,
   unsigned count, uint32_t incr,
   uint32_t flags)
 {
trace_amdgpu_vm_set_page(pe, addr, count, incr, flags);

-   if (src) {
-   src += (addr >> 12) * 8;
-   amdgpu_vm_copy_pte(adev, ib, pe, src, count);
+   if (vm_update_params->src) {
+   amdgpu_vm_copy_pte(adev, vm_update_params->ib,
+   pe, (vm_update_params->src + (addr >> 12) * 8), count);

-   } else if (pages_addr) {
-   amdgpu_vm_write_pte(adev, ib, pages_addr, pe, addr,
-   count, incr, flags);
+   } else if (vm_update_params->pages_addr) {
+   amdgpu_vm_write_pte(adev, vm_update_params->ib,
+   vm_update_params->pages_addr,
+   pe, addr, count, incr, flags);

} else if (count < 3) {
-   amdgpu_vm_write_pte(adev, ib, NULL, pe, addr,
+   amdgpu_vm_write_pte(adev, vm_update_params->ib, NULL, pe, addr,
count, incr, flags);

} else {
-   amdgpu_vm_set_pte_pde(adev, ib, pe, addr,
+   amdgpu_vm_set_pte_pde(adev, vm_update_params->ib, pe, addr,
  count, incr, flags);
}
 }
@@ -444,10 +454,12 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
struct amdgpu_ring *ring;
struct fence *fence = NULL;
struct amdgpu_job *job;
+   struct amdgpu_vm_update_params vm_update_params;
unsigned entries;
uint64_t addr;
int r;

+   memset(_update_params, 0, sizeof(vm_update_params));
ring = container_of(vm->entity.sched, struct amdgpu_ring, sched);

r = reservation_object_reserve_shared(bo->tbo.resv);
@@ -465,7 +477,8 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
if (r)
goto error;

-   amdgpu_vm_update_pages(adev, 0, NULL, >ibs[0], addr, 0, entries,
+   vm_update_params.ib = >ibs[0];
+   amdgpu_vm_update_pages(adev, _update_params, addr, 0, entries,
   0, 0);
amdgpu_ring_pad_ib(ring, >ibs[0]);

@@ -538,11 +551,12 @@ int amdgpu_vm_update_page_directory(struct amdgpu_device 
*adev,
uint64_t last_pde = ~0, last_pt = ~0;
unsigned count = 0, pt_idx, ndw;
struct amdgpu_job *job;
-   struct amdgpu_ib *ib;
+   struct amdgpu_vm_update_params vm_update_params;
struct fence *fence = NULL;

int r;

+   memset(_update_params, 0, sizeof(vm_update_params));
ring = 

[PATCH] drm/amdgpu: fix TC cache flushing

[Alex Deucher]

From: Marek Olšák 

TC_WB_ACTION must be set according to the docs

Signed-off-by: Marek Olšák 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1dab5f2..0dee008 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -50,9 +50,11 @@
  * KMS wrapper.
  * - 3.0.0 - initial driver
  * - 3.1.0 - allow reading more status registers (GRBM, SRBM, SDMA, CP)
+ * - 3.2.0 - GFX8: Uses EOP_TC_WB_ACTION_EN, so UMDs don't have to do the same
+ *   at the end of IBs.
  */
 #define KMS_DRIVER_MAJOR   3
-#define KMS_DRIVER_MINOR   1
+#define KMS_DRIVER_MINOR   2
 #define KMS_DRIVER_PATCHLEVEL  0

 int amdgpu_vram_limit = 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 92647fb..ef192aa 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -5725,6 +5725,7 @@ static void gfx_v8_0_ring_emit_fence_gfx(struct 
amdgpu_ring *ring, u64 addr,
amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
 EOP_TC_ACTION_EN |
+EOP_TC_WB_ACTION_EN |
 EVENT_TYPE(CACHE_FLUSH_AND_INV_TS_EVENT) |
 EVENT_INDEX(5)));
amdgpu_ring_write(ring, addr & 0xfffc);
-- 
2.5.5

[PATCH 1/4] drm: add generic zpos property

[Benjamin Gaignard]

Hi Laurent,


2016-05-11 13:24 GMT+02:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch.
>
> I would have started working on this next week, thanks for beating me to it
> :-)
>
> On Wednesday 11 May 2016 12:25:05 Benjamin Gaignard wrote:
>> This patch adds support for generic plane's zpos property property with
>> well-defined semantics:
>> - added zpos properties to plane and plane state structures
>> - added helpers for normalizing zpos properties of given set of planes
>> - well defined semantics: planes are sorted by zpos values and then plane
>>   id value if zpos equals
>>
>> Normalized zpos values are calculated automatically when generic
>> muttable zpos property has been initialized. Drivers can simply use
>> plane_state->normalized_zpos in their atomic_check and/or plane_update
>> callbacks without any additional calls to DRM core.
>>
>> Signed-off-by: Marek Szyprowski 
>>
>> Compare to Marek's original patch zpos property is now specific to each
>> plane and no more to the core.
>> Normalize function take care of the range of per plane defined range
>> before set normalized_zpos.
>>
>> Signed-off-by: Benjamin Gaignard 
>>
>> Cc: Inki Dae 
>> Cc: Daniel Vetter 
>> Cc: Ville Syrjala 
>> Cc: Joonyoung Shim 
>> Cc: Seung-Woo Kim 
>> Cc: Andrzej Hajda 
>> Cc: Krzysztof Kozlowski 
>> Cc: Bartlomiej Zolnierkiewicz 
>> Cc: Tobias Jakobi 
>> Cc: Gustavo Padovan 
>> Cc: vincent.abriou at st.com
>> Cc: fabien.dessenne at st.com
>> Cc: Laurent Pinchart 
>>
>> ---
>>  Documentation/DocBook/gpu.tmpl  |  10 ++
>>  drivers/gpu/drm/Makefile|   2 +-
>>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>>  drivers/gpu/drm/drm_blend.c | 284 +
>>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>>  include/drm/drm_crtc.h  |  25 
>>  6 files changed, 329 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/gpu/drm/drm_blend.c
>>
>> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
>> index 9dd48f7..0df6abb 100644
>> --- a/Documentation/DocBook/gpu.tmpl
>> +++ b/Documentation/DocBook/gpu.tmpl
>> @@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
>>   the underlying hardware).
>>   
>>   
>> +  "zpos" 
>> + RANGE
>> + Min= driver dependent, Max= driver dependent
>> + Plane
>> + Plane's 'z' position during blending operation (0 for
>> background, highest for frontmost).
>> + If two planes assigned to same CRTC have equal zpos values, 
>> the plane
>> with higher plane
>> + id is treated as closer to front. Can be IMMUTABLE if driver 
>> doesn't
>> support changing
>> + planes' order. Exact value range is driver dependent.
>> + 
>> + 
>>   i915
>>   Generic
>>   "Broadcast RGB"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 2bd3e5a..df88253 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -2,7 +2,7 @@
>>  # Makefile for the drm device driver.  This driver provides support for the
>> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>>
>> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
>> +drm-y   :=   drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
>>   drm_context.o drm_dma.o \
>>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c index 997fd21..f10652f 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -32,6 +32,8 @@
>>  #include 
>>  #include 
>>
>> +#include "drm_crtc_internal.h"
>
> drm_atomic_helper_normalize_zpos() is declared in , why do you
> need to include drm_crtc_internal.h ?

drm_atomic_helper_normalize_zpos() is declared in drm_crtc_internal.h
not into 

>
>>  /**
>>   * DOC: overview
>>   *
>> @@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>>   struct drm_plane_state *plane_state;
>>   int i, ret = 0;
>>
>> + ret = drm_atomic_helper_normalize_zpos(dev, state);
>> + if (ret)
>> + return ret;
>> +
>>   for_each_plane_in_state(state, plane, plane_state, i) {
>>   const struct drm_plane_helper_funcs *funcs;
>>
>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
>> new file mode 100644
>> index 000..7017715
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_blend.c
>> @@ -0,0 +1,284 @@
>
> [snip]
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Nitpicking, could you please keep header files alphabetically sorted ? It
> helps locating and avoiding duplicates.
>

sure, I will for v2

>> +#include "drm_internal.h"
>> +
>> +#define MAX(a, b) (((a) > (b)) ? (a) : (b))
>
> linux/kernel.h has max and max_t, is there really a need for a new 

[PATCH 15/23] drm: omapdrm: Don't expose the omap_irq_(un)register() functions

[Tomi Valkeinen]

On 26/04/16 23:35, Laurent Pinchart wrote:
> The functions are not used outside of their compilation unit, make them
> static.

The patch doesn't seem to match the description. If I'm not mistaken,
the patch is doing: remove __omap_irq_* funcs, remove parameter from the
irq callback, make funcs static.

Combining everything into one patch makes it difficult to review,
especially if the description doesn't explain what's done.

 Tomi

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

[PATCH 17/23] drm: omapdrm: Make pipe2vbl function static

[Tomi Valkeinen]

On 26/04/16 23:35, Laurent Pinchart wrote:
> The function is only used in omap_irq.c, move it there and make it
> static.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ---
>  drivers/gpu/drm/omapdrm/omap_drv.h  | 1 -
>  drivers/gpu/drm/omapdrm/omap_irq.c  | 7 ++-
>  3 files changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 3265cd990acf..e077d36016c2 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -47,13 +47,6 @@ struct omap_crtc {
>   * Helper Functions
>   */
>  
> -uint32_t pipe2vbl(struct drm_crtc *crtc)
> -{
> - struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> -
> - return dispc_mgr_get_vsync_irq(omap_crtc->channel);
> -}
> -
>  struct omap_video_timings *omap_crtc_timings(struct drm_crtc *crtc)
>  {
>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> index c8c0e207c823..29f2cc2ce555 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -248,7 +248,6 @@ static inline int align_pitch(int pitch, int width, int 
> bpp)
>  }
>  
>  /* map crtc to vblank mask */
> -uint32_t pipe2vbl(struct drm_crtc *crtc);
>  struct omap_dss_device *omap_encoder_get_dssdev(struct drm_encoder *encoder);
>  
>  #endif /* __OMAP_DRV_H__ */
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
> b/drivers/gpu/drm/omapdrm/omap_irq.c
> index 0b28db014569..f7c507cc104b 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -108,6 +108,11 @@ int omap_irq_wait(struct drm_device *dev, struct 
> omap_irq_wait *wait,
>   return 0;
>  }
>  
> +static uint32_t pipe2vbl(struct drm_crtc *crtc)
> +{
> + return dispc_mgr_get_vsync_irq(omap_crtc_channel(crtc));
> +}
> +
>  /**
>   * enable_vblank - enable vblank interrupt events
>   * @dev: DRM device
> @@ -223,7 +228,7 @@ static irqreturn_t omap_irq_handler(int irq, void *arg)
>   struct drm_crtc *crtc = priv->crtcs[id];
>   enum omap_channel channel = omap_crtc_channel(crtc);
>  
> - if (irqstatus & pipe2vbl(crtc)) {
> + if (irqstatus & dispc_mgr_get_vsync_irq(channel)) {
>   drm_handle_vblank(dev, id);
>   omap_crtc_vblank_irq(crtc);
>   }

You move pipe2vbl() to omap_irq.c, and then you change omap_irq to not
use pipe2vbl()?

 Tomi

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

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

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

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

--- Comment #17 from GhostlyDeath  ---
I do not believe the patches were ever applied upstream. Last time I tried
about two years ago, the patches did not work against the latest mesa at the
time.

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

[PATCH 1/4] drm: add generic zpos property

[Krzysztof Kozlowski]

On 05/11/2016 12:25 PM, Benjamin Gaignard wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to plane and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> 
> Compare to Marek's original patch zpos property is now specific to each
> plane and no more to the core.
> Normalize function take care of the range of per plane defined range
> before set normalized_zpos.
> 
> Signed-off-by: Benjamin Gaignard 

The order of SoB is ok, but the "from" field should be set to Marek.

Best regards,
Krzysztof

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Krzysztof Kozlowski]

On 05/11/2016 12:25 PM, Benjamin Gaignard wrote:
> This patch replaces zpos property handling custom code in Exynos DRM
> driver with calls to generic DRM code.
> 
> Signed-off-by: Marek Szyprowski 

Ekhm? From=Benjamin, SoB=Marek... why did you change the author?

Best regards,
Krzysztof

[PATCH 4/4] drm: rcar: use generic code for managing zpos plane property

[Laurent Pinchart]

Hi Benjamin,

Thank you for the patch.

On Wednesday 11 May 2016 12:25:08 Benjamin Gaignard wrote:
> This patch replaces zpos property handling custom code in rcar DRM
> driver with calls to generic DRM code.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Laurent Pinchart 
> Cc: Marek Szyprowski 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
>  5 files changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 0d8bdda..28d2cb6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,
> 
>  static unsigned int plane_zpos(struct rcar_du_plane *plane)
>  {
> - return to_rcar_plane_state(plane->plane.state)->zpos;
> + return plane->plane.state->normalized_zpos;
>  }

More code can be removed from the driver as the core now normalizes the zpos, 
but I can handle that as a follow-up patch.

Reviewed-by: Laurent Pinchart 

> 
>  static const struct rcar_du_format_info *
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index ed35467..c843c31 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -92,7 +92,6 @@ struct rcar_du_device {
>   struct {
>   struct drm_property *alpha;
>   struct drm_property *colorkey;
> - struct drm_property *zpos;
>   } props;
> 
>   unsigned int dpad0_source;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index e70a4f3..4ace0aa 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct
> rcar_du_device *rcdu) if (rcdu->props.colorkey == NULL)
>   return -ENOMEM;
> 
> - rcdu->props.zpos =
> - drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
> - if (rcdu->props.zpos == NULL)
> - return -ENOMEM;
> -
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index 8460ae1..4764afc 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -656,7 +656,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
> state->source = RCAR_DU_PLANE_MEMORY;
>   state->alpha = 255;
>   state->colorkey = RCAR_DU_COLORKEY_NONE;
> - state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> + plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> 
>   plane->state = >state;
>   plane->state->plane = plane;
> @@ -674,8 +674,6 @@ static int rcar_du_plane_atomic_set_property(struct
> drm_plane *plane, rstate->alpha = val;
>   else if (property == rcdu->props.colorkey)
>   rstate->colorkey = val;
> - else if (property == rcdu->props.zpos)
> - rstate->zpos = val;
>   else
>   return -EINVAL;
> 
> @@ -694,8 +692,6 @@ static int rcar_du_plane_atomic_get_property(struct
> drm_plane *plane, *val = rstate->alpha;
>   else if (property == rcdu->props.colorkey)
>   *val = rstate->colorkey;
> - else if (property == rcdu->props.zpos)
> - *val = rstate->zpos;
>   else
>   return -EINVAL;
> 
> @@ -767,8 +763,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
>   drm_object_attach_property(>plane.base,
>  rcdu->props.colorkey,
>  RCAR_DU_COLORKEY_NONE);
> - drm_object_attach_property(>plane.base,
> -rcdu->props.zpos, 1);
> + drm_plane_create_zpos_property(>plane, 1, 7);
>   }
> 
>   return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h index b18b7b2..8b91dd3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
> drm_plane *plane) * @hwindex: 0-based hardware plane index, -1 means unused
>   * @alpha: value of the plane alpha property
>   * @colorkey: value of the plane colorkey property
> - * @zpos: value of the plane zpos property
>   */
>  struct rcar_du_plane_state {
>   struct drm_plane_state state;
> @@ -62,7 +61,6 @@ struct rcar_du_plane_state {
> 
>   unsigned int alpha;
>   unsigned int colorkey;
> - unsigned int zpos;
>  };
> 
>  static inline struct rcar_du_plane_state *

-- 
Regards,

[pull] amdgpu drm-next-4.7

[Alex Deucher]

Hi Dave,

More amdgpu fixes for 4.7.  Highlights:
- enable async pageflips
- UVD fixes for polaris
- lots of GPUVM fixes
- whitespace and code cleanups
- misc bug fixes

The following changes since commit 2e726dc4b4e2dd3ae3fe675f9d3af88a2d593ee1:

  Merge tag 'mediatek-drm-2016-05-09' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2016-05-10 15:01:47 +1000)

are available in the git repository at:

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

for you to fetch changes up to b4eeed590deeff13a53db641129f0301d70248f3:

  drm/amd/powerplay: rewrite pp_sw_init to make code readable (2016-05-11 
13:30:33 -0400)


Alex Deucher (5):
  drm/amdgpu: fetch cu_info once at init
  drm/amdgpu: add missing licenses on a couple of files
  drm/amdgpu/dce11: don't share PLLs on Polaris
  drm/amdgpu: Support DRM_MODE_PAGE_FLIP_ASYNC (v2)
  drm/amdgpu/dce11: fix audio offset for asics with >7 audio pins

Christian König (11):
  drm/amdgpu: two minor 80 char fixes
  drm/amdgpu: make the VMID owner always 64bit
  drm/amdgpu: remove owner cleanup v2
  drm/amdgpu: remove define for reserved client ID
  drm/amd: cleanup remaining spaces and tabs v2
  drm/amdgpu: use fence_context to judge ctx switch v2
  drm/amdgpu: move preamble IB handling into common code
  drm/amdgpu: move context switch handling into common code v2
  drm/amdgpu: move the context from the IBs into the job
  drm/amdgpu: move VM fields into job
  drm/amdgpu: fix and cleanup user fence handling v2

Chunming Zhou (5):
  drm/amdgpu: fix wrong release of vmid owner
  drm/amdgpu: add client id for every vm
  drm/amdgpu: make vmid owner be client_id
  drm/amdgpu: add pipeline sync for compute job
  drm/amdgpu/gfx7: fix pipeline sync

Huang Rui (1):
  drm/amd/powerplay: rewrite pp_sw_init to make code readable

Monk Liu (2):
  drm/amdgpu: keep vm in job instead of ib (v2)
  drm/amdgpu: hdp flush should always do

Nils Wallménius (4):
  drm/amd/powerplay: Use defined constants for minium engine clock
  drm/amdgpu: Use max macro in *get_sleep_divider_id_from_clock
  drm/amdgpu: Simplify calculation in *get_sleep_divider_id_from_clock
  drm/amdgpu: Drop unused parameter for *get_sleep_divider_id_from_clock

Sonny Jiang (1):
  amdgpu/uvd: separate context buffer from DPB

Tom St Denis (3):
  drm/amd/amdgpu:  Enable CG for UVD6 on Carrizo
  drm/amd/amdgpu: Add name field to amd_ip_funcs (v2)
  drm/amd/amdgpu:  Added more named DRM info messages for debugging

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  92 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c|   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 104 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  24 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h|   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  81 
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  30 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   9 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c  |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  70 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  13 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  21 ++---
 drivers/gpu/drm/amd/amdgpu/atom.h  |   2 +-
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  14 ++-
 drivers/gpu/drm/amd/amdgpu/cik.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/cik_ih.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/cikd.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c|   1 +
 drivers/gpu/drm/amd/amdgpu/cz_ih.c |   3 +-
 drivers/gpu/drm/amd/amdgpu/cz_smumgr.h |   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  26 --
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  32 ---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  21 +++--
 drivers/gpu/drm/amd/amdgpu/fiji_dpm.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  70 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h  |   1 -
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  37 
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.h  |   1 -
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |   

[Bug 95329] Metro 2033 Redux benchmark fails to start

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

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

--- Comment #2 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
The game itself (excluding the benchmark) runs OK with Mesa.

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

[PATCH 4/4] drm: rcar: use generic code for managing zpos plane property

[Benjamin Gaignard]

This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 

Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Laurent Pinchart 
Cc: Marek Szyprowski 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
 5 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..28d2cb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index e70a4f3..4ace0aa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 8460ae1..4764afc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -656,7 +656,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = >state;
plane->state->plane = plane;
@@ -674,8 +674,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -694,8 +692,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -767,8 +763,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(>plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(>plane, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @hwindex: 0-based hardware plane index, -1 means unused
  * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
  */
 struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {

unsigned int alpha;
unsigned int colorkey;
-   unsigned int zpos;
 };

 static inline struct rcar_du_plane_state *
-- 
1.9.1

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Benjamin Gaignard]

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc33ec9..b34a7b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
-   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

struct device *dma_dev;
unsigned long da_start;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 50185ac..bbaf6d3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
-   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = _state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, >base);
-   copy->zpos = exynos_state->zpos;
return >base;
 }

@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_plane_state *exynos_state =
-   to_exynos_plane_state(state);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-   const struct exynos_drm_plane_config *config = exynos_plane->config;
-
-   if (property == dev_priv->plane_zpos_property &&
-   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
-   exynos_state->zpos = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
-   const struct exynos_drm_plane_state *exynos_state =
-   container_of(state, const struct exynos_drm_plane_state, base);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property)
-   *val = exynos_state->zpos;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
-   .atomic_set_property = exynos_drm_plane_atomic_set_property,
-   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private *dev_priv = dev->dev_private;
-   struct drm_property *prop;
-
-   prop = 

[PATCH 2/4] drm: sti: use generic zpos for plane

[Benjamin Gaignard]

remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/sti/sti_mixer.c |  2 +-
 drivers/gpu/drm/sti/sti_plane.c | 84 -
 drivers/gpu/drm/sti/sti_plane.h |  2 -
 3 files changed, 33 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index e7425c3..040abfe 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -245,7 +245,7 @@ static void sti_mixer_set_background_area(struct sti_mixer 
*mixer,

 int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
 {
-   int plane_id, depth = plane->zorder;
+   int plane_id, depth = plane->drm_plane.state->normalized_zpos + 1;
unsigned int i;
u32 mask, val;

diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index f10c98d..7c2e9d3 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
 #include "sti_drv.h"
 #include "sti_plane.h"

-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
-   STI_GDP_0,
-   STI_GDP_1,
-   STI_HQVDP_0,
-   STI_GDP_2,
-   STI_GDP_3,
-};
-
 const char *sti_plane_to_str(struct sti_plane *plane)
 {
switch (plane->desc) {
@@ -114,69 +105,58 @@ static void sti_plane_destroy(struct drm_plane *drm_plane)
drm_plane_cleanup(drm_plane);
 }

-static int sti_plane_set_property(struct drm_plane *drm_plane,
- struct drm_property *property,
- uint64_t val)
+static int sti_plane_get_default_zpos(enum drm_plane_type type)
 {
-   struct drm_device *dev = drm_plane->dev;
-   struct sti_private *private = dev->dev_private;
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (property == private->plane_zorder_property) {
-   plane->zorder = val;
+   switch (type) {
+   case DRM_PLANE_TYPE_PRIMARY:
return 0;
+   case DRM_PLANE_TYPE_OVERLAY:
+   return 1;
+   case DRM_PLANE_TYPE_CURSOR:
+   return 8;
}
+   return 0;
+}

-   return -EINVAL;
+static void sti_plane_reset(struct drm_plane *plane)
+{
+   drm_atomic_helper_plane_reset(plane);
+   plane->state->zpos = sti_plane_get_default_zpos(plane->type);
 }

-static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane)
+static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane,
+enum drm_plane_type type)
 {
-   struct drm_device *dev = drm_plane->dev;
-   struct sti_private *private = dev->dev_private;
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-   struct drm_property *prop;
-
-   prop = private->plane_zorder_property;
-   if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos", 1,
-GAM_MIXER_NB_DEPTH_LEVEL);
-   if (!prop)
-   return;
-
-   private->plane_zorder_property = prop;
+   switch (type) {
+   case DRM_PLANE_TYPE_PRIMARY:
+   drm_plane_create_zpos_immutable_property(drm_plane, 0, 0);
+   break;
+   case DRM_PLANE_TYPE_OVERLAY:
+   drm_plane_create_zpos_property(drm_plane, 1, 7);
+   break;
+   case DRM_PLANE_TYPE_CURSOR:
+   drm_plane_create_zpos_immutable_property(drm_plane, 8, 8);
+   break;
}
-
-   drm_object_attach_property(_plane->base, prop, plane->zorder);
 }

 void sti_plane_init_property(struct sti_plane *plane,
 enum drm_plane_type type)
 {
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(sti_plane_default_zorder); i++)
-   if (sti_plane_default_zorder[i] == plane->desc)
-   break;
-
-   plane->zorder = i + 1;
-
-   if (type == DRM_PLANE_TYPE_OVERLAY)
-   sti_plane_attach_zorder_property(>drm_plane);
+   sti_plane_attach_zorder_property(>drm_plane, type);

-   DRM_DEBUG_DRIVER("drm plane:%d mapped to %s with zorder:%d\n",
-plane->drm_plane.base.id,
-sti_plane_to_str(plane), plane->zorder);
+   DRM_DEBUG_DRIVER("drm plane:%d mapped to %s\n",
+plane->drm_plane.base.id, sti_plane_to_str(plane));
 }

 struct drm_plane_funcs 

[PATCH 1/4] drm: add generic zpos property

[Benjamin Gaignard]

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 

---
 Documentation/DocBook/gpu.tmpl  |  10 ++
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_atomic_helper.c |   6 +
 drivers/gpu/drm/drm_blend.c | 284 
 drivers/gpu/drm/drm_crtc_internal.h |   3 +
 include/drm/drm_crtc.h  |  25 
 6 files changed, 329 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 9dd48f7..0df6abb 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
the underlying hardware).


+"zpos" 
+   RANGE
+   Min= driver dependent, Max= driver dependent
+   Plane
+   Plane's 'z' position during blending operation (0 for 
background, highest for frontmost).
+   If two planes assigned to same CRTC have equal zpos values, the 
plane with higher plane
+   id is treated as closer to front. Can be IMMUTABLE if driver 
doesn't support changing
+   planes' order. Exact value range is driver dependent.
+   
+   
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2bd3e5a..df88253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 997fd21..f10652f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
 #include 
 #include 

+#include "drm_crtc_internal.h"
+
 /**
  * DOC: overview
  *
@@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;

+   ret = drm_atomic_helper_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
new file mode 100644
index 000..7017715
--- /dev/null
+++ b/drivers/gpu/drm/drm_blend.c
@@ -0,0 +1,284 @@
+/*
+ * Copyright (C) 2016 Samsung Electronics Co.Ltd
+ * Authors:
+ * Marek Szyprowski 
+ *
+ * DRM core plane blending related functions
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS 

[pull] radeon drm-fixes-4.6

[Alex Deucher]

Hi Dave,

Just two small display fixes for radeon.

The following changes since commit fca097169faf8b9cfe92d8926da7a1fa2d3cd452:

  Merge tag 'drm-intel-fixes-2016-05-02' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-05-05 12:12:09 
+1000)

are available in the git repository at:

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

for you to fetch changes up to e3c00d87845ab375f90fa6e10a5e72a3a5778cd3:

  drm/radeon: fix PLL sharing on DCE6.1 (v2) (2016-05-05 11:14:53 -0400)


Arindam Nath (1):
  drm/radeon: fix DP link training issue with second 4K monitor

Lucas Stach (1):
  drm/radeon: fix PLL sharing on DCE6.1 (v2)

 drivers/gpu/drm/radeon/atombios_crtc.c   | 10 ++
 drivers/gpu/drm/radeon/radeon_dp_auxch.c |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

[PATCH] drm: use seqlock for vblank time/count

[Matthew Auld]

This patch aims to replace the roll-your-own seqlock implementation with
full-blown seqlock'. We also remove the timestamp ring-buffer in favour
of single timestamp/count pair protected by a seqlock. In turn this
means we can now increment the vblank freely without the need for
clamping.

v2:
  - reduce the scope of the seqlock, keeping vblank_time_lock
  - make the seqlock per vblank_crtc, so multiple readers aren't blocked by
the writer

Cc: Mario Kleiner 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/drm_irq.c | 90 +++
 include/drm/drmP.h| 14 +++-
 2 files changed, 17 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3c1a6f1..0e95100 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -42,10 +42,6 @@
 #include 
 #include 

-/* Access macro for slots in vblank timestamp ringbuffer. */
-#define vblanktimestamp(dev, pipe, count) \
-   ((dev)->vblank[pipe].time[(count) % DRM_VBLANKTIME_RBSIZE])
-
 /* Retry timestamp calculation up to 3 times to satisfy
  * drm_timestamp_precision before giving up.
  */
@@ -82,29 +78,15 @@ static void store_vblank(struct drm_device *dev, unsigned 
int pipe,
 struct timeval *t_vblank, u32 last)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
-   u32 tslot;

assert_spin_locked(>vblank_time_lock);

vblank->last = last;

-   /* All writers hold the spinlock, but readers are serialized by
-* the latching of vblank->count below.
-*/
-   tslot = vblank->count + vblank_count_inc;
-   vblanktimestamp(dev, pipe, tslot) = *t_vblank;
-
-   /*
-* vblank timestamp updates are protected on the write side with
-* vblank_time_lock, but on the read side done locklessly using a
-* sequence-lock on the vblank counter. Ensure correct ordering using
-* memory barrriers. We need the barrier both before and also after the
-* counter update to synchronize with the next timestamp write.
-* The read-side barriers for this are in drm_vblank_count_and_time.
-*/
-   smp_wmb();
+   write_seqlock(>seqlock);
+   vblank->time = *t_vblank;
vblank->count += vblank_count_inc;
-   smp_wmb();
+   write_sequnlock(>seqlock);
 }

 /**
@@ -205,7 +187,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
const struct timeval *t_old;
u64 diff_ns;

-   t_old = (dev, pipe, vblank->count);
+   t_old = >time;
diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);

/*
@@ -239,49 +221,6 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
diff = 1;
}

-   /*
-* FIMXE: Need to replace this hack with proper seqlocks.
-*
-* Restrict the bump of the software vblank counter to a safe maximum
-* value of +1 whenever there is the possibility that concurrent readers
-* of vblank timestamps could be active at the moment, as the current
-* implementation of the timestamp caching and updating is not safe
-* against concurrent readers for calls to store_vblank() with a bump
-* of anything but +1. A bump != 1 would very likely return corrupted
-* timestamps to userspace, because the same slot in the cache could
-* be concurrently written by store_vblank() and read by one of those
-* readers without the read-retry logic detecting the collision.
-*
-* Concurrent readers can exist when we are called from the
-* drm_vblank_off() or drm_vblank_on() functions and other non-vblank-
-* irq callers. However, all those calls to us are happening with the
-* vbl_lock locked to prevent drm_vblank_get(), so the vblank refcount
-* can't increase while we are executing. Therefore a zero refcount at
-* this point is safe for arbitrary counter bumps if we are called
-* outside vblank irq, a non-zero count is not 100% safe. Unfortunately
-* we must also accept a refcount of 1, as whenever we are called from
-* drm_vblank_get() -> drm_vblank_enable() the refcount will be 1 and
-* we must let that one pass through in order to not lose vblank counts
-* during vblank irq off - which would completely defeat the whole
-* point of this routine.
-*
-* Whenever we are called from vblank irq, we have to assume concurrent
-* readers exist or can show up any time during our execution, even if
-* the refcount is currently zero, as vblank irqs are usually only
-* enabled due to the presence of readers, and because when we are 
called
-* from vblank irq we can't hold the vbl_lock to protect us from sudden
-

[PATCH] MAINTAINERS: add entry for the Sync File Framework

[Gustavo Padovan]

From: Gustavo Padovan 

Add Gustavo as maintainer for the Sync File Framework. Sumit is
co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
tree as base.

Cc: Sumit Semwal 
Signed-off-by: Gustavo Padovan 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8c10b4c..0abc9c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3677,6 +3677,16 @@ F:   include/linux/*fence.h
 F: Documentation/dma-buf-sharing.txt
 T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

+SYNC FILE FRAMEWORK
+M: Gustavo Padovan 
+S: Maintained
+L: linux-media at vger.kernel.org
+L: dri-devel at lists.freedesktop.org
+F: drivers/dma-buf/sync_file.c
+F: include/linux/sync_file.h
+F: Documentation/sync_file.txt
+T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
+
 DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
 M: Vinod Koul 
 L: dmaengine at vger.kernel.org
-- 
2.5.5

[PATCH v2 2/2] PM / Domains: Remove redundant wrapper functions for system PM

[Ulf Hansson]

Due to the previous changes to genpd, which removed the suspend_power_off
flag, several of the system PM callbacks is no longer doing any additional
checks but only invoking a corresponding pm_generic_* helper function.

To clean up the code let's remove these wrapper functions as they have
become redundant. Instead assign the system PM callbacks directly to
the pm_generic_*() helper function.

While changing this, it became clear that some of the current system PM
callbacks in genpd, invokes the wrong callback at the driver level. For
example, genpd's ->restore() callback invokes pm_generic_resume(), while
it should be pm_generic_restore(). Let's fix this as well.

Signed-off-by: Ulf Hansson 
---

Changes in v2:
- Updated changelog.

---
 drivers/base/power/domain.c | 203 +++-
 1 file changed, 12 insertions(+), 191 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index a608f52..658eb1b 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -768,48 +768,6 @@ static int pm_genpd_prepare(struct device *dev)
 }

 /**
- * pm_genpd_suspend - Suspend a device belonging to an I/O PM domain.
- * @dev: Device to suspend.
- *
- * Suspend a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a PM domain consisting of I/O devices.
- */
-static int pm_genpd_suspend(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_suspend(dev);
-}
-
-/**
- * pm_genpd_suspend_late - Late suspend of a device from an I/O PM domain.
- * @dev: Device to suspend.
- *
- * Carry out a late suspend of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a PM domain consisting of I/O devices.
- */
-static int pm_genpd_suspend_late(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_suspend_late(dev);
-}
-
-/**
  * pm_genpd_suspend_noirq - Completion of suspend of device in an I/O PM 
domain.
  * @dev: Device to suspend.
  *
@@ -873,92 +831,6 @@ static int pm_genpd_resume_noirq(struct device *dev)
 }

 /**
- * pm_genpd_resume_early - Early resume of a device in an I/O PM domain.
- * @dev: Device to resume.
- *
- * Carry out an early resume of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a power domain consisting of I/O
- * devices.
- */
-static int pm_genpd_resume_early(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_resume_early(dev);
-}
-
-/**
- * pm_genpd_resume - Resume of device in an I/O PM domain.
- * @dev: Device to resume.
- *
- * Resume a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a power domain consisting of I/O devices.
- */
-static int pm_genpd_resume(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_resume(dev);
-}
-
-/**
- * pm_genpd_freeze - Freezing a device in an I/O PM domain.
- * @dev: Device to freeze.
- *
- * Freeze a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a power domain consisting of I/O devices.
- */
-static int pm_genpd_freeze(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_freeze(dev);
-}
-
-/**
- * pm_genpd_freeze_late - Late freeze of a device in an I/O PM domain.
- * @dev: Device to freeze.
- *
- * Carry out a late freeze of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a power domain consisting of I/O
- * devices.
- */
-static int pm_genpd_freeze_late(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_freeze_late(dev);
-}
-
-/**
  * 

[PATCH v2 1/2] PM / Domains: Allow genpd to power on during the system PM phase

[Ulf Hansson]

If the PM domain is powered off when the first device in the domain starts
its system PM prepare phase, genpd prevents any further attempts to power
on the PM domain during the system PM phase. This constraint affects not
only the current device which is being prepared, but all devices within
the same PM domain.

This behaviour needs to be changed, as a subsystem/driver for a device in
the same PM domain may still need to be able to serve requests in the
system PM phase. Accordingly, it may need to runtime resume its device and
thus also request the corresponding PM domain to be powered on.

To deal with these scenarios, let's make the device operational in the
system PM prepare phase by runtime resuming it, no matter if the PM domain
is powered on or off. Changing this also enables us to remove genpd's
suspend_power_off flag, as it's being used to track this condition.
Additionally, we must allow the PM domain to be powered on via runtime PM
during the system PM phase.

This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
driver. It registers a genpd to model the ACP as a PM domain, but
unfortunately it's also abuses genpd's "internal" suspend_power_off flag
to deal with a corner case at system PM resume.

More precisely, the so called SMU block powers on the ACP at system PM
resume, unconditionally if it's being used or not. This may lead to that
genpd's internal status of the power state, may not correctly reflect the
power state of the HW after a system PM resume.

Because of changing the behaviour of genpd, by runtime resuming devices in
the prepare phase, the AMD ACP drm driver no longer have to deal with this
corner case. So let's just drop the related code in this driver.

Cc: David Airlie 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Maruthi Srinivas Bayyavarapu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ulf Hansson 
---

Changes in v2:
- Updated changelog.
- Added a fix in the AMD ACP (Audio CoProcessor) drm driver, which
registers a genpd. The fix removes the usage of genpd's internal
suspend_power_off flag as it's not needed after this change. Because of
this change I am also requesting an ack from the drm driver maintainer.

---
 drivers/base/power/domain.c | 84 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 23 -
 include/linux/pm_domain.h   |  1 -
 3 files changed, 31 insertions(+), 77 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index de23b64..a608f52 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -187,8 +187,7 @@ static int genpd_poweron(struct generic_pm_domain *genpd, 
unsigned int depth)
struct gpd_link *link;
int ret = 0;

-   if (genpd->status == GPD_STATE_ACTIVE
-   || (genpd->prepared_count > 0 && genpd->suspend_power_off))
+   if (genpd->status == GPD_STATE_ACTIVE)
return 0;

/*
@@ -735,21 +734,22 @@ static int pm_genpd_prepare(struct device *dev)

mutex_lock(>lock);

-   if (genpd->prepared_count++ == 0) {
+   if (genpd->prepared_count++ == 0)
genpd->suspended_count = 0;
-   genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
-   }

mutex_unlock(>lock);

-   if (genpd->suspend_power_off)
-   return 0;
-
/*
-* The PM domain must be in the GPD_STATE_ACTIVE state at this point,
-* so genpd_poweron() will return immediately, but if the device
-* is suspended (e.g. it's been stopped by genpd_stop_dev()), we need
-* to make it operational.
+* Even if the PM domain is powered off at this point, we can't expect
+* it to remain in that state during the entire system PM suspend
+* phase. Any subsystem/driver for a device in the PM domain, may still
+* need to serve a request which may require the device to be runtime
+* resumed and its PM domain to be powered.
+*
+* As we are disabling runtime PM at this point, we are preventing the
+* subsystem/driver to decide themselves. For that reason, we need to
+* make sure the device is operational as it may be required in some
+* cases.
 */
pm_runtime_resume(dev);
__pm_runtime_disable(dev, false);
@@ -758,8 +758,7 @@ static int pm_genpd_prepare(struct device *dev)
if (ret) {
mutex_lock(>lock);

-   if (--genpd->prepared_count == 0)
-   genpd->suspend_power_off = false;
+   genpd->prepared_count--;

mutex_unlock(>lock);
pm_runtime_enable(dev);
@@ -786,7 +785,7 @@ static int pm_genpd_suspend(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;

-   return genpd->suspend_power_off ? 0 : pm_generic_suspend(dev);
+   return 

[PATCH v2 0/2] PM / Domains: Second step in improving system PM code in genpd

[Ulf Hansson]

Changes in v2:
- Updated changelogs for both patches according to comments from Kevin.
- Updated patch 1/2, as I realized one genpd client driver, (ab)uses
genpd's suspend_power_off flag.

This is the second step in improving the system PM code in genpd. The first
patch is actually fixing a bug while it also enables for further clean-ups,
which is done in the second patch.

The next step of improving system PM code in genpd will move it to the part of
trying to optimize the behaviour, such as avoid waking up devices unless it's
really needed.

Ulf Hansson (2):
  PM / Domains: Allow genpd to power on during the system PM phase
  PM / Domains: Remove redundant wrapper functions for system PM

 drivers/base/power/domain.c | 271 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c |  23 ---
 include/linux/pm_domain.h   |   1 -
 3 files changed, 35 insertions(+), 260 deletions(-)

-- 
1.9.1

[PATCH 2/2] drm/sti: include linux/seq_file.h where needed

[Daniel Vetter]

On Wed, May 11, 2016 at 09:07:06AM +0200, Benjamin Gaignard wrote:
> Acked-by: Benjamin Gaignard 
> 
> 2016-05-09 23:51 GMT+02:00 Arnd Bergmann :
> > The sti drm driver has a lot of debugfs interface that cause
> > build errors in some configurations when seq_file.h is not
> > included implicitly:
> >
> > drm/sti/sti_mixer.c: In function 'mixer_dbg_ctl':
> > drm/sti/sti_mixer.c:88:2: error: implicit declaration of function 
> > 'seq_puts' [-Werror=implicit-function-declaration]
> > drm/sti/sti_mixer.c:91:4: error: implicit declaration of function 
> > 'seq_printf' [-Werror=implicit-function-declaration]
> > drm/sti/sti_gdp.c: In function 'gdp_dbg_ctl':
> > drm/sti/sti_gdp.c:146:2: error: implicit declaration of function 'seq_puts' 
> > [-Werror=implicit-function-declaration]
> > drm/sti/sti_gdp.c:149:4: error: implicit declaration of function 
> > 'seq_printf' [-Werror=implicit-function-declaration]
> > drm/sti/sti_gdp.c: In function 'gdp_dbg_show':
> > drm/sti/sti_gdp.c:208:32: error: dereferencing pointer to incomplete type 
> > 'struct seq_file'
> >
> > This adds an explicit #include statement in all of the affected files.
> >
> > Signed-off-by: Arnd Bergmann 

Applied to drm-misc.
-Daniel

> > ---
> >  drivers/gpu/drm/sti/sti_cursor.c | 2 ++
> >  drivers/gpu/drm/sti/sti_gdp.c| 1 +
> >  drivers/gpu/drm/sti/sti_hda.c| 1 +
> >  drivers/gpu/drm/sti/sti_hqvdp.c  | 1 +
> >  drivers/gpu/drm/sti/sti_mixer.c  | 1 +
> >  drivers/gpu/drm/sti/sti_tvout.c  | 1 +
> >  drivers/gpu/drm/sti/sti_vid.c| 1 +
> >  7 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sti/sti_cursor.c 
> > b/drivers/gpu/drm/sti/sti_cursor.c
> > index 3abb400151ac..4e990299735c 100644
> > --- a/drivers/gpu/drm/sti/sti_cursor.c
> > +++ b/drivers/gpu/drm/sti/sti_cursor.c
> > @@ -6,6 +6,8 @@
> >   * License terms:  GNU General Public License (GPL), version 2
> >   */
> >
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include 
> > diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> > index ff3d3e7e7704..ff33c38da197 100644
> > --- a/drivers/gpu/drm/sti/sti_gdp.c
> > +++ b/drivers/gpu/drm/sti/sti_gdp.c
> > @@ -5,6 +5,7 @@
> >   *  for STMicroelectronics.
> >   * License terms:  GNU General Public License (GPL), version 2
> >   */
> > +#include 
> >
> >  #include 
> >  #include 
> > diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> > index ec0d017eaf1a..f7d3464cdf09 100644
> > --- a/drivers/gpu/drm/sti/sti_hda.c
> > +++ b/drivers/gpu/drm/sti/sti_hda.c
> > @@ -8,6 +8,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c 
> > b/drivers/gpu/drm/sti/sti_hqvdp.c
> > index e05b0dc523ff..1edec29b9e45 100644
> > --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> > +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> > @@ -7,6 +7,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > diff --git a/drivers/gpu/drm/sti/sti_mixer.c 
> > b/drivers/gpu/drm/sti/sti_mixer.c
> > index e7425c38fc93..aed7801b51f7 100644
> > --- a/drivers/gpu/drm/sti/sti_mixer.c
> > +++ b/drivers/gpu/drm/sti/sti_mixer.c
> > @@ -5,6 +5,7 @@
> >   *  for STMicroelectronics.
> >   * License terms:  GNU General Public License (GPL), version 2
> >   */
> > +#include 
> >
> >  #include "sti_compositor.h"
> >  #include "sti_mixer.h"
> > diff --git a/drivers/gpu/drm/sti/sti_tvout.c 
> > b/drivers/gpu/drm/sti/sti_tvout.c
> > index 2c99016443e5..f983db5a59da 100644
> > --- a/drivers/gpu/drm/sti/sti_tvout.c
> > +++ b/drivers/gpu/drm/sti/sti_tvout.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gpu/drm/sti/sti_vid.c
> > index 5a2c5dc3687b..523ed19f5ac6 100644
> > --- a/drivers/gpu/drm/sti/sti_vid.c
> > +++ b/drivers/gpu/drm/sti/sti_vid.c
> > @@ -3,6 +3,7 @@
> >   * Author: Fabien Dessenne  for 
> > STMicroelectronics.
> >   * License terms:  GNU General Public License (GPL), version 2
> >   */
> > +#include 
> >
> >  #include 
> >
> > --
> > 2.7.0
> >
> 
> 
> 
> -- 
> Benjamin Gaignard
> 
> Graphic Working Group
> 
> Linaro.org │ Open source software for ARM SoCs
> 
> Follow Linaro: Facebook | Twitter | Blog

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

[PATCH 01/14] drm/amdgpu: fix wrong release of vmid owner

[Daniel Vetter]

On Tue, May 10, 2016 at 10:21:53AM +0200, Christian König wrote:
> Am 10.05.2016 um 07:05 schrieb Dave Airlie:
> >On 9 May 2016 at 18:17, Daniel Vetter  wrote:
> >>On Wed, May 04, 2016 at 02:26:42PM -0400, Alex Deucher wrote:
> >>>From: Chunming Zhou 
> >>>
> >>>The release of the vmid owner was not handled
> >>>correctly.  We need to take the lock and walk
> >>>the lru list.
> >>>
> >>>Signed-off-by: Chunming Zhou 
> >>>Reviewed-by: Alex Deucher 
> >>>Reviewed-by: Monk Liu 
> >>>Signed-off-by: Alex Deucher 
> >>I know that it's super hard to get former proprietary driver teams to
> >>stick their heads out on a public mailing lists. But imo being steward for
> >>them is totally the worst case option you can pick long term. It means you
> >>keep all the frustration of them not being fully in control (because
> >>sometimes other people from outside the company jump in), never learning
> >>how to driver the process themselves. And from the community pov it just
> >>looks like code-drop over the wall. In my experience (I've been trying to
> >>pull this off in public for almost 4 years now) trying to make exceptions
> >>to get folks started just doesn't help anyone.
> >>
> >>Imo contributors need to fence for their patches themselves (with you
> >>helping behind the scenes ofc) from the start.
> >I'd prefer this as well, I'd also prefer at least people who do develop 
> >upstream
> >like Christian be set free to do so again, having patches spring on
> >the lists fully
> >formed isn't really great.
> 
> Yeah, completely agree.
> 
> I actually tried to work on the public list again. Especially since I'm
> working on TTM improvements that would make things much easier.
> 
> The problem is that then internal people started to complain that some
> patches only got reviewed and merged upstream, but not internally.

Here at intel there's no internal review for patches, except things which
are embargoed. And even there the internal review is very often just a
"you can split out this refactoring step, please submit that part to
upstream directly".

> >It would be also nice if there was more external discussion around
> >design decisions etc,
> >get the internal patch debate onto the mailing list.
> 
> Yeah, again completely agree. Alex and I already spend a lot of effort
> trying to explain the difference between releasing code to the public and
> making code open source.
> 
> >Because at this rate I've no idea about most of the design internals
> >of the VM stuff,
> >and I really think you guys can do a lot better.
> >
> >Maybe start setup another mailing list like intel-gfx for this, so
> >it's a bit more private
> >than dri-devel, but what is happening at the moment is worse than what
> >used to happen.
> 
> Yeah, that sounds like a good idea to me.

One thing I do to force the isse, and it's a bit an asshole move, is to
just not merge or review anything posted to internal lists that should go
upstream. At least with repeat offenders, new people get 2-3 reminders how
it's supposed to work. But once people realize that they're just wasting
their own time, they tend to learn much faster ;-)

The other thing I learned is that you'll not win any popularity contest as
upstream maintainer trying to get a proprietary team to open up :(

Good luck!

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

[PATCH 11/23] drm: omapdrm: Check DSS manager state in the enable/disable helpers

[Daniel Vetter]

On Tue, May 10, 2016 at 04:28:22PM +0300, Tomi Valkeinen wrote:
> 
> On 26/04/16 23:35, Laurent Pinchart wrote:
> > The omapdrm DSS manager enable/disable operations check the DSS manager
> > state to avoid double enabling/disabling. Move that code to the DSS
> > manager to decrease the dependency of the DRM layer to the DSS layer.
> 
> Shouldn't omapdrm know if the CRTC is enabled or not, and avoid
> double-enable/disable by just looking at its internal state?
> 
> If so, we could remove dispc_mgr_is_enabled() call as you do, and add a
> WARN_ON() to omapdss if the mgr is already enabled/disabled to catch
> bugs in omapdrm.

Yeah, atomic helpers guarantees you that it'll never screw this up and
disable/enable twice. The only tricky bit to consider is boot-up, where
the firmware might have left something enabled, but by default the reset
helpers assume everything is off, and just reset sw state to all off.

Either patch up that state to match (you only need to set very few things,
no need to recover all the details about the mode), or manually shut
things down. But you need to make sure that at driver load sw matches hw
state.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 10/23] drm: omapdrm: Use atomic state instead of local device state

[Daniel Vetter]

On Tue, May 10, 2016 at 04:24:11PM +0300, Tomi Valkeinen wrote:
> 
> On 26/04/16 23:35, Laurent Pinchart wrote:
> > Instead of conditioning planes update based on the hardware device
> > state, use the CRTC state stored in the atomic state. This reduces the
> > dependency from the DRM layer to the DSS layer.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/omapdrm/omap_crtc.c | 23 ++-
> >  1 file changed, 14 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> > b/drivers/gpu/drm/omapdrm/omap_crtc.c
> > index 6359d7933b93..4c56d6a68390 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> > @@ -381,18 +381,23 @@ static void omap_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> >  
> > WARN_ON(omap_crtc->vblank_irq.registered);
> >  
> > -   if (dispc_mgr_is_enabled(omap_crtc->channel)) {
> > +   /*
> > +* Only flush the CRTC if it is currently active. CRTCs that require a
> > +* mode set are disabled prior plane updates and enabled afterwards.
> > +* They are thus not active, regardless of what their state report.
> > +*/
> > +   if (!crtc->state->active || drm_atomic_crtc_needs_modeset(crtc->state))
> > +   return;
> 
> If the DRM core doesn't track whether a CRTC HW is enabled at the
> moment, maybe omapdrm should? I guess the above works, but that if()
> makes me a bit uneasy, as it's not really obvious, and the logic behind
> it could possibly change later...
> 
> A "if (crtc->is_hw_enabled)" would be much more readable.

Look at the active_only paramater of the planes_commit helper. That should
do exactly what you want.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 27/35] drm/tegra: Use lockless gem BO free callback

[Daniel Vetter]

On Tue, May 10, 2016 at 03:33:00PM +0200, Thierry Reding wrote:
> On Tue, Apr 26, 2016 at 07:30:00PM +0200, Daniel Vetter wrote:
> > No dev->struct_mutex anywhere to be seen.
> > 
> > Cc: Thierry Reding 
> > Cc: Terje Bergström 
> > Cc: linux-tegra at vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/tegra/drm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Acked-by: Thierry Reding 

Applied to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/3] cec: correctly cancel delayed work when the CEC adapter is disabled

[Hans Verkuil]

From: Hans Verkuil 

When cleaning up pending work from the wait_queue list, make sure to cancel the
delayed work. Otherwise nasty kernel oopses will occur when the timer goes off
and the cec_data struct has disappeared.

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/cec.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/cec/cec.c b/drivers/staging/media/cec/cec.c
index 9a62aa2..c2a876e 100644
--- a/drivers/staging/media/cec/cec.c
+++ b/drivers/staging/media/cec/cec.c
@@ -393,13 +393,28 @@ static int cec_thread_func(void *_adap)
struct cec_data, list);
cec_data_cancel(data);
}
+   if (adap->transmitting)
+   cec_data_cancel(adap->transmitting);
+
+   /*
+* Cancel the pending timeout work. We have to unlock
+* the mutex when flushing the work since
+* cec_wait_timeout() will take it. This is OK since
+* no new entries can be added to wait_queue as long
+* as adap->transmitting is NULL, which it is due to
+* the cec_data_cancel() above.
+*/
while (!list_empty(>wait_queue)) {
data = list_first_entry(>wait_queue,
struct cec_data, list);
+
+   if (!cancel_delayed_work(>work)) {
+   mutex_unlock(>lock);
+   flush_scheduled_work();
+   mutex_lock(>lock);
+   }
cec_data_cancel(data);
}
-   if (adap->transmitting)
-   cec_data_cancel(adap->transmitting);
goto unlock;
}

-- 
2.8.1

[PATCH 2/3] cec: remove WARN_ON

[Hans Verkuil]

From: Hans Verkuil 

If a transmit is issued and before cec_transmit_done() is called the HDMI cable
is unplugged, then it is possible that adap->transmitting == NULL.

So drop the WARN_ON, explain why it can happen and just ignore the tranmit.

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/cec.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/cec/cec.c b/drivers/staging/media/cec/cec.c
index 3c5f084..9a62aa2 100644
--- a/drivers/staging/media/cec/cec.c
+++ b/drivers/staging/media/cec/cec.c
@@ -485,9 +485,13 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
dprintk(2, "cec_transmit_done %02x\n", status);
mutex_lock(>lock);
data = adap->transmitting;
-   if (WARN_ON(data == NULL)) {
-   /* This is weird and should not happen. Ignore this transmit */
-   dprintk(0, "cec_transmit_done without an ongoing transmit!\n");
+   if (data == NULL) {
+   /*
+* This can happen if a transmit was issued and the cable is
+* unplugged while the transmit is ongoing. Ignore this
+* transmit in that case.
+*/
+   dprintk(1, "cec_transmit_done without an ongoing transmit!\n");
goto unlock;
}

-- 
2.8.1

[PATCH 1/3] adv7511: always update CEC irq mask

[Hans Verkuil]

From: Hans Verkuil 

Instead of doing:

if (state->cec_enabled_adap)
adv7511_wr_and_or(sd, 0x95, 0xc0, enable ? 0x39 : 0x00);

do:

adv7511_wr_and_or(sd, 0x95, 0xc0,
  (state->cec_enabled_adap && enable) ? 0x39 : 0x00);

This ensures that the cec irq mask is always updated correctly according
to both conditions.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/adv7511.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 002117b..ddcde2d 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -937,8 +937,8 @@ static void adv7511_set_isr(struct v4l2_subdev *sd, bool 
enable)
else if (adv7511_have_hotplug(sd))
irqs |= MASK_ADV7511_EDID_RDY_INT;

-   if (state->cec_enabled_adap)
-   adv7511_wr_and_or(sd, 0x95, 0xc0, enable ? 0x39 : 0x00);
+   adv7511_wr_and_or(sd, 0x95, 0xc0,
+ (state->cec_enabled_adap && enable) ? 0x39 : 0x00);

/*
 * This i2c write can fail (approx. 1 in 1000 writes). But it
-- 
2.8.1

[PATCH 0/3] CEC Framework fixes

[Hans Verkuil]

From: Hans Verkuil 

While stress testing my CEC Framework v16 patch series found here:

http://www.spinics.net/lists/linux-input/msg44422.html

I discovered a few issues when dealing with HDMI disconnects.

The adv7511 patch fixes a potential race condition (never seen it go
wrong, but I feel much safer with the new code). The WARN_ON patch
removes a WARN_ON I thought could never happen when in fact it can
in a disconnect scenario, and the final patch fixes a nasty kernel
oops because the delayed work timer was never cleaned up while the
underlying data structure was freed.

I decided not to post a v17 patch series to avoid spamming everyone,
instead I'll merge these fixes in my cec pull request for Mauro and
update that pull request.

Regards,

Hans

Hans Verkuil (3):
  adv7511: always update CEC irq mask
  cec: remove WARN_ON
  cec: correctly cancel delayed work when the CEC adapter is disabled

 drivers/media/i2c/adv7511.c |  4 ++--
 drivers/staging/media/cec/cec.c | 29 -
 2 files changed, 26 insertions(+), 7 deletions(-)

-- 
2.8.1

[PATCH 9/9] dt-bindings: msm/dsi: Add assigned clocks bindings

[Rob Herring]

On Wed, May 04, 2016 at 11:34:39PM +0530, Archit Taneja wrote:
> 
> 
> On 5/4/2016 7:14 PM, Rob Herring wrote:
> >On Tue, May 03, 2016 at 04:28:01PM +0530, Archit Taneja wrote:
> >>The PLL in the DSI PHY block generates 2 clock outputs (Byte and Pixel
> >>clocks) that are fed into the Multimedia Clock Controller (MMCC). The MMCC
> >>uses these as source clocks for some of its RCGs to generate clocks that
> >>finally feed to the DSI host controller.
> >>
> >>Use the assigned clocks DT bindings to set up the MMCC RCGs that feed to
> >>the DSI host. Use the DSI PHY provided clocks to set up the parents
> >>of these assigned clocks.
> >>
> >>Signed-off-by: Archit Taneja 
> >>---
> >>  Documentation/devicetree/bindings/display/msm/dsi.txt | 15 +++
> >>  1 file changed, 15 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
> >>b/Documentation/devicetree/bindings/display/msm/dsi.txt
> >>index 0223f06..686f475 100644
> >>--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> >>+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> >>@@ -22,6 +22,10 @@ Required properties:
> >>* "core_clk"
> >>For DSIv2, we need an additional clock:
> >> * "src_clk"
> >>+- assigned-clocks: Parents of "byte_clk" and "pixel_clk" for the given 
> >>platform.
> >>+  See [1] for more details.
> >>+- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs 
> >>provided
> >>+  by a DSI PHY block.
> >>  - vdd-supply: phandle to vdd regulator device node
> >>  - vddio-supply: phandle to vdd-io regulator device node
> >>  - vdda-supply: phandle to vdda regulator device node
> >>@@ -90,6 +94,8 @@ Required properties:
> >>* "dsi_pll"
> >>* "dsi_phy"
> >>* "dsi_phy_regulator"
> >>+- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, 
> >>creating
> >>+  2 clocks: A byte clock (index 0), and a pixel clock (index 1).
> >
> >You can't really add new required properties unless they are for a new
> >compatible string.
> 
> Does this hold even when currently there isn't any device tree file in
> the kernel that has this DT node in it?

Generally it should, but in this case that is fine.

Acked-by: Rob Herring 

> I was trying to get all the properties in place before posting out
> patches that actually add the nodes into the platform files. Currently,
> they exist only DT files in downstream kernels.

"If it is not upstream, it doesn't exist." :)

Rob

[PATCH 2/2] drm/sti: include linux/seq_file.h where needed

[Benjamin Gaignard]

Acked-by: Benjamin Gaignard 

2016-05-09 23:51 GMT+02:00 Arnd Bergmann :
> The sti drm driver has a lot of debugfs interface that cause
> build errors in some configurations when seq_file.h is not
> included implicitly:
>
> drm/sti/sti_mixer.c: In function 'mixer_dbg_ctl':
> drm/sti/sti_mixer.c:88:2: error: implicit declaration of function 'seq_puts' 
> [-Werror=implicit-function-declaration]
> drm/sti/sti_mixer.c:91:4: error: implicit declaration of function 
> 'seq_printf' [-Werror=implicit-function-declaration]
> drm/sti/sti_gdp.c: In function 'gdp_dbg_ctl':
> drm/sti/sti_gdp.c:146:2: error: implicit declaration of function 'seq_puts' 
> [-Werror=implicit-function-declaration]
> drm/sti/sti_gdp.c:149:4: error: implicit declaration of function 'seq_printf' 
> [-Werror=implicit-function-declaration]
> drm/sti/sti_gdp.c: In function 'gdp_dbg_show':
> drm/sti/sti_gdp.c:208:32: error: dereferencing pointer to incomplete type 
> 'struct seq_file'
>
> This adds an explicit #include statement in all of the affected files.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/sti/sti_cursor.c | 2 ++
>  drivers/gpu/drm/sti/sti_gdp.c| 1 +
>  drivers/gpu/drm/sti/sti_hda.c| 1 +
>  drivers/gpu/drm/sti/sti_hqvdp.c  | 1 +
>  drivers/gpu/drm/sti/sti_mixer.c  | 1 +
>  drivers/gpu/drm/sti/sti_tvout.c  | 1 +
>  drivers/gpu/drm/sti/sti_vid.c| 1 +
>  7 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_cursor.c 
> b/drivers/gpu/drm/sti/sti_cursor.c
> index 3abb400151ac..4e990299735c 100644
> --- a/drivers/gpu/drm/sti/sti_cursor.c
> +++ b/drivers/gpu/drm/sti/sti_cursor.c
> @@ -6,6 +6,8 @@
>   * License terms:  GNU General Public License (GPL), version 2
>   */
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> index ff3d3e7e7704..ff33c38da197 100644
> --- a/drivers/gpu/drm/sti/sti_gdp.c
> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> @@ -5,6 +5,7 @@
>   *  for STMicroelectronics.
>   * License terms:  GNU General Public License (GPL), version 2
>   */
> +#include 
>
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index ec0d017eaf1a..f7d3464cdf09 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index e05b0dc523ff..1edec29b9e45 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
> index e7425c38fc93..aed7801b51f7 100644
> --- a/drivers/gpu/drm/sti/sti_mixer.c
> +++ b/drivers/gpu/drm/sti/sti_mixer.c
> @@ -5,6 +5,7 @@
>   *  for STMicroelectronics.
>   * License terms:  GNU General Public License (GPL), version 2
>   */
> +#include 
>
>  #include "sti_compositor.h"
>  #include "sti_mixer.h"
> diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
> index 2c99016443e5..f983db5a59da 100644
> --- a/drivers/gpu/drm/sti/sti_tvout.c
> +++ b/drivers/gpu/drm/sti/sti_tvout.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gpu/drm/sti/sti_vid.c
> index 5a2c5dc3687b..523ed19f5ac6 100644
> --- a/drivers/gpu/drm/sti/sti_vid.c
> +++ b/drivers/gpu/drm/sti/sti_vid.c
> @@ -3,6 +3,7 @@
>   * Author: Fabien Dessenne  for 
> STMicroelectronics.
>   * License terms:  GNU General Public License (GPL), version 2
>   */
> +#include 
>
>  #include 
>
> --
> 2.7.0
>



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

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

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

--- Comment #43 from Mez  ---
I also have those freezes in the Steam context menu when using DRI3 and
DRI_PRIME=1 to start Steam. Never with the integrated GPU or with fglrx.

I have a muxless AMD/AMD hybrid 6480G/6650M setup, I'm running Ubuntu
16.04/Unity on kernel 4.6-rc6 with radeon.runpm=0 set as boot (DRI_PRIME
doesn't work with dpm enabled for me), and this happens with mesa 11.2 and
11.3-devel (oibaf or padoka ppa).

I must add that I can play games perfectly without any freezes, it's just when
navigating in Steam context menus or settings that I encounter this, and the
system is unresponsive, no Ctrl-alt-fx to tty or such.

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

[Bug 95206] Display port bandwidth regression

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

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

--- Comment #10 from Christian L.  ---
Created attachment 123618
  --> https://bugs.freedesktop.org/attachment.cgi?id=123618=edit
dmesg with debugging patch

attached dmesg output of mainline kernel 4.5.0 with your debugging patch
applied

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

[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

[Javier Martinez Canillas]

On Wed, May 11, 2016 at 8:16 AM, Krzysztof Kozlowski
 wrote:
> On 05/11/2016 02:09 PM, Benjamin Gaignard wrote:
>> I haven't double check but I had to do changes into the original patch
>> so I guess that "from" field comes the new commit.
>>
>> I will manually edit the commit for v2,
>
> Git keeps original author untouched. You have to manually change the
> author to remove the original one (or use non-standard way of applying
> patches). If you use Git, just stick to typical workflow - git am, git
> commit --amend --signoff, git format-patch, etc.
>

and if the patch doesn't apply cleanly anymore and need to manually
re-do it, git allows to change the author when doing a commit with:

$ git commit --author='Marek Szyprowski '

> Best regards,
> Krzysztof
> --

Best regards,
Javier

[PATCH RESEND v2 3/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

Signed-off-by: Andrzej Hajda 
---
v2:
- changed specifier of INT pin from gpio to interrupt property
v3:
- improved gpio handling

sii8620: improve gpio_reset handling

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/Kconfig   |7 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/sil-sii8620.c | 1558 ++
 drivers/gpu/drm/bridge/sil-sii8620.h | 1517 +
 4 files changed, 3083 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index efd94e0..2823bc6 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -42,4 +42,11 @@ config DRM_PARADE_PS8622

 source "drivers/gpu/drm/bridge/analogix/Kconfig"

+config DRM_SIL_SII8620
+   tristate "Silicon Image SII8620 HDMI/MHL bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Silicon Image SII8620 HDMI/MHL bridge chip driver.
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index ff821f4..6dddaf1 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
+obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
new file mode 100644
index 000..6b72767
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -0,0 +1,1558 @@
+/*
+ * Driver for Silicon Image SiI8620 Mobile HD Transmitter
+ *
+ * Copyright (C) 2015, Samsung Electronics Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sil-sii8620.h"
+
+#define VAL_RX_HDMI_CTRL2_DEFVAL   VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+
+enum sii8620_mode {
+   CM_DISCONNECTED,
+   CM_DISCOVERY,
+   CM_MHL1,
+   CM_MHL3,
+   CM_ECBUS_S
+};
+
+enum sii8620_sink_type {
+   SINK_NONE,
+   SINK_HDMI,
+   SINK_DVI
+};
+
+enum sii8620_mt_state {
+   MT_STATE_READY,
+   MT_STATE_BUSY,
+   MT_STATE_DONE
+};
+
+struct sii8620 {
+   struct drm_bridge bridge;
+   struct device *dev;
+   struct clk *clk_xtal;
+   struct gpio_desc *gpio_reset;
+   struct gpio_desc *gpio_int;
+   struct regulator_bulk_data supplies[2];
+   struct mutex lock; /* context lock, protects fields below */
+   int error;
+   enum sii8620_mode mode;
+   enum sii8620_sink_type sink_type;
+   u8 cbus_status;
+   u8 stat[MHL_DST_SIZE];
+   u8 xstat[MHL_XDS_SIZE];
+   u8 devcap[MHL_DCAP_SIZE];
+   u8 xdevcap[MHL_XDC_SIZE];
+   u8 avif[19];
+   struct edid *edid;
+   unsigned int gen2_write_burst:1;
+   enum sii8620_mt_state mt_state;
+   struct list_head mt_queue;
+};
+
+struct sii8620_mt_msg;
+
+typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
+ struct sii8620_mt_msg *msg);
+
+struct sii8620_mt_msg {
+   struct list_head node;
+   u8 reg[4];
+   u8 ret;
+   sii8620_mt_msg_cb send;
+   sii8620_mt_msg_cb recv;
+};
+
+static const u8 sii8620_i2c_page[] = {
+   0x39, /* Main System */
+   0x3d, /* TDM and HSIC */
+   0x49, /* TMDS Receiver, MHL EDID */
+   0x4d, /* eMSC, HDCP, HSIC */
+   0x5d, /* MHL Spec */
+   0x64, /* MHL CBUS */
+   0x59, /* Hardware TPI (Transmitter Programming Interface) */
+   0x61, /* eCBUS-S, eCBUS-D */
+};
+
+static void sii8620_fetch_edid(struct sii8620 *ctx);
+static void sii8620_set_upstream_edid(struct sii8620 *ctx);
+static void sii8620_enable_hpd(struct sii8620 *ctx);
+static void sii8620_mhl_disconnected(struct sii8620 *ctx);
+
+static int sii8620_clear_error(struct sii8620 *ctx)
+{
+   int ret = ctx->error;
+
+   ctx->error = 0;
+   return ret;
+}
+
+static void sii8620_read_buf(struct sii8620 *ctx, u16 addr, u8 *buf, int len)
+{
+   struct device *dev = ctx->dev;
+   struct i2c_client *client = to_i2c_client(dev);
+   u8 data = addr;
+   struct i2c_msg msg[] 

[PATCH RESEND v2 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings

[Andrzej Hajda]

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
via I2C bus.

Signed-off-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/video/bridge/sil-sii8620.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
new file mode 100644
index 000..9409d9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
@@ -0,0 +1,33 @@
+Silicon Image SiI8620 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible: "sil,sii8620"
+   - reg: i2c address of the bridge
+   - cvcc10-supply: Digital Core Supply Voltage (1.0V)
+   - iovcc18-supply: I/O Supply Voltage (1.8V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin
+   - clocks, clock-names: specification and name of "xtal" clock
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii8620 at 39 {
+   reg = <0x39>;
+   compatible = "sil,sii8620";
+   cvcc10-supply = <_reg>;
+   iovcc18-supply = <_reg>;
+   interrupt-parent = <>;
+   interrupts = <2 0>;
+   reset-gpio = < 0 0>;
+   clocks = <_system_controller 0>;
+   clock-names = "xtal";
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH RESEND v2 1/3] video: add header file for Mobile High-Definition Link (MHL) interface

[Andrzej Hajda]

This header adds definitions specific to MHL protocol.

Signed-off-by: Andrzej Hajda 
---
 include/linux/mhl.h | 292 
 1 file changed, 292 insertions(+)
 create mode 100644 include/linux/mhl.h

diff --git a/include/linux/mhl.h b/include/linux/mhl.h
new file mode 100644
index 000..6917508
--- /dev/null
+++ b/include/linux/mhl.h
@@ -0,0 +1,292 @@
+/*
+ * Defines for Mobile High-Definition Link (MHL) interface
+ *
+ * Copyright (C) 2015, Samsung Electronics, Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * Based on MHL driver for Android devices.
+ * Copyright (C) 2013-2014 Silicon Image, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef LINUX_MHL_H
+#define LINUX_MHL_H
+
+/* Device Capabilities Registers */
+enum {
+   MHL_DCAP_DEV_STATE,
+   MHL_DCAP_MHL_VERSION,
+   MHL_DCAP_CAT,
+   MHL_DCAP_ADOPTER_ID_H,
+   MHL_DCAP_ADOPTER_ID_L,
+   MHL_DCAP_VID_LINK_MODE,
+   MHL_DCAP_AUD_LINK_MODE,
+   MHL_DCAP_VIDEO_TYPE,
+   MHL_DCAP_LOG_DEV_MAP,
+   MHL_DCAP_BANDWIDTH,
+   MHL_DCAP_FEATURE_FLAG,
+   MHL_DCAP_DEVICE_ID_H,
+   MHL_DCAP_DEVICE_ID_L,
+   MHL_DCAP_SCRATCHPAD_SIZE,
+   MHL_DCAP_INT_STAT_SIZE,
+   MHL_DCAP_RESERVED,
+   MHL_DCAP_SIZE
+};
+
+#define MHL_DCAP_CAT_SINK  0x01
+#define MHL_DCAP_CAT_SOURCE0x02
+#define MHL_DCAP_CAT_POWER 0x10
+#define MHL_DCAP_CAT_PLIM(x)   ((x) << 5)
+
+#define MHL_DCAP_VID_LINK_RGB444   0x01
+#define MHL_DCAP_VID_LINK_YCBCR444 0x02
+#define MHL_DCAP_VID_LINK_YCBCR422 0x04
+#define MHL_DCAP_VID_LINK_PPIXEL   0x08
+#define MHL_DCAP_VID_LINK_ISLANDS  0x10
+#define MHL_DCAP_VID_LINK_VGA  0x20
+#define MHL_DCAP_VID_LINK_16BPP0x40
+
+#define MHL_DCAP_AUD_LINK_2CH  0x01
+#define MHL_DCAP_AUD_LINK_8CH  0x02
+
+#define MHL_DCAP_VT_GRAPHICS   0x00
+#define MHL_DCAP_VT_PHOTO  0x02
+#define MHL_DCAP_VT_CINEMA 0x04
+#define MHL_DCAP_VT_GAMES  0x08
+#define MHL_DCAP_SUPP_VT   0x80
+
+#define MHL_DCAP_LD_DISPLAY0x01
+#define MHL_DCAP_LD_VIDEO  0x02
+#define MHL_DCAP_LD_AUDIO  0x04
+#define MHL_DCAP_LD_MEDIA  0x08
+#define MHL_DCAP_LD_TUNER  0x10
+#define MHL_DCAP_LD_RECORD 0x20
+#define MHL_DCAP_LD_SPEAKER0x40
+#define MHL_DCAP_LD_GUI0x80
+#define MHL_DCAP_LD_ALL0xFF
+
+#define MHL_DCAP_FEATURE_RCP_SUPPORT   0x01
+#define MHL_DCAP_FEATURE_RAP_SUPPORT   0x02
+#define MHL_DCAP_FEATURE_SP_SUPPORT0x04
+#define MHL_DCAP_FEATURE_UCP_SEND_SUPPOR   0x08
+#define MHL_DCAP_FEATURE_UCP_RECV_SUPPORT  0x10
+#define MHL_DCAP_FEATURE_RBP_SUPPORT   0x40
+
+/* Extended Device Capabilities Registers */
+enum {
+   MHL_XDC_ECBUS_SPEEDS,
+   MHL_XDC_TMDS_SPEEDS,
+   MHL_XDC_ECBUS_ROLES,
+   MHL_XDC_LOG_DEV_MAPX,
+   MHL_XDC_SIZE
+};
+
+#define MHL_XDC_ECBUS_S_0750x01
+#define MHL_XDC_ECBUS_S_8BIT   0x02
+#define MHL_XDC_ECBUS_S_12BIT  0x04
+#define MHL_XDC_ECBUS_D_1500x10
+#define MHL_XDC_ECBUS_D_8BIT   0x20
+
+#define MHL_XDC_TMDS_000   0x00
+#define MHL_XDC_TMDS_150   0x01
+#define MHL_XDC_TMDS_300   0x02
+#define MHL_XDC_TMDS_600   0x04
+
+/* MHL_XDC_ECBUS_ROLES flags */
+#define MHL_XDC_DEV_HOST   0x01
+#define MHL_XDC_DEV_DEVICE 0x02
+#define MHL_XDC_DEV_CHARGER0x04
+#define MHL_XDC_HID_HOST   0x08
+#define MHL_XDC_HID_DEVICE 0x10
+
+/* MHL_XDC_LOG_DEV_MAPX flags */
+#define MHL_XDC_LD_PHONE   0x01
+
+/* Device Status Registers */
+enum {
+   MHL_DST_CONNECTED_RDY,
+   MHL_DST_LINK_MODE,
+   MHL_DST_VERSION,
+   MHL_DST_SIZE
+};
+
+/* Offset of DEVSTAT registers */
+#define MHL_DST_OFFSET 0x30
+#define MHL_DST_REG(name) (MHL_DST_OFFSET + MHL_DST_##name)
+
+#define MHL_DST_CONN_DCAP_RDY  0x01
+#define MHL_DST_CONN_XDEVCAPP_SUPP 0x02
+#define MHL_DST_CONN_POW_STAT  0x04
+#define MHL_DST_CONN_PLIM_STAT_MASK0x38
+
+#define MHL_DST_LM_CLK_MODE_MASK   0x07
+#define MHL_DST_LM_CLK_MODE_PACKED_PIXEL   0x02
+#define MHL_DST_LM_CLK_MODE_NORMAL 0x03
+#define 

[PATCH RESEND v2 0/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

Hi Inki, Daniel,

This is RESEND of the patchset from 01-08-2016 (5 months already).
The only change is added ack for bindings, thanks Rob.
I have put Inki as the main recipient because Sii8620 is present on Samsung
dev board and since drivers of bridges have no dedicated maintainer the practice
is (am I right?) to push such drivers via DRM device maintainers.
Inki could you take a look?

I have added also Daniel to check if include/linux/mhl.h is correct enough
and in proper location, I hope I have addressed this kind request correctly.

Below original message:

This version of patchset contains fixes of interrupt pin and binding description
according to Rob Herring comments.

This patchset adds MHL bridge driver for Silicon Image SiI8620 chip.
The chip is quite powerful, supports MHL versions up to 3.0. It is present
in multiple mobile devices.

I have put common MHL definitions into include/linux/mhl.h header file,
similarily to include/linux/hdmi.h.

The patchset is based on latest exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (3):
  video: add header file for Mobile High-Definition Link (MHL) interface
  dt-bindings: add Silicon Image SiI8620 bridge bindings
  drm/bridge: add Silicon Image SiI8620 driver

 .../bindings/video/bridge/sil-sii8620.txt  |   33 +
 drivers/gpu/drm/bridge/Kconfig |7 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/sil-sii8620.c   | 1558 
 drivers/gpu/drm/bridge/sil-sii8620.h   | 1517 +++
 include/linux/mhl.h|  292 
 6 files changed, 3408 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h
 create mode 100644 include/linux/mhl.h

-- 
1.9.1

[Bug 95346] Stellaris - Black/super dark planets

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

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core

--- Comment #3 from Michel Dänzer  ---
Replaying the apitrace with LIBGL_ALWAYS_SOFTWARE=1 (forcing llvmpipe) gives
the same broken rendering, so this doesn't seem to be a driver specific issue.
Reassigning to Mesa core for now.


I also noticed a lot of messages like these while replaying the apitrace, which
might even indicate a game bug:

555820 @0 glCompileShaderARB(shaderObj = 266)
555820: warning: 0:298(55): warning: `vSinCos' used uninitialized
0:298(66): warning: `vSinCos' used uninitialized

555825 @0 glCompileShaderARB(shaderObj = 267)
555825: warning: 0:547(83): warning: `diffLight' used uninitialized
0:547(94): warning: `specLight' used uninitialized

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

[Bug 95346] Stellaris - Black/super dark planets

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

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

--- Comment #2 from Christopher W. Carpenter  ---
apitrace is too large for attachment. I have it on dropbox here:
https://www.dropbox.com/s/6s7sc0ao5sxr1f1/stellaris.trace?dl=0. Please let me
know if there is a better place to put this.

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

[Bug 95346] Stellaris - Black/super dark planets

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

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

--- Comment #1 from Christopher W. Carpenter  ---
Created attachment 123614
  --> https://bugs.freedesktop.org/attachment.cgi?id=123614=edit
An example of the planet rendering properly

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

[Bug 95346] Stellaris - Black/super dark planets

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

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

Bug ID: 95346
   Summary: Stellaris - Black/super dark planets
   Product: Mesa
   Version: git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mordocai at mordocai.net
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 123613
  --> https://bugs.freedesktop.org/attachment.cgi?id=123613=edit
Visual glitch of planet in stellaris

Stellaris is 32-bit only. This was tested on debian testing x86_64 with
compiled for 32-bit and installed git master radeonsi driver and libGL. 

I confirmed stellaris was using the correct libGL and radeonsi_dri via
/proc/pid/maps.

I compiled mesa with:

CC="gcc -m32" CXX="g++ -m32" ./autogen.sh --with-gallium-drivers=radeonsi
--with-egl-platforms=drm,x11 --enable-texture-float --enable-glx-tls
--enable-shared-glapi --enable-glx --enable-driglx-direct --enable-gles1
--enable-gles2 --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu

It ouputs:
prefix:  /usr/local
exec_prefix: ${prefix}
libdir:  ${exec_prefix}/lib
includedir:  ${prefix}/include

OpenGL:  yes (ES1: yes ES2: yes)

OSMesa:  no

DRI platform:drm
DRI drivers: i915 i965 nouveau r200 radeon swrast 
DRI driver dir:  ${libdir}/dri
GLX: DRI-based

EGL: yes
EGL platforms:   drm x11
EGL drivers: builtin:egl_dri2 builtin:egl_dri3

Vulkan drivers:  no

llvm:yes
llvm-config: /usr/bin/llvm-config
llvm-version:3.6.2

Gallium drivers: radeonsi
Gallium st:  mesa vdpau

Shader cache:no

Shared libs: yes
Static libs: no
Shared-glapi:yes

CFLAGS:  -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-math-errno -fno-trapping-math -fno-builtin-memcmp
CXXFLAGS:-g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp
Macros:  -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-D_GNU_SOURCE -DUSE_SSE41 -DNDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_XLOCALE_H
-DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN
-DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_ALIAS
-DHAVE_DRI3 -DHAVE_MINCORE -DHAVE_ST_VDPAU -DHAVE_LLVM=0x0306
-DMESA_LLVM_VERSION_PATCH=2

LLVM_CFLAGS: -I/usr/lib/llvm-3.6/include   -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
LLVM_CXXFLAGS:   -I/usr/lib/llvm-3.6/include   -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS-std=c++11  
LLVM_CPPFLAGS:   -I/usr/lib/llvm-3.6/include   -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
LLVM_LDFLAGS:-L/usr/lib/llvm-3.6/lib 

PYTHON2: python2.7
PYTHON3: python3.5

Run 'make' to build Mesa


My graphics card shows up as:

Advanced Micro Devices [AMD/ATI] Curacao XT [Radeon R7 370 / R9 270X/370 OEM]

I have attached a picture with this description. I don't see a way to add
multiple attachments so I will attach a picture of what it should look like as
well as the apitrace after I submit.

I'm new to all this so sorry if I missed anything! I have a vested interest in
fixing this and am a programmer(though super inexperienced with graphics) so
feel free to give me technical instructions.

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

[Bug 117861] DRM dead lock code path

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

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

--- Comment #2 from Qiang Yu  ---
(In reply to Alex Deucher from comment #1)
> I believe this is fixed in:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=6984128d01cf935820a0563f3a00c6623ba58109
> Which should probably go to stable.

Your fix is in 4.5 kernel and related to another dead lock path:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579610

This dead lock path is different and remains in the kernel master branch.

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

[PATCH 3/4] drm: Add helper for simple display pipeline

[Daniel Vetter]

On Tue, May 10, 2016 at 8:59 AM, Daniel Vetter  wrote:
>> if (ret)
>> return ret;
>>
>> /* How to handle !visible, is it even possible? */
>
> if (!visible)
> return -EINVAL;
>
> You can't, so need to reject it.

Ok, on further thought I think we need a bit more here. We not just
need to make sure the plane is visible and not scaled or positioned,
but also that the plane is only enabled iff the crtc is.

So even before you call anything else you need to have this check:

if (crtc_state->enable != !!plane_state->crtc)
return -EINVAL; /* plane must match crtc enable state */

if (!crtc_state->enable)
return 0; /* nothing to check when disabling or disabled
already, calling check helpers and driver callbacks might only result
in confusion in such a case. */

Then continue with the remaining check logic that you have already,
with my coments in the earlier mail addressed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC 00/11] drm/tilcdc: Atomic modeset support

[Daniel Vetter]

On Tue, May 10, 2016 at 7:30 PM, Noralf Trønnes  wrote:
>> Hm, my idea with external transcoders was to pull them in as a
>> drm_bridge. That's of course more work, and we already have a
>> proliferation of different transcoder driver standards in drm
>> unfortunately (there's drm_bridge, but als to drm_encoder_slave).
>
>
> Does this mean that you want the drm_bridge_*() functions in
> disable_outputs(), crtc_set_mode() and
> drm_atomic_helper_commit_modeset_enables() to run for
> drm_simple_display_pipe?
>
> Because "drm: Make drm_encoder_helper_funcs optional" skips those bridge
> functions if encoder->helper_private is not set (I found this pattern in
> mode_fixup() which skips drm_bridge_mode_fixup() on !funcs).
> So if that's the case, I have to add an empty drm_encoder_helper_funcs to
> the
> simple pipe.

Oops you're right. I think the correct fix would be to always run the
bridge functions though, there's really no need to break that when
there's no encoder vtable. Since I merged your initial patch already,
care to create a follow-up patch to rectify this?

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

[GIT PULL 2nd] exynos-drm-next

[Inki Dae]

Hi Dave,

   This 2nd pull request includes one patch I missed, some cleanups
   and fixups.

   Summary:
   - expose HDMI-PHY clock to other drivers.
 . this patch was included in below patch series but I missed.
 http://www.spinics.net/lists/dri-devel/msg103097.html
   - some fixups about DECON5433 driver
 . this patch corrects vblank handling and fixes up trigger
   configuration.
   - use generic functions - gem_prime_mmap and dma_buf_mmap.
   - use DMA-Mapping API instead of specific one.
   - some code cleanups and fixeups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 2e726dc4b4e2dd3ae3fe675f9d3af88a2d593ee1:

  Merge tag 'mediatek-drm-2016-05-09' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2016-05-10 15:01:47 +1000)

are available in the git repository at:


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

for you to fetch changes up to dd65a6867454117ecaeb8944dc231a4737681782:

  drm/exynos/decon5433: fix trigger configuration (2016-05-10 23:11:46 +0900)


Andrzej Hajda (5):
  drm/exynos/hdmi: expose HDMI-PHY clock as pipeline clock
  drm/exynos/decon5433: handle vblank in vblank interrupt
  drm/exynos/decon5433: do not use unnecessary software trigger
  drm/exynos: fix cancel page flip code
  drm/exynos/decon5433: fix trigger configuration

Daniel Vetter (1):
  drm/exynos: Nuke dummy fb->dirty callback

Javier Martinez Canillas (1):
  drm/exynos/hdmi: Don't print error on deferral due to regulators

Joonyoung Shim (3):
  drm/exynos: support gem_prime_mmap
  drm/exynos: fix imported dma-buf to be mapped
  drm/exynos: use directly DMA mapping APIs on g2d

Philipp Zabel (2):
  drm/exynos/dpi: use of_graph_get_endpoint_by_regs helper
  drm/exynos/dsi: use of_graph_get_endpoint_by_regs helper

Tobias Jakobi (1):
  drm/exynos: fimd: harden fimd_calc_clkdiv()

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |   16 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   15 ++---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |   69 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |   57 +--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   11 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |9 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   10 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   70 
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   12 +---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   73 ++---
 11 files changed, 120 insertions(+), 223 deletions(-)