[PATCH v2 3/4] drm/dsi: Implement dcs set/get display brightness

[Emil Velikov]

On 13 July 2016 at 17:44, Vinay Simha BN  wrote:

> +int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
> +   u16 *brightness)
> +{
> +   ssize_t err;
> +
> +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
> +   brightness, sizeof(*brightness));
> +   if (err < 0) {
> +   if (err == 0)
Something looks fishy here. This can never be true, can it ?

 -Emil

[PATCH v8 4/4] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Emil Velikov]

On 13 July 2016 at 19:58, John Stultz  wrote:
> On Wed, Jul 13, 2016 at 9:44 AM, Vinay Simha BN  wrote:
>> Add support for the JDI LT070ME05000 WUXGA DSI panel used in
>> Nexus 7 2013 devices.
>>
>> Programming sequence for the panel is was originally found in the
>> android-msm-flo-3.4-lollipop-release branch from:
>> https://android.googlesource.com/kernel/msm.git
>>
>> And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
>> file in:
>> git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27
>>
>> Cc: Archit Taneja 
>> Cc: Rob Clark 
>> Cc: Sumit Semwal 
>> Cc: John Stultz 
>> Cc: Emil Velikov 
>> Cc: Thierry Reding 
>> Cc: David Airlie 
>> Signed-off-by: Sumit Semwal 
>> Signed-off-by: John Stultz 
>> Signed-off-by: Vinay Simha BN 
>
> Just fyi, I've re-integrated this patch set into my flo-WIP branch and
> its working well.
>
> I dunno if its of any use, but:
> Tested-by: John Stultz 
>
It always is. Thank you!

Vinay, thanks for the patience and I hope you grok the reason behind
the requested changes.

The patch is
Reviewed-by: Emil Velikov 

Regards,
Emil

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Just 2 regression fixes.

I've also realized that a pile of hang fixes for kbl landed in next, and
no one thought of backporting it to 4.7 - kbl has lost prelim_hw_support
tagging in 4.7-rc1 already. Mika is prepping a topic branch for those,
will send you a separate pull request since it's quite a bit (but should
be all well restricted to kbl code, so similar to polaris in amdgpu).

Cheers, Daniel


The following changes since commit cab103274352721b77fc5923a631fc63350bef8e:

  drm/i915: Fix missing unlock on error in i915_ppgtt_info() (2016-06-30 
13:30:15 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-07-14

for you to fetch changes up to aeddda06c1a704bb97c8a7bfe7a472120193bd56:

  drm/i915: Ignore panel type from OpRegion on SKL (2016-07-14 16:08:04 +0200)


Chris Wilson (1):
  drm/i915: Update ifdeffery for mutex->owner

Ville Syrjälä (1):
  drm/i915: Ignore panel type from OpRegion on SKL

 drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
 drivers/gpu/drm/i915/intel_opregion.c| 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

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

[PATCH 0/3] drm/msm: Deletion of a few unnecessary checks

[Rob Clark]

On Wed, Jul 13, 2016 at 1:54 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 13 Jul 2016 19:46:45 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (3):
>   HDMI: Delete an unnecessary check before the function call "kfree"
>   Delete unnecessary checks before drm_gem_object_unreference_unlocked()
>   Delete an unnecessary check before drm_gem_object_unreference()

thanks, I've pushed these to msm-next

BR,
-R

>  drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c| 2 +-
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 3 +--
>  drivers/gpu/drm/msm/msm_fb.c| 4 ++--
>  drivers/gpu/drm/msm/msm_gem.c   | 8 ++--
>  4 files changed, 6 insertions(+), 11 deletions(-)
>
> --
> 2.9.0
>

[PATCH v3 2/2] drm/fsl-dcu: add support for drm bridge

[Stefan Agner]

On 2016-07-14 03:54, Meng Yi wrote:
> The current output code only supports connection to drm panels.
> Add code to support drm bridge, to support connections to
> external connectors.
> 
> Signed-off-by: Meng Yi 
> ---
> Changes since V1:
> -no change
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 2e71f4b..e875b4e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -189,6 +189,7 @@ err_cleanup:
>  static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
>   const struct of_endpoint *ep)
>  {
> + struct drm_bridge *bridge;
>   struct device_node *np;
>   int ret;
>  
> @@ -201,7 +202,17 @@ static int fsl_dcu_attach_endpoint(struct
> fsl_dcu_drm_device *fsl_dev,
>   return ret;
>   }
>  
> - return -ENODEV;
> + bridge = of_drm_find_bridge(np);

Since you need np here again, you need to move the of_node_put above
back into the if statement...


> + of_node_put(np);
> + if (!bridge)
> + return -ENODEV;
> +
> + fsl_dev->encoder.bridge = bridge;
> + bridge->encoder = _dev->encoder;
> +
> + ret = drm_bridge_attach(fsl_dev->drm, bridge);
> +
> + return ret;

Also simplify this return statement.

--
Stefan

>  }
>  
>  int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev)

[PATCH v3 1/2] drm/fsl-dcu: rework codes to support of_graph dt binding for panel

[Stefan Agner]

Hi Meng,

This currently does not apply on top of drm-next, can you please rebase?

Some more comments below:

On 2016-07-14 03:54, Meng Yi wrote:
> This patch rework the output code to add of_graph dt binding support
> for panel device and also keeps the backward compatibility
> 
> Signed-off-by: Meng Yi 
> ---
> Changes in V3:
> -simplify return value statements
> Changes in V2:
> -fix some coding style issue
> -add fsl_dev->connector.panel check
> -use fsl_dev->np and drop fsl_dev->dev->of_node
> -return 'ret' when fsl_dcu_attach_panel failed
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h |  3 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 73 
> 
>  3 files changed, 55 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> index c564ec6..b48ffa7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> @@ -43,7 +43,7 @@ int fsl_dcu_drm_modeset_init(struct
> fsl_dcu_drm_device *fsl_dev)
>   if (ret)
>   goto fail_encoder;
>  
> - ret = fsl_dcu_drm_connector_create(fsl_dev, _dev->encoder);
> + ret = fsl_dcu_create_outputs(fsl_dev);
>   if (ret)
>   goto fail_connector;
>  
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> index 7093109..5a7b88e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> @@ -25,9 +25,8 @@ to_fsl_dcu_connector(struct drm_connector *con)
>: NULL;
>  }
>  
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder);
>  int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
>   struct drm_crtc *crtc);
> +int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev);
>  
>  #endif /* __FSL_DCU_DRM_CONNECTOR_H__ */
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 98c998d..2e71f4b 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -141,12 +142,12 @@ static const struct drm_connector_helper_funcs
> connector_helper_funcs = {
>   .mode_valid = fsl_dcu_drm_connector_mode_valid,
>  };
>  
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder)
> +static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
> +  struct drm_panel *panel)
>  {
> + struct drm_encoder *encoder = _dev->encoder;
>   struct drm_connector *connector = _dev->connector.base;
>   struct drm_mode_config *mode_config = _dev->drm->mode_config;
> - struct device_node *panel_node;
>   int ret;
>  
>   fsl_dev->connector.encoder = encoder;
> @@ -170,21 +171,7 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
> mode_config->dpms_property,
> DRM_MODE_DPMS_OFF);
>  
> - panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
> - if (!panel_node) {
> - dev_err(fsl_dev->dev, "fsl,panel property not found\n");
> - ret = -ENODEV;
> - goto err_sysfs;
> - }
> -
> - fsl_dev->connector.panel = of_drm_find_panel(panel_node);
> - if (!fsl_dev->connector.panel) {
> - ret = -EPROBE_DEFER;
> - goto err_panel;
> - }
> - of_node_put(panel_node);
> -
> - ret = drm_panel_attach(fsl_dev->connector.panel, connector);
> + ret = drm_panel_attach(panel, connector);
>   if (ret) {
>   dev_err(fsl_dev->dev, "failed to attach panel\n");
>   goto err_sysfs;
> @@ -192,11 +179,57 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
>  
>   return 0;
>  
> -err_panel:
> - of_node_put(panel_node);
>  err_sysfs:
>   drm_connector_unregister(connector);
>  err_cleanup:
>   drm_connector_cleanup(connector);
>   return ret;
>  }
> +
> +static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
> + const struct of_endpoint *ep)
> +{
> + struct device_node *np;
> + int ret;
> +
> + np = of_graph_get_remote_port_parent(ep->local_node);
> +
> + fsl_dev->connector.panel = of_drm_find_panel(np);
> + of_node_put(np);
> + if (fsl_dev->connector.panel) {
> + ret = fsl_dcu_attach_panel(fsl_dev, fsl_dev->connector.panel);
> + return ret;

Why put it in a variable? That is confusing, just return like this:

return fsl_dcu_attach_panel(fsl_dev, 

[PATCH] drm/edid: move DDC_SEGMENT_ADDR into drm_edid.h

[Shawn Guo]

On Thu, Jul 14, 2016 at 02:45:41PM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 05:00:28PM +0800, Shawn Guo wrote:
> > The same definition of DDC_SEGMENT_ADDR is currently defined in two
> > places, drm_edid.c and inno_hdmi.h.  Let's consolidate the definition
> > into drm_edid.h in the same way that DDC_ADDR is defined.
> > 
> > Signed-off-by: Shawn Guo 
> 
> What really should be done here is nuke the fake i2c adapter in
> inno_hdmi.c and instead just directly read the edid from the hdim IP.
> Using drm_get_edid for something that's not backed by a real i2c bus is
> bonghits.

This patch just makes some change literally.  I do not understand how
the IP block works at all.  I thought the HDMI IP talks to monitors
using I2C protocol implemented inside the IP block.  I added Rockchip
folks to see if we can get any clarifications from them.

Shawn

[PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

[Mario Kleiner]

Ok, so legacy gamma table updates are completely broken for Intel on 
Linux-4.7-rc7, the final release candidate.

The good news is that applying Lionel's patch

"drm/i915: add missing condition for committing planes on crtc"

from

https://patchwork.freedesktop.org/patch/89111/

fixes it nicely. The patch currently applies cleanly to drm-fixes and 
drm-next and is

Reviewed-and-tested-by: Mario Kleiner 


When we are at it, could somebody please look at that updated series of 
my Displayport color depth fixes ("EDID/DP fixes for proper bpc 
detection of displays.") i sent out a week ago?

Especially pulling patch 2/5 "[PATCH 2/5] drm/i915/dp: Revert 
"drm/i915/dp: fall back to 18 bpp when sink capability is unknown" would 
be important, as that bug introduced a regression for Intel + DP + 
legacy DP converters into stable kernels which is very serious for users 
of scientific/medical display equipment, especially as the failures can 
easily go unnoticed during normal equipment tests, but would introduce 
the equivalent of "silent data corruption" into their measured 
scientific data, which is not a great experience given that collecting 
such data can easily take half a year of work time and ten-thousands of 
euros of wasted research funding.

Patches 3 and 4 contain changes Daniel asked me to do, patch 5 would be 
good to safe-guard against similar issues in the future.

thanks,
-mario

On 07/12/2016 12:50 PM, Lionel Landwerlin wrote:
> Hi Mario,
>
> There was a couple of patch to fix this issue :
>
> https://patchwork.freedesktop.org/series/5467/
> https://patchwork.freedesktop.org/series/5466/
>
> I tested this late last week on drm-intel-nightly, it seems a series of
> revert fixed most of the issues.
>
> Cheers,
>
> -
> Lionel
>
> On 12/07/16 11:33, Mario Kleiner wrote:
>> Updating legacy gamma tables, e.g., via RandR doesn't work at all
>> as of Linux 4.7-rc6.
>>
>> Reason seems to be that the required call to
>> drm_atomic_helper_commit_planes_on_crtc is skipped in
>> intel_atomic_commit after userspace set new gamma tables,
>> because neither crtc->state->planes_changed nor
>> update_pipe (= pipe_config->update_pipe) are true.
>>
>> Removing the check for planes_changed || update_pipe fixes
>> gamma table updates.
>>
>> The code for Linux 4.8 drm-next has changed a lot in that area
>> wrt. 4.7, but the new code for 4.8 also removed those checks
>> and calls drm_atomic_helper_commit_planes_on_crtc unconditionally,
>> and legacy gamma lut updates work on drm-next, so this seems to be
>> the right solution.
>>
>> Tested also shutdown/reboot, suspend/resume, (un-)plugging displays,
>> mode switches for resolution/refresh rate, display rotation, and
>> page-flipping/pageflip timing on Intel HD Ironlake to confirm the
>> fix apparently doesn't break anything under X11.
>>
>> Signed-off-by: Mario Kleiner 
>> Cc: Maarten Lankhorst 
>> Cc: Lionel Landwerlin 
>> Cc: Daniel Vetter 
>> ---
>>   drivers/gpu/drm/i915/intel_display.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 04452cf..eb8fb36 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13685,7 +13685,6 @@ static int intel_atomic_commit(struct
>> drm_device *dev,
>>   bool modeset = needs_modeset(crtc->state);
>>   struct intel_crtc_state *pipe_config =
>>   to_intel_crtc_state(crtc->state);
>> -bool update_pipe = !modeset && pipe_config->update_pipe;
>>   if (modeset && crtc->state->active) {
>>   update_scanline_offset(to_intel_crtc(crtc));
>> @@ -13699,8 +13698,7 @@ static int intel_atomic_commit(struct
>> drm_device *dev,
>>   drm_atomic_get_existing_plane_state(state, crtc->primary))
>>   intel_fbc_enable(intel_crtc);
>> -if (crtc->state->active &&
>> -(crtc->state->planes_changed || update_pipe))
>> +if (crtc->state->active)
>>   drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
>>   if (pipe_config->base.active && needs_vblank_wait(pipe_config))
>
>

[PATCH] drivers: gpu: drm: amd: powerplay: hwmgr: Remove unused variable

[Matthias Beyer]

Hi list,

I just wondered: I send the patch >14 days ago, 9 days ago it was 
reviewed by Rex Zhu. As far as I know, it isn't applied by now. At 
least I did not get a mail indicating that it was applied.

Are there issues with the patch I missed?

On 05-07-2016 15:06:59, Zhu, Rex wrote:
> 
> Yes, stretch_amount2 was not used on Polaris.
> 
> 
> Patch was Reviewed-by: Rex Zhu 
> 
> 
> Thanks.
> 
> 
> Best Regards
> 
> Rex
> 
> 
> From: Matthias Beyer 
> Sent: Friday, July 1, 2016 12:38:49 AM
> To: linuxdev.baldrick at gmail.com
> Cc: Deucher, Alexander; Koenig, Christian; airlied at linux.ie; dri-devel at 
> lists.freedesktop.org; dcb314 at hotmail.com; linux-kernel at 
> vger.kernel.org; Zhu, Rex; Huang, JinHuiEric; nils.wallmenius at gmail.com; 
> Matthias Beyer
> Subject: [PATCH] drivers: gpu: drm: amd: powerplay: hwmgr: Remove unused 
> variable
> 
> Signed-off-by: Matthias Beyer 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> index 64ee78f..1dcd52d 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> @@ -1761,7 +1761,7 @@ static int 
> polaris10_populate_clock_stretcher_data_table(struct pp_hwmgr *hwmgr)
>  {
>  uint32_t ro, efuse, volt_without_cks, volt_with_cks, value, max, min;
>  struct polaris10_hwmgr *data = (struct polaris10_hwmgr 
> *)(hwmgr->backend);
> -   uint8_t i, stretch_amount, stretch_amount2, volt_offset = 0;
> +   uint8_t i, stretch_amount, volt_offset = 0;
>  struct phm_ppt_v1_information *table_info =
>  (struct phm_ppt_v1_information *)(hwmgr->pptable);
>  struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
> @@ -1806,11 +1806,8 @@ static int 
> polaris10_populate_clock_stretcher_data_table(struct pp_hwmgr *hwmgr)
>  }
> 
>  /* Populate CKS Lookup Table */
> -   if (stretch_amount == 1 || stretch_amount == 2 || stretch_amount == 5)
> -   stretch_amount2 = 0;
> -   else if (stretch_amount == 3 || stretch_amount == 4)
> -   stretch_amount2 = 1;
> -   else {
> +   if (stretch_amount != 1 && stretch_amount != 2 && stretch_amount != 3 
> &&
> +   stretch_amount != 4 && stretch_amount != 5) {
>  phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
>  PHM_PlatformCaps_ClockStretcher);
>  PP_ASSERT_WITH_CODE(false,
> --
> 2.9.0
> 

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160714/fcef649e/attachment.sig>

[PATCH v3 2/2] drm/fsl-dcu: add support for drm bridge

[Meng Yi]

The current output code only supports connection to drm panels.
Add code to support drm bridge, to support connections to
external connectors.

Signed-off-by: Meng Yi 
---
Changes since V1:
-no change
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 2e71f4b..e875b4e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -189,6 +189,7 @@ err_cleanup:
 static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
const struct of_endpoint *ep)
 {
+   struct drm_bridge *bridge;
struct device_node *np;
int ret;

@@ -201,7 +202,17 @@ static int fsl_dcu_attach_endpoint(struct 
fsl_dcu_drm_device *fsl_dev,
return ret;
}

-   return -ENODEV;
+   bridge = of_drm_find_bridge(np);
+   of_node_put(np);
+   if (!bridge)
+   return -ENODEV;
+
+   fsl_dev->encoder.bridge = bridge;
+   bridge->encoder = _dev->encoder;
+
+   ret = drm_bridge_attach(fsl_dev->drm, bridge);
+
+   return ret;
 }

 int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev)
-- 
2.1.0.27.g96db324

[PATCH v3 1/2] drm/fsl-dcu: rework codes to support of_graph dt binding for panel

[Meng Yi]

This patch rework the output code to add of_graph dt binding support
for panel device and also keeps the backward compatibility

Signed-off-by: Meng Yi 
---
Changes in V3:
-simplify return value statements
Changes in V2:
-fix some coding style issue
-add fsl_dev->connector.panel check
-use fsl_dev->np and drop fsl_dev->dev->of_node
-return 'ret' when fsl_dcu_attach_panel failed
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c|  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h |  3 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 73 
 3 files changed, 55 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
index c564ec6..b48ffa7 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
@@ -43,7 +43,7 @@ int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device 
*fsl_dev)
if (ret)
goto fail_encoder;

-   ret = fsl_dcu_drm_connector_create(fsl_dev, _dev->encoder);
+   ret = fsl_dcu_create_outputs(fsl_dev);
if (ret)
goto fail_connector;

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
index 7093109..5a7b88e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
@@ -25,9 +25,8 @@ to_fsl_dcu_connector(struct drm_connector *con)
 : NULL;
 }

-int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
-struct drm_encoder *encoder);
 int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
struct drm_crtc *crtc);
+int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev);

 #endif /* __FSL_DCU_DRM_CONNECTOR_H__ */
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 98c998d..2e71f4b 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -10,6 +10,7 @@
  */

 #include 
+#include 

 #include 
 #include 
@@ -141,12 +142,12 @@ static const struct drm_connector_helper_funcs 
connector_helper_funcs = {
.mode_valid = fsl_dcu_drm_connector_mode_valid,
 };

-int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
-struct drm_encoder *encoder)
+static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
+struct drm_panel *panel)
 {
+   struct drm_encoder *encoder = _dev->encoder;
struct drm_connector *connector = _dev->connector.base;
struct drm_mode_config *mode_config = _dev->drm->mode_config;
-   struct device_node *panel_node;
int ret;

fsl_dev->connector.encoder = encoder;
@@ -170,21 +171,7 @@ int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device 
*fsl_dev,
  mode_config->dpms_property,
  DRM_MODE_DPMS_OFF);

-   panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
-   if (!panel_node) {
-   dev_err(fsl_dev->dev, "fsl,panel property not found\n");
-   ret = -ENODEV;
-   goto err_sysfs;
-   }
-
-   fsl_dev->connector.panel = of_drm_find_panel(panel_node);
-   if (!fsl_dev->connector.panel) {
-   ret = -EPROBE_DEFER;
-   goto err_panel;
-   }
-   of_node_put(panel_node);
-
-   ret = drm_panel_attach(fsl_dev->connector.panel, connector);
+   ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
goto err_sysfs;
@@ -192,11 +179,57 @@ int fsl_dcu_drm_connector_create(struct 
fsl_dcu_drm_device *fsl_dev,

return 0;

-err_panel:
-   of_node_put(panel_node);
 err_sysfs:
drm_connector_unregister(connector);
 err_cleanup:
drm_connector_cleanup(connector);
return ret;
 }
+
+static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
+   const struct of_endpoint *ep)
+{
+   struct device_node *np;
+   int ret;
+
+   np = of_graph_get_remote_port_parent(ep->local_node);
+
+   fsl_dev->connector.panel = of_drm_find_panel(np);
+   of_node_put(np);
+   if (fsl_dev->connector.panel) {
+   ret = fsl_dcu_attach_panel(fsl_dev, fsl_dev->connector.panel);
+   return ret;
+   }
+
+   return -ENODEV;
+}
+
+int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev)
+{
+   struct of_endpoint ep;
+   struct device_node *ep_node, *panel_node;
+   int ret;
+
+   /* This is for backward compatibility */
+   panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
+   if (panel_node) {
+   fsl_dev->connector.panel = of_drm_find_panel(panel_node);
+

[libdrm][PATCH v2 1/2] drm: Fix multi GPU drmGetDevice return wrong device

[Emil Velikov]

On 14 July 2016 at 10:10, Qiang Yu  wrote:
> drmGetDevice will always return the first device it find
> under /dev/dri/. This is not true for multi GPU situation.
>
> Change-Id: I2a85a8a4feba8a5cc517ad75c6afb532fa07c53d
Hope you don't mind if I drop the change-id lines before committing ?

If anyone beats be to it, for the series:
Reviewed-by: Emil Velikov 

Thanks
Emil

DRM device memory writeback (Mali-DP)

[Brian Starkey]

Hi,

The Mali-DP display processors have a memory-writeback engine which
can write the result of the composition (CRTC output) to a memory
buffer in a variety of formats.

We're looking for feedback/suggestions on how to expose this in the
mali-dp DRM kernel driver - possibly via V4L2.

We've got a few use cases where writeback is useful:
- testing, to check the displayed image
- screen recording
- wireless display (e.g. Miracast)
- dual-display clone mode
- memory-to-memory composition
Note that the HW is capable of writing one of the input planes instead
of the CRTC output, but we've no good use-case for wanting to expose
that.

In our Android ADF driver[1] we exposed the memory write engine as
part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
doesn't have any similar support for memory output from CRTCs, but we
want to expose the functionality in the mainline Mali-DP DRM driver.

A previous discussion on the topic went towards exposing the
memory-write engine via V4L2[2].

I'm thinking to userspace this would look like two distinct devices:
- A DRM KMS display controller.
- A V4L2 video source.
They'd both exist in the same kernel driver.
A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
the DRM driver would see if there's a buffer to dequeue every time a
new modeset is received via the DRM API - if so, it can configure the
HW to dump into it (one-shot operation).

An implication of this is that if the screen is actively displaying a
static scene and the V4L2 client queues up a buffer, it won't get
filled until the DRM scene changes. This seems best, otherwise the
V4L2 driver has to change the HW configuration out-of-band from the
DRM device which sounds horribly racy.

One further complication is scaling. Our HW has a scaler which can
tasked with either scaling an input plane or the buffer being written
to memory, but not both at the same time. This means we need to
arbitrate the scaler between the DRM device (scaling input planes) and
the V4L2 device (scaling output buffers).

I think the simplest approach here is to allow V4L2 to "claim" the
scaler by setting the image size (VIDIOC_S_FMT) to something other
than the CRTC's current resolution. After that, any attempt to use the
scaler on an input plane via DRM should fail atomic_check().

If the V4L2 client goes away or sets the image size to the CRTC's
native resolution, then the DRM device is allowed to use the scaler.
I don't know if/how the DRM device should communicate to userspace
that the scaler is or isn't available for use.

Any thoughts on this approach?
Is it acceptable to both V4L2 and DRM folks?

Thanks for your time,

-Brian

[1] 
http://malideveloper.arm.com/resources/drivers/open-source-mali-dp-adf-kernel-device-drivers/
[2] 
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel=2016-05-04

[PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

[Emil Velikov]

On 14 July 2016 at 04:02, Yu, Qiang  wrote:
> Thanks Emil, I'll submit v2 to address your comments.
>
I believed you covered them all. Thanks !

Small suggestion for the future - I many devs are appreciate when
patches have a brief shortlog before or after the --- line.

>
> I'm using office365, not sure this mail is OK for formatting, otherwise I'll
> switch to a mail client.
>
Don't think you need to need to switch email client(s). See http://bfy.tw/6kFa

Thanks
Emil

[PATCH 0/3] Support fast framebuffer panning for i.MX6

[Stefan Christ]

Hi Daniel,

On Wed, Jul 13, 2016 at 12:00:07PM +0200, Daniel Vetter wrote:
> On Wed, Jul 13, 2016 at 10:11:45AM +0200, Stefan Christ wrote:
> > Hi,
> > 
> > im currently working on supporting double/tripple buffering for the 
> > framebuffer
> > emulation on the i.MX6.  While working on it I noticed that the mainline 
> > kernel
> > does not support some features in the generic drm framebuffer emulation for
> > framebuffer panning and vsync synchronisation. They are needed for simple
> > framebuffer applications and some OpenGL libraries using double buffering 
> > with
> > FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.
> > 
> > Any comments?
> 
> Don't ever do OpenGL on fbdev. Ever. The fbdev emulation we have is to
> support boot splashs, kernel console, oopses and legacy applications that
> just love fbdev too much and don't support native kms dumb buffers.
> 
> Anything that goes beyond kms dumb buffers (like displaying buffers
> rendered through opengl) is imo a complete no-go. Yes Android loves to do
> that, but for upstream we need a proper drm render driver, buffer sharing
> through prime and the userspace hwcomposer needs to use native drm kms
> ioctls. Also, userspace (especially the opengl part) needs to be open
> source for upstream.

Yeah, these closed libraries are kind of ugly, but implementing these features
maybe interesting for legacy framebuffer applications that do double buffering
via panning.

Thanks for the comments. I totally overlooked the dpms/blank and locking issue.
I will work through them and send v2 patches.

Mit freundlichen Grüßen / Kind regards,
Stefan Christ

> 
> Thanks, Daniel
> > 
> > Kind regards,
> > Stefan Christ
> > 
> > Stefan Christ (2):
> >   drm: fb_helper: implement ioctl FBIO_WAITFORVSYNC
> >   drm/imx: ipuv3-crtc: implement fast path mode_set_base
> > 
> > Xinliang Liu (1):
> >   drm/cma-helper: Add multi buffer support for cma fbdev
> > 
> >  drivers/gpu/drm/Kconfig |  8 +++
> >  drivers/gpu/drm/drm_fb_cma_helper.c |  9 +++-
> >  drivers/gpu/drm/drm_fb_helper.c | 43 
> > +
> >  drivers/gpu/drm/imx/ipuv3-crtc.c| 10 +
> >  include/drm/drm_fb_helper.h |  2 ++
> >  5 files changed, 71 insertions(+), 1 deletion(-)
> > 
> > -- 
> > 1.9.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[libdrm][PATCH v2 2/2] drm: fix multi GPU drmFreeDevices memory leak

[Qiang Yu]

When in multi GPU case, devices array may have some
NULL "hole" in between two devices. So check all
array elements and free non-NULL device.

Change-Id: Ifc32d240f895059bc4b19138cb81de38d99fb88a
Signed-off-by: Qiang Yu 
---
 xf86drm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 19001db..32bedeb 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2992,8 +2992,9 @@ void drmFreeDevices(drmDevicePtr devices[], int count)
 if (devices == NULL)
 return;

-for (i = 0; i < count && devices[i] != NULL; i++)
-drmFreeDevice([i]);
+for (i = 0; i < count; i++)
+if (devices[i])
+drmFreeDevice([i]);
 }

 static int drmProcessPciDevice(drmDevicePtr *device, const char *d_name,
-- 
1.9.1

[libdrm][PATCH v2 1/2] drm: Fix multi GPU drmGetDevice return wrong device

[Qiang Yu]

drmGetDevice will always return the first device it find
under /dev/dri/. This is not true for multi GPU situation.

Change-Id: I2a85a8a4feba8a5cc517ad75c6afb532fa07c53d
Signed-off-by: Qiang Yu 
---
 xf86drm.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 6689f7c..19001db 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3087,6 +3087,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 int maj, min;
 int ret, i, node_count;
 int max_count = 16;
+dev_t find_rdev;

 if (fd == -1 || device == NULL)
 return -EINVAL;
@@ -3094,6 +3095,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 if (fstat(fd, ))
 return -errno;

+find_rdev = sbuf.st_rdev;
 maj = major(sbuf.st_rdev);
 min = minor(sbuf.st_rdev);

@@ -3154,17 +3156,24 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 local_devices = temp;
 }

-local_devices[i] = d;
+/* store target at local_devices[0] for ease to use below */
+if (find_rdev == sbuf.st_rdev && i) {
+local_devices[i] = local_devices[0];
+local_devices[0] = d;
+}
+else
+local_devices[i] = d;
 i++;
 }
 node_count = i;

-/* Fold nodes into a single device if they share the same bus info */
+/* Fold nodes into a single device if they share the same bus info
+ * and nodes with same bus info will be merged into the first node
+ * position in local_devices */
 drmFoldDuplicatedDevices(local_devices, node_count);

 *device = local_devices[0];
-for (i = 1; i < node_count && local_devices[i]; i++)
-drmFreeDevice(_devices[i]);
+drmFreeDevices(_devices[1], node_count - 1);

 closedir(sysdir);
 free(local_devices);
-- 
1.9.1

[PATCH] drm/edid: move DDC_SEGMENT_ADDR into drm_edid.h

[Shawn Guo]

The same definition of DDC_SEGMENT_ADDR is currently defined in two
places, drm_edid.c and inno_hdmi.h.  Let's consolidate the definition
into drm_edid.h in the same way that DDC_ADDR is defined.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/drm_edid.c   | 1 -
 drivers/gpu/drm/rockchip/inno_hdmi.h | 2 --
 include/drm/drm_edid.h   | 1 +
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7df26d4b7ad8..9d6735b68152 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1191,7 +1191,6 @@ bool drm_edid_is_valid(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_edid_is_valid);

-#define DDC_SEGMENT_ADDR 0x30
 /**
  * drm_do_probe_ddc_edid() - get EDID information via I2C
  * @data: I2C device adapter
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.h 
b/drivers/gpu/drm/rockchip/inno_hdmi.h
index aa7c415f8cc1..b27b30934c7e 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.h
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.h
@@ -16,8 +16,6 @@
 #ifndef __INNO_HDMI_H__
 #define __INNO_HDMI_H__

-#define DDC_SEGMENT_ADDR   0x30
-
 enum PWR_MODE {
NORMAL,
LOWER_PWR,
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d1beb4..7ee78d5c9252 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -26,6 +26,7 @@
 #include 

 #define EDID_LENGTH 128
+#define DDC_SEGMENT_ADDR 0x30
 #define DDC_ADDR 0x50
 #define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */

-- 
1.9.1

[pull] amdgpu drm-fixes-4.7

[Alex Deucher]

Hi Dave,

Just two small polaris fixes.

The following changes since commit 39c8859418d5d2d29482fcd7d58daba6e299fac5:

  Merge tag 'sunxi-drm-fixes-for-4.7-2' of 
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-fixes 
(2016-07-08 13:29:11 +1000)

are available in the git repository at:

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

for you to fetch changes up to eeade25ad029cb1f31f27f8e0ddc9bb9c22b5537:

  drm/amdgpu: fix power distribution issue for Polaris10 XT (2016-07-14 
16:39:35 -0400)


Ken Wang (2):
  drm/amdgpu: Add a missing register to Polaris golden setting
  drm/amdgpu: fix power distribution issue for Polaris10 XT

 drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |  7 +++
 3 files changed, 24 insertions(+)

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Daniel Vetter]

On Thu, Jul 14, 2016 at 02:39:54PM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> > The biggest reason I had against going the sw_sync only route was that
> > vgem should provide unprivileged fences and that through the bookkeeping
> > in vgem we can keep them safe, ensure that we don't leak random buffers
> > or fences. (And I need a source of foriegn dma-buf with implicit fence
> > tracking with which I can try and break the driver.)
> 
> And for testing passing around content + fences is more useful than
> passing fences alone.

Yup, agreed. But having fences free-standing isn't a real issue since
their refcounted and the userspace parts (sync_file) will get cleaned up
on process exit latest. Ḯ'm not advocating for any behaviour change at
all, just for hiding these things in debugfs.

Or maybe we could add a special (tainting) module option to vgem.ko which
enables this interface? That would be even less work, can easily be
integrated into igt (just set that knob at runtime, done), and with a
stern enough warning in dmesg + tainting the point should be clear. Of
course that switch would be off by default. Thoughts?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Daniel Vetter]

On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 02:40:59PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote:
> > > On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote:
> > > > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> > > > > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > > > > > vGEM buffers are useful for passing data between software clients 
> > > > > > and
> > > > > > hardware renders. By allowing the user to create and attach fences 
> > > > > > to
> > > > > > the exported vGEM buffers (on the dma-buf), the user can implement a
> > > > > > deferred renderer and queue hardware operations like flipping and 
> > > > > > then
> > > > > > signal the buffer readiness (i.e. this allows the user to schedule
> > > > > > operations out-of-order, but have them complete in-order).
> > > > > > 
> > > > > > This also makes it much easier to write tightly controlled 
> > > > > > testcases for
> > > > > > dma-buf fencing and signaling between hardware drivers.
> > > > > > 
> > > > > > v2: Don't pretend the fences exist in an ordered timeline, but 
> > > > > > allocate
> > > > > > a separate fence-context for each fence so that the fences are
> > > > > > unordered.
> > > > > > v3: Make the debug output more interesting, and so the signaled 
> > > > > > status.
> > > > > > 
> > > > > > Testcase: igt/vgem_basic/dmabuf-fence
> > > > > > Signed-off-by: Chris Wilson 
> > > > > > Cc: Sean Paul 
> > > > > > Cc: Zach Reizner 
> > > > > > Cc: Gustavo Padovan 
> > > > > > Cc: Daniel Vetter 
> > > > > > Acked-by: Zach Reizner 
> > > > > 
> > > > > One thing I completely forgotten: This allows userspace to hang kernel
> > > > > drivers. i915 (and other gpu drivers) can recover using hangcheck, but
> > > > > dumber drivers (v4l, if that ever happens) probably never except such 
> > > > > a
> > > > > case. We've had a similar discusion with the userspace fences exposed 
> > > > > in
> > > > > sw_fence, and decided to move all those ioctl into debugfs. I think we
> > > > > should do the same for this vgem-based debugging of implicit sync. 
> > > > > Sorry
> > > > > for realizing this this late.
> > > > 
> > > > One of the very tests I make is to ensure that we recover from such a
> > > > hang. I don't see the difference between this any of the other ways
> > > > userspace can shoot itself (and others) in the foot.
> > > 
> > > So one solution would be to make vgem fences automatically timeout (with
> > > a flag for root to override for the sake of testing hang detection).
> > 
> > The problem is other drivers. E.g. right now atomic helpers assume that
> > fences will signal, and can't recover if they don't. This is why drivers
> > where things might fail must have some recovery (hangcheck, timeout) to
> > make sure dma_fences always signal.
> 
> Urm, all the atomic helpers should work with fails. The waits on dma-buf
> should be before any hardware is modified and so cancellation is trivial.
> Anyone using a foriegn fence (or even native) must cope that it may not
> meet some deadline.
> 
> They have to. Anyone sharing a i915 dma-buf is susceptible to all kinds
> of (unprivileged) fun.
>  
> > Imo not even root should be allowed to break this, since it could put
> > drivers into a non-recoverable state. I think this must be restricted to
> > something known-unsafe-don't-enable-on-production like debugfs.
> 
> Providing fences is extremely useful, even for software buffers. (For
> the sake of argument, just imagine an asynchronous multithreaded llvmpipe
> wanting to support client fences for deferred rendering.) The only
> question in my mind is how much cotton wool to use.
> 
> > Other solutions which I don't like:
> > - Everyone needs to be able to recover. Given how much effort it is to
> >   just keep i915 hangcheck in working order I think that's totally
> >   illusionary to assume. At least once world+dog (atomic, v4l, ...) all
> >   consume/produce fences, subsystems where the usual assumption holds that
> >   async ops complete.
> > 
> > - Really long timeouts are allowed for root in vgem. Could lead to even
> >   more fun in testing i915 hangchecks I think, so don't like that much
> >   either.
> 
> The whole point is in testing our handling before we become suspectible
> to real world fail - because as you point out, not everyone guarantees
> that a fence will be signaled. I can't simply pass around i915 dma-buf
> simply because we may unwind them and in the process completely curtail
> being able to test a foriegn fence that hangs.

I think that's where we differ in opinion: Right now we do have the
guarantee that every fence gets signalled in finite time. For drivers
where that is not just guaranteed there must be a hangcheck to force the
completion.

The only exception thus far is the debugfs-only sw_fence interface.
-Daniel

> 
> > I think the best option is to just do the same as 

[PATCH] drm/rockchip: allocate correct crtc state structure on reset

[John Keeping]

Because we are using a custom crtc_state structure, we must override the
reset helper to allocate the correct amount of memory.

Cc: stable at vger.kernel.org
Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: John Keeping 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 1c4d5b5a70a2..21e1247098be 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1048,6 +1048,17 @@ static void vop_crtc_destroy(struct drm_crtc *crtc)
drm_crtc_cleanup(crtc);
 }

+static void vop_crtc_reset(struct drm_crtc *crtc)
+{
+   if (crtc->state)
+   __drm_atomic_helper_crtc_destroy_state(crtc, crtc->state);
+   kfree(crtc->state);
+
+   crtc->state = kzalloc(sizeof(struct rockchip_crtc_state), GFP_KERNEL);
+   if (crtc->state)
+   crtc->state->crtc = crtc;
+}
+
 static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
 {
struct rockchip_crtc_state *rockchip_state;
@@ -1073,7 +1084,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.destroy = vop_crtc_destroy,
-   .reset = drm_atomic_helper_crtc_reset,
+   .reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
 };
-- 
2.9.0.465.g8850cbc.dirty

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

On Thu, Jul 14, 2016 at 04:36:37PM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 02:39:54PM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> > > The biggest reason I had against going the sw_sync only route was that
> > > vgem should provide unprivileged fences and that through the bookkeeping
> > > in vgem we can keep them safe, ensure that we don't leak random buffers
> > > or fences. (And I need a source of foriegn dma-buf with implicit fence
> > > tracking with which I can try and break the driver.)
> > 
> > And for testing passing around content + fences is more useful than
> > passing fences alone.
> 
> Yup, agreed. But having fences free-standing isn't a real issue since
> their refcounted and the userspace parts (sync_file) will get cleaned up
> on process exit latest. Ḯ'm not advocating for any behaviour change at
> all, just for hiding these things in debugfs.

It's just a choice of api. We could equally hide it behind a separate
config flag.

First question, are we happy that there is a legitimate usecase for fences
on vgem?

If so, what enforced timeout on the fence should we use?

(I think that this ioctl api is correct, I don't forsee sw_sync being
viable for unprivileged use.)

Then we can restrict this patch to add the safe interface, enable a bunch
more tests and get on with discussing how to break the kernel "safely"!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[GIT PULL] drm/panel: Changes for v4.8-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.8-rc1

for you to fetch changes up to 9bb34c4c730dbfaf9c91af57bf41d0a453067e87:

  drm/panel: simple: Add support for Starry KR122EA0SRA panel (2016-07-11 
14:30:43 +0200)

Thanks,
Thierry


drm/panel: Changes for v4.8-rc1

This set of changes contains a few cleanups for existing panels as well
as improved handling of certain backlights. In addition there's support
for a few new simple panels.


Doug Anderson (1):
  dt-bindings: Add vendor prefix for Starry

Douglas Anderson (2):
  dt-bindings: Add Starry KR122EA0SRA panel binding
  drm/panel: simple: Add support for Starry KR122EA0SRA panel

Joshua Clayton (2):
  drm/panel: simple: Add support for Sharp LQ101K1LY04
  dt-bindings: display: Add Sharp LQ101K1LY04 panel binding

Thierry Reding (3):
  drm/panel: simple: Fix a couple of physical sizes
  drm/panel: simple: Remove gratuitous blank line
  drm/panel: simple: Update backlight state property

Yakir Yang (8):
  dt-bindings: Add LG LP097QX1-SPA1 panel binding
  drm/panel: simple: Add support for LG LP097QX1-SPA1 panel
  dt-bindings: Add Samsung LSN122DL01-C01 panel binding
  drm/panel: simple: Add support for Samsung LSN122DL01-C01 panel
  dt-bindings: Add Sharp LQ123P1JX31 panel binding
  drm/panel: simple: Add support for Sharp LQ123P1JX31 panel
  dt-bindings: Add support for LG LP079QX1-SP0V panel
  drm/panel: simple: Add support for LG LP079QX1-SP0V panel

 .../bindings/display/panel/lg,lp079qx1-sp0v.txt|   7 +
 .../bindings/display/panel/lg,lp097qx1-spa1.txt|   7 +
 .../display/panel/samsung,lsn122dl01-c01.txt   |   7 +
 .../bindings/display/panel/sharp,lq101k1ly04.txt   |   7 +
 .../bindings/display/panel/sharp,lq123p1jx31.txt   |   7 +
 .../bindings/display/panel/starry,kr122ea0sra.txt  |   7 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/gpu/drm/panel/panel-simple.c   | 166 -
 8 files changed, 204 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,lsn122dl01-c01.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,lq101k1ly04.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,lq123p1jx31.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt

[GIT PULL] drm/tegra: Changes for v4.8-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.8-rc1

for you to fetch changes up to 64ea25c3bc86c05c7da6c683b86663f4c90158d6:

  drm/tegra: sor: Reject HDMI 2.0 modes (2016-07-14 14:57:04 +0200)

Thanks,
Thierry


drm/tegra: Changes for v4.8-rc1

This set of changes contains a bunch of cleanups to the host1x driver as
well as the addition of a pin controller for DPAUX, which is required by
boards to configure the DPAUX pads in AUX mode (for DisplayPort) or I2C
mode (for HDMI and DDC).

Included is also a bit of rework of the SOR driver in preparation to add
DisplayPort support as well as some refactoring and cleanup.

Finally, all output drivers are converted to runtime PM, which greatly
simplifies the handling of clocks and resets.


Bhaktipriya Shridhar (1):
  gpu: host1x: hw: intr_hw: Remove create_workqueue

Jon Hunter (9):
  pinctrl: pinconf: Add generic helper function for freeing mappings
  drm/tegra: dpaux: Clean-up on probe failure
  drm/tegra: dpaux: Add helpers for setting up pads
  dt-bindings: display: Update Tegra DPAUX documentation
  drm/tegra: Prepare DPAUX for supporting generic PM domains
  dt-bindings: Add bindings for Tegra DPAUX pinctrl driver
  drm/tegra: dpaux: Add pinctrl support
  drm/tegra: dsi: Prepare for generic PM domain support
  drm/tegra: sor: Prepare for generic PM domain support

Thierry Reding (26):
  Merge branch 'devel-dt-free-map' of 
git://git.kernel.org/.../linusw/linux-pinctrl into drm/tegra/for-next
  gpu: host1x: Consistently use unsigned int for counts
  gpu: host1x: Use unsigned int consistently for IDs
  gpu: host1x: channel: Use correct type
  gpu: host1x: cdma: Drop unnecessary local variable
  gpu: host1x: syncpt: Use kcalloc() instead of kzalloc()
  gpu: host1x: Fix a couple of checkpatch warnings
  gpu: host1x: Whitespace cleanup for readability
  gpu: host1x: Remove redundant parentheses
  gpu: host1x: Constify array of action handlers
  gpu: host1x: Remove useless local variable
  drm/tegra: sor: Factor out tegra_sor_set_parent_clock()
  drm/tegra: sor: Rename tegra_sor_calc_config()
  drm/tegra: sor: Split out tegra_sor_apply_config()
  drm/tegra: sor: Extract tegra_sor_mode_set()
  drm/tegra: sor: Do not support deep color modes
  drm/tegra: hdmi: Enable audio over HDMI
  drm/tegra: dc: Implement runtime PM
  drm/tegra: dsi: Implement runtime PM
  drm/tegra: hdmi: Implement runtime PM
  drm/tegra: sor: Implement runtime PM
  drm/tegra: sor: Implement sor1_brick clock
  dt-bindings: display: tegra: Add source clock for SOR
  drm/tegra: sor: Use sor1_src clock to set parent for HDMI
  drm/tegra: sor: Make XBAR configurable per SoC
  drm/tegra: sor: Reject HDMI 2.0 modes

 .../display/tegra/nvidia,tegra20-host1x.txt|  13 +-
 .../pinctrl/nvidia,tegra124-dpaux-padctl.txt   |  60 ++
 drivers/gpu/drm/tegra/dc.c | 176 +++--
 drivers/gpu/drm/tegra/dpaux.c  | 245 +--
 drivers/gpu/drm/tegra/drm.c|   2 +-
 drivers/gpu/drm/tegra/dsi.c| 247 ---
 drivers/gpu/drm/tegra/hdmi.c   | 507 +++
 drivers/gpu/drm/tegra/hdmi.h   |  21 +-
 drivers/gpu/drm/tegra/output.c |   1 +
 drivers/gpu/drm/tegra/sor.c| 716 ++---
 drivers/gpu/drm/tegra/sor.h|   3 +
 drivers/gpu/host1x/cdma.c  |  42 +-
 drivers/gpu/host1x/channel.c   |   5 +-
 drivers/gpu/host1x/debug.c |  38 +-
 drivers/gpu/host1x/dev.c   |  16 +-
 drivers/gpu/host1x/dev.h   |  38 +-
 drivers/gpu/host1x/hw/cdma_hw.c|  23 +-
 drivers/gpu/host1x/hw/channel_hw.c |   5 +-
 drivers/gpu/host1x/hw/debug_hw.c   |  36 +-
 drivers/gpu/host1x/hw/intr_hw.c|  30 +-
 drivers/gpu/host1x/hw/syncpt_hw.c  |  10 +-
 drivers/gpu/host1x/intr.c  |  16 +-
 drivers/gpu/host1x/intr.h  |   4 +-
 drivers/gpu/host1x/job.c   |   8 +-
 drivers/gpu/host1x/syncpt.c|  58 +-
 drivers/gpu/host1x/syncpt.h|   8 +-
 drivers/pinctrl/pinconf-generic.c  |   8 +
 include/linux/pinctrl/pinconf-generic.h|   2 +
 28 files changed, 1636 insertions(+), 702 deletions(-)
 create mode 100644 

[PATCH] Revert "drm: Resurrect atomic rmfb code"

[Daniel Vetter]

On Thu, Jul 14, 2016 at 03:16:34PM +0200, Daniel Vetter wrote:
> This reverts commit 11c21e73f848844d439cbccb42a1018b8c560e5c.
> 
> For reasons totally unclear this manages to wreak havoc with the audio
> rpm refcount:
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 215 at drivers/gpu/drm/i915/intel_runtime_pm.c:1729 
> intel_display_power_put+0xe8/0x100 [i915]
> Use count on domain AUDIO is already zero
> Modules linked in: i915 ax88179_178a usbnet mii snd_hda_codec_hdmi 
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec 
> x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_hda_core co
> f_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei e1000e ptp 
> pps_core i2c_hid [last unloaded: i915]
> CPU: 0 PID: 215 Comm: kworker/0:2 Not tainted 4.7.0-rc6+ #44
> Hardware name: Intel Corporation Skylake Client platform/Skylake Halo DDR4 
> RVP11, BIOS SKLSE2R1.R00.X106.B00.1601180206 01/18/2016
> Workqueue: events output_poll_execute
>   88045573fa38 813a2d6b 88045573fa88
>   88045573fa78 81075db6 06c15a59
>  88045a59a238 88045a590054 88045a59 88045a59
> Call Trace:
>  [] dump_stack+0x4d/0x72
>  [] __warn+0xc6/0xe0
>  [] warn_slowpath_fmt+0x4a/0x50
>  [] ? hsw_audio_codec_disable+0xdd/0x110 [i915]
>  [] intel_display_power_put+0xe8/0x100 [i915]
>  [] intel_disable_ddi+0x46/0x80 [i915]
>  [] haswell_crtc_disable+0x16f/0x290 [i915]
>  [] intel_atomic_commit_tail+0x153/0x10e0 [i915]
>  [] ? drm_atomic_helper_swap_state+0x140/0x2d0
>  [] intel_atomic_commit+0x3fd/0x520 [i915]
>  [] ? drm_atomic_add_affected_connectors+0x22/0xf0
>  [] drm_atomic_commit+0x32/0x50
>  [] restore_fbdev_mode+0x147/0x260
>  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
>  [] drm_fb_helper_set_par+0x28/0x50
>  [] drm_fb_helper_hotplug_event+0x143/0x180
>  [] intel_fbdev_output_poll_changed+0x15/0x20 [i915]
>  [] drm_kms_helper_hotplug_event+0x22/0x30
>  [] output_poll_execute+0x192/0x1e0
>  [] process_one_work+0x14c/0x480
>  [] worker_thread+0x24a/0x4e0
>  [] ? process_one_work+0x480/0x480
>  [] ? process_one_work+0x480/0x480
>  [] kthread+0xc4/0xe0
>  [] ret_from_fork+0x1f/0x40
>  [] ? kthread_worker_fn+0x180/0x180
> ---[ end trace 2d440da5f0c053e4 ]---
> 
> Instead of scratching heads too much while CI is down, let's revert
> before more trouble is caused.
> 
> Cc: Maarten Lankhorst 
> Cc: Mika Kuoppala 
> Cc: Ville Syrjälä 
> Reported-by: Mika Kuoppala 
> Reported-by: Ville Syrjälä 
> Acked-by: Mika Kuoppala 
> Acked-by: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 

... and applied.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c| 66 
> -
>  drivers/gpu/drm/drm_crtc.c  |  6 
>  drivers/gpu/drm/drm_crtc_internal.h |  1 -
>  3 files changed, 73 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 34cdbe154540..6712278c73f0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1590,72 +1590,6 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>  
> -int drm_atomic_remove_fb(struct drm_framebuffer *fb)
> -{
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_device *dev = fb->dev;
> - struct drm_atomic_state *state;
> - struct drm_plane *plane;
> - int ret = 0;
> - unsigned plane_mask;
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state)
> - return -ENOMEM;
> -
> - drm_modeset_acquire_init(, 0);
> - state->acquire_ctx = 
> -
> -retry:
> - plane_mask = 0;
> - ret = drm_modeset_lock_all_ctx(dev, );
> - if (ret)
> - goto unlock;
> -
> - drm_for_each_plane(plane, dev) {
> - struct drm_plane_state *plane_state;
> -
> - if (plane->state->fb != fb)
> - continue;
> -
> - plane_state = drm_atomic_get_plane_state(state, plane);
> - if (IS_ERR(plane_state)) {
> - ret = PTR_ERR(plane_state);
> - goto unlock;
> - }
> -
> - drm_atomic_set_fb_for_plane(plane_state, NULL);
> - ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> - if (ret)
> - goto unlock;
> -
> - plane_mask |= BIT(drm_plane_index(plane));
> -
> - plane->old_fb = plane->fb;
> - plane->fb = NULL;
> - }
> -
> - if (plane_mask)
> - ret = drm_atomic_commit(state);
> -
> -unlock:
> - if (plane_mask)
> - drm_atomic_clean_old_fb(dev, plane_mask, ret);
> -
> - if (ret == -EDEADLK) {
> - drm_modeset_backoff();
> - goto retry;
> - }
> -
> - if (ret || !plane_mask)
> - drm_atomic_state_free(state);
> -
> - drm_modeset_drop_locks();
> - drm_modeset_acquire_fini();
> -
> - return 

[PATCH] Revert "drm: Resurrect atomic rmfb code"

[Daniel Vetter]

This reverts commit 11c21e73f848844d439cbccb42a1018b8c560e5c.

For reasons totally unclear this manages to wreak havoc with the audio
rpm refcount:

[ cut here ]
WARNING: CPU: 0 PID: 215 at drivers/gpu/drm/i915/intel_runtime_pm.c:1729 
intel_display_power_put+0xe8/0x100 [i915]
Use count on domain AUDIO is already zero
Modules linked in: i915 ax88179_178a usbnet mii snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec x86_pkg_temp_thermal 
snd_hwdep intel_powerclamp snd_hda_core co
f_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei e1000e ptp 
pps_core i2c_hid [last unloaded: i915]
CPU: 0 PID: 215 Comm: kworker/0:2 Not tainted 4.7.0-rc6+ #44
Hardware name: Intel Corporation Skylake Client platform/Skylake Halo DDR4 
RVP11, BIOS SKLSE2R1.R00.X106.B00.1601180206 01/18/2016
Workqueue: events output_poll_execute
  88045573fa38 813a2d6b 88045573fa88
  88045573fa78 81075db6 06c15a59
 88045a59a238 88045a590054 88045a59 88045a59
Call Trace:
 [] dump_stack+0x4d/0x72
 [] __warn+0xc6/0xe0
 [] warn_slowpath_fmt+0x4a/0x50
 [] ? hsw_audio_codec_disable+0xdd/0x110 [i915]
 [] intel_display_power_put+0xe8/0x100 [i915]
 [] intel_disable_ddi+0x46/0x80 [i915]
 [] haswell_crtc_disable+0x16f/0x290 [i915]
 [] intel_atomic_commit_tail+0x153/0x10e0 [i915]
 [] ? drm_atomic_helper_swap_state+0x140/0x2d0
 [] intel_atomic_commit+0x3fd/0x520 [i915]
 [] ? drm_atomic_add_affected_connectors+0x22/0xf0
 [] drm_atomic_commit+0x32/0x50
 [] restore_fbdev_mode+0x147/0x260
 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
 [] drm_fb_helper_set_par+0x28/0x50
 [] drm_fb_helper_hotplug_event+0x143/0x180
 [] intel_fbdev_output_poll_changed+0x15/0x20 [i915]
 [] drm_kms_helper_hotplug_event+0x22/0x30
 [] output_poll_execute+0x192/0x1e0
 [] process_one_work+0x14c/0x480
 [] worker_thread+0x24a/0x4e0
 [] ? process_one_work+0x480/0x480
 [] ? process_one_work+0x480/0x480
 [] kthread+0xc4/0xe0
 [] ret_from_fork+0x1f/0x40
 [] ? kthread_worker_fn+0x180/0x180
---[ end trace 2d440da5f0c053e4 ]---

Instead of scratching heads too much while CI is down, let's revert
before more trouble is caused.

Cc: Maarten Lankhorst 
Cc: Mika Kuoppala 
Cc: Ville Syrjälä 
Reported-by: Mika Kuoppala 
Reported-by: Ville Syrjälä 
Acked-by: Mika Kuoppala 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c| 66 -
 drivers/gpu/drm/drm_crtc.c  |  6 
 drivers/gpu/drm/drm_crtc_internal.h |  1 -
 3 files changed, 73 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34cdbe154540..6712278c73f0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1590,72 +1590,6 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_atomic_clean_old_fb);

-int drm_atomic_remove_fb(struct drm_framebuffer *fb)
-{
-   struct drm_modeset_acquire_ctx ctx;
-   struct drm_device *dev = fb->dev;
-   struct drm_atomic_state *state;
-   struct drm_plane *plane;
-   int ret = 0;
-   unsigned plane_mask;
-
-   state = drm_atomic_state_alloc(dev);
-   if (!state)
-   return -ENOMEM;
-
-   drm_modeset_acquire_init(, 0);
-   state->acquire_ctx = 
-
-retry:
-   plane_mask = 0;
-   ret = drm_modeset_lock_all_ctx(dev, );
-   if (ret)
-   goto unlock;
-
-   drm_for_each_plane(plane, dev) {
-   struct drm_plane_state *plane_state;
-
-   if (plane->state->fb != fb)
-   continue;
-
-   plane_state = drm_atomic_get_plane_state(state, plane);
-   if (IS_ERR(plane_state)) {
-   ret = PTR_ERR(plane_state);
-   goto unlock;
-   }
-
-   drm_atomic_set_fb_for_plane(plane_state, NULL);
-   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
-   if (ret)
-   goto unlock;
-
-   plane_mask |= BIT(drm_plane_index(plane));
-
-   plane->old_fb = plane->fb;
-   plane->fb = NULL;
-   }
-
-   if (plane_mask)
-   ret = drm_atomic_commit(state);
-
-unlock:
-   if (plane_mask)
-   drm_atomic_clean_old_fb(dev, plane_mask, ret);
-
-   if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
-   }
-
-   if (ret || !plane_mask)
-   drm_atomic_state_free(state);
-
-   drm_modeset_drop_locks();
-   drm_modeset_acquire_fini();
-
-   return ret;
-}
-
 int drm_mode_atomic_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1b7d31186f25..0098d5e6921a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ 

[PATCH v3] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

[Ard Biesheuvel]

On 7 July 2016 at 18:59, Ard Biesheuvel  wrote:
> The 100c08 scratch page is mapped using dma_map_page() before the TTM
> layer has had a chance to set the DMA mask. This means we are still
> running with the default of 32 when this code executes, and this causes
> problems for platforms with no memory below 4 GB (such as AMD Seattle)
>
> So move the dma_map_page() to the .init hook, and set the streaming DMA
> mask based on the MMU subdev parameters before performing the call.
>
> Signed-off-by: Ard Biesheuvel 
> ---
> I am sure there is a much better way to address this, but this fixes the
> problem I get on AMD Seattle with a GeForce 210 PCIe card:
>
>nouveau :02:00.0: enabling device ( -> 0003)
>nouveau :02:00.0: NVIDIA GT218 (0a8280b1)
>nouveau :02:00.0: bios: version 70.18.a6.00.00
>nouveau :02:00.0: fb ctor failed, -14
>nouveau: probe of :02:00.0 failed with error -14
>
> v2: replace incorrect comparison of dma_addr_t type var against NULL
> v3: rework code to get rid of DMA_ERROR_CODE references, which is not
> defined on all architectures
>

Ping?


>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 40 ++--
>  1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
> index 1b5fb02eab2a..f713cb3fe56c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c
> @@ -216,11 +216,33 @@ nv50_fb_init(struct nvkm_fb *base)
> struct nv50_fb *fb = nv50_fb(base);
> struct nvkm_device *device = fb->base.subdev.device;
>
> +   if (!fb->r100c08) {
> +   /* We are calling the DMA api way before the TTM layer sets 
> the
> +* DMA mask based on the MMU subdev parameters. This means we
> +* are using the default DMA mask of 32, which may cause
> +* problems on systems with no RAM below the 4 GB mark. So set
> +* the streaming DMA mask here as well.
> +*/
> +   dma_addr_t addr;
> +
> +   dma_set_mask(device->dev, 
> DMA_BIT_MASK(device->mmu->dma_bits));
> +
> +   addr = dma_map_page(device->dev, fb->r100c08_page, 0, 
> PAGE_SIZE,
> +   DMA_BIDIRECTIONAL);
> +   if (!dma_mapping_error(device->dev, addr)) {
> +   fb->r100c08 = addr;
> +   } else {
> +   nvkm_warn(>base.subdev,
> + "dma_map_page() failed on 100c08 page\n");
> +   }
> +   }
> +
> /* Not a clue what this is exactly.  Without pointing it at a
>  * scratch page, VRAM->GART blits with M2MF (as in DDX DFS)
>  * cause IOMMU "read from address 0" errors (rh#561267)
>  */
> -   nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8);
> +   if (fb->r100c08)
> +   nvkm_wr32(device, 0x100c08, fb->r100c08 >> 8);
>
> /* This is needed to get meaningful information from 100c90
>  * on traps. No idea what these values mean exactly. */
> @@ -233,11 +255,11 @@ nv50_fb_dtor(struct nvkm_fb *base)
> struct nv50_fb *fb = nv50_fb(base);
> struct nvkm_device *device = fb->base.subdev.device;
>
> -   if (fb->r100c08_page) {
> +   if (fb->r100c08)
> dma_unmap_page(device->dev, fb->r100c08, PAGE_SIZE,
>DMA_BIDIRECTIONAL);
> -   __free_page(fb->r100c08_page);
> -   }
> +
> +   __free_page(fb->r100c08_page);
>
> return fb;
>  }
> @@ -264,13 +286,9 @@ nv50_fb_new_(const struct nv50_fb_func *func, struct 
> nvkm_device *device,
> *pfb = >base;
>
> fb->r100c08_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> -   if (fb->r100c08_page) {
> -   fb->r100c08 = dma_map_page(device->dev, fb->r100c08_page, 0,
> -  PAGE_SIZE, DMA_BIDIRECTIONAL);
> -   if (dma_mapping_error(device->dev, fb->r100c08))
> -   return -EFAULT;
> -   } else {
> -   nvkm_warn(>base.subdev, "failed 100c08 page alloc\n");
> +   if (!fb->r100c08_page) {
> +   nvkm_error(>base.subdev, "failed 100c08 page alloc\n");
> +   return -ENOMEM;
> }
>
> return 0;
> --
> 2.7.4
>

[PATCH] drm/edid: move DDC_SEGMENT_ADDR into drm_edid.h

[Daniel Vetter]

On Thu, Jul 14, 2016 at 05:00:28PM +0800, Shawn Guo wrote:
> The same definition of DDC_SEGMENT_ADDR is currently defined in two
> places, drm_edid.c and inno_hdmi.h.  Let's consolidate the definition
> into drm_edid.h in the same way that DDC_ADDR is defined.
> 
> Signed-off-by: Shawn Guo 

What really should be done here is nuke the fake i2c adapter in
inno_hdmi.c and instead just directly read the edid from the hdim IP.
Using drm_get_edid for something that's not backed by a real i2c bus is
bonghits.
-Daniel

> ---
>  drivers/gpu/drm/drm_edid.c   | 1 -
>  drivers/gpu/drm/rockchip/inno_hdmi.h | 2 --
>  include/drm/drm_edid.h   | 1 +
>  3 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7df26d4b7ad8..9d6735b68152 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1191,7 +1191,6 @@ bool drm_edid_is_valid(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_edid_is_valid);
>  
> -#define DDC_SEGMENT_ADDR 0x30
>  /**
>   * drm_do_probe_ddc_edid() - get EDID information via I2C
>   * @data: I2C device adapter
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.h 
> b/drivers/gpu/drm/rockchip/inno_hdmi.h
> index aa7c415f8cc1..b27b30934c7e 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.h
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.h
> @@ -16,8 +16,6 @@
>  #ifndef __INNO_HDMI_H__
>  #define __INNO_HDMI_H__
>  
> -#define DDC_SEGMENT_ADDR 0x30
> -
>  enum PWR_MODE {
>   NORMAL,
>   LOWER_PWR,
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 919933d1beb4..7ee78d5c9252 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -26,6 +26,7 @@
>  #include 
>  
>  #define EDID_LENGTH 128
> +#define DDC_SEGMENT_ADDR 0x30
>  #define DDC_ADDR 0x50
>  #define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Daniel Vetter]

On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> > > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > > > vGEM buffers are useful for passing data between software clients and
> > > > hardware renders. By allowing the user to create and attach fences to
> > > > the exported vGEM buffers (on the dma-buf), the user can implement a
> > > > deferred renderer and queue hardware operations like flipping and then
> > > > signal the buffer readiness (i.e. this allows the user to schedule
> > > > operations out-of-order, but have them complete in-order).
> > > > 
> > > > This also makes it much easier to write tightly controlled testcases for
> > > > dma-buf fencing and signaling between hardware drivers.
> > > > 
> > > > v2: Don't pretend the fences exist in an ordered timeline, but allocate
> > > > a separate fence-context for each fence so that the fences are
> > > > unordered.
> > > > v3: Make the debug output more interesting, and so the signaled status.
> > > > 
> > > > Testcase: igt/vgem_basic/dmabuf-fence
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Sean Paul 
> > > > Cc: Zach Reizner 
> > > > Cc: Gustavo Padovan 
> > > > Cc: Daniel Vetter 
> > > > Acked-by: Zach Reizner 
> > > 
> > > One thing I completely forgotten: This allows userspace to hang kernel
> > > drivers. i915 (and other gpu drivers) can recover using hangcheck, but
> > > dumber drivers (v4l, if that ever happens) probably never except such a
> > > case. We've had a similar discusion with the userspace fences exposed in
> > > sw_fence, and decided to move all those ioctl into debugfs. I think we
> > > should do the same for this vgem-based debugging of implicit sync. Sorry
> > > for realizing this this late.
> > 
> > One of the very tests I make is to ensure that we recover from such a
> > hang. I don't see the difference between this any of the other ways
> > userspace can shoot itself (and others) in the foot.
> 
> So one solution would be to make vgem fences automatically timeout (with
> a flag for root to override for the sake of testing hang detection).

The problem is other drivers. E.g. right now atomic helpers assume that
fences will signal, and can't recover if they don't. This is why drivers
where things might fail must have some recovery (hangcheck, timeout) to
make sure dma_fences always signal.

Imo not even root should be allowed to break this, since it could put
drivers into a non-recoverable state. I think this must be restricted to
something known-unsafe-don't-enable-on-production like debugfs.

Other solutions which I don't like:
- Everyone needs to be able to recover. Given how much effort it is to
  just keep i915 hangcheck in working order I think that's totally
  illusionary to assume. At least once world+dog (atomic, v4l, ...) all
  consume/produce fences, subsystems where the usual assumption holds that
  async ops complete.

- Really long timeouts are allowed for root in vgem. Could lead to even
  more fun in testing i915 hangchecks I think, so don't like that much
  either.

I think the best option is to just do the same as we've done for sw_fence,
and move it to debugfs. We could reuse the debugfs sw_fence interface to
create them (gives us more control as a bonus), and just have an ioctl to
attach fences to vgem (which could be unpriviledged).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> The biggest reason I had against going the sw_sync only route was that
> vgem should provide unprivileged fences and that through the bookkeeping
> in vgem we can keep them safe, ensure that we don't leak random buffers
> or fences. (And I need a source of foriegn dma-buf with implicit fence
> tracking with which I can try and break the driver.)

And for testing passing around content + fences is more useful than
passing fences alone.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

On Thu, Jul 14, 2016 at 02:40:59PM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote:
> > > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> > > > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > > > > vGEM buffers are useful for passing data between software clients and
> > > > > hardware renders. By allowing the user to create and attach fences to
> > > > > the exported vGEM buffers (on the dma-buf), the user can implement a
> > > > > deferred renderer and queue hardware operations like flipping and then
> > > > > signal the buffer readiness (i.e. this allows the user to schedule
> > > > > operations out-of-order, but have them complete in-order).
> > > > > 
> > > > > This also makes it much easier to write tightly controlled testcases 
> > > > > for
> > > > > dma-buf fencing and signaling between hardware drivers.
> > > > > 
> > > > > v2: Don't pretend the fences exist in an ordered timeline, but 
> > > > > allocate
> > > > > a separate fence-context for each fence so that the fences are
> > > > > unordered.
> > > > > v3: Make the debug output more interesting, and so the signaled 
> > > > > status.
> > > > > 
> > > > > Testcase: igt/vgem_basic/dmabuf-fence
> > > > > Signed-off-by: Chris Wilson 
> > > > > Cc: Sean Paul 
> > > > > Cc: Zach Reizner 
> > > > > Cc: Gustavo Padovan 
> > > > > Cc: Daniel Vetter 
> > > > > Acked-by: Zach Reizner 
> > > > 
> > > > One thing I completely forgotten: This allows userspace to hang kernel
> > > > drivers. i915 (and other gpu drivers) can recover using hangcheck, but
> > > > dumber drivers (v4l, if that ever happens) probably never except such a
> > > > case. We've had a similar discusion with the userspace fences exposed in
> > > > sw_fence, and decided to move all those ioctl into debugfs. I think we
> > > > should do the same for this vgem-based debugging of implicit sync. Sorry
> > > > for realizing this this late.
> > > 
> > > One of the very tests I make is to ensure that we recover from such a
> > > hang. I don't see the difference between this any of the other ways
> > > userspace can shoot itself (and others) in the foot.
> > 
> > So one solution would be to make vgem fences automatically timeout (with
> > a flag for root to override for the sake of testing hang detection).
> 
> The problem is other drivers. E.g. right now atomic helpers assume that
> fences will signal, and can't recover if they don't. This is why drivers
> where things might fail must have some recovery (hangcheck, timeout) to
> make sure dma_fences always signal.

Urm, all the atomic helpers should work with fails. The waits on dma-buf
should be before any hardware is modified and so cancellation is trivial.
Anyone using a foriegn fence (or even native) must cope that it may not
meet some deadline.

They have to. Anyone sharing a i915 dma-buf is susceptible to all kinds
of (unprivileged) fun.

> Imo not even root should be allowed to break this, since it could put
> drivers into a non-recoverable state. I think this must be restricted to
> something known-unsafe-don't-enable-on-production like debugfs.

Providing fences is extremely useful, even for software buffers. (For
the sake of argument, just imagine an asynchronous multithreaded llvmpipe
wanting to support client fences for deferred rendering.) The only
question in my mind is how much cotton wool to use.

> Other solutions which I don't like:
> - Everyone needs to be able to recover. Given how much effort it is to
>   just keep i915 hangcheck in working order I think that's totally
>   illusionary to assume. At least once world+dog (atomic, v4l, ...) all
>   consume/produce fences, subsystems where the usual assumption holds that
>   async ops complete.
> 
> - Really long timeouts are allowed for root in vgem. Could lead to even
>   more fun in testing i915 hangchecks I think, so don't like that much
>   either.

The whole point is in testing our handling before we become suspectible
to real world fail - because as you point out, not everyone guarantees
that a fence will be signaled. I can't simply pass around i915 dma-buf
simply because we may unwind them and in the process completely curtail
being able to test a foriegn fence that hangs.

> I think the best option is to just do the same as we've done for sw_fence,
> and move it to debugfs. We could reuse the debugfs sw_fence interface to
> create them (gives us more control as a bonus), and just have an ioctl to
> attach fences to vgem (which could be unpriviledged).

The biggest reason I had against going the sw_sync only route was that
vgem should provide unprivileged fences and that through the bookkeeping
in vgem we can keep them safe, ensure that we don't leak random buffers
or fences. (And I need a source of foriegn dma-buf with implicit fence
tracking with which I can try and break the driver.)
-Chris

-- 
Chris Wilson, Intel Open 

[PATCH v4 5/5] dma-buf/sync_file: only enable fence signalling on poll()

[John Harrison]

On 12/07/2016 19:08, Gustavo Padovan wrote:
> ...
>
> +++ b/include/linux/sync_file.h
> @@ -28,6 +28,7 @@
>* @name:   name of sync_file.  Useful for debugging
>* @sync_file_list: membership in global file list
>* @wq: wait queue for fence signaling
> + * @enabled: wether fence signal is enabled or not
Minor typo: should be 'whether'.

[PATCH 2/4] drm/msm/hdmi: Use more DT friendly GPIO names

[Archit Taneja]

On 07/13/2016 07:15 PM, Rob Herring wrote:
> On Fri, Jul 08, 2016 at 11:25:52AM +0530, Archit Taneja wrote:
>> Update the gpio name parsing code to try to search for without the
>> "qcom,hdmi-tx-" prefix. The older downstream bindings that expect
>> "qcom,hdmi-tx-xyz" or "qcom,hdmi-tx-xyz-gpio" would work as the
>> property name would work as before.
>
> Why?

Why we want the older names to work? Just to make life easier if
backporting the drm driver to a downstream msm kernel (like a 3.10,
or 3.18).

>
>> Update the binding doc. Add an entry for the missing hpd and lpm
>> gpios.
>>
>> Cc: Rob Herring 
>> Cc: devicetree at vger.kernel.org
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   Documentation/devicetree/bindings/display/msm/hdmi.txt |  6 --
>>   drivers/gpu/drm/msm/hdmi/hdmi.c| 16 
>> 
>>   2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt 
>> b/Documentation/devicetree/bindings/display/msm/hdmi.txt
>> index b63f614..4da1abd 100644
>> --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
>> +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt
>> @@ -23,8 +23,10 @@ Required properties:
>>   - phy-names: the name of the corresponding PHY device
>>
>>   Optional properties:
>> -- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
>> -- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
>> +- hpd-gpio: hdmi hpd pin
>
> hpd-gpios is the somewhat standard name.
>
>> +- mux-en-gpio: hdmi mux enable pin
>> +- mux-sel-gpio: hdmi mux select pin
>> +- mux-lpm-gpio: hdmi mux lpm pin
>
> These look pretty QCom specific and should keep the vendor prefix.

Okay.

>
> I understand why you don't have '-gpios', but if we change these they
> should use the preferred form.


Sure, I'll update these to the preferred form.

Archit

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

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote:
> So one solution would be to make vgem fences automatically timeout (with
> a flag for root to override for the sake of testing hang detection).

diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index b7da11419ad6..17c63c9a8ea0 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -28,6 +28,7 @@
 struct vgem_fence {
struct fence base;
struct spinlock lock;
+   struct timer_list timer;
 };

 static const char *vgem_fence_get_driver_name(struct fence *fence)
@@ -50,6 +51,14 @@ static bool vgem_fence_enable_signaling(struct fence *fence)
return true;
 }

+static void vgem_fence_release(struct fence *base)
+{
+   struct vgem_fence *fence = container_of(base, typeof(*fence), base);
+
+   del_timer_sync(>timer);
+   fence_free(>base);
+}
+
 static void vgem_fence_value_str(struct fence *fence, char *str, int size)
 {
snprintf(str, size, "%u", fence->seqno);
@@ -67,11 +76,21 @@ const struct fence_ops vgem_fence_ops = {
.enable_signaling = vgem_fence_enable_signaling,
.signaled = vgem_fence_signaled,
.wait = fence_default_wait,
+   .release = vgem_fence_release,
+
.fence_value_str = vgem_fence_value_str,
.timeline_value_str = vgem_fence_timeline_value_str,
 };

-static struct fence *vgem_fence_create(struct vgem_file *vfile)
+static void vgem_fence_timeout(unsigned long data)
+{
+   struct vgem_fence *fence = (struct vgem_fence *)data;
+
+   fence_signal(>base);
+}
+
+static struct fence *vgem_fence_create(struct vgem_file *vfile,
+  unsigned int flags)
 {
struct vgem_fence *fence;

@@ -83,6 +102,12 @@ static struct fence *vgem_fence_create(struct vgem_file 
*vfile)
fence_init(>base, _fence_ops, >lock,
   fence_context_alloc(1), 1);

+   setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);
+
+   /* We force the fence to expire within 10s to prevent driver hangs */
+   if (!(flags & VGEM_FENCE_NOTIMEOUT))
+   mod_timer(>timer, 10*HZ);
+
return >base;
 }

@@ -114,9 +139,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
struct fence *fence;
int ret;

-   if (arg->flags & ~VGEM_FENCE_WRITE)
+   if (arg->flags & ~(VGEM_FENCE_WRITE | VGEM_FENCE_NOTIMEOUT))
return -EINVAL;

+   if (arg->flags & VGEM_FENCE_NOTIMEOUT && !capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
if (arg->pad)
return -EINVAL;

@@ -128,7 +156,7 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
if (ret)
goto out;

-   fence = vgem_fence_create(vfile);
+   fence = vgem_fence_create(vfile, arg->flags);
if (!fence) {
ret = -ENOMEM;
goto out;
diff --git a/include/uapi/drm/vgem_drm.h b/include/uapi/drm/vgem_drm.h
index 352d2fae8de9..55fd08750773 100644
--- a/include/uapi/drm/vgem_drm.h
+++ b/include/uapi/drm/vgem_drm.h
@@ -45,7 +45,8 @@ extern "C" {
 struct drm_vgem_fence_attach {
__u32 handle;
__u32 flags;
-#define VGEM_FENCE_WRITE 0x1
+#define VGEM_FENCE_WRITE   0x1
+#define VGEM_FENCE_NOTIMEOUT   0x2
__u32 out_fence;
__u32 pad;
 };


-- 
Chris Wilson, Intel Open Source Technology Centre

vga_switcheroo audio runpm

[Peter Wu]

On Sun, Jul 10, 2016 at 03:20:13PM +0200, Lukas Wunner wrote:
> Hi Peter,
> 
> > [12:42] Lekensteyn: Should the video card always be powered up when a
> >   register is read from the HDMI audio controller? Or would it be
> >   better to leave the video card suspended and just fail the HDA
> >   register reads?
> 
> It should probably be powered up.

Seems sensible, a video signal is apparently also required if you want
to play audio.

> > [12:43] Lekensteyn: I'm trying to figure out how vga_switcheroo should
> handle this, maybe l1k has an idea?
> > [12:48] Lekensteyn: The current implemented policy is that the video card
> >   dictates the power state and that the HDMI audio device has to
> >   adapt (even if it is seemingly in use)
> 
> This current architecture seems to have come about historically (Dave
> Airlie first implemented vga_switcheroo with manual power control,
> then added runtime pm in a second step).
> 
> It may also be motivated by the fact that the driver core is currently
> not supporting dependencies between devices beyond the hierarchical
> parent/child relationship.
> 
> Rafael Wysocki (cc:) posted a series in January addressing the latter
> problem with so-called "device links". The series was reposted recently
> by Marek Szyprowski:
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1170031.html
> 
> The vga_switcheroo audio handling should probably be reworked to use such
> "device links". The result would be that the GPU won't runtime suspend
> as long as a ref is held for the audio card. The audio card needs to then
> make sure that it releases any refs if it has nothing to do.
> 
> The "device links" series seems to impose more restrictions than we
> actually need here, it seems to require that the "supplier" is bound
> to a driver before the "consumer" may probe. IOW nouveau needs to be
> bound before snd_hda_audio can probe. I'm not sure if that additional
> (unnecessary) restriction is a problem.

The device links feature looks promising. My initial guess that it is OK
to wait for nouveau to become available (as supplier), the audio port
(as consumer) probably does not work anyway without a video signal.

> I've recently tried to add runtime pm for muxed laptops to vga_switcheroo,
> this is something that Pierre Moreau (cc:) has expressed an interest in
> for his MacBook Pro. I came across a major roadblock in the form of
> vga_switcheroo_set_dynamic_switch(). That function is called from the
> DRM driver when the GPU runtime suspends and resumes. It takes the
> vgasr_mutex. The problem is, if the user initiates a switch of the mux,
> that mutex is already taken in vga_switcheroo_debugfs_write(). If the
> GPU we're switching to is asleep, it'll wake up for the switch and
> we'll get a deadlock when the DRM driver subsequently calls
> vga_switcheroo_set_dynamic_switch().
> 
> I would like to get rid of vga_switcheroo_set_dynamic_switch() to solve
> this. The function has two purposes: Number one, vga_switcheroo updates
> its internal power state representation for the GPU. That is actually
> pointless for driver power control because we can always query the
> driver core for this information (e.g. pm_runtime_suspended()).
> The second purpose is to switch the audio client on and off. If we would
> use a "device link" to express the dependency between the audio device
> and the GPU, we wouldn't need this. So moving to "device links" is
> a prerequisite to make runtime pm work for muxed laptops.

This internal state is likely a historical artifact due to the manual
control (ON / OFF) that was needed in the past. I have recently tried to
draw the dependencies on paper and the suspend/resume to dynamic switch
flow is not the prettiest ;) Using runtime pm would probably make the
dependencies clearer in a logical way.

> If you want to take a stab at using "device links" for vga_switcheroo
> then please go ahead as I'm swamped with other work. (I've reverse-
> engineered retrieval of Apple device properties from EFI this week,
> which is needed for Thunderbolt.) Let me know if you have any questions
> or need stuff reviewed or whatever. Since the "device links" series
> hasn't landed yet, it's still possible I think to ask for feature
> requests should it not work for this particular use case. The
> linux-pm at vger.kernel.org mailing list is the right place to inquire
> about the series.
> 
> Thanks for raising this important question.

I'll give this a go after finishing the PR3 nouveau patches and fixing
some locking issues.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

[PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

[Yakir Yang]

Alway enable the PSR function for Rockchip analogix_dp driver. If panel
don't support PSR, then the core analogix_dp would ignore this setting.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. 
(Stéphane, reviewed at Google gerrit)

[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
 at 83]

Changes in v3:
- split the common psr logic into a seperate driver, make this to a
  simple sub-psr device driver.

Changes in v2:
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 57 +
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e81e19a..aa916f4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -32,6 +32,7 @@
 #include 

 #include "rockchip_drm_drv.h"
+#include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"

 #define RK3288_GRF_SOC_CON60x25c
@@ -41,6 +42,9 @@

 #define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)

+#define PSR_SET_DELAY_TIME msecs_to_jiffies(10)
+#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS  100
+
 #define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)

 /**
@@ -68,11 +72,55 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;

+   struct delayed_work  psr_work;
+   unsigned int psr_state;
+
const struct rockchip_dp_chip_data *data;

struct analogix_dp_plat_data plat_data;
 };

+static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
+{
+   struct rockchip_dp_device *dp = to_dp(encoder);
+
+   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+
+   if (enabled)
+   dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
+   else
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+
+   schedule_delayed_work(>psr_work, PSR_SET_DELAY_TIME);
+}
+
+static void analogix_dp_psr_work(struct work_struct *work)
+{
+   struct rockchip_dp_device *dp =
+   container_of(work, typeof(*dp), psr_work.work);
+   struct drm_crtc *crtc = dp->encoder.crtc;
+   int psr_state = dp->psr_state;
+   int vact_end;
+   int ret;
+
+   if (!crtc)
+   return;
+
+   vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + 
crtc->mode.vdisplay;
+
+   ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
+ PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   return;
+   }
+
+   if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+   analogix_dp_enable_psr(dp->dev);
+   else
+   analogix_dp_disable_psr(dp->dev);
+}
+
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
 {
reset_control_assert(dp->rst);
@@ -340,12 +388,21 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;

+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+   INIT_DELAYED_WORK(>psr_work, analogix_dp_psr_work);
+
+   rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
+
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
 }

 static void rockchip_dp_unbind(struct device *dev, struct device *master,
   void *data)
 {
+   struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+
+   rockchip_drm_psr_unregister(>encoder);
+
return analogix_dp_unbind(dev, master, data);
 }

-- 
1.9.1

[PATCH v4 3/4] drm/bridge: analogix_dp: add the PSR function support

[Yakir Yang]

The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make lots of
sense to save the power consumption.

This patch have exported two symbols for platform driver to implement
the PSR function in hardware side:
- analogix_dp_active_psr()
- analogix_dp_inactive_psr()

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Downgrade the PSR version print message to debug level. (Sean)
- Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
- Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
(Sean)
- Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
- Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
- Rename "active/inactive" to "enable/disable". (Sean, Dominik)
- Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().

Changes in v3:
- split analogix_dp_enable_psr(), make it more clearly
analogix_dp_detect_sink_psr()
analogix_dp_enable_sink_psr()
- remove some nosie register setting comments

Changes in v2:
- introduce in v2, splite the common Analogix DP changes out

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 60 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 49 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  | 28 ++
 include/drm/bridge/analogix_dp.h   |  3 ++
 5 files changed, 144 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..1fec91a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -97,6 +97,62 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 }

+int analogix_dp_enable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   analogix_dp_send_psr_spd(dp, EDP_VSC_PSR_STATE_ACTIVE |
+EDP_VSC_PSR_CRC_VALUES_VALID);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
+
+int analogix_dp_disable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   analogix_dp_send_psr_spd(dp, 0);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
+
+static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+{
+   unsigned char psr_version;
+
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_SUPPORT, _version);
+   dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
+
+   return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+}
+
+static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
+{
+   unsigned char psr_en;
+
+   /* Disable psr function */
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_EN_CFG, _en);
+   psr_en &= ~DP_PSR_ENABLE;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   /* Main-Link transmitter remains active during PSR active states */
+   psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   /* Enable psr function */
+   psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
+DP_PSR_CRC_VERIFICATION;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   analogix_dp_enable_psr_crc(dp);
+}
+
 static unsigned char analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 {
int i;
@@ -921,6 +977,10 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)

/* Enable video */
analogix_dp_start_video(dp);
+
+   dp->psr_support = analogix_dp_detect_sink_psr(dp);
+   if (dp->psr_support)
+   analogix_dp_enable_sink_psr(dp);
 }

 int analogix_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index b456380..6ca5dde 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -177,6 +177,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
unsigned char   edid[EDID_BLOCK_LENGTH * 2];
+   boolpsr_support;

struct analogix_dp_plat_data *plat_data;
 };
@@ -278,4 +279,7 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
+void 

[PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

[Yakir Yang]

The PSR driver have exported four symbols for specific device driver:
- rockchip_drm_psr_register()
- rockchip_drm_psr_unregister()
- rockchip_drm_psr_enable()
- rockchip_drm_psr_disable()
- rockchip_drm_psr_flush()

Encoder driver should call the register/unregister interfaces to hook
itself into common PSR driver, encoder have implement the 'psr_set'
callback which use the set PSR state in hardware side.

Crtc driver would call the enable/disable interfaces when vblank is
enable/disable, after that the common PSR driver would call the encoder
registered callback to set the PSR state.

Fb driver would call the flush interface in 'fb->dirty' callback, this
helper function would force all PSR enabled encoders to exit from PSR
for 3 seconds.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Tuck the global "psr_list" & "psr_list_mutex" in struct rockchip_drm_private. 
(Sean)
- Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
- Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
- Collect psr_enable() and psr_disable() into psr_set_state()
- s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
- Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in Google 
gerrit)

[https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 at 475]
- Add the missing file head with license. (Stéphane, reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
 at 3]

Changes in v3:
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2

Changes in v2: None

 drivers/gpu/drm/rockchip/Makefile   |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  12 ++
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 223 
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  26 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  29 
 7 files changed, 298 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..9746365 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,7 +3,7 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_vop.o
+   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d665fb0..26c12b3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -156,6 +156,9 @@ static int rockchip_drm_bind(struct device *dev)

drm_dev->dev_private = private;

+   INIT_LIST_HEAD(>psr_list);
+   mutex_init(>psr_list_mutex);
+
drm_mode_config_init(drm_dev);

rockchip_drm_mode_config_init(drm_dev);
@@ -218,6 +221,7 @@ static int rockchip_drm_bind(struct device *dev)

if (is_support_iommu)
arm_iommu_release_mapping(mapping);
+
return 0;
 err_fbdev_fini:
rockchip_drm_fbdev_fini(drm_dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 239b830..9c34c9e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -61,6 +61,9 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
+
+   struct list_head psr_list;
+   struct mutex psr_list_mutex;
 };

 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..36afd9c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -21,6 +21,7 @@

 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
+#include "rockchip_drm_psr.h"

 #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)

@@ -66,9 +67,20 @@ static int rockchip_drm_fb_create_handle(struct 
drm_framebuffer *fb,
 rockchip_fb->obj[0], handle);
 }

+static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file,
+  

[PATCH v4 1/4] drm/rockchip: vop: export line flag function

[Yakir Yang]

VOP have integrated a hardware counter which indicate the exact display
line that vop is scanning. And if we're interested in a specific line,
we can set the line number to vop line_flag register, and then vop would
generate a line_flag interrupt for it.

For example eDP PSR function is interested in the vertical blanking
period, then driver could set the line number to zero.

This patch have exported a symbol that allow other driver to listen the
line flag event with given timeout limit:
-  rockchip_drm_wait_line_flag()

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
- Make line_flag_num_x to an array. (Sean)
- Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 at 466]

Changes in v3:
- Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
- Add 'line_flag_num_0' for RK3288/RK3036
- Remove the notify for waiting line_flag event (Daniel)

Changes in v2:
- Introduce in v2, split VOP line flag changes out

 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 118 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   4 +
 4 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index ea39329..239b830 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,4 +70,7 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
+int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
+   unsigned int mstimeout);
+
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c8a62a8..69d32f1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -121,6 +121,8 @@ struct vop {
/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;

+   struct completion line_flag_completion;
+
const struct vop_data *data;

uint32_t *regsbak;
@@ -431,6 +433,71 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }

+/*
+ * (1) each frame starts at the start of the Vsync pulse which is signaled by
+ * the "FRAME_SYNC" interrupt.
+ * (2) the active data region of each frame ends at dsp_vact_end
+ * (3) we should program this same number (dsp_vact_end) into 
dsp_line_frag_num,
+ *  to get "LINE_FLAG" interrupt at the end of the active on screen data.
+ *
+ * VOP_INTR_CTRL0.dsp_line_frag_num = VOP_DSP_VACT_ST_END.dsp_vact_end
+ * Interrupts
+ * LINE_FLAG ---+
+ * FRAME_SYNC + |
+ *| |
+ *v v
+ *| Vsync | Vbp |  Vactive  | Vfp |
+ *^ ^   ^ ^
+ *| |   | |
+ *| |   | |
+ * dsp_vs_end + |   | |   VOP_DSP_VTOTAL_VS_END
+ * dsp_vact_start --+   | |   VOP_DSP_VACT_ST_END
+ * dsp_vact_end + |   VOP_DSP_VACT_ST_END
+ * dsp_total -+   VOP_DSP_VTOTAL_VS_END
+ */
+static bool vop_line_flag_irq_is_enabled(struct vop *vop)
+{
+   uint32_t line_flag_irq;
+   unsigned long flags;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   line_flag_irq = VOP_INTR_GET_TYPE(vop, enable, LINE_FLAG_INTR);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+
+   return !!line_flag_irq;
+}
+
+static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   VOP_CTRL_SET(vop, line_flag_num[0], line_num);
+   VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
+static void vop_line_flag_irq_disable(struct vop *vop)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 0);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
@@ -1157,6 

[PATCH v4 0/4] Add PSR function support for Analogix/Rockchip DP

[Yakir Yang]

The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make a lots
of sense to save the power consumption.

This v3 version have splited an common PSR driver for Rockchip, which is
biggest changes from v2.

This thread is based on Mark's RK3399 VOP thread[0] and my RK3399 eDP
thread[1].

[0]: https://patchwork.kernel.org/patch/8886041/
[1]: https://patchwork.kernel.org/patch/9204497/


Changes in v4:
- Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
- Make line_flag_num_x to an array. (Sean)
- Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 at 466]
- Tuck the global "psr_list" & "psr_list_mutex" in struct rockchip_drm_private. 
(Sean)
- Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
- Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
- Collect psr_enable() and psr_disable() into psr_set_state()
- s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
- Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in Google 
gerrit)

[https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 at 475]
- Add the missing file head with license. (Stéphane, reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
 at 3]
- Downgrade the PSR version print message to debug level. (Sean)
- Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
- Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
(Sean)
- Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
- Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
- Rename "active/inactive" to "enable/disable". (Sean, Dominik)
- Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. 
(Stéphane, reviewed at Google gerrit)

[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
 at 83]

Changes in v3:
- Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
- Add 'line_flag_num_0' for RK3288/RK3036
- Remove the notify for waiting line_flag event (Daniel)
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2
- split analogix_dp_enable_psr(), make it more clearly
analogix_dp_detect_sink_psr()
analogix_dp_enable_sink_psr()
- remove some nosie register setting comments
- split the common psr logic into a seperate driver, make this to a
  simple sub-psr device driver.

Changes in v2:
- Introduce in v2, split VOP line flag changes out
- introduce in v2, splite the common Analogix DP changes out
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

Yakir Yang (4):
  drm/rockchip: vop: export line flag function
  drm/rockchip: add an common abstracted PSR driver
  drm/bridge: analogix_dp: add the PSR function support
  drm/rockchip: analogix_dp: implement PSR function

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  60 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   4 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  49 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |  28 +++
 drivers/gpu/drm/rockchip/Makefile  |   2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  57 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   6 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  12 ++
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 223 +
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  26 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 147 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   4 +
 include/drm/bridge/analogix_dp.h   |   3 +
 15 files changed, 626 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

-- 
1.9.1

[PATCH v5] drm/imx: convey the pixelclk-active and de-active flags from DT to the ipu-di driver

[Philipp Zabel]

Hi Lothar,

Am Dienstag, den 12.07.2016, 18:50 +0200 schrieb Philipp Zabel:
> From: Lothar Waßmann 
> 
> The 'de-active' and 'pixelclk-active' DT properties are evaluated
> by of_parse_display_timing() called from  of_get_drm_display_mode(),
> but later lost in the conversion from videomode.flags to
> drm_display_mode.flags.
> Enhance of_get_drm_display_mode() to also return the bus flags in a
> separate variable, so that they can be passed on to the ipu-di
> driver.
> 
> Signed-off-by: Lothar Waßmann 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v4:
>  - Rebased onto imx-drm/next after atomic modeset changes

could you double check
git://git.pengutronix.de/git/pza/linux.git imx-drm/next
works for you?
Let me know if you agree with my changes to your patch.

regards
Philipp

[GIT PULL] imx-drm atomic mode setting conversion and cleanup

[Philipp Zabel]

Hi Dave,

this tag contains Liu Ying's atomic modesetting conversion of the
imx-drm driver, support for external bridges connected to the parallel
display ports, and various error handling fixes and cleanups.

regards
Philipp

The following changes since commit 9253d0590ef17b4ef2167a66ad500c51b2d61610:

  Merge tag 'topic/drm-misc-2016-06-22-updated' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-24 11:01:17 
+1000)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2016-07-14

for you to fetch changes up to f140b0cc776f8771adfa45d2ef234da72662443d:

  drm/imx: parallel-display: add bridge support (2016-07-14 11:18:46 +0200)


imx-drm updates

- atomic mode setting conversion
- replace DMFC FIFO allocation mechanism with a fixed allocation
  that is good enough for all cases
- support for external bridges connected to parallel-display
- improved error handling in imx-ldb, imx-tve, and parallel-display
- some code cleanup in imx-tve


Fabio Estevam (3):
  drm/imx: imx-tve: check the value returned by regulator_set_voltage()
  drm/imx: imx-tve: remove unneeded 'or' operation
  drm/imx: imx-tve: fix the error message

Liu Ying (10):
  drm/imx: ipuv3 plane: Check different types of plane separately
  gpu: ipu-v3: ipu-dmfc: Use static DMFC FIFO allocation mechanism
  drm/imx: atomic phase 1: Use transitional atomic CRTC and plane helpers
  drm/imx: atomic phase 2 step 1: Wire up state ->reset, ->duplicate and 
->destroy
  drm/imx: atomic phase 2 step 2: Track plane_state->fb correctly in 
->page_flip
  drm/imx: Remove encoders' ->prepare callbacks
  drm/imx: atomic phase 3 step 1: Use atomic configuration
  drm/bridge: dw-hdmi: Remove the legacy drm_connector_funcs structure
  drm/imx: atomic phase 3 step 2: Legacy callback fixups
  drm/imx: atomic phase 3 step 3: Advertise DRIVER_ATOMIC

Lothar Waßmann (1):
  drm/imx: parallel-display: check return code from 
of_get_drm_display_mode()

Lucas Stach (1):
  drm/imx: imx-ldb: check return code on panel attach

Philipp Zabel (5):
  drm/imx: remove empty mode_set encoder callbacks
  drm/imx: store internal bus configuration in crtc state
  drm/imx: turn remaining container_of macros into inline functions
  gpu: ipu-v3: ipu-dc: don't bug out on invalid bus_format
  drm/imx: parallel-display: add bridge support

 drivers/gpu/drm/bridge/dw-hdmi.c   |  19 +-
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  32 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 120 +---
 drivers/gpu/drm/imx/imx-drm.h  |  21 +-
 drivers/gpu/drm/imx/imx-ldb.c  | 192 +++-
 drivers/gpu/drm/imx/imx-tve.c  |  97 +++---
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 400 
 drivers/gpu/drm/imx/ipuv3-plane.c  | 548 -
 drivers/gpu/drm/imx/ipuv3-plane.h  |  16 -
 drivers/gpu/drm/imx/parallel-display.c | 149 +
 drivers/gpu/ipu-v3/ipu-dc.c|   9 +-
 drivers/gpu/ipu-v3/ipu-di.c|   3 -
 drivers/gpu/ipu-v3/ipu-dmfc.c  | 213 +
 include/video/imx-ipu-v3.h |   3 -
 14 files changed, 781 insertions(+), 1041 deletions(-)

[PATCH 6/6] drm/rockchip: vop: correct rk3036 register define

[Mark Yao]

Signed-off-by: Mark Yao 
Reported-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a348a7a..919992c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -190,7 +190,7 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };

-static const struct vop_scl_regs rk3066_win_scl = {
+static const struct vop_scl_regs rk3036_win_scl = {
.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
.scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
@@ -198,7 +198,7 @@ static const struct vop_scl_regs rk3066_win_scl = {
 };

 static const struct vop_win_phy rk3036_win0_data = {
-   .scl = _win_scl,
+   .scl = _win_scl,
.data_formats = formats_win_full,
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
-- 
1.9.1

[PATCH 5/6] drm/rockchip: vop: correct the source size of uv scale factor setting

[Mark Yao]

When the input color format is YUV, we need to do some external scale
for CBCR. Like,
 * In YUV420 data format:
 cbcr_xscale = dst_w / src_w * 2;
 cbcr_yscale = dst_h / src_h * 2;
 * In YUV422 data format:
 cbcr_xscale = dst_w / src_w * 2;
 cbcr_yscale = dst_h / src_h;
 * In YUV444 data format
 cbcr_xscale = dst_w / src_w;
 cbcr_yscale = dst_h / src_h;

Signed-off-by: Yakir Yang 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index e01c435..aad105b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -328,9 +328,9 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
scl_cal_scale2(src_h, dst_h));
if (is_yuv) {
VOP_SCL_SET(vop, win, scale_cbcr_x,
-   scl_cal_scale2(src_w, dst_w));
+   scl_cal_scale2(cbcr_src_w, dst_w));
VOP_SCL_SET(vop, win, scale_cbcr_y,
-   scl_cal_scale2(src_h, dst_h));
+   scl_cal_scale2(cbcr_src_h, dst_h));
}
return;
}
-- 
1.9.1

[PATCH 4/6] drm/rockchip: vop: add uv_vir register field for RK3036 VOP

[Mark Yao]

From: Yakir Yang 

The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.

Signed-off-by: Yakir Yang 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 52661d1..a348a7a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -210,6 +210,7 @@ static const struct vop_win_phy rk3036_win0_data = {
.yrgb_mst = VOP_REG(RK3036_WIN0_YRGB_MST, 0x, 0),
.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0x, 0),
+   .uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
 };

 static const struct vop_win_phy rk3036_win1_data = {
-- 
1.9.1

[PATCH 3/6] drm/rockchip: fix "should it be static?" warnings

[Mark Yao]

From: John Keeping 

Combined with the previous commit, this fixes all of the sparse warnings
in drm/rockchip.

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d665fb0..7216180 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -257,7 +257,7 @@ static void rockchip_drm_unbind(struct device *dev)
dev_set_drvdata(dev, NULL);
 }

-void rockchip_drm_lastclose(struct drm_device *dev)
+static void rockchip_drm_lastclose(struct drm_device *dev)
 {
struct rockchip_drm_private *priv = dev->dev_private;

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 4fe2ab3..b33debc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -246,7 +246,7 @@ rockchip_atomic_commit_tail(struct drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
 }

-struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
+static struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
.atomic_commit_tail = rockchip_atomic_commit_tail,
 };

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6255e5b..e01c435 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -798,7 +798,7 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
.atomic_disable = vop_plane_atomic_disable,
 };

-void vop_atomic_plane_reset(struct drm_plane *plane)
+static void vop_atomic_plane_reset(struct drm_plane *plane)
 {
struct vop_plane_state *vop_plane_state =
to_vop_plane_state(plane->state);
@@ -815,7 +815,7 @@ void vop_atomic_plane_reset(struct drm_plane *plane)
plane->state->plane = plane;
 }

-struct drm_plane_state *
+static struct drm_plane_state *
 vop_atomic_plane_duplicate_state(struct drm_plane *plane)
 {
struct vop_plane_state *old_vop_plane_state;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..52661d1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -299,7 +299,7 @@ static int vop_remove(struct platform_device *pdev)
return 0;
 }

-struct platform_driver vop_platform_driver = {
+static struct platform_driver vop_platform_driver = {
.probe = vop_probe,
.remove = vop_remove,
.driver = {
-- 
1.9.1

[PATCH 2/6] drm/rockchip: fb: add missing header

[Mark Yao]

From: John Keeping 

This fixes the following sparse warnings:

drivers/gpu/drm/rockchip/rockchip_drm_fb.c:32:23: warning: symbol 
'rockchip_fb_get_gem_obj' was not declared. Should it be static?
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:315:24: warning: symbol 
'rockchip_drm_framebuffer_init' was not declared. Should it be static?
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:329:6: warning: symbol 
'rockchip_drm_mode_config_init' was not declared. Should it be static?

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..4fe2ab3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -20,6 +20,7 @@
 #include 

 #include "rockchip_drm_drv.h"
+#include "rockchip_drm_fb.h"
 #include "rockchip_drm_gem.h"

 #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
-- 
1.9.1

[PATCH 1/6] drm/rockchip: dw_hdmi: remove unused #include

[Mark Yao]

From: John Keeping 

drm_encoder_slave is not used in this file.

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 801110f..0665fb9 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include "rockchip_drm_drv.h"
-- 
1.9.1

[PATCH 0/6] drm/rockchip: some fixes

[Mark Yao]

Here are some fixes for drm/rockchip:

These following patches were sent to upstream, seems no doubt about them,
I just rebase them to newest Dave's branch and resent.
  drm/rockchip: vop: correct the source size of uv scale factor setting
  drm/rockchip: vop: add uv_vir register field for RK3036 VOP
  drm/rockchip: fix "should it be static?" warnings
  drm/rockchip: fb: add missing header
  drm/rockchip: dw_hdmi: remove unused #include

This patch is new one, only register rename
  drm/rockchip: vop: correct rk3036 register define

John Keeping (3):
  drm/rockchip: dw_hdmi: remove unused #include
  drm/rockchip: fb: add missing header
  drm/rockchip: fix "should it be static?" warnings

Mark Yao (2):
  drm/rockchip: vop: correct the source size of uv scale factor setting
  drm/rockchip: vop: correct rk3036 register define

Yakir Yang (1):
  drm/rockchip: vop: add uv_vir register field for RK3036 VOP

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 7 ---
 5 files changed, 11 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

[Sean Paul]

On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote:
> Alway enable the PSR function for Rockchip analogix_dp driver. If panel
> don't support PSR, then the core analogix_dp would ignore this setting.
> 
> Signed-off-by: Yakir Yang 

Reviewed-by: Sean Paul 

> ---
> Changes in v4:
> - Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
> - Pull the 10ms delay time out into a #define. (Sean)
> - Improved the code of analogix_dp_psr_work(). (Sean)
> - Indented with spaces for new numbers in rockchip_dp_device struct. 
> (Stéphane, reviewed at Google gerrit)
> 
> [https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>  at 83]
> 
> Changes in v3:
> - split the common psr logic into a seperate driver, make this to a
>   simple sub-psr device driver.
> 
> Changes in v2:
> - remove vblank notify out (Daniel)
> - create a psr_active() callback in vop data struct.
> 
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 57 
> +
>  1 file changed, 57 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index e81e19a..aa916f4 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -32,6 +32,7 @@
>  #include 
>  
>  #include "rockchip_drm_drv.h"
> +#include "rockchip_drm_psr.h"
>  #include "rockchip_drm_vop.h"
>  
>  #define RK3288_GRF_SOC_CON6  0x25c
> @@ -41,6 +42,9 @@
>  
>  #define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
>  
> +#define PSR_SET_DELAY_TIME   msecs_to_jiffies(10)
> +#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS100
> +
>  #define to_dp(nm)container_of(nm, struct rockchip_dp_device, nm)
>  
>  /**
> @@ -68,11 +72,55 @@ struct rockchip_dp_device {
>   struct regmap*grf;
>   struct reset_control *rst;
>  
> + struct delayed_work  psr_work;
> + unsigned int psr_state;
> +
>   const struct rockchip_dp_chip_data *data;
>  
>   struct analogix_dp_plat_data plat_data;
>  };
>  
> +static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
> +{
> + struct rockchip_dp_device *dp = to_dp(encoder);
> +
> + dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
> +
> + if (enabled)
> + dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
> + else
> + dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
> +
> + schedule_delayed_work(>psr_work, PSR_SET_DELAY_TIME);
> +}
> +
> +static void analogix_dp_psr_work(struct work_struct *work)
> +{
> + struct rockchip_dp_device *dp =
> + container_of(work, typeof(*dp), psr_work.work);
> + struct drm_crtc *crtc = dp->encoder.crtc;
> + int psr_state = dp->psr_state;
> + int vact_end;
> + int ret;
> +
> + if (!crtc)
> + return;
> +
> + vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + 
> crtc->mode.vdisplay;
> +
> + ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
> +   PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
> + if (ret) {
> + dev_err(dp->dev, "line flag interrupt did not arrive\n");
> + return;
> + }
> +
> + if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
> + analogix_dp_enable_psr(dp->dev);
> + else
> + analogix_dp_disable_psr(dp->dev);
> +}
> +
>  static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
>  {
>   reset_control_assert(dp->rst);
> @@ -340,12 +388,21 @@ static int rockchip_dp_bind(struct device *dev, struct 
> device *master,
>   dp->plat_data.power_off = rockchip_dp_powerdown;
>   dp->plat_data.get_modes = rockchip_dp_get_modes;
>  
> + dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
> + INIT_DELAYED_WORK(>psr_work, analogix_dp_psr_work);
> +
> + rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
> +
>   return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
>  }
>  
>  static void rockchip_dp_unbind(struct device *dev, struct device *master,
>  void *data)
>  {
> + struct rockchip_dp_device *dp = dev_get_drvdata(dev);
> +
> + rockchip_drm_psr_unregister(>encoder);
> +
>   return analogix_dp_unbind(dev, master, data);
>  }
>  
> -- 
> 1.9.1
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/4] drm/bridge: analogix_dp: add the PSR function support

[Sean Paul]

On Thu, Jul 14, 2016 at 12:15:53PM +0800, Yakir Yang wrote:
> The full name of PSR is Panel Self Refresh, panel device could refresh
> itself with the hardware framebuffer in panel, this would make lots of
> sense to save the power consumption.
> 
> This patch have exported two symbols for platform driver to implement
> the PSR function in hardware side:
> - analogix_dp_active_psr()
> - analogix_dp_inactive_psr()
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> - Downgrade the PSR version print message to debug level. (Sean)
> - Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
> - Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
> (Sean)
> - Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
> - Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
> - Rename "active/inactive" to "enable/disable". (Sean, Dominik)
> - Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().
> 
> Changes in v3:
> - split analogix_dp_enable_psr(), make it more clearly
> analogix_dp_detect_sink_psr()
> analogix_dp_enable_sink_psr()
> - remove some nosie register setting comments
> 
> Changes in v2:
> - introduce in v2, splite the common Analogix DP changes out
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 60 
> ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 49 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  | 28 ++
>  include/drm/bridge/analogix_dp.h   |  3 ++
>  5 files changed, 144 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 32715da..1fec91a 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -97,6 +97,62 @@ static int analogix_dp_detect_hpd(struct 
> analogix_dp_device *dp)
>   return 0;
>  }
>  
> +int analogix_dp_enable_psr(struct device *dev)
> +{
> + struct analogix_dp_device *dp = dev_get_drvdata(dev);
> +
> + if (!dp->psr_support)
> + return -EINVAL;
> +
> + analogix_dp_send_psr_spd(dp, EDP_VSC_PSR_STATE_ACTIVE |
> +  EDP_VSC_PSR_CRC_VALUES_VALID);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
> +
> +int analogix_dp_disable_psr(struct device *dev)
> +{
> + struct analogix_dp_device *dp = dev_get_drvdata(dev);
> +
> + if (!dp->psr_support)
> + return -EINVAL;
> +
> + analogix_dp_send_psr_spd(dp, 0);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
> +
> +static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
> +{
> + unsigned char psr_version;
> +
> + analogix_dp_read_byte_from_dpcd(dp, DP_PSR_SUPPORT, _version);
> + dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
> +
> + return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
> +}
> +
> +static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
> +{
> + unsigned char psr_en;
> +
> + /* Disable psr function */
> + analogix_dp_read_byte_from_dpcd(dp, DP_PSR_EN_CFG, _en);
> + psr_en &= ~DP_PSR_ENABLE;
> + analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
> +
> + /* Main-Link transmitter remains active during PSR active states */
> + psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
> + analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
> +
> + /* Enable psr function */
> + psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
> +  DP_PSR_CRC_VERIFICATION;
> + analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
> +
> + analogix_dp_enable_psr_crc(dp);
> +}
> +
>  static unsigned char analogix_dp_calc_edid_check_sum(unsigned char 
> *edid_data)
>  {
>   int i;
> @@ -921,6 +977,10 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>  
>   /* Enable video */
>   analogix_dp_start_video(dp);
> +
> + dp->psr_support = analogix_dp_detect_sink_psr(dp);
> + if (dp->psr_support)
> + analogix_dp_enable_sink_psr(dp);
>  }
>  
>  int analogix_dp_get_modes(struct drm_connector *connector)
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index b456380..6ca5dde 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -177,6 +177,7 @@ struct analogix_dp_device {
>   int hpd_gpio;
>   boolforce_hpd;
>   unsigned char   edid[EDID_BLOCK_LENGTH * 2];
> + boolpsr_support;
>  
>   struct analogix_dp_plat_data *plat_data;
>  };
> @@ -278,4 +279,7 @@ int analogix_dp_is_video_stream_on(struct 
> 

[PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

[Sean Paul]

On Thu, Jul 14, 2016 at 12:15:49PM +0800, Yakir Yang wrote:
> The PSR driver have exported four symbols for specific device driver:
> - rockchip_drm_psr_register()
> - rockchip_drm_psr_unregister()
> - rockchip_drm_psr_enable()
> - rockchip_drm_psr_disable()
> - rockchip_drm_psr_flush()
> 
> Encoder driver should call the register/unregister interfaces to hook
> itself into common PSR driver, encoder have implement the 'psr_set'
> callback which use the set PSR state in hardware side.
> 
> Crtc driver would call the enable/disable interfaces when vblank is
> enable/disable, after that the common PSR driver would call the encoder
> registered callback to set the PSR state.
> 
> Fb driver would call the flush interface in 'fb->dirty' callback, this
> helper function would force all PSR enabled encoders to exit from PSR
> for 3 seconds.
> 
> Signed-off-by: Yakir Yang 


I still don't think it's a good idea to pull this out into a separate PSR
driver, but I suppose we can integrate it at a later time if it becomes
cumbersome.

Reviewed-by: Sean Paul 


> ---
> Changes in v4:
> - Tuck the global "psr_list" & "psr_list_mutex" in struct 
> rockchip_drm_private. (Sean)
> - Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
> - Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
> - Collect psr_enable() and psr_disable() into psr_set_state()
> - s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
> - Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in 
> Google gerrit)
> 
> [https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>  at 475]
> - Add the missing file head with license. (Stéphane, reviewed in Google 
> gerrit)
> 
> [https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
>  at 3]
> 
> Changes in v3:
> - split the psr flow into an common abstracted PSR driver
> - implement the 'fb->dirty' callback function (Daniel)
> - avoid to use notify to acqiure for vact event (Daniel)
> - remove psr_active() callback which introduce in v2
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/Makefile   |   2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   4 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  12 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 223 
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  26 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  29 
>  7 files changed, 298 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h
> 
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index 05d0713..9746365 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -3,7 +3,7 @@
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
>  rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> - rockchip_drm_gem.o rockchip_drm_vop.o
> + rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
>  obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index d665fb0..26c12b3 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -156,6 +156,9 @@ static int rockchip_drm_bind(struct device *dev)
>  
>   drm_dev->dev_private = private;
>  
> + INIT_LIST_HEAD(>psr_list);
> + mutex_init(>psr_list_mutex);
> +
>   drm_mode_config_init(drm_dev);
>  
>   rockchip_drm_mode_config_init(drm_dev);
> @@ -218,6 +221,7 @@ static int rockchip_drm_bind(struct device *dev)
>  
>   if (is_support_iommu)
>   arm_iommu_release_mapping(mapping);
> +
>   return 0;
>  err_fbdev_fini:
>   rockchip_drm_fbdev_fini(drm_dev);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index 239b830..9c34c9e 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -61,6 +61,9 @@ struct rockchip_drm_private {
>   struct drm_gem_object *fbdev_bo;
>   const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
>   struct drm_atomic_state *state;
> +
> + struct list_head psr_list;
> + struct mutex psr_list_mutex;
>  };
>  
>  int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 20f12bc..36afd9c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -21,6 +21,7 @@
>  
>  

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > > vGEM buffers are useful for passing data between software clients and
> > > hardware renders. By allowing the user to create and attach fences to
> > > the exported vGEM buffers (on the dma-buf), the user can implement a
> > > deferred renderer and queue hardware operations like flipping and then
> > > signal the buffer readiness (i.e. this allows the user to schedule
> > > operations out-of-order, but have them complete in-order).
> > > 
> > > This also makes it much easier to write tightly controlled testcases for
> > > dma-buf fencing and signaling between hardware drivers.
> > > 
> > > v2: Don't pretend the fences exist in an ordered timeline, but allocate
> > > a separate fence-context for each fence so that the fences are
> > > unordered.
> > > v3: Make the debug output more interesting, and so the signaled status.
> > > 
> > > Testcase: igt/vgem_basic/dmabuf-fence
> > > Signed-off-by: Chris Wilson 
> > > Cc: Sean Paul 
> > > Cc: Zach Reizner 
> > > Cc: Gustavo Padovan 
> > > Cc: Daniel Vetter 
> > > Acked-by: Zach Reizner 
> > 
> > One thing I completely forgotten: This allows userspace to hang kernel
> > drivers. i915 (and other gpu drivers) can recover using hangcheck, but
> > dumber drivers (v4l, if that ever happens) probably never except such a
> > case. We've had a similar discusion with the userspace fences exposed in
> > sw_fence, and decided to move all those ioctl into debugfs. I think we
> > should do the same for this vgem-based debugging of implicit sync. Sorry
> > for realizing this this late.
> 
> One of the very tests I make is to ensure that we recover from such a
> hang. I don't see the difference between this any of the other ways
> userspace can shoot itself (and others) in the foot.

So one solution would be to make vgem fences automatically timeout (with
a flag for root to override for the sake of testing hang detection).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[v5 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Hi Sean

Thanks for your detailed review. I'm working to modify most of code 
according to comment.
And there is reply for some comment

On 07/13/2016 09:59 PM, Sean Paul wrote:
> On Tue, Jul 12, 2016 at 8:09 AM, Chris Zhong  wrote:
>> Add support for cdn DP controller which is embedded in the rk3399
>> SoCs. The DP is compliant with DisplayPort Specification,
>> Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
>> There is a uCPU in DP controller, it need a firmware to work,
>> please put the firmware file to /lib/firmware/cdn/dptx.bin. The
>> uCPU in charge of aux communication and link training, the host use
>> mailbox to communicate with the ucpu.
>> The dclk pin_pol of vop must not be invert for DP.
>>
>> Signed-off-by: Chris Zhong 
>>
>> ---
>>
>> Changes in v5:
>> - alphabetical order
>> - do not use long, use u32 or u64
>> - return MODE_CLOCK_HIGH when requested > actual
>> - Optimized Coding Style
>> - add a formula to get better tu size and symbol value.
>>
>> Changes in v4:
>> - use phy framework to control DP phy
>> - support 2 phys
>>
>> Changes in v3:
>> - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
>> - reset spdif before config it
>> - modify the firmware clk to 100Mhz
>> - retry load firmware if fw file is requested too early
>>
>> Changes in v2:
>> - Alphabetic order
>> - remove excess error message
>> - use define clk_rate
>> - check all return value
>> - remove dev_set_name(dp->dev, "cdn-dp");
>> - use schedule_delayed_work
>> - remove never-called functions
>> - remove some unnecessary ()
>>
>> Changes in v1:
>> - use extcon API
>> - use hdmi-codec for the DP Asoc
>> - do not initialize the "ret"
>> - printk a err log when drm_of_encoder_active_endpoint_id
>> - modify the dclk pin_pol to a single line
>>
>>   drivers/gpu/drm/rockchip/Kconfig|   9 +
>>   drivers/gpu/drm/rockchip/Makefile   |   1 +
>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  | 761 
>> 
>>   drivers/gpu/drm/rockchip/cdn-dp-core.h  | 113 +
>>   drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 740 
>> +++
>>   drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 409 +++
> Could you explain the file naming convention in the rk driver? We've
> got analogix_dp-rockchip.c, dw_hdmi-rockchip.c, dw-mipi-dsi.c, and now
> cdn-dp-(core|reg).[ch]. I'm honestly not sure whether these filenames
> are consistent with the rest, but bleh.
>
cdn is the IP vendor's name
dp is the controller's name.

>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
>>   9 files changed, 2042 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
>>
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
>> b/drivers/gpu/drm/rockchip/Kconfig
>> index d30bdc3..20da9a8 100644
>> --- a/drivers/gpu/drm/rockchip/Kconfig
>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>> @@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
>>for the Analogix Core DP driver. If you want to enable DP
>>on RK3288 based SoC, you should selet this option.
>>
>> +config ROCKCHIP_CDN_DP
>> +tristate "Rockchip cdn DP"
>> +depends on DRM_ROCKCHIP
>> +help
>> + This selects support for Rockchip SoC specific extensions
>> + for the cdn Dp driver. If you want to enable Dp on
> s/Dp/DP/
>
>> + RK3399 based SoC, you should selet this
> s/selet/select/
>
>> + option.
>> +
>>   config ROCKCHIP_DW_HDMI
>>   tristate "Rockchip specific extensions for Synopsys DW HDMI"
>>   depends on DRM_ROCKCHIP
>> diff --git a/drivers/gpu/drm/rockchip/Makefile 
>> b/drivers/gpu/drm/rockchip/Makefile
>> index 05d0713..abdecd5 100644
>> --- a/drivers/gpu/drm/rockchip/Makefile
>> +++ b/drivers/gpu/drm/rockchip/Makefile
>> @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>>   rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>>
>>   obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
>> +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
>>   obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>>   obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>>   obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
>> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> new file mode 100644
>> index 000..5b8a15e
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> @@ -0,0 +1,761 @@
>> +/*
>> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
>> + * Author: Chris Zhong 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * 

[PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> > the exported vGEM buffers (on the dma-buf), the user can implement a
> > deferred renderer and queue hardware operations like flipping and then
> > signal the buffer readiness (i.e. this allows the user to schedule
> > operations out-of-order, but have them complete in-order).
> > 
> > This also makes it much easier to write tightly controlled testcases for
> > dma-buf fencing and signaling between hardware drivers.
> > 
> > v2: Don't pretend the fences exist in an ordered timeline, but allocate
> > a separate fence-context for each fence so that the fences are
> > unordered.
> > v3: Make the debug output more interesting, and so the signaled status.
> > 
> > Testcase: igt/vgem_basic/dmabuf-fence
> > Signed-off-by: Chris Wilson 
> > Cc: Sean Paul 
> > Cc: Zach Reizner 
> > Cc: Gustavo Padovan 
> > Cc: Daniel Vetter 
> > Acked-by: Zach Reizner 
> 
> One thing I completely forgotten: This allows userspace to hang kernel
> drivers. i915 (and other gpu drivers) can recover using hangcheck, but
> dumber drivers (v4l, if that ever happens) probably never except such a
> case. We've had a similar discusion with the userspace fences exposed in
> sw_fence, and decided to move all those ioctl into debugfs. I think we
> should do the same for this vgem-based debugging of implicit sync. Sorry
> for realizing this this late.

One of the very tests I make is to ensure that we recover from such a
hang. I don't see the difference between this any of the other ways
userspace can shoot itself (and others) in the foot.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v4 1/4] drm/rockchip: vop: export line flag function

[Sean Paul]

On Thu, Jul 14, 2016 at 12:15:44PM +0800, Yakir Yang wrote:
> VOP have integrated a hardware counter which indicate the exact display
> line that vop is scanning. And if we're interested in a specific line,
> we can set the line number to vop line_flag register, and then vop would
> generate a line_flag interrupt for it.
> 
> For example eDP PSR function is interested in the vertical blanking
> period, then driver could set the line number to zero.
> 
> This patch have exported a symbol that allow other driver to listen the
> line flag event with given timeout limit:
> -  rockchip_drm_wait_line_flag()
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> - Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
> - Make line_flag_num_x to an array. (Sean)
> - Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
> reviewed in Google gerrit)
> 
> [https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>  at 466]
> 
> Changes in v3:
> - Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
> - Add 'line_flag_num_0' for RK3288/RK3036
> - Remove the notify for waiting line_flag event (Daniel)
> 
> Changes in v2:
> - Introduce in v2, split VOP line flag changes out
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 118 
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   4 +
>  4 files changed, 127 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index ea39329..239b830 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -70,4 +70,7 @@ int rockchip_drm_dma_attach_device(struct drm_device 
> *drm_dev,
>  struct device *dev);
>  void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
>   struct device *dev);
> +int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
> + unsigned int mstimeout);
> +
>  #endif /* _ROCKCHIP_DRM_DRV_H_ */
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index c8a62a8..69d32f1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -121,6 +121,8 @@ struct vop {
>   /* protected by dev->event_lock */
>   struct drm_pending_vblank_event *event;
>  
> + struct completion line_flag_completion;
> +
>   const struct vop_data *data;
>  
>   uint32_t *regsbak;
> @@ -431,6 +433,71 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
> *vop)
>   spin_unlock_irqrestore(>irq_lock, flags);
>  }
>  
> +/*
> + * (1) each frame starts at the start of the Vsync pulse which is signaled by
> + * the "FRAME_SYNC" interrupt.
> + * (2) the active data region of each frame ends at dsp_vact_end
> + * (3) we should program this same number (dsp_vact_end) into 
> dsp_line_frag_num,
> + *  to get "LINE_FLAG" interrupt at the end of the active on screen data.
> + *
> + * VOP_INTR_CTRL0.dsp_line_frag_num = VOP_DSP_VACT_ST_END.dsp_vact_end
> + * Interrupts
> + * LINE_FLAG ---+
> + * FRAME_SYNC + |
> + *| |
> + *v v
> + *| Vsync | Vbp |  Vactive  | Vfp |
> + *^ ^   ^ ^
> + *| |   | |
> + *| |   | |
> + * dsp_vs_end + |   | |   VOP_DSP_VTOTAL_VS_END
> + * dsp_vact_start --+   | |   VOP_DSP_VACT_ST_END
> + * dsp_vact_end + |   VOP_DSP_VACT_ST_END
> + * dsp_total -+   VOP_DSP_VTOTAL_VS_END
> + */
> +static bool vop_line_flag_irq_is_enabled(struct vop *vop)
> +{
> + uint32_t line_flag_irq;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>irq_lock, flags);
> +
> + line_flag_irq = VOP_INTR_GET_TYPE(vop, enable, LINE_FLAG_INTR);
> +
> + spin_unlock_irqrestore(>irq_lock, flags);
> +
> + return !!line_flag_irq;
> +}
> +
> +static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
> +{
> + unsigned long flags;
> +
> + if (WARN_ON(!vop->is_enabled))
> + return;
> +
> + spin_lock_irqsave(>irq_lock, flags);
> +
> + VOP_CTRL_SET(vop, line_flag_num[0], line_num);
> + VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
> +
> + spin_unlock_irqrestore(>irq_lock, flags);
> +}
> +
> +static void vop_line_flag_irq_disable(struct vop *vop)
> +{
> + unsigned long flags;
> +
> + if (WARN_ON(!vop->is_enabled))
> + 

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

I recovered dri-devel backlog from my vacation, more misc stuff:
- of_put_node fixes from Peter Chen (not all yet)
- more patches from Gustavo to use kms-native drm_crtc_vblank_* funcs
- docs sphinxification from Lukas Wunner
- bunch of fixes all over from Dan Carpenter
- more follow up work from Chris register/unregister rework in various
  places
- vgem dma-buf export (for writing testcases)
- small things all over from tons of different people

This is just the delta against the previous pull request, pls take them
both.

Cheers, Daniel


The following changes since commit 2a3467063ae3b17264578626dec2377dd48cd1c3:

  Merge tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2016-06-24 13:16:07 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-07-14

for you to fetch changes up to 01d3434a565ada5ca084c68ec1e087ada5a7b157:

  drm: Don't overwrite user ioctl arg unless requested (2016-07-14 10:12:50 
+0200)


Alexey Khoroshilov (1):
  drm_aux-dev: fix error handling in drm_dp_aux_dev_init()

Benjamin Herrenschmidt (1):
  drm: Fix broken use of _PAGE_NO_CACHE on powerpc

Bhaktipriya Shridhar (1):
  drm/qxl: Remove deprecated create_singlethread_workqueue

Chris Wilson (8):
  drm/vgem: Fix mmaping
  drm/vgem: Enable dmabuf interface for export
  drm: Unexport drm_connector_register_all()
  drm: Do a full device unregister when unplugging
  drm/udl: Unplugging a device now unregisters it
  drm: Restore double clflush on the last partial cacheline
  drm/vgem: Use PAGE_KERNEL in place of x86-specific PAGE_KERNEL_IO
  drm: Don't overwrite user ioctl arg unless requested

Dan Carpenter (3):
  drm/mediatek/mtk_mipi_tx: checking the wrong variable
  qxl: check for kmap failures
  qxl: silence uninitialized variable warning

Daniel Vetter (1):
  drm: Resurrect atomic rmfb code

Frank Binns (2):
  drm: fix some spelling mistakes
  drm/vmwgfx: Stop checking minor type directly

Gustavo Padovan (8):
  drm: make drm_vblank_count_and_time() static
  drm/armada: use drm_crtc_handle_vblank()
  drm/atmel: use drm_crtc_handle_vblank()
  drm/nouveau: use drm_crtc_handle_vblank()
  drm/rcar-du: use drm_crtc_handle_vblank()
  drm/tilcdc: use drm_crtc_handle_vblank()
  MAINTAINERS: add entry for the Sync File Framework
  dma-buf/sync_file: improve Kconfig description for Sync Files

Lukas Wunner (16):
  drm/nouveau: Don't leak runtime pm ref on driver unload
  drm/nouveau: Forbid runtime pm on driver unload
  drm/radeon: Don't leak runtime pm ref on driver unload
  drm/radeon: Don't leak runtime pm ref on driver load
  drm/radeon: Forbid runtime pm on driver unload
  drm/amdgpu: Don't leak runtime pm ref on driver unload
  drm/amdgpu: Don't leak runtime pm ref on driver load
  drm/amdgpu: Forbid runtime pm on driver unload
  drm: Add helpers to turn off CRTCs
  drm/nouveau: Turn off CRTCs on driver unload
  drm/radeon: Turn off CRTCs on driver unload
  drm/amdgpu: Turn off CRTCs on driver unload
  drm: Use helper to turn off CRTC
  drm/i2c/ch7006: Use helper to turn off CRTC
  drm/nouveau/dispnv04: Use helper to turn off CRTC
  vga_switcheroo: Sphinxify docs

Masanari Iida (1):
  drm: Fix a typo in drm_ioctl.c

Michel Dänzer (1):
  drm: Only handle _DRM_VBLANK_NEXTONMISS once

Peter Chen (5):
  gpu: drm: sti_compositor: add missing of_node_put after calling 
of_parse_phandle
  gpu: drm: sti_vdo: add missing of_node_put after calling of_parse_phandle
  gpu: drm: sti_hqvdp: add missing of_node_put after calling 
of_parse_phandle
  gpu: drm: sti_vtg: add missing of_node_put after calling of_parse_phandle
  gpu: drm: rockchip_drm_drv: add missing of_node_put after calling 
of_parse_phandle

Thierry Reding (2):
  drm/qxl: Remove dead code
  drm/dsi: Make set_tear_scanline command consistent

Tobias Jakobi (1):
  drm/exynos: make fbdev support really optional

Xinliang Liu (1):
  drm/hisilicon: Fix ADE vblank on/off handling

 Documentation/gpu/drm-internals.rst |   4 +-
 Documentation/gpu/vga-switcheroo.rst|   8 +-
 MAINTAINERS |  11 ++
 drivers/dma-buf/Kconfig |  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  12 +-
 drivers/gpu/drm/armada/armada_crtc.c|   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |   2 +-
 drivers/gpu/drm/drm_atomic.c|  66 +++
 drivers/gpu/drm/drm_cache.c |   1 +
 drivers/gpu/drm/drm_crtc.c  |  78 +---
 drivers/gpu/drm/drm_crtc_internal.h |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c

[Bug 115011] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller

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

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

Hans de Goede  changed:

   What|Removed |Added

 CC||jwrdegoede at fedoraproject.or
   ||g

--- Comment #12 from Hans de Goede  ---
Hi Alex,

(In reply to Alex Deucher from comment #10)
> (In reply to Luya Tshimbalanga from comment #7)
> > Created attachment 210281 [details]
> > dmesg with 4.6.0-0.rc0.git13.1
> > 
> > dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> > 
> > [7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> > backlight controller
> 
> This message is harmless.  Your laptop has two GPUs.  The ATIF ACPI method
> is used to notify the driver of backlight change events so the driver checks
> to see if it exists.  Depending on the board configuration, the secondary
> GPU may or may not have access to the backlight controller.  In this case it
> does not.

Mayebe we need to make the error a bit less scary then, e.g. :

 [drm:radeon_acpi_init [radeon]] *Warning* Cannot find a backlight controller,
this is ussualy harmless on dual gpu systems

Yes it is a bit long, but it will likely help to avoid future bug reports about
this.

Regards,

Hans

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

[patch] drm/rockchip: fix a couple off by one bugs

[Mark yao]

On 2016年07月13日 18:15, Dan Carpenter wrote:
> The priv->crtc_funcs[] array has ROCKCHIP_MAX_CRTC elements so > should
> be >= here.
>
> Fixes: 2048e3286f34 ('drm: rockchip: Add basic drm driver')
> Signed-off-by: Dan Carpenter 

Thanks for the fix, applied to my drm-fixes.

> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 7fd20c0..37ca427 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -79,7 +79,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
>   int pipe = drm_crtc_index(crtc);
>   struct rockchip_drm_private *priv = crtc->dev->dev_private;
>   
> - if (pipe > ROCKCHIP_MAX_CRTC)
> + if (pipe >= ROCKCHIP_MAX_CRTC)
>   return -EINVAL;
>   
>   priv->crtc_funcs[pipe] = crtc_funcs;
> @@ -92,7 +92,7 @@ void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
>   int pipe = drm_crtc_index(crtc);
>   struct rockchip_drm_private *priv = crtc->dev->dev_private;
>   
> - if (pipe > ROCKCHIP_MAX_CRTC)
> + if (pipe >= ROCKCHIP_MAX_CRTC)
>   return;
>   
>   priv->crtc_funcs[pipe] = NULL;
>
>
>


-- 
ï¼­ark Yao

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2016-07-11:
- select igt testing depencies for CONFIG_DRM_I915_DEBUG (Chris)
- track outputs in crtc state and clean up all our ad-hoc connector/encoder
  walking in modest code (Ville)
- demidlayer drm_device/drm_i915_private (Chris Wilson)
- thundering herd fix from Chris Wilson, with lots of help from Tvrtko Ursulin
- piles of assorted clean and fallout from the thundering herd fix
- documentation and more tuning for waitboosting (Chris)
- pooled EU support on bxt (Arun Siluvery)
- bxt support is no longer considered prelimary!
- ring/engine vfunc cleanup from Tvrtko
- introduce intel_wait_for_register helper (Chris)
- opregion updates (Jani Nukla)
- tuning and fixes for wait_for macros (Tvrkto)
- more kabylake pci ids (Rodrigo)
- pps cleanup and fixes for bxt (Imre)
- move sink crc support over to atomic state (Maarten)
- fix up async fbdev init ordering (Chris)
- fbc fixes from Paulo and Chris

Final feature pull request for 4.8.

Cheers, Daniel


The following changes since commit 2a3467063ae3b17264578626dec2377dd48cd1c3:

  Merge tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2016-06-24 13:16:07 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-07-11

for you to fetch changes up to 0b2c0582f1570bfc95aa9ac1cd340a215d8e8335:

  drm/i915: Update DRIVER_DATE to 20160711 (2016-07-11 09:18:31 +0200)


- select igt testing depencies for CONFIG_DRM_I915_DEBUG (Chris)
- track outputs in crtc state and clean up all our ad-hoc connector/encoder
  walking in modest code (Ville)
- demidlayer drm_device/drm_i915_private (Chris Wilson)
- thundering herd fix from Chris Wilson, with lots of help from Tvrtko Ursulin
- piles of assorted clean and fallout from the thundering herd fix
- documentation and more tuning for waitboosting (Chris)
- pooled EU support on bxt (Arun Siluvery)
- bxt support is no longer considered prelimary!
- ring/engine vfunc cleanup from Tvrtko
- introduce intel_wait_for_register helper (Chris)
- opregion updates (Jani Nukla)
- tuning and fixes for wait_for macros (Tvrkto)
- more kabylake pci ids (Rodrigo)
- pps cleanup and fixes for bxt (Imre)
- move sink crc support over to atomic state (Maarten)
- fix up async fbdev init ordering (Chris)
- fbc fixes from Paulo and Chris


Chris Wilson (149):
  drm/i915: Extract checking for backing struct pages to a helper
  drm/i915: pwrite/pread do not require obj->base.filp, just pages
  drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps
  drm/i915/fbdev: Perform async fbdev initialisation much later
  drm/i915/fbdev: Limit the global async-domain synchronization
  drm/i915/fbdev: Flush mode configuration before lastclose
  drm/i915/gvt: Mark i915.enable_gvt as false if loading fails
  drm/i915: Move panel's backlight setup next to panel init
  drm/i915: Move registration actions to connector->late_register
  drm/i915: Move backlight registration to connector registration
  drm/i915: Move connector registration to driver registration
  drm/i915: Register debugfs interface last
  drm/i915: Demidlayer driver loading
  drm/i915: Demidlayer driver unloading
  drm/i915: Remove redundant drm_connector_register_all()
  drm/i915: Start exploiting drm_device subclassing
  drm/i915: Merge i915_dma.c into i915_drv.c
  drm/i915: Remove user controllable DRM_ERROR for i915_getparam()
  drm/i915: Remove user controllable DRM_ERROR for 
intel_get_pipe_from_crtc_id()
  drm/i915: Split out the PCI driver interface to i915_pci.c
  drm/i915: Move module init/exit to i915_pci.c
  drm/i915: Skip idling an idle engine
  drm/i915: Move legacy kernel context pinning to intel_ringbuffer.c
  drm/i915: Treat kernel context as initialised
  drm/i915: Mark all default contexts as uninitialised after context loss
  drm/i915: No need to wait for idle on L3 remap
  drm/i915: Split idling from forcing context switch
  drm/i915: Only switch to default context when evicting from GGTT
  drm/i915: Remove request->reset_counter
  Revert "drm/i915: Use atomic commits for legacy page_flips"
  drm/i915: Use a hybrid scheme for fast register waits
  drm/i915: Convert sandybridge_pcode_*() to use intel_wait_for_register()
  drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
  drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
  drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
  drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
  drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
  drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()
  drm/i915: 

[PATCH] drm: Don't overwrite user ioctl arg unless requested

[Daniel Vetter]

On Thu, Jul 14, 2016 at 09:46:24AM +0200, Christian König wrote:
> Am 12.07.2016 um 16:59 schrieb Chris Wilson:
> > Currently, we completely ignore the user when it comes to the in/out
> > direction of the ioctl argument, as we simply cannot trust userspace.
> > (For example, they might request a copy of the modified ioctl argument
> > when the driver is not expecting such and so leak kernel stack.)
> > However, blindly copying over the target address may also lead to a
> > spurious EFAULT, and a failure after the ioctl was completed
> > successfully. This is important in order to avoid an ABI break when
> > extending an ioctl from IOR to IORW. Similar to how we only copy the
> > intersection of the kernel arg size and the user arg size, we only want
> > to copy back the kernel arg data iff both the kernel and userspace
> > request the copy.
> > 
> > Signed-off-by: Chris Wilson 
> 
> Seems to make a lot of sense to me, patch is Reviewed-by: Christian König
> 

Applied to drm-misc, thanks.
-Daniel

> 
> Regards,
> Christian.
> 
> > ---
> >   drivers/gpu/drm/drm_ioctl.c | 50 
> > -
> >   1 file changed, 22 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 2c87c1df0910..33af4a5ddca1 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -648,7 +648,7 @@ long drm_ioctl(struct file *filp,
> > int retcode = -EINVAL;
> > char stack_kdata[128];
> > char *kdata = NULL;
> > -   unsigned int usize, asize, drv_size;
> > +   unsigned int in_size, out_size, drv_size, ksize;
> > bool is_driver_ioctl;
> > dev = file_priv->minor->dev;
> > @@ -671,9 +671,12 @@ long drm_ioctl(struct file *filp,
> > }
> > drv_size = _IOC_SIZE(ioctl->cmd);
> > -   usize = _IOC_SIZE(cmd);
> > -   asize = max(usize, drv_size);
> > -   cmd = ioctl->cmd;
> > +   out_size = in_size = _IOC_SIZE(cmd);
> > +   if ((cmd & ioctl->cmd & IOC_IN) == 0)
> > +   in_size = 0;
> > +   if ((cmd & ioctl->cmd & IOC_OUT) == 0)
> > +   out_size = 0;
> > +   ksize = max(max(in_size, out_size), drv_size);
> > DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
> >   task_pid_nr(current),
> > @@ -693,30 +696,24 @@ long drm_ioctl(struct file *filp,
> > if (unlikely(retcode))
> > goto err_i1;
> > -   if (cmd & (IOC_IN | IOC_OUT)) {
> > -   if (asize <= sizeof(stack_kdata)) {
> > -   kdata = stack_kdata;
> > -   } else {
> > -   kdata = kmalloc(asize, GFP_KERNEL);
> > -   if (!kdata) {
> > -   retcode = -ENOMEM;
> > -   goto err_i1;
> > -   }
> > +   if (ksize <= sizeof(stack_kdata)) {
> > +   kdata = stack_kdata;
> > +   } else {
> > +   kdata = kmalloc(ksize, GFP_KERNEL);
> > +   if (!kdata) {
> > +   retcode = -ENOMEM;
> > +   goto err_i1;
> > }
> > -   if (asize > usize)
> > -   memset(kdata + usize, 0, asize - usize);
> > }
> > -   if (cmd & IOC_IN) {
> > -   if (copy_from_user(kdata, (void __user *)arg,
> > -  usize) != 0) {
> > -   retcode = -EFAULT;
> > -   goto err_i1;
> > -   }
> > -   } else if (cmd & IOC_OUT) {
> > -   memset(kdata, 0, usize);
> > +   if (copy_from_user(kdata, (void __user *)arg, in_size) != 0) {
> > +   retcode = -EFAULT;
> > +   goto err_i1;
> > }
> > +   if (ksize > in_size)
> > +   memset(kdata + in_size, 0, ksize - in_size);
> > +
> > /* Enforce sane locking for kms driver ioctls. Core ioctls are
> >  * too messy still. */
> > if ((drm_core_check_feature(dev, DRIVER_MODESET) && is_driver_ioctl) ||
> > @@ -728,11 +725,8 @@ long drm_ioctl(struct file *filp,
> > mutex_unlock(_global_mutex);
> > }
> > -   if (cmd & IOC_OUT) {
> > -   if (copy_to_user((void __user *)arg, kdata,
> > -usize) != 0)
> > -   retcode = -EFAULT;
> > -   }
> > +   if (copy_to_user((void __user *)arg, kdata, out_size) != 0)
> > +   retcode = -EFAULT;
> > err_i1:
> > if (!ioctl)
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Daniel Vetter]

On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> deferred renderer and queue hardware operations like flipping and then
> signal the buffer readiness (i.e. this allows the user to schedule
> operations out-of-order, but have them complete in-order).
> 
> This also makes it much easier to write tightly controlled testcases for
> dma-buf fencing and signaling between hardware drivers.
> 
> v2: Don't pretend the fences exist in an ordered timeline, but allocate
> a separate fence-context for each fence so that the fences are
> unordered.
> v3: Make the debug output more interesting, and so the signaled status.
> 
> Testcase: igt/vgem_basic/dmabuf-fence
> Signed-off-by: Chris Wilson 
> Cc: Sean Paul 
> Cc: Zach Reizner 
> Cc: Gustavo Padovan 
> Cc: Daniel Vetter 
> Acked-by: Zach Reizner 

One thing I completely forgotten: This allows userspace to hang kernel
drivers. i915 (and other gpu drivers) can recover using hangcheck, but
dumber drivers (v4l, if that ever happens) probably never except such a
case. We've had a similar discusion with the userspace fences exposed in
sw_fence, and decided to move all those ioctl into debugfs. I think we
should do the same for this vgem-based debugging of implicit sync. Sorry
for realizing this this late.
-Daniel

> ---
>  drivers/gpu/drm/vgem/Makefile |   2 +-
>  drivers/gpu/drm/vgem/vgem_drv.c   |  34 +++
>  drivers/gpu/drm/vgem/vgem_drv.h   |  16 +++
>  drivers/gpu/drm/vgem/vgem_fence.c | 207 
> ++
>  include/uapi/drm/vgem_drm.h   |  62 
>  5 files changed, 320 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
>  create mode 100644 include/uapi/drm/vgem_drm.h
> 
> diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
> index 3f4c7b842028..bfcdea1330e6 100644
> --- a/drivers/gpu/drm/vgem/Makefile
> +++ b/drivers/gpu/drm/vgem/Makefile
> @@ -1,4 +1,4 @@
>  ccflags-y := -Iinclude/drm
> -vgem-y := vgem_drv.o
> +vgem-y := vgem_drv.o vgem_fence.o
>  
>  obj-$(CONFIG_DRM_VGEM)   += vgem.o
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 29c2aab3c1a7..c15bafb06665 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -83,6 +83,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops = 
> {
>   .close = drm_gem_vm_close,
>  };
>  
> +static int vgem_open(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vgem_file *vfile;
> + int ret;
> +
> + vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
> + if (!vfile)
> + return -ENOMEM;
> +
> + file->driver_priv = vfile;
> +
> + ret = vgem_fence_open(vfile);
> + if (ret) {
> + kfree(vfile);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vgem_file *vfile = file->driver_priv;
> +
> + vgem_fence_close(vfile);
> + kfree(vfile);
> +}
> +
>  /* ioctls */
>  
>  static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> @@ -164,6 +192,8 @@ unref:
>  }
>  
>  static struct drm_ioctl_desc vgem_ioctls[] = {
> + DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>  };
>  
>  static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
> @@ -271,9 +301,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>  
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_PRIME,
> + .open   = vgem_open,
> + .preclose   = vgem_preclose,
>   .gem_free_object_unlocked   = vgem_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
>   .ioctls = vgem_ioctls,
> + .num_ioctls = ARRAY_SIZE(vgem_ioctls),
>   .fops   = _driver_fops,
>  
>   .dumb_create= vgem_gem_dumb_create,
> @@ -328,5 +361,6 @@ module_init(vgem_init);
>  module_exit(vgem_exit);
>  
>  MODULE_AUTHOR("Red Hat, Inc.");
> +MODULE_AUTHOR("Intel Corporation");
>  MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_LICENSE("GPL and additional rights");
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
> index 988cbaae7588..1f8798ad329c 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.h
> +++ b/drivers/gpu/drm/vgem/vgem_drv.h
> @@ -32,9 +32,25 @@
>  #include 
>  #include 
>  
> +#include 
> +
> +struct vgem_file {
> + struct idr fence_idr;
> + struct mutex fence_mutex;
> 

[PATCH] drm: Don't overwrite user ioctl arg unless requested

[Christian König]

Am 12.07.2016 um 16:59 schrieb Chris Wilson:
> Currently, we completely ignore the user when it comes to the in/out
> direction of the ioctl argument, as we simply cannot trust userspace.
> (For example, they might request a copy of the modified ioctl argument
> when the driver is not expecting such and so leak kernel stack.)
> However, blindly copying over the target address may also lead to a
> spurious EFAULT, and a failure after the ioctl was completed
> successfully. This is important in order to avoid an ABI break when
> extending an ioctl from IOR to IORW. Similar to how we only copy the
> intersection of the kernel arg size and the user arg size, we only want
> to copy back the kernel arg data iff both the kernel and userspace
> request the copy.
>
> Signed-off-by: Chris Wilson 

Seems to make a lot of sense to me, patch is Reviewed-by: Christian 
König 

Regards,
Christian.

> ---
>   drivers/gpu/drm/drm_ioctl.c | 50 
> -
>   1 file changed, 22 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 2c87c1df0910..33af4a5ddca1 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -648,7 +648,7 @@ long drm_ioctl(struct file *filp,
>   int retcode = -EINVAL;
>   char stack_kdata[128];
>   char *kdata = NULL;
> - unsigned int usize, asize, drv_size;
> + unsigned int in_size, out_size, drv_size, ksize;
>   bool is_driver_ioctl;
>   
>   dev = file_priv->minor->dev;
> @@ -671,9 +671,12 @@ long drm_ioctl(struct file *filp,
>   }
>   
>   drv_size = _IOC_SIZE(ioctl->cmd);
> - usize = _IOC_SIZE(cmd);
> - asize = max(usize, drv_size);
> - cmd = ioctl->cmd;
> + out_size = in_size = _IOC_SIZE(cmd);
> + if ((cmd & ioctl->cmd & IOC_IN) == 0)
> + in_size = 0;
> + if ((cmd & ioctl->cmd & IOC_OUT) == 0)
> + out_size = 0;
> + ksize = max(max(in_size, out_size), drv_size);
>   
>   DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
> task_pid_nr(current),
> @@ -693,30 +696,24 @@ long drm_ioctl(struct file *filp,
>   if (unlikely(retcode))
>   goto err_i1;
>   
> - if (cmd & (IOC_IN | IOC_OUT)) {
> - if (asize <= sizeof(stack_kdata)) {
> - kdata = stack_kdata;
> - } else {
> - kdata = kmalloc(asize, GFP_KERNEL);
> - if (!kdata) {
> - retcode = -ENOMEM;
> - goto err_i1;
> - }
> + if (ksize <= sizeof(stack_kdata)) {
> + kdata = stack_kdata;
> + } else {
> + kdata = kmalloc(ksize, GFP_KERNEL);
> + if (!kdata) {
> + retcode = -ENOMEM;
> + goto err_i1;
>   }
> - if (asize > usize)
> - memset(kdata + usize, 0, asize - usize);
>   }
>   
> - if (cmd & IOC_IN) {
> - if (copy_from_user(kdata, (void __user *)arg,
> -usize) != 0) {
> - retcode = -EFAULT;
> - goto err_i1;
> - }
> - } else if (cmd & IOC_OUT) {
> - memset(kdata, 0, usize);
> + if (copy_from_user(kdata, (void __user *)arg, in_size) != 0) {
> + retcode = -EFAULT;
> + goto err_i1;
>   }
>   
> + if (ksize > in_size)
> + memset(kdata + in_size, 0, ksize - in_size);
> +
>   /* Enforce sane locking for kms driver ioctls. Core ioctls are
>* too messy still. */
>   if ((drm_core_check_feature(dev, DRIVER_MODESET) && is_driver_ioctl) ||
> @@ -728,11 +725,8 @@ long drm_ioctl(struct file *filp,
>   mutex_unlock(_global_mutex);
>   }
>   
> - if (cmd & IOC_OUT) {
> - if (copy_to_user((void __user *)arg, kdata,
> -  usize) != 0)
> - retcode = -EFAULT;
> - }
> + if (copy_to_user((void __user *)arg, kdata, out_size) != 0)
> + retcode = -EFAULT;
>   
> err_i1:
>   if (!ioctl)

[PATCH 1/1] gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle

[Daniel Vetter]

On Thu, Jul 14, 2016 at 5:30 AM, Peter Chen  wrote:
 >Just an aside: When you do the same bugfix for multiple places it's
 >good practice to submit it as one series (and cc everyone involved).
 >Increases the odds that someone is in a good mood and reviews them
 >all, instead of just the one affecting their own driver.

 Thanks, I realized that, and did it for later fixes for drm.
 But if the bug fixes are at several subsystems, I think we should
 split patch set per subsystem.
>>>
>>>Yeah, splitting per subsystem makes sense I'd say. I merged some of
>>>your patches, others are merged by driver maintainers directly. Is
>>>there anything left? If so, pls resend those as a new series to make sure 
>>>it's all in
>>one place.
>>>-Daniel
>>>
>>
>>Thanks, Daniel.
>>
>>I am afraid I don't know which one is merged, do you have a tree? And, I can 
>>re-send
>>them all.
>>The latest patches which merged Linux-next is at [1], I remembered I dropped 
>>one
>>since the fix has already been there.
>>
>>git log --oneline miss-of-node-put (for drm)
>>
>>e167f2a gpu: drm: vc4_hdmi: add missing of_node_put after calling
>>of_parse_phandle
>>9f86a38 gpu: drm: sun4i_drv: add missing of_node_put after calling
>>of_parse_phandle e0475ac gpu: drm: sti_vtg: add missing of_node_put after 
>>calling
>>of_parse_phandle
>>99ad059 gpu: drm: sti_hqvdp: add missing of_node_put after calling
>>of_parse_phandle
>>7d90d71 gpu: drm: sti_vdo: add missing of_node_put after calling 
>>of_parse_phandle
>>57c9e36 gpu: drm: sti_compositor: add missing of_node_put after calling
>>of_parse_phandle 2cb11fb gpu: drm: rockchip_drm_drv: add missing of_node_put
>>after calling of_parse_phandle 2668b9c gpu: drm: omapdrm: dss-of: add missing
>>of_node_put after calling of_parse_phandle ab81c2e gpu: drm: omapdrm:
>>connector-dvi: add missing of_node_put after calling of_parse_phandle
>>4fc7ab7 gpn: drm: fsl_tcon: add missing of_node_put after calling 
>>of_parse_phandle
>>df5f61f gpu: drm: exynos_hdmi: add missing of_node_put after calling
>>of_parse_phandle
>>6d294e6 gpu: drm: arcpgu_drv: add missing of_node_put after calling
>>of_parse_phandle
>>
>>
>>[1] 
>>https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/log/?h=fix-missing-of-
>>node-put
>>
>>
>
> I find below are at Linux-next, do you need me to send remains?

Yes please, that would be good.
-Daniel

>
> 6d5fa28 gpu: drm: rockchip_drm_drv: add missing of_node_put after calling 
> of_parse_phandle
> e8ef1b6 gpu: drm: sti_vtg: add missing of_node_put after calling 
> of_parse_phandle
> 5d950ef gpu: drm: sti_hqvdp: add missing of_node_put after calling 
> of_parse_phandle
> f33dd64 gpu: drm: sti_vdo: add missing of_node_put after calling 
> of_parse_phandle
> 9897f79 gpu: drm: sti_compositor: add missing of_node_put after calling 
> of_parse_phandle
> f7d8a3c drm/msm: add missing of_node_put after calling of_parse_phandle
>
> Peter
>
>>Peter

 Peter

 >
 >> ---
 >>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
 >>  1 file changed, 4 insertions(+), 3 deletions(-)
 >>
 >> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
 >> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
 >> index bf407b6..1ee6e5e 100644
 >> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
 >> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
 >> @@ -126,15 +126,16 @@ u32 dss_of_port_get_port_number(struct
 >> device_node *port)
 >>
 >>  static struct device_node *omapdss_of_get_remote_port(const
 >> struct device_node *node)  {
 >> -struct device_node *np;
 >> +struct device_node *np, *np_parent;
 >>
 >>  np = of_parse_phandle(node, "remote-endpoint", 0);
 >>  if (!np)
 >>  return NULL;
 >>
 >> -np = of_get_next_parent(np);
 >> +np_parent = of_get_next_parent(np);
 >> +of_node_put(np);
 >>
 >> -return np;
 >> +return np_parent;
 >>  }
 >>
 >>  struct device_node *
 >> --
 >> 1.9.1
 >>
 >> ___
 >> dri-devel mailing list
 >> dri-devel at lists.freedesktop.org
 >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
 >
 >--
 >Daniel Vetter
 >Software Engineer, Intel Corporation http://blog.ffwll.ch
>>>
>>>--
>>>Daniel Vetter
>>>Software Engineer, Intel Corporation
>>>http://blog.ffwll.ch



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

[PATCH 6/6] drm/rockchip: vop: correct rk3036 register define

[Sean Paul]

On Wed, Jul 13, 2016 at 8:33 PM, Mark Yao  wrote:
> Signed-off-by: Mark Yao 
> Reported-by: Tomasz Figa 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index a348a7a..919992c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -190,7 +190,7 @@ static const struct vop_data rk3288_vop = {
> .win_size = ARRAY_SIZE(rk3288_vop_win_data),
>  };
>
> -static const struct vop_scl_regs rk3066_win_scl = {
> +static const struct vop_scl_regs rk3036_win_scl = {
> .scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
> .scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
> .scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
> @@ -198,7 +198,7 @@ static const struct vop_scl_regs rk3066_win_scl = {
>  };
>
>  static const struct vop_win_phy rk3036_win0_data = {
> -   .scl = _win_scl,
> +   .scl = _win_scl,
> .data_formats = formats_win_full,
> .nformats = ARRAY_SIZE(formats_win_full),
> .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: allocate correct crtc state structure on reset

[Sean Paul]

On Thu, Jul 14, 2016 at 8:29 AM, John Keeping  wrote:
> Because we are using a custom crtc_state structure, we must override the
> reset helper to allocate the correct amount of memory.
>
> Cc: stable at vger.kernel.org
> Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
> Signed-off-by: John Keeping 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 1c4d5b5a70a2..21e1247098be 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1048,6 +1048,17 @@ static void vop_crtc_destroy(struct drm_crtc *crtc)
> drm_crtc_cleanup(crtc);
>  }
>
> +static void vop_crtc_reset(struct drm_crtc *crtc)
> +{
> +   if (crtc->state)
> +   __drm_atomic_helper_crtc_destroy_state(crtc, crtc->state);
> +   kfree(crtc->state);
> +
> +   crtc->state = kzalloc(sizeof(struct rockchip_crtc_state), GFP_KERNEL);
> +   if (crtc->state)
> +   crtc->state->crtc = crtc;
> +}
> +
>  static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
>  {
> struct rockchip_crtc_state *rockchip_state;
> @@ -1073,7 +1084,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .page_flip = drm_atomic_helper_page_flip,
> .destroy = vop_crtc_destroy,
> -   .reset = drm_atomic_helper_crtc_reset,
> +   .reset = vop_crtc_reset,
> .atomic_duplicate_state = vop_crtc_duplicate_state,
> .atomic_destroy_state = vop_crtc_destroy_state,
>  };
> --
> 2.9.0.465.g8850cbc.dirty
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7 v3] drm/vc4: Add a getparam ioctl for getting the V3D identity regs.

[Eric Anholt]

As I extend the driver to support different V3D revisions, userspace
needs to know what version it's targeting.  This is most easily
detected using the V3D identity registers.

v2: Make sure V3D is runtime PM on when reading the registers.
v3: Switch to a 64-bit param value (suggested by Rob Clark in review)

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter  (v2)
Reviewed-by: Rob Clark  (v3, over irc)
---
 drivers/gpu/drm/vc4/vc4_drv.c | 42 ++
 include/uapi/drm/vc4_drm.h| 12 
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 2f30214ee810..047d7a265ceb 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drm_fb_cma_helper.h"

 #include "uapi/drm/vc4_drm.h"
@@ -43,6 +44,46 @@ void __iomem *vc4_ioremap_regs(struct platform_device *dev, 
int index)
return map;
 }

+static int vc4_get_param_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_priv)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct drm_vc4_get_param *args = data;
+   int ret;
+
+   if (args->pad != 0)
+   return -EINVAL;
+
+   switch (args->param) {
+   case DRM_VC4_PARAM_V3D_IDENT0:
+   ret = pm_runtime_get_sync(>v3d->pdev->dev);
+   if (ret)
+   return ret;
+   args->value = V3D_READ(V3D_IDENT0);
+   pm_runtime_put(>v3d->pdev->dev);
+   break;
+   case DRM_VC4_PARAM_V3D_IDENT1:
+   ret = pm_runtime_get_sync(>v3d->pdev->dev);
+   if (ret)
+   return ret;
+   args->value = V3D_READ(V3D_IDENT1);
+   pm_runtime_put(>v3d->pdev->dev);
+   break;
+   case DRM_VC4_PARAM_V3D_IDENT2:
+   ret = pm_runtime_get_sync(>v3d->pdev->dev);
+   if (ret)
+   return ret;
+   args->value = V3D_READ(V3D_IDENT2);
+   pm_runtime_put(>v3d->pdev->dev);
+   break;
+   default:
+   DRM_DEBUG("Unknown parameter %d\n", args->param);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static void vc4_lastclose(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -74,6 +115,7 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
  DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(VC4_GET_PARAM, vc4_get_param_ioctl, DRM_RENDER_ALLOW),
 };

 static struct drm_driver vc4_drm_driver = {
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index af12e8a184c8..1143e954048d 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -37,6 +37,7 @@ extern "C" {
 #define DRM_VC4_MMAP_BO   0x04
 #define DRM_VC4_CREATE_SHADER_BO  0x05
 #define DRM_VC4_GET_HANG_STATE0x06
+#define DRM_VC4_GET_PARAM 0x07

 #define DRM_IOCTL_VC4_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SUBMIT_CL, struct drm_vc4_submit_cl)
 #define DRM_IOCTL_VC4_WAIT_SEQNO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno)
@@ -45,6 +46,7 @@ extern "C" {
 #define DRM_IOCTL_VC4_MMAP_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_MMAP_BO, struct drm_vc4_mmap_bo)
 #define DRM_IOCTL_VC4_CREATE_SHADER_BODRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_CREATE_SHADER_BO, struct drm_vc4_create_shader_bo)
 #define DRM_IOCTL_VC4_GET_HANG_STATE  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_HANG_STATE, struct drm_vc4_get_hang_state)
+#define DRM_IOCTL_VC4_GET_PARAM   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_PARAM, struct drm_vc4_get_param)

 struct drm_vc4_submit_rcl_surface {
__u32 hindex; /* Handle index, or ~0 if not present. */
@@ -280,6 +282,16 @@ struct drm_vc4_get_hang_state {
__u32 pad[16];
 };

+#define DRM_VC4_PARAM_V3D_IDENT0   0
+#define DRM_VC4_PARAM_V3D_IDENT1   1
+#define DRM_VC4_PARAM_V3D_IDENT2   2
+
+struct drm_vc4_get_param {
+   __u32 param;
+   __u32 pad;
+   __u64 value;
+};
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.8.1

[PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Chris Wilson]

vGEM buffers are useful for passing data between software clients and
hardware renders. By allowing the user to create and attach fences to
the exported vGEM buffers (on the dma-buf), the user can implement a
deferred renderer and queue hardware operations like flipping and then
signal the buffer readiness (i.e. this allows the user to schedule
operations out-of-order, but have them complete in-order).

This also makes it much easier to write tightly controlled testcases for
dma-buf fencing and signaling between hardware drivers.

v2: Don't pretend the fences exist in an ordered timeline, but allocate
a separate fence-context for each fence so that the fences are
unordered.
v3: Make the debug output more interesting, and so the signaled status.

Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris Wilson 
Cc: Sean Paul 
Cc: Zach Reizner 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Acked-by: Zach Reizner 
---
 drivers/gpu/drm/vgem/Makefile |   2 +-
 drivers/gpu/drm/vgem/vgem_drv.c   |  34 +++
 drivers/gpu/drm/vgem/vgem_drv.h   |  16 +++
 drivers/gpu/drm/vgem/vgem_fence.c | 207 ++
 include/uapi/drm/vgem_drm.h   |  62 
 5 files changed, 320 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
 create mode 100644 include/uapi/drm/vgem_drm.h

diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
index 3f4c7b842028..bfcdea1330e6 100644
--- a/drivers/gpu/drm/vgem/Makefile
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -1,4 +1,4 @@
 ccflags-y := -Iinclude/drm
-vgem-y := vgem_drv.o
+vgem-y := vgem_drv.o vgem_fence.o

 obj-$(CONFIG_DRM_VGEM) += vgem.o
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 29c2aab3c1a7..c15bafb06665 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -83,6 +83,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops = {
.close = drm_gem_vm_close,
 };

+static int vgem_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct vgem_file *vfile;
+   int ret;
+
+   vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
+   if (!vfile)
+   return -ENOMEM;
+
+   file->driver_priv = vfile;
+
+   ret = vgem_fence_open(vfile);
+   if (ret) {
+   kfree(vfile);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
+{
+   struct vgem_file *vfile = file->driver_priv;
+
+   vgem_fence_close(vfile);
+   kfree(vfile);
+}
+
 /* ioctls */

 static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
@@ -164,6 +192,8 @@ unref:
 }

 static struct drm_ioctl_desc vgem_ioctls[] = {
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
 };

 static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
@@ -271,9 +301,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,

 static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .open   = vgem_open,
+   .preclose   = vgem_preclose,
.gem_free_object_unlocked   = vgem_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
+   .num_ioctls = ARRAY_SIZE(vgem_ioctls),
.fops   = _driver_fops,

.dumb_create= vgem_gem_dumb_create,
@@ -328,5 +361,6 @@ module_init(vgem_init);
 module_exit(vgem_exit);

 MODULE_AUTHOR("Red Hat, Inc.");
+MODULE_AUTHOR("Intel Corporation");
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index 988cbaae7588..1f8798ad329c 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -32,9 +32,25 @@
 #include 
 #include 

+#include 
+
+struct vgem_file {
+   struct idr fence_idr;
+   struct mutex fence_mutex;
+};
+
 #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
 struct drm_vgem_gem_object {
struct drm_gem_object base;
 };

+int vgem_fence_open(struct vgem_file *file);
+int vgem_fence_attach_ioctl(struct drm_device *dev,
+   void *data,
+   struct drm_file *file);
+int vgem_fence_signal_ioctl(struct drm_device *dev,
+   void *data,
+   struct drm_file *file);
+void vgem_fence_close(struct vgem_file *file);
+
 #endif
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
new file mode 100644
index ..b7da11419ad6
--- /dev/null
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -0,0 

[v5 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Sean Paul]

On Wed, Jul 13, 2016 at 8:08 PM, Chris Zhong  wrote:
> Hi Sean
>
> Thanks for your detailed review. I'm working to modify most of code
> according to comment.
> And there is reply for some comment
>
> On 07/13/2016 09:59 PM, Sean Paul wrote:
>>
>> On Tue, Jul 12, 2016 at 8:09 AM, Chris Zhong  wrote:
>>>
>>> Add support for cdn DP controller which is embedded in the rk3399
>>> SoCs. The DP is compliant with DisplayPort Specification,
>>> Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
>>> There is a uCPU in DP controller, it need a firmware to work,
>>> please put the firmware file to /lib/firmware/cdn/dptx.bin. The
>>> uCPU in charge of aux communication and link training, the host use
>>> mailbox to communicate with the ucpu.
>>> The dclk pin_pol of vop must not be invert for DP.
>>>
>>> Signed-off-by: Chris Zhong 
>>>
>>> ---
>>>
>>> Changes in v5:
>>> - alphabetical order
>>> - do not use long, use u32 or u64
>>> - return MODE_CLOCK_HIGH when requested > actual
>>> - Optimized Coding Style
>>> - add a formula to get better tu size and symbol value.
>>>
>>> Changes in v4:
>>> - use phy framework to control DP phy
>>> - support 2 phys
>>>
>>> Changes in v3:
>>> - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
>>> - reset spdif before config it
>>> - modify the firmware clk to 100Mhz
>>> - retry load firmware if fw file is requested too early
>>>
>>> Changes in v2:
>>> - Alphabetic order
>>> - remove excess error message
>>> - use define clk_rate
>>> - check all return value
>>> - remove dev_set_name(dp->dev, "cdn-dp");
>>> - use schedule_delayed_work
>>> - remove never-called functions
>>> - remove some unnecessary ()
>>>
>>> Changes in v1:
>>> - use extcon API
>>> - use hdmi-codec for the DP Asoc
>>> - do not initialize the "ret"
>>> - printk a err log when drm_of_encoder_active_endpoint_id
>>> - modify the dclk pin_pol to a single line
>>>
>>>   drivers/gpu/drm/rockchip/Kconfig|   9 +
>>>   drivers/gpu/drm/rockchip/Makefile   |   1 +
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  | 761
>>> 
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.h  | 113 +
>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 740
>>> +++
>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 409 +++
>>
>> Could you explain the file naming convention in the rk driver? We've
>> got analogix_dp-rockchip.c, dw_hdmi-rockchip.c, dw-mipi-dsi.c, and now
>> cdn-dp-(core|reg).[ch]. I'm honestly not sure whether these filenames
>> are consistent with the rest, but bleh.
>>
> cdn is the IP vendor's name
> dp is the controller's name.
>
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
>>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
>>>   9 files changed, 2042 insertions(+), 1 deletion(-)
>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/Kconfig
>>> b/drivers/gpu/drm/rockchip/Kconfig
>>> index d30bdc3..20da9a8 100644
>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>> @@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
>>>for the Analogix Core DP driver. If you want to enable DP
>>>on RK3288 based SoC, you should selet this option.
>>>
>>> +config ROCKCHIP_CDN_DP
>>> +tristate "Rockchip cdn DP"
>>> +depends on DRM_ROCKCHIP
>>> +help
>>> + This selects support for Rockchip SoC specific extensions
>>> + for the cdn Dp driver. If you want to enable Dp on
>>
>> s/Dp/DP/
>>
>>> + RK3399 based SoC, you should selet this
>>
>> s/selet/select/
>>
>>> + option.
>>> +
>>>   config ROCKCHIP_DW_HDMI
>>>   tristate "Rockchip specific extensions for Synopsys DW HDMI"
>>>   depends on DRM_ROCKCHIP
>>> diff --git a/drivers/gpu/drm/rockchip/Makefile
>>> b/drivers/gpu/drm/rockchip/Makefile
>>> index 05d0713..abdecd5 100644
>>> --- a/drivers/gpu/drm/rockchip/Makefile
>>> +++ b/drivers/gpu/drm/rockchip/Makefile
>>> @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>>>   rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>>>
>>>   obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
>>> +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
>>>   obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>>>   obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>>>   obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> new file mode 100644
>>> index 000..5b8a15e
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> @@ -0,0 

[PATCH 1/1] gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

>>> >
>>> >Just an aside: When you do the same bugfix for multiple places it's
>>> >good practice to submit it as one series (and cc everyone involved).
>>> >Increases the odds that someone is in a good mood and reviews them
>>> >all, instead of just the one affecting their own driver.
>>>
>>> Thanks, I realized that, and did it for later fixes for drm.
>>> But if the bug fixes are at several subsystems, I think we should
>>> split patch set per subsystem.
>>
>>Yeah, splitting per subsystem makes sense I'd say. I merged some of
>>your patches, others are merged by driver maintainers directly. Is
>>there anything left? If so, pls resend those as a new series to make sure 
>>it's all in
>one place.
>>-Daniel
>>
>
>Thanks, Daniel.
>
>I am afraid I don't know which one is merged, do you have a tree? And, I can 
>re-send
>them all.
>The latest patches which merged Linux-next is at [1], I remembered I dropped 
>one
>since the fix has already been there.
>
>git log --oneline miss-of-node-put (for drm)
>
>e167f2a gpu: drm: vc4_hdmi: add missing of_node_put after calling
>of_parse_phandle
>9f86a38 gpu: drm: sun4i_drv: add missing of_node_put after calling
>of_parse_phandle e0475ac gpu: drm: sti_vtg: add missing of_node_put after 
>calling
>of_parse_phandle
>99ad059 gpu: drm: sti_hqvdp: add missing of_node_put after calling
>of_parse_phandle
>7d90d71 gpu: drm: sti_vdo: add missing of_node_put after calling 
>of_parse_phandle
>57c9e36 gpu: drm: sti_compositor: add missing of_node_put after calling
>of_parse_phandle 2cb11fb gpu: drm: rockchip_drm_drv: add missing of_node_put
>after calling of_parse_phandle 2668b9c gpu: drm: omapdrm: dss-of: add missing
>of_node_put after calling of_parse_phandle ab81c2e gpu: drm: omapdrm:
>connector-dvi: add missing of_node_put after calling of_parse_phandle
>4fc7ab7 gpn: drm: fsl_tcon: add missing of_node_put after calling 
>of_parse_phandle
>df5f61f gpu: drm: exynos_hdmi: add missing of_node_put after calling
>of_parse_phandle
>6d294e6 gpu: drm: arcpgu_drv: add missing of_node_put after calling
>of_parse_phandle
>
>
>[1] 
>https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/log/?h=fix-missing-of-
>node-put
>
>

I find below are at Linux-next, do you need me to send remains?

6d5fa28 gpu: drm: rockchip_drm_drv: add missing of_node_put after calling 
of_parse_phandle
e8ef1b6 gpu: drm: sti_vtg: add missing of_node_put after calling 
of_parse_phandle
5d950ef gpu: drm: sti_hqvdp: add missing of_node_put after calling 
of_parse_phandle
f33dd64 gpu: drm: sti_vdo: add missing of_node_put after calling 
of_parse_phandle
9897f79 gpu: drm: sti_compositor: add missing of_node_put after calling 
of_parse_phandle
f7d8a3c drm/msm: add missing of_node_put after calling of_parse_phandle

Peter

>Peter
>>>
>>> Peter
>>>
>>> >
>>> >> ---
>>> >>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
>>> >>  1 file changed, 4 insertions(+), 3 deletions(-)
>>> >>
>>> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> >> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> >> index bf407b6..1ee6e5e 100644
>>> >> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> >> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> >> @@ -126,15 +126,16 @@ u32 dss_of_port_get_port_number(struct
>>> >> device_node *port)
>>> >>
>>> >>  static struct device_node *omapdss_of_get_remote_port(const
>>> >> struct device_node *node)  {
>>> >> -struct device_node *np;
>>> >> +struct device_node *np, *np_parent;
>>> >>
>>> >>  np = of_parse_phandle(node, "remote-endpoint", 0);
>>> >>  if (!np)
>>> >>  return NULL;
>>> >>
>>> >> -np = of_get_next_parent(np);
>>> >> +np_parent = of_get_next_parent(np);
>>> >> +of_node_put(np);
>>> >>
>>> >> -return np;
>>> >> +return np_parent;
>>> >>  }
>>> >>
>>> >>  struct device_node *
>>> >> --
>>> >> 1.9.1
>>> >>
>>> >> ___
>>> >> dri-devel mailing list
>>> >> dri-devel at lists.freedesktop.org
>>> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>> >
>>> >--
>>> >Daniel Vetter
>>> >Software Engineer, Intel Corporation http://blog.ffwll.ch
>>
>>--
>>Daniel Vetter
>>Software Engineer, Intel Corporation
>>http://blog.ffwll.ch

[PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

[Yu, Qiang]

Thanks Emil, I'll submit v2 to address your comments.


I'm using office365, not sure this mail is OK for formatting, otherwise I'll 
switch to a mail client.


Regards,

Qiang


From: Emil Velikov <emil.l.veli...@gmail.com>
Sent: Wednesday, July 13, 2016 7:15:43 PM
To: Yu, Qiang
Cc: amd-gfx at lists.freedesktop.org; ML dri-devel
Subject: Re: [PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

On 13 July 2016 at 11:17, Yu, Qiang  wrote:
> Hi Emil,
>
>
> Nice to hear from you.
>
>
> On 11 July 2016 at 06:17, Qiang Yu  wrote:
>> drmGetDevice will always return the first device it find
>> under /dev/dri/. This is not true for multi GPU situation.
>>
> How does the following alternative solution sound:
>  - keep drmFoldDuplicatedDevices as is
>  - after the drmFoldDuplicatedDevices call use the find_rdev to find
> the correct device in local_devices.
>
> [yuq] This is also OK. But drmFoldDuplicatedDevices() has to be changed for
> the
> drmFreeDevices() in the error handling path: it also exit after see a NULL
> in the array.
>
>> Plus fix the memory leak in error handling path of
>> drmGetDevices.
>>
> Unless I'm missing something, there is no memory leak fix below ?
> Alternatively please keep it as separate patch.
>
> [yuq] This is fixed at the same time by changing drmFoldDuplicatedDevices().
>
Heh, silly me was assumed that your earlier patch fixed all the
codepaths to handle the "holes" made by drmFoldDuplicatedDevices.
Seems like the ones drmFreeDevices and drmGetDevice are still
outstanding, thus the predicament.

In this case we could do either:
 - go with the above making sure drmFoldDuplicatedDevices doesn't create 'holes'
Note: we still want to fix drmFreeDevices to continue (as opposed to
break) when it sees one.
 - or, fix drmGetDevice/drmFreeDevices

In either case we want that as separate patch, bonus points for adding
a inline comment about the behaviour of drmFoldDuplicatedDevices.

About the core issue a trivial suggestion - s/move target to the first
of local_devices/store target at local_devices[0] for ease to use
below/

Thanks
Emil
P.S. When working with mailing lists please use plain text emails.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160714/a0a85a76/attachment-0001.html>

[PATCH 1/1] gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

>>
>> >
>> >Just an aside: When you do the same bugfix for multiple places it's
>> >good practice to submit it as one series (and cc everyone involved).
>> >Increases the odds that someone is in a good mood and reviews them
>> >all, instead of just the one affecting their own driver.
>>
>> Thanks, I realized that, and did it for later fixes for drm.
>> But if the bug fixes are at several subsystems, I think we should
>> split patch set per subsystem.
>
>Yeah, splitting per subsystem makes sense I'd say. I merged some of your 
>patches,
>others are merged by driver maintainers directly. Is there anything left? If 
>so, pls
>resend those as a new series to make sure it's all in one place.
>-Daniel
>

Thanks, Daniel.

I am afraid I don't know which one is merged, do you have a tree? And, I can 
re-send them all.
The latest patches which merged Linux-next is at [1], I remembered I dropped
one since the fix has already been there.

git log --oneline miss-of-node-put (for drm)

e167f2a gpu: drm: vc4_hdmi: add missing of_node_put after calling 
of_parse_phandle
9f86a38 gpu: drm: sun4i_drv: add missing of_node_put after calling 
of_parse_phandle
e0475ac gpu: drm: sti_vtg: add missing of_node_put after calling 
of_parse_phandle
99ad059 gpu: drm: sti_hqvdp: add missing of_node_put after calling 
of_parse_phandle
7d90d71 gpu: drm: sti_vdo: add missing of_node_put after calling 
of_parse_phandle
57c9e36 gpu: drm: sti_compositor: add missing of_node_put after calling 
of_parse_phandle
2cb11fb gpu: drm: rockchip_drm_drv: add missing of_node_put after calling 
of_parse_phandle
2668b9c gpu: drm: omapdrm: dss-of: add missing of_node_put after calling 
of_parse_phandle
ab81c2e gpu: drm: omapdrm: connector-dvi: add missing of_node_put after calling 
of_parse_phandle
4fc7ab7 gpn: drm: fsl_tcon: add missing of_node_put after calling 
of_parse_phandle
df5f61f gpu: drm: exynos_hdmi: add missing of_node_put after calling 
of_parse_phandle
6d294e6 gpu: drm: arcpgu_drv: add missing of_node_put after calling 
of_parse_phandle


[1] 
https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/log/?h=fix-missing-of-node-put


Peter
>>
>> Peter
>>
>> >
>> >> ---
>> >>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
>> >>  1 file changed, 4 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> >> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> >> index bf407b6..1ee6e5e 100644
>> >> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> >> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>> >> @@ -126,15 +126,16 @@ u32 dss_of_port_get_port_number(struct
>> >> device_node *port)
>> >>
>> >>  static struct device_node *omapdss_of_get_remote_port(const struct
>> >> device_node *node)  {
>> >> - struct device_node *np;
>> >> + struct device_node *np, *np_parent;
>> >>
>> >>   np = of_parse_phandle(node, "remote-endpoint", 0);
>> >>   if (!np)
>> >>   return NULL;
>> >>
>> >> - np = of_get_next_parent(np);
>> >> + np_parent = of_get_next_parent(np);
>> >> + of_node_put(np);
>> >>
>> >> - return np;
>> >> + return np_parent;
>> >>  }
>> >>
>> >>  struct device_node *
>> >> --
>> >> 1.9.1
>> >>
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >
>> >--
>> >Daniel Vetter
>> >Software Engineer, Intel Corporation
>> >http://blog.ffwll.ch
>
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch

[RFC] dma-buf: Rename struct fence to dma_fence

[Inki Dae]

Hi,

2016-07-13 23:10 GMT+09:00 Chris Wilson :
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
>
> As an indication of the scale of the flag day:
>
>  91 files changed, 904 insertions(+), 880 deletions(-)

Seems files changed and below patch codes are not inconsistent. i.e.,
I cannot see modified codes for Android sync driver.
And Android sync driver - explicit fence - can use a fence object
regardless of DMA buffer. So it looks reasonable to use 'fence' as-is.
Was there any changes for Android sync driver to be dependent on DMA buffer?

Thanks,
Inki Dae

>
> with the greatest victim being amdgpu.
>
> Just the highlights shown below.
> -Chris
>
> ---
>  drivers/base/Kconfig|   6 +-
>  drivers/dma-buf/Makefile|   2 +-
>  drivers/dma-buf/dma-buf.c   |  28 +-
>  drivers/dma-buf/dma-fence.c | 535 
> 
>  drivers/dma-buf/fence.c | 532 ---
>  drivers/dma-buf/reservation.c   |  90 ++--
>  drivers/dma-buf/seqno-fence.c   |  18 +-
>  drivers/dma-buf/sw_sync.c   |  44 +-
>  drivers/dma-buf/sync_debug.c|   9 +-
>  drivers/dma-buf/sync_debug.h|  13 +-
>  drivers/dma-buf/sync_file.c |  30 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
>  drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
>  drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
>  drivers/gpu/drm/msm/msm_drv.h   |   2 +-
>  drivers/gpu/drm/msm/msm_fence.c |  30 +-
>  drivers/gpu/drm/msm/msm_fence.h |   2 +-
>  drivers/gpu/drm/msm/msm_gem.c   |  14 +-
>  drivers/gpu/drm/msm/msm_gem.h   |   2 +-
>  drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
>  drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
>  drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
>  drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
>  drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
>  drivers/gpu/drm/qxl/qxl_drv.h   |   4 +-
>  drivers/gpu/drm/qxl/qxl_release.c   |  27 +-
>  drivers/gpu/drm/radeon/radeon.h |  10 +-
>  drivers/gpu/drm/radeon/radeon_device.c  |   2 +-
>  

[PATCH v3 1/7] lib: string: add functions to case-convert strings

[Luis de Bethencourt]

On 13/07/16 23:26, Markus Mayer wrote:
> On 13 July 2016 at 10:19, Luis de Bethencourt  
> wrote:
>> On 11/07/16 23:46, Markus Mayer wrote:
>>
>> Hi Markus,
>>
>> Amazing. I see this happening as well, but I know it shouldn't.
>>
>> The reason the #ifndef guards in headers are there is precisely to allow
>> circular dependencies.
>>
>> The problem in your output reads as:
>> strstr() is in string.h
>> #include string.h -> that includes kernel.h -> that includes string.h
>>
>> The third should do nothing based on _LINUX_STRING_H_ being defined already
>> and all code inside the #ifndef in string.h not being executed.
>> Yet it shouldn't block the first include above since that macro isn't 
>> defined,
>> which is what the error suggests since it doesn't have strstr()
>> If _LINUX_STRING_H is defined, strstr() should be available.
>>
>> Investigating this issue, it only happens when CONFIG_DYNAMIC_DEBUG is not
>> set and line 170 of dynamic_debug.h runs, but just above we have an
>> include of string.h.
>>
>> Very strange that #include  isn't doing its job.
>>
>> The first thing I tried is to understand where dynamic_debug.h is used and
>> removed the unneeded ones:
>> --
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -11,7 +11,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>
>> diff --git a/include/linux/printk.h b/include/linux/printk.h
>> --- a/include/linux/printk.h
>> +++ b/include/linux/printk.h
>> @@ -307,10 +307,11 @@ asmlinkage __printf(1, 2) __cold void __pr_info(const 
>> char *fmt, ...);
>> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>>  #endif
>>
>> -#include 
>>
>>  /* If you are writing a driver, please use dev_dbg instead */
>>  #if defined(CONFIG_DYNAMIC_DEBUG)
>> +#include 
>> +
>>  /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
>>  #define pr_debug(fmt, ...) \
>> dynamic_pr_debug(fmt, ##__VA_ARGS__)
>> diff --git a/kernel/module.c b/kernel/module.c
>> index beaebea..e70a2fa 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -60,6 +60,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include "module-internal.h"
>> --
>>
>> This diff [0] fixes the issue but it is a workaround for the original
>> issue about string.h not being properly included in dynamic_debug.h
>>
>> Puzzled by this and can't figure out what is happening wrong.
>>
>> The second thing I tried was adding
>> #warning "Linking to string header"
>> in include/linux/string.h, and I don't see any include path mentioning
>> kernel.h, where do you see the circular dependency? I might be missing
>> something.
> 
> I did some more poking around and this is what I found.
> 
> For starters, the problem happens with kernel/bounds.c. Without
> worrying about SIZE_MAX or making any other changes, I added a
> #warning line to kernel.h and string.h to see the include sequence.
> 
> $ aarch64-linux-gcc -Wp,-MD,kernel/.bounds.s.d  -nostdinc -isystem
> /opt/toolchain/stbgcc-4.8-1.5/bin/../lib/gcc/aarch64-linux-gnu/4.8.5/include
> -I./arch/arm64/include -Iarch/arm64/include/generated/uapi
> -Iarch/arm64/include/generated  -Iinclude -I./arch/arm64/include/uapi
> -Iarch/arm64/include/generated/uapi -I./include/uapi
> -Iinclude/generated/uapi -include ./include/linux/kconfig.h
> -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common
> -Werror-implicit-function-declaration -Wno-format-security -std=gnu89
> -mgeneral-regs-only -fno-asynchronous-unwind-tables
> -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
> -Wframe-larger-than=2048 -fno-stack-protector
> -Wno-unused-but-set-variable -fno-omit-frame-pointer
> -fno-optimize-sibling-calls -fno-var-tracking-assignments -g
> -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
> -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
> -DKBUILD_BASENAME='"bounds"'  -DKBUILD_MODNAME='"bounds"'
> -fverbose-asm -E -o kernel/bounds.i kernel/bounds.c
> In file included from include/asm-generic/bug.h:13:0,
>  from ./arch/arm64/include/asm/bug.h:62,
>  from include/linux/bug.h:4,
>  from include/linux/page-flags.h:9,
>  from kernel/bounds.c:9:
> include/linux/kernel.h:4:2: warning: #warning In kernel.h [-Wcpp]
>  #warning In kernel.h
>   ^
> In file included from include/linux/dynamic_debug.h:111:0,
>  from include/linux/printk.h:289,
>  from include/linux/kernel.h:14,
>  from include/asm-generic/bug.h:13,
>  from ./arch/arm64/include/asm/bug.h:62,
>  from include/linux/bug.h:4,
>  from 

[Intel-gfx] [PATCH v3] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Oskar Berggren]

2016-07-12 19:21 GMT+01:00 Matt Roper :

> On Tue, Jul 12, 2016 at 01:36:03PM -0400, Lyude wrote:
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if this was fixed, it's not. Another problem
> > that's been coming from this however, is the mysterious issue of
> > underruns causing full system hangs. An easy way to reproduce this with
> > a skylake system:
> >
> > - Get a laptop with a skylake GPU, and hook up two external monitors to
> >   it
> > - Move the cursor from the built-in LCD to one of the external displays
> >   as quickly as you can
> > - You'll get a few pipe underruns, and eventually the entire system will
> >   just freeze.
> >
> > After doing a lot of investigation and reading through the bspec, I
> > found the existence of the SAGV, which is responsible for adjusting the
> > system agent voltage and clock frequencies depending on how much power
> > we need. According to the bspec:
> >
> > "The display engine access to system memory is blocked during the
> >  adjustment time. SAGV defaults to enabled. Software must use the
> >  GT-driver pcode mailbox to disable SAGV when the display engine is not
> >  able to tolerate the blocking time."
> >
> > The rest of the bspec goes on to explain that software can simply leave
> > the SAGV enabled, and disable it when we use interlaced pipes/have more
> > then one pipe active.
> >
> > Sure enough, with this patchset the system hangs resulting from pipe
> > underruns on Skylake have completely vanished on my T460s. Additionally,
> > the bspec mentions turning off the SAGV   with more then one pipe
> enabled
> > as a workaround for display underruns. While this patch doesn't entirely
> > fix that, it looks like it does improve the situation a little bit so
> > it's likely this is going to be required to make watermarks on Skylake
> > fully functional.
> >
> > Changes since v2:
> >  - Really apply minor style nitpicks to patch this time
> > Changes since v1:
> >  - Added comments about this probably being one of the requirements to
> >fixing Skylake's watermark issues
> >  - Minor style nitpicks from Matt Roper
> >  - Disable these functions on Broxton, since it doesn't have an SAGV
> >
> > Cc: Matt Roper 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Lyude 
>
> I don't have a SKL to try this out on (only BXT here), but this matches
> my interpretation of the current bspec text, so
>
> Reviewed-by: Matt Roper 
>
> I think this also applies to
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94625
>
>
Yes, this does sound very similar to the problems I were having in that
report.
Vacation etc. so haven't found time to try the 4.6 kernel yet, and now I
will be
travelling until next week. If someone is easily able to prepare a kernel
for
Fedora 24 with this patch it's more likely I can find time to try it next
week (on
Dell XPS 9550 with 1 or 2 external monitors).

I should mention that there was a brief period in 4.4.4-4.4.9 or so that
seemed
to work fairly stable compared to both 4.3 and 4.5.

/Oskar
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH v2 2/2] drm/fsl-dcu: update panel syntax to of_graph dt binding

[Stefan Agner]

On 2016-06-29 01:17, Meng Yi wrote:
> add of_graph dt binding for panel, and "fsl,panel" property

Nit: "binding" typically describes the requirement, the specification
and hence is under Documentation/devicetree/bindings/.

What you add here is the dt nodes according to the bindings...

Hence I would say something like

Add of_graph dt nodes to describe the panel and remove the "fsl,panel"
property.

> is deprecated
> 
> Signed-off-by: Meng Yi 
> ---
> Changes in V2:
> -dropp the unit address of port
> ---
>  arch/arm/boot/dts/ls1021a-twr.dts | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index 75ecaed..cbd92c8 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -108,12 +108,22 @@
>  
>   panel: panel {
>   compatible = "nec,nl4827hc19-05b";

Nit: We typically add a new line before adding a subnode.

> + port {
> + panel_out: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
>   };
>  };
>  
>   {
> - fsl,panel = <>;
>   status = "okay";
> +
> + port: port {

Same as in bindings, port does not need a label too.

> + dcu_out: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
>  };
>  
>   {

There is still a patch for vf-colibri-eval-v3.dtsi missing which does
the same.

--
Stefan

[GIT PULL] exynos-drm-next

[Inki Dae]

Hi Dave,
   This pull request adds to the rework patch series for IOMMU
   integration to support ARM64bit architecture with DMA-IOMMU
   glue code.

   With this patch series, Exynos DRM works well on Exynos5433 SoC
   with IOMMU enabled.

   Ps. current implementation has conditional codes in exynos_drm_iommu.h
   for ARM32/64 supports because these two architectures are not compatible
   yet so the conditional codes will be removed later with architectures
   unified.

   Please kindly let me know if there is any problem.


Thanks,
Inki Dae


The following changes since commit 5dd0775e502b26b44e5bcb5f504a977a565f2f3e:

  Merge tag 'asoc-hdmi-codec-pdata' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into drm-next 
(2016-07-05 09:57:23 +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 197adf0b7e419247a6e54d05d0d334e07e9e4c33:

  drm/exynos: iommu: add support for ARM64 specific code for IOMMU glue 
(2016-07-13 23:06:07 +0900)


Marek Szyprowski (5):
  drm/exynos: iommu: move dma_params configuration code to separate 
functions
  drm/exynos: iommu: add a check if all sub-devices have iommu controller
  drm/exynos: iommu: remove unused entries from exynos_drm_private strcuture
  drm/exynos: iommu: move ARM specific code to exynos_drm_iommu.h
  drm/exynos: iommu: add support for ARM64 specific code for IOMMU glue

 drivers/gpu/drm/exynos/Kconfig|2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |7 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |2 -
 drivers/gpu/drm/exynos/exynos_drm_iommu.c |   77 +++-
 drivers/gpu/drm/exynos/exynos_drm_iommu.h |   91 +
 5 files changed, 126 insertions(+), 53 deletions(-)

[PATCH v2 1/2] drm/fsl-dcu: update the panel dt binding document

[Stefan Agner]

On 2016-06-29 01:17, Meng Yi wrote:
> dropped the old "fsl,panel" property, using the of_graph dt
> binding syntax
> 
> Signed-off-by: Meng Yi 
> ---
> Changes in V2:
> -drop the unit address of port
> ---
>  Documentation/devicetree/bindings/display/fsl,dcu.txt | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> index ae55cde..c96ec1f 100644
> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> @@ -12,7 +12,7 @@ Required properties:
>  - clock-names:   Should be "dcu" and "pix"
>   See ../clocks/clock-bindings.txt for details.
>  - big-endian Boolean property, LS1021A DCU registers are big-endian.
> -- fsl,panel: The phandle to panel node.
> +- port   Video port for the panel output
>  
>  Optional properties:
>  - fsl,tcon:  The phandle to the timing controller node.
> @@ -24,6 +24,11 @@ dcu: dcu at 2ce {
>   clocks = <_clk 0>, <_clk 0>;
>   clock-names = "dcu", "pix";
>   big-endian;
> - fsl,panel = <>;
>   fsl,tcon = <>;
> +
> + port: port {

Port does not need a label here.

> + dcu_out: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
>  };

Otherwise looks good. However, I would prefer to have this change as
part of the corresponding driver change. Can you squash that into the
"drm/fsl-dcu: rework codes to support of_graph dt binding for panel"
patch?

--
Stefan

[PATCH v2 1/2] drm/fsl-dcu: rework codes to support of_graph dt binding for panel

[Stefan Agner]

On 2016-06-28 02:32, Meng Yi wrote:
> This patch rework the output code to add of_graph dt binding support
> for panel device and also keeps the backward compatibility
> 
> Signed-off-by: Meng Yi 
> ---
> Changes in V2:
> -fix some coding style issue
> -add fsl_dev->connector.panel check
> -use fsl_dev->np and drop fsl_dev->dev->of_node
> -return 'ret' when fsl_dcu_attach_panel failed
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h |  3 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 79 
> 
>  3 files changed, 60 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> index c564ec6..b48ffa7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> @@ -43,7 +43,7 @@ int fsl_dcu_drm_modeset_init(struct
> fsl_dcu_drm_device *fsl_dev)
>   if (ret)
>   goto fail_encoder;
>  
> - ret = fsl_dcu_drm_connector_create(fsl_dev, _dev->encoder);
> + ret = fsl_dcu_create_outputs(fsl_dev);
>   if (ret)
>   goto fail_connector;
>  
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> index 7093109..5a7b88e 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
> @@ -25,9 +25,8 @@ to_fsl_dcu_connector(struct drm_connector *con)
>: NULL;
>  }
>  
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder);
>  int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
>  struct drm_crtc *crtc);
> +int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev);
>  
>  #endif /* __FSL_DCU_DRM_CONNECTOR_H__ */
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 98c998d..b23cc58 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -141,15 +142,15 @@ static const struct drm_connector_helper_funcs
> connector_helper_funcs = {
>   .mode_valid = fsl_dcu_drm_connector_mode_valid,
>  };
>  
> -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
> -  struct drm_encoder *encoder)
> +static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev,
> + struct drm_panel *panel)

Align the second line with the beginning of the arguments of the first
line (using tabs first, and if necessary spaces).

>  {
> + struct drm_encoder *encoder = _dev->encoder;
>   struct drm_connector *connector = _dev->connector.base;
>   struct drm_mode_config *mode_config = _dev->drm->mode_config;
> - struct device_node *panel_node;
>   int ret;
>  
> - fsl_dev->connector.encoder = encoder;
> + fsl_dev->connector.encoder = _dev->encoder;

You don't need to change this line since you created a local variable
above.

>  
>   ret = drm_connector_init(fsl_dev->drm, connector,
>_dcu_drm_connector_funcs,
> @@ -170,21 +171,7 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
> mode_config->dpms_property,
> DRM_MODE_DPMS_OFF);
>  
> - panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
> - if (!panel_node) {
> - dev_err(fsl_dev->dev, "fsl,panel property not found\n");
> - ret = -ENODEV;
> - goto err_sysfs;
> - }
> -
> - fsl_dev->connector.panel = of_drm_find_panel(panel_node);
> - if (!fsl_dev->connector.panel) {
> - ret = -EPROBE_DEFER;
> - goto err_panel;
> - }
> - of_node_put(panel_node);
> -
> - ret = drm_panel_attach(fsl_dev->connector.panel, connector);
> + ret = drm_panel_attach(panel, connector);
>   if (ret) {
>   dev_err(fsl_dev->dev, "failed to attach panel\n");
>   goto err_sysfs;
> @@ -192,11 +179,61 @@ int fsl_dcu_drm_connector_create(struct
> fsl_dcu_drm_device *fsl_dev,
>  
>   return 0;
>  
> -err_panel:
> - of_node_put(panel_node);
>  err_sysfs:
>   drm_connector_unregister(connector);
>  err_cleanup:
>   drm_connector_cleanup(connector);
>   return ret;
>  }
> +
> +static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
> + const struct of_endpoint *ep)
> +{
> + struct device_node *np;
> + int ret;
> +
> + np = of_graph_get_remote_port_parent(ep->local_node);
> +
> + fsl_dev->connector.panel = of_drm_find_panel(np);
> + if (fsl_dev->connector.panel) {
> + of_node_put(np);

After using np