Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

On 4/6/2018 11:14 PM, Ville Syrjälä wrote:

On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:

This patch is causing failure of IGT test kms_3d. The kms_3d test
expects the no. of 3d modes to be 13.

(The test has hard-coded value for expected no. of 3d modes as 13)

But due to the addition of "matching aspect_ratio" in drm_mode_equal in
this patch, the total no. of

modes in the connector modelist is increased by 2, resulting in failure
of assertion 'mode_count==13'.

If kms_3d isn't setting the aspect ratio cap how is it affected by these
changes?

In drm_mode.c, the drm_mode_connector_list_update() uses drm_mode_equal,
to remove duplicate modes in connector_modes from the 
connector->probe_modes.
Earlier, it wasn't matching for aspect-ratio and was discarding two of 
the modes with aspect ratio,

as duplicates of other modes in the list.

Later, when we are pruning the modes in drm_mode_get_connector, the 
logic there assumes,
that the modes are in a sorted order so that we just match with the last 
valid mode for uniqueness.

This isn't the case with the spoofed edid in kms_3d.
Earlier, I was thinking if we should change the no. of expected modes in 
kms_3d,

but that's not correct approach.

So finally, The pruning logic needs to be changed, to do away with any 
assumption and check
all the modes in the list for duplicates. This however will take more 
time to remove duplicates.


Any other suggestions on this?

Regards
-Ankit




Perhaps this need to be handled in the test.

-Regards,

Ankit


On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
  provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
  drm_fb_helper, while trying to find a common mode among connectors
  for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
---
   drivers/gpu/drm/drm_fb_helper.c | 12 ++--
   drivers/gpu/drm/drm_modes.c | 35 ++-
   2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b10..2ee1eaa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
-   if (!drm_mode_equal(modes[j], modes[i]))
+   if (!drm_mode_match(modes[j], modes[i],
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
can_clone = false;
}
}
@@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
   
   		fb_helper_conn = fb_helper->connector_info[i];

list_for_each_entry(mode, _helper_conn->connector->modes, 
head) {
-   if (drm_mode_equal(mode, dmt_mode))
+   if (drm_mode_match(mode, dmt_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
 

Re: [Intel-gfx] [PATCH v1 2/2] i915: content-type property for HDMI connector

[Sean Paul]

On Tue, Apr 17, 2018 at 02:16:59AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added encoding of drm content_type property from
> drm_connector_state within AVI infoframe in order to properly handle
> external HDMI TV content-type setting.
> 
> Signed-off-by: Stanislav Lisovskiy 

Hi Stanislav,
Thank you for your patch.

> ---
>  drivers/gpu/drm/i915/intel_atomic.c |  1 +
>  drivers/gpu/drm/i915/intel_drv.h|  1 +
>  drivers/gpu/drm/i915/intel_hdmi.c   |  4 
>  drivers/gpu/drm/i915/intel_modes.c  | 10 ++
>  4 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 40285d1b91b7..61ddb5871d8a 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
> drm_connector *conn,
>   if (new_conn_state->force_audio != old_conn_state->force_audio ||
>   new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
>   new_conn_state->base.picture_aspect_ratio != 
> old_conn_state->base.picture_aspect_ratio ||
> + new_conn_state->base.content_type != 
> old_conn_state->base.content_type ||
>   new_conn_state->base.scaling_mode != 
> old_conn_state->base.scaling_mode)
>   crtc_state->mode_changed = true;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5bd2263407b2..07fd7ba21f38 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1818,6 +1818,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct 
> i2c_adapter *adapter);
>  void intel_attach_force_audio_property(struct drm_connector *connector);
>  void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
>  void intel_attach_aspect_ratio_property(struct drm_connector *connector);
> +void intel_attach_content_type_property(struct drm_connector *connector);
>  
>  
>  /* intel_overlay.c */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ee929f31f7db..cd484276e9b0 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>  
> intel_hdmi->rgb_quant_range_selectable,
>  is_hdmi2_sink);
>  
> + frame.avi.content_type = connector->state->content_type;
> +
>   /* TODO: handle pixel repetition for YCBCR420 outputs */
>   intel_write_infoframe(encoder, crtc_state, );
>  }
> @@ -2065,7 +2067,9 @@ intel_hdmi_add_properties(struct intel_hdmi 
> *intel_hdmi, struct drm_connector *c
>   intel_attach_force_audio_property(connector);
>   intel_attach_broadcast_rgb_property(connector);
>   intel_attach_aspect_ratio_property(connector);
> + intel_attach_content_type_property(connector);
>   connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + connector->state->content_type = HDMI_CONTENT_TYPE_GRAPHICS;

This is redudant, the attach function already sets this.

>  }
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/intel_modes.c 
> b/drivers/gpu/drm/i915/intel_modes.c
> index b39846613e3c..232811ab71a3 100644
> --- a/drivers/gpu/drm/i915/intel_modes.c
> +++ b/drivers/gpu/drm/i915/intel_modes.c
> @@ -133,3 +133,13 @@ intel_attach_aspect_ratio_property(struct drm_connector 
> *connector)
>   connector->dev->mode_config.aspect_ratio_property,
>   DRM_MODE_PICTURE_ASPECT_NONE);
>  }
> +
> +void
> +intel_attach_content_type_property(struct drm_connector *connector)
> +{
> + if (!drm_mode_create_content_type_property(connector->dev))
> + drm_object_attach_property(>base,
> + connector->dev->mode_config.content_type_property,
> + DRM_MODE_CONTENT_TYPE_GRAPHICS);
> +}

I think the "in" thing to do is to add this helper to the core, since this is a
core property.

Sean

> +
> -- 
> 2.17.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

mi0283qt driver issues

[Tom Callaway]

Noralf,

Thanks for the guidance on how to use the mi0283qt driver to run the
panel included in the Adafruit 2.8" capacitive PiTFT Plus (running on
top of a Raspberry Pi 3).

I am working with 4.16.0 (Fedora 28). I can get the driver to load, and
have console output appearing on it, but I have run into some issues
that I am unclear how to resolve.

Specifically:

1) If I change the rotation value to anything other than 90 (0x5a), the
screen output from the console is corrupt.
2) The resolution is set to 240x320, not the 320x240 that I expected.
3) pygame cannot run a display.set_mode call, always returning:

No video mode large enough for 240x320

When I run this python code:

   import os
   import pygame
   os.putenv('SDL_VIDEODRIVER', 'fbcon')
   os.putenv('SDL_FBDEV'  , '/dev/fb1')
   pygame.init()
   list = pygame.display.list_modes()
   print "List of modes: %s" % (list)

It shows an empty set ("List of modes: []").

Do you have any advice on how to resolve these issues?

Thanks in advance,

~tom

For debugging purposes:

I have the following device tree entry for the device (taken from dtc
-Ifs /proc/device-tree):

pitft@0 {
compatible = "multi-inno,mi0283qt";
buswidth = <0x8>;
rotation = <0x5a>;
bgr;
fps = <0x1e>;
reg = <0x0>;
pinctrl-0 = <0x10>;
debug = <0x0>;
dc-gpios = <0xf 0x19 0x0>;
spi-max-frequency = <0x3d09000>;
pinctrl-names = "default";
};

*** modetest output ***

[root@localhost ~]# modetest -M "mi0283qt" -c
Connectors:
id  encoder status  namesize (mm)   modes   encoders
28  31  connected   Virtual-1   43x58   1   31
  modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  240x320 0 240 240 240 240 320 320 320 320 1 flags: ; type: preferred,
driver
  props:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
5 link-status:
flags: enum
enums: Good=0 Bad=1
value: 0
6 non-desktop:
flags: immutable range
values: 0 1
value: 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v2 2/2] drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

[Sean Paul]

On Fri, Apr 13, 2018 at 01:52:17PM -0700, abhin...@codeaurora.org wrote:
> On 2018-04-13 13:29, Sean Paul wrote:
> > On Tue, Apr 10, 2018 at 06:54:07PM -0700, Abhinav Kumar wrote:
> > > Currently the DSI PHY timings are hard-coded for a specific panel
> > > for the 10nm PHY.
> > > 
> > > Replace this with the auto PHY timing calculator which can calculate
> > > the PHY timings for any panel.
> > 
> > Any chance you could document what you're doing so anyone without
> > documentation
> > has a clue what's going on?
> > 
> > Sean
> > 
> I am afraid it will hard to document more about this function other than
> whats mentioned here.
> Basically, we have an excel sheet which does this math to calculate the DSI
> timings.
> This patch implements that excel sheet for SDM845 which uses 10nm PHY.
> We will not be able to explain the math in more detail.

Ahh, ok :(

Reviewed-by: Sean Paul 

> > > 
> > > Changes in v2:
> > > - None
> > > 
> > > Reviewed-by: Archit Taneja 
> > > Signed-off-by: Abhinav Kumar 
> > > ---
> > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 111
> > > +
> > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
> > >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 
> > >  3 files changed, 113 insertions(+), 28 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > > index 8e9d5c2..5b42885 100644
> > > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > > @@ -265,6 +265,117 @@ int msm_dsi_dphy_timing_calc_v2(struct
> > > msm_dsi_dphy_timing *timing,
> > >   return 0;
> > >  }
> > > 
> > > +int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing *timing,
> > > +struct msm_dsi_phy_clk_request *clk_req)
> > > +{
> > > + const unsigned long bit_rate = clk_req->bitclk_rate;
> > > + const unsigned long esc_rate = clk_req->escclk_rate;
> > > + s32 ui, ui_x8, lpx;
> > > + s32 tmax, tmin;
> > > + s32 pcnt0 = 50;
> > > + s32 pcnt1 = 50;
> > > + s32 pcnt2 = 10;
> > > + s32 pcnt3 = 30;
> > > + s32 pcnt4 = 10;
> > > + s32 pcnt5 = 2;
> > > + s32 coeff = 1000; /* Precision, should avoid overflow */
> > > + s32 hb_en, hb_en_ckln;
> > > + s32 temp;
> > > +
> > > + if (!bit_rate || !esc_rate)
> > > + return -EINVAL;
> > > +
> > > + timing->hs_halfbyte_en = 0;
> > > + hb_en = 0;
> > > + timing->hs_halfbyte_en_ckln = 0;
> > > + hb_en_ckln = 0;
> > > +
> > > + ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
> > > + ui_x8 = ui << 3;
> > > + lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
> > > +
> > > + temp = S_DIV_ROUND_UP(38 * coeff, ui_x8);
> > > + tmin = max_t(s32, temp, 0);
> > > + temp = (95 * coeff) / ui_x8;
> > > + tmax = max_t(s32, temp, 0);
> > > + timing->clk_prepare = linear_inter(tmax, tmin, pcnt0, 0, false);
> > > +
> > > +
> > > + temp = 300 * coeff - (timing->clk_prepare << 3) * ui;
> > > + tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
> > > + tmax = (tmin > 255) ? 511 : 255;
> > > + timing->clk_zero = linear_inter(tmax, tmin, pcnt5, 0, false);
> > > +
> > > + tmin = DIV_ROUND_UP(60 * coeff + 3 * ui, ui_x8);
> > > + temp = 105 * coeff + 12 * ui - 20 * coeff;
> > > + tmax = (temp + 3 * ui) / ui_x8;
> > > + timing->clk_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
> > > +
> > > + temp = S_DIV_ROUND_UP(40 * coeff + 4 * ui, ui_x8);
> > > + tmin = max_t(s32, temp, 0);
> > > + temp = (85 * coeff + 6 * ui) / ui_x8;
> > > + tmax = max_t(s32, temp, 0);
> > > + timing->hs_prepare = linear_inter(tmax, tmin, pcnt1, 0, false);
> > > +
> > > + temp = 145 * coeff + 10 * ui - (timing->hs_prepare << 3) * ui;
> > > + tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
> > > + tmax = 255;
> > > + timing->hs_zero = linear_inter(tmax, tmin, pcnt4, 0, false);
> > > +
> > > + tmin = DIV_ROUND_UP(60 * coeff + 4 * ui, ui_x8) - 1;
> > > + temp = 105 * coeff + 12 * ui - 20 * coeff;
> > > + tmax = (temp / ui_x8) - 1;
> > > + timing->hs_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
> > > +
> > > + temp = 50 * coeff + ((hb_en << 2) - 8) * ui;
> > > + timing->hs_rqst = S_DIV_ROUND_UP(temp, ui_x8);
> > > +
> > > + tmin = DIV_ROUND_UP(100 * coeff, ui_x8) - 1;
> > > + tmax = 255;
> > > + timing->hs_exit = linear_inter(tmax, tmin, pcnt2, 0, false);
> > > +
> > > + temp = 50 * coeff + ((hb_en_ckln << 2) - 8) * ui;
> > > + timing->hs_rqst_ckln = S_DIV_ROUND_UP(temp, ui_x8);
> > > +
> > > + temp = 60 * coeff + 52 * ui - 43 * ui;
> > > + tmin = DIV_ROUND_UP(temp, ui_x8) - 1;
> > > + tmax = 63;
> > > + timing->shared_timings.clk_post =
> > > + linear_inter(tmax, tmin, pcnt2, 0, false);
> > > +
> > > + temp = 8 * ui + (timing->clk_prepare << 3) * ui;
> > > + temp += (((timing->clk_zero + 3) << 3) + 11) * ui;
> > > + temp += hb_en_ckln ? (((timing->hs_rqst_ckln << 3) + 4) * ui) :
> > > + (((timing->hs_rqst_ckln << 

Re: [Freedreno] [DPU PATCH v2 1/2] drm/msm/dsi: check video mode engine status before waiting

[abhinavk]

Hi Sean

Thanks for reviewing.

Reply inline.

On 2018-04-16 10:07, Sean Paul wrote:
On Fri, Apr 13, 2018 at 03:04:48PM -0700, abhin...@codeaurora.org 
wrote:

On 2018-04-13 14:10, abhin...@codeaurora.org wrote:
> Hi Sean
>
> Thanks for the review.
>
> Reply inline.
>
> On 2018-04-13 13:26, Sean Paul wrote:
> > On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
> > > Make sure the video mode engine is on before waiting
> > > for the video done interrupt.
> > >
> > > Otherwise it leads to silent timeouts increasing display
> > > turn ON time.
> > >
> > > Changes in v2:
> > > - Replace pr_err with dev_err
> > > - Changed error message
> > >
> > > Signed-off-by: Abhinav Kumar 
> > > ---
> > >  drivers/gpu/drm/msm/dsi/dsi_host.c | 15 +++
> > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > index 7a03a94..5b7b290 100644
> > > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > @@ -173,6 +173,7 @@ struct msm_dsi_host {
> > >
> > >  bool registered;
> > >  bool power_on;
> > > +bool enabled;
> > >  int irq;
> > >  };
> > >
> > > @@ -986,13 +987,19 @@ static void dsi_set_tx_power_mode(int
> > > mode, struct msm_dsi_host *msm_host)
> > >
> > >  static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
> > >  {
> > > +u32 ret = 0;
> > > +struct device *dev = _host->pdev->dev;
> > > +
> > >  dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
> > >
> > >  reinit_completion(_host->video_comp);
> > >
> > > -wait_for_completion_timeout(_host->video_comp,
> > > +ret = wait_for_completion_timeout(_host->video_comp,
> > >  msecs_to_jiffies(70));
> > >
> > > +if (ret <= 0)
> > > +dev_err(dev, "wait for video done timed out\n");
> > > +
> > >  dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0);
> > >  }
> > >
> > > @@ -1001,7 +1008,7 @@ static void dsi_wait4video_eng_busy(struct
> > > msm_dsi_host *msm_host)
> > >  if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
> > >  return;
> > >
> > > -if (msm_host->power_on) {
> > > +if (msm_host->power_on && msm_host->enabled) {
> > >  dsi_wait4video_done(msm_host);
> > >  /* delay 4 ms to skip BLLP */
> > >  usleep_range(2000, 4000);
> > > @@ -2203,7 +2210,7 @@ int msm_dsi_host_enable(struct
> > > mipi_dsi_host *host)
> > >   *  pm_runtime_put_autosuspend(_host->pdev->dev);
> > >   * }
> > >   */
> > > -
> > > +msm_host->enabled = true;
> > >  return 0;
> > >  }
> > >
> > > @@ -2219,7 +2226,7 @@ int msm_dsi_host_disable(struct
> > > mipi_dsi_host *host)
> > >   * Reset to disable video engine so that we can send off cmd.
> > >   */
> > >  dsi_sw_reset(msm_host);
> > > -
> > > +msm_host->enabled = false;
> >
> > This should go at the start of the function. Also, it's unclear from
> > this patch,
> > but I assume this is protected by a lock?
> >
> > Sean
> [Abhinav] Yes, will move this to the start.
> No, there is no lock here but at this point doesnt need one.
> The reason is that, this variable will be written to and read by the
> same process
> (suspend thread OR resume thread which sends the panel ON/OFF commands).
> If we decide to expose other interfaces to send commands like debugfs
> or sysfs and
> introduce more threads, we will add the locking.
[Abhinav] Correction to my prev comment, we do have the 
msm_host->cmd_mutex

which will
ensure this entire process is protected. That should suffice.


Ok, thanks for confirming. Could you also please split this patch into 
the
wait4video_done ret fix and the ->enabled addition? The 2 seem mostly 
unrelated.


Sean


They are quite related actually. So we were not able to catch this 
earlier
because the wait was silently timing out. Hence along with the fix I 
wanted

to change the ret to add the error log because such condition should not
happen with the ->enabled fix. To signify that I clubbed them together.
I can split them, if this still feels unrelated.


> >
> >
> > >  return 0;
> > >  }
> > >
> > > --
> > > The Qualcomm Innovation Center, Inc. is a member of the Code
> > > Aurora Forum,
> > > a Linux Foundation Collaborative Project
> > >
> > > ___
> > > Freedreno mailing list
> > > freedr...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/freedreno
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
dri-devel mailing list

Re: [Intel-gfx] [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

[Eric Anholt]

Chris Wilson  writes:

> Quoting Jordan Crouse (2018-04-05 23:06:53)
>> On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote:
>> > The i915 DRM driver very cleverly used ascii85 encoding for their
>> > GPU state file. Move the encode functions to a general header file to
>> > support other drivers that might be interested in the same
>> > functionality.
>> 
>> In a previous version of this patch, Chris asked what tree I wanted this 
>> applied
>> to, and the answer is: I'm not sure?  I'm hoping that Rob will be cool with
>> picking the rest up for msm-next for 4.18 but I'm okay with putting this
>> particular patch wherever it is easiest for the maintainers.
>
> We are a bit late to sneak it into the 4.17 drm base via i915. I don't
> anticipate any problems (for i915) with this patch going in through
> msm-next, so happy to have it land there and percolate back to i915 3
> months later.

I'd love to have it in drm-misc-next, so I can build a similar hang dump
interface for vc5.  But most importantly, I'd like to have it somewhere
soon.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH 0/6] Switch DPU to use upstream DSI driver for SDM845

[Jeykumar Sankaran]

SDM845 DPU driver was talking to dsi-staging driver for its dsi 
operations through the customized dpu_connector layer. The following 
series of patches removes DPU dependency from various dpu
connector API's before purging the dpu_connector altogether. It
also completes the switch to upstream DSI driver by removing
the dsi-staging driver and it's dependent sources.

The patch series is based on:
[1]https://www.spinics.net/lists/dri-devel/msg172315.html
[2]https://www.spinics.net/lists/dri-devel/msg172395.html

Jeykumar Sankaran (6):
  drm/msm: remove display stream compression(DSC) support for SM845
  drm/msm: remove support for ping pong split topology
  drm/msm: remove panel autorefresh support for SDM845
  drm/msm: strip down custom event ioctl's
  drm/msm: hook up DPU with upstream DSI
  drm/msm: remove dsi-staging driver

 .../config/arm64/chromiumos-arm64.flavour.config   |3 +-
 .../arm64/chromiumos-qualcomm.flavour.config   |3 +-
 drivers/gpu/drm/msm/Kconfig|   12 -
 drivers/gpu/drm/msm/Makefile   |   23 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  | 1195 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h  |  555 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  246 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  861 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   24 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   38 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  409 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   32 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   30 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   18 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c |  252 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h |  100 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   89 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|   40 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |   46 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |   18 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h   |4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  251 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  146 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   21 +-
 drivers/gpu/drm/msm/dpu_dbg.c  |3 -
 drivers/gpu/drm/msm/dsi-staging/dsi_catalog.c  |  241 --
 drivers/gpu/drm/msm/dsi-staging/dsi_catalog.h  |  201 -
 drivers/gpu/drm/msm/dsi-staging/dsi_clk.h  |  276 --
 drivers/gpu/drm/msm/dsi-staging/dsi_clk_manager.c  | 1235 --
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl.c | 2846 -
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl.h |  623 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw.h  |  752 
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_1_4.c  |  480 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_2_0.c  |  234 --
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_2_2.c  |   42 -
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_cmn.c  | 1312 --
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_reg.h |  196 -
 drivers/gpu/drm/msm/dsi-staging/dsi_defs.h |  579 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_display.c  | 4221 
 drivers/gpu/drm/msm/dsi-staging/dsi_display.h  |  556 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_display_test.c |  114 -
 drivers/gpu/drm/msm/dsi-staging/dsi_display_test.h |   31 -
 drivers/gpu/drm/msm/dsi-staging/dsi_drm.c  |  688 
 drivers/gpu/drm/msm/dsi-staging/dsi_drm.h  |  127 -
 drivers/gpu/drm/msm/dsi-staging/dsi_hw.h   |   48 -
 drivers/gpu/drm/msm/dsi-staging/dsi_panel.c| 3321 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_panel.h|  257 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy.c  |  937 -
 drivers/gpu/drm/msm/dsi-staging/dsi_phy.h  |  235 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw.h   |  260 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v2_0.c  |  252 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v3_0.c  |  447 ---
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_calc.c  |  676 
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_calc.h  |  144 -
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_v2_0.c  |  126 -
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_v3_0.c  |  107 -
 drivers/gpu/drm/msm/dsi-staging/dsi_pwr.c  |  365 --
 drivers/gpu/drm/msm/dsi-staging/dsi_pwr.h  |   93 -
 drivers/gpu/drm/msm/msm_drv.c  |  242 +-
 drivers/gpu/drm/msm/msm_drv.h  |   55 -
 drivers/gpu/drm/msm/msm_kms.h  |2 -
 63 files changed, 185 insertions(+), 26575 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h
 delete mode 

[DPU PATCH 5/6] drm/msm: hook up DPU with upstream DSI

[Jeykumar Sankaran]

Switch DPU from dsi-staging to upstream dsi driver. To make
the switch atomic, this change includes:
- remove dpu connector layers
- clean up dpu connector dependencies in encoder/crtc
- compile out writeback and display port drivers
- compile out dsi-staging driver (separate patch submitted to
  remove the driver)
- adapt upstream device hierarchy

Signed-off-by: Jeykumar Sankaran 
---
 .../config/arm64/chromiumos-arm64.flavour.config   |4 +-
 .../arm64/chromiumos-qualcomm.flavour.config   |4 +-
 drivers/gpu/drm/msm/Makefile   |1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  | 1184 
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h  |  555 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  173 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   10 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |8 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  220 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |   54 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   11 +
 drivers/gpu/drm/msm/dpu_dbg.c  |3 -
 drivers/gpu/drm/msm/msm_drv.c  |   41 +-
 drivers/gpu/drm/msm/msm_drv.h  |   39 -
 16 files changed, 158 insertions(+), 2164 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h

diff --git a/chromeos/config/arm64/chromiumos-arm64.flavour.config 
b/chromeos/config/arm64/chromiumos-arm64.flavour.config
index c676a69..7b20c8b 100644
--- a/chromeos/config/arm64/chromiumos-arm64.flavour.config
+++ b/chromeos/config/arm64/chromiumos-arm64.flavour.config
@@ -117,14 +117,14 @@ CONFIG_DRM_MIPI_DSI=y
 CONFIG_DRM_MSM=y
 CONFIG_DRM_MSM_DPU=y
 CONFIG_DRM_MSM_DSI=y
-CONFIG_DRM_MSM_DSI_STAGING=y
+# CONFIG_DRM_MSM_DSI_STAGING is not set
 # CONFIG_DRM_MSM_HDCP is not set
 # CONFIG_DRM_MSM_HDMI is not set
 # CONFIG_DRM_MSM_HDMI_HDCP is not set
 # CONFIG_DRM_MSM_MDP4 is not set
 # CONFIG_DRM_MSM_MDP5 is not set
 # CONFIG_DRM_MSM_REGISTER_LOGGING is not set
-CONFIG_DRM_MSM_WRITEBACK=y
+# CONFIG_DRM_MSM_WRITEBACK is not set
 # CONFIG_DRM_NOUVEAU is not set
 CONFIG_DRM_PANEL_INNOLUX_P079ZCA=y
 # CONFIG_DRM_PANEL_JDI_LT070ME05000 is not set
diff --git a/chromeos/config/arm64/chromiumos-qualcomm.flavour.config 
b/chromeos/config/arm64/chromiumos-qualcomm.flavour.config
index e7f45f3..aad22a7 100644
--- a/chromeos/config/arm64/chromiumos-qualcomm.flavour.config
+++ b/chromeos/config/arm64/chromiumos-qualcomm.flavour.config
@@ -30,14 +30,14 @@ CONFIG_DRM_MIPI_DSI=y
 CONFIG_DRM_MSM=y
 CONFIG_DRM_MSM_DPU=y
 CONFIG_DRM_MSM_DSI=y
-CONFIG_DRM_MSM_DSI_STAGING=y
+# CONFIG_DRM_MSM_DSI_STAGING is not set
 # CONFIG_DRM_MSM_HDCP is not set
 # CONFIG_DRM_MSM_HDMI is not set
 # CONFIG_DRM_MSM_HDMI_HDCP is not set
 # CONFIG_DRM_MSM_MDP4 is not set
 # CONFIG_DRM_MSM_MDP5 is not set
 # CONFIG_DRM_MSM_REGISTER_LOGGING is not set
-CONFIG_DRM_MSM_WRITEBACK=y
+# CONFIG_DRM_MSM_WRITEBACK is not set
 CONFIG_DRM_PANEL_TRULY_WQXGA=y
 # CONFIG_DRM_PANEL_INNOLUX_P079ZCA is not set
 # CONFIG_DRM_PANEL_JDI_LT070ME05000 is not set
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b23a001..a8d8ad9 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -48,7 +48,6 @@ msm-y := \
disp/mdp5/mdp5_plane.o \
disp/mdp5/mdp5_smp.o \
disp/dpu1/dpu_color_processing.o \
-   disp/dpu1/dpu_connector.o \
disp/dpu1/dpu_core_irq.o \
disp/dpu1/dpu_core_perf.o \
disp/dpu1/dpu_crtc.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
deleted file mode 100644
index dc0978d..000
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ /dev/null
@@ -1,1184 +0,0 @@
-/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
-#include "msm_drv.h"
-#include "dpu_dbg.h"
-
-#include "dpu_kms.h"
-#include "dpu_connector.h"
-#ifdef CONFIG_DRM_MSM_DSI_STAGING
-#include 
-#include "dsi_drm.h"
-#include "dsi_display.h"
-#endif
-
-#define BL_NODE_NAME_SIZE 32
-
-#define DPU_DEBUG_CONN(c, fmt, ...) DPU_DEBUG("conn%d " fmt,\
-   (c) ? (c)->base.base.id : -1, 

Re: [PATCH] drm/rockchip: fix VOP vblank race

[John Keeping]

Hi Sandy,

On Tue, 10 Apr 2018 20:40:06 +0800, Sandy Huang wrote:

> Reviewed-by: Sandy huang 

Thanks for the review, but I don't see this in drm-misc yet.  Are you
planning to pick this up?

> 在 2018/3/29 0:03, John Keeping 写道:
> > We have seen a case of a bad reference count for vblanks with the
> > Rockchip VOP:
> >
> > [ cut here ]
> > WARNING: CPU: 1 PID: 383 at drivers/gpu/drm/drm_irq.c:1198 
> > drm_vblank_put+0x40/0xcc
> > Modules linked in: brcmfmac brcmutil
> > CPU: 1 PID: 383 Comm: kworker/u8:2 Not tainted 4.9.75-rt60 #1
> > Hardware name: Rockchip (Device Tree)
> > Workqueue: events_unbound flip_worker
> > Backtrace:
> > [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
> >  r7:c0b1b13c r6:600b0013 r5: r4:c0b1b13c
> > [] (show_stack) from [] (dump_stack+0x78/0x94)
> > [] (dump_stack) from [] (__warn+0xe4/0x104)
> >  r7:0009 r6:c03cf26c r5: r4:
> > [] (__warn) from [] (warn_slowpath_null+0x28/0x30)
> >  r9:eeb443a0 r8:eeb443c8 r7:ee8a5ec0 r6:ee8a5ec0 r5:edb47f00 r4:ee096200
> > [] (warn_slowpath_null) from [] 
> > (drm_vblank_put+0x40/0xcc)
> > [] (drm_vblank_put) from [] 
> > (drm_crtc_vblank_put+0x18/0x1c)
> >  r5:edb47f00 r4:ee3c8a80
> > [] (drm_crtc_vblank_put) from [] 
> > (vop_fb_unref_worker+0x18/0x24)
> > [] (vop_fb_unref_worker) from [] 
> > (flip_worker+0x98/0xb4)
> >  r5:edb47f00 r4:eeb443a8
> > [] (flip_worker) from [] 
> > (process_one_work+0x1a8/0x2fc)
> >  r9: r8:ee807d00 r7: r6:ee809c00 r5:eeb443a8 r4:edfe5f80
> > [] (process_one_work) from [] 
> > (worker_thread+0x2ac/0x458)
> >  r10:0088 r9:edfe5f98 r8:ee809c2c r7:c0b04100 r6:ee809c00 
> > r5:ee809c00
> >  r4:edfe5f80
> > [] (worker_thread) from [] (kthread+0xfc/0x10c)
> >  r10: r9: r8:c0135640 r7:edfe5f80 r6: 
> > r5:edf0e240
> >  r4:ee8a4000 r3:ed194e00
> > [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> >  r8: r7: r6: r5:c0139fc0 r4:edf0e240
> > ---[ end trace 0002 ]---
> >
> > It seems that this is caused by unfortunate timing between
> > vop_crtc_atomic_flush() and vop_handle_vblank() given the following
> > ordering:
> >
> > atomic_flushhandle_vblank
> > -
> >
> > drm_flip_work_queue
> > set_bit
> > if (test_and_clear_bit(...))
> > drm_flip_work_commit
> > drm_vblank_get
> >
> > This results in vop_fb_unref_worker (called as flip work) decrementing
> > the vblank refcount before it has been incremented.
> >
> > Signed-off-by: John Keeping 
> > ---
> >   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index 6755a9eea4b2..d4e1400aedf3 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -1017,9 +1017,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> > continue;
> >   
> > drm_framebuffer_get(old_plane_state->fb);
> > +   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > drm_flip_work_queue(>fb_unref_work, old_plane_state->fb);
> > set_bit(VOP_PENDING_FB_UNREF, >pending);
> > -   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > }
> >   }
> > 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote:
> I did not mean you should dma_map_sg/page. I just meant that using
> dma_map_resource to fill only the dma address part of the sg table seems
> perfectly sufficient.

But that is not how the interface work, especially facing sg_dma_len.

> Assuming you get an sg table that's been mapping by calling dma_map_sg was
> always a bit a case of bending the abstraction to avoid typing code. The
> only thing an importer ever should have done is look at the dma addresses
> in that sg table, nothing else.

The scatterlist is not a very good abstraction unfortunately, but it
it is spread all over the kernel.  And we do expect that anyone who
gets passed a scatterlist can use sg_page() or sg_virt() (which calls
sg_page()) on it.  Your changes would break that, and will cause major
trouble because of that.

If you want to expose p2p memory returned from dma_map_resource in
dmabuf do not use scatterlists for this please, but with a new interface
that explicitly passes a virtual address, a dma address and a length
and make it very clear that virt_to_page will not work on the virtual
address.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Mon, Apr 16, 2018 at 2:39 PM, Christoph Hellwig  wrote:
> On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote:
>> I did not mean you should dma_map_sg/page. I just meant that using
>> dma_map_resource to fill only the dma address part of the sg table seems
>> perfectly sufficient.
>
> But that is not how the interface work, especially facing sg_dma_len.
>
>> Assuming you get an sg table that's been mapping by calling dma_map_sg was
>> always a bit a case of bending the abstraction to avoid typing code. The
>> only thing an importer ever should have done is look at the dma addresses
>> in that sg table, nothing else.
>
> The scatterlist is not a very good abstraction unfortunately, but it
> it is spread all over the kernel.  And we do expect that anyone who
> gets passed a scatterlist can use sg_page() or sg_virt() (which calls
> sg_page()) on it.  Your changes would break that, and will cause major
> trouble because of that.
>
> If you want to expose p2p memory returned from dma_map_resource in
> dmabuf do not use scatterlists for this please, but with a new interface
> that explicitly passes a virtual address, a dma address and a length
> and make it very clear that virt_to_page will not work on the virtual
> address.

We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.

Of course we'll never feed such a strange sg table to a driver which
doesn't understand it, but allowing sg_page == NULL works perfectly
fine. At least for gpu drivers.

If that's not acceptable then I guess we could go over the entire tree
and frob all the gpu related code to switch over to a new struct
sg_table_might_not_be_struct_page_backed, including all the other
functions we added over the past few years to iterate over sg tables.
But seems slightly silly, given that sg tables seem to do exactly what
we need.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199407] Radeon night light/redshift flickers

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Should be fixed with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1cb19e8267a57c5174da09e0d52d1477baceccca

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

[DPU PATCH 1/6] drm/msm: remove display stream compression(DSC) support for SM845

[Jeykumar Sankaran]

Upstream DSI driver doesn't support DSC panels yet. Remove
the support for compression from DPU for now.

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/Makefile   |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 476 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   7 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   1 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  25 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  16 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 252 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 100 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|  17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|  48 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|  22 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |  13 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  55 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   8 -
 drivers/gpu/drm/msm/msm_drv.h  |  16 -
 20 files changed, 7 insertions(+), 1084 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 9c27991..b23a001 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -64,7 +64,6 @@ msm-y := \
disp/dpu1/dpu_hw_color_processing_v1_7.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_ds.o \
-   disp/dpu1/dpu_hw_dsc.o \
disp/dpu1/dpu_hw_dspp.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index 36607e3..1237efc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -39,12 +39,8 @@
 static const struct drm_prop_enum_list e_topology_name[] = {
{DPU_RM_TOPOLOGY_NONE,  "dpu_none"},
{DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
-   {DPU_RM_TOPOLOGY_SINGLEPIPE_DSC,"dpu_singlepipe_dsc"},
{DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_DSC,  "dpu_dualpipe_dsc"},
{DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE_DSC,  "dpu_dualpipemerge_dsc"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_DSCMERGE, "dpu_dualpipe_dscmerge"},
{DPU_RM_TOPOLOGY_PPSPLIT,   "dpu_ppsplit"},
 };
 static const struct drm_prop_enum_list e_topology_control[] = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 8756b2b..fade658 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -147,7 +147,7 @@ struct dpu_crtc_event {
  * @num_ctls  : Number of ctl paths in use
  * @num_mixers: Number of mixers in use
  * @mixers_swapped: Whether the mixers have been swapped for left/right update
- *  especially in the case of DSC Merge.
+   especially in the case of DSC Merge.
  * @mixers: List of active mixers
  * @event : Pointer to last received drm vblank event. If there is a
  *  pending vblank event, this will be non-null.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 198c618..6f12355 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -32,7 +32,6 @@
 #include "dpu_formats.h"
 #include "dpu_encoder_phys.h"
 #include "dpu_power_handle.h"
-#include "dpu_hw_dsc.h"
 #include "dpu_crtc.h"
 #include "dpu_trace.h"
 #include "dpu_core_irq.h"
@@ -152,7 +151,6 @@ enum dpu_enc_rc_states {
  * Only valid after enable. Cleared as disable.
  * @hw_pp  Handle to the pingpong blocks used for the display. No.
  * pingpong blocks can be different than num_phys_encs.
- * @hw_dsc:Array of DSC block handles used for the display.
  * @intfs_swapped  Whether or not the phys_enc interfaces have been swapped
  * for partial update right-only cases, such as pingpong
  * split where virtual pingpong does not generate IRQs
@@ -199,7 +197,6 @@ struct dpu_encoder_virt {
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
struct dpu_hw_pingpong 

[DPU PATCH 4/6] drm/msm: strip down custom event ioctl's

[Jeykumar Sankaran]

Remove custom ioctl support in SDM845 which allows
user space to register/unregister for hw events.

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 218 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  31 -
 drivers/gpu/drm/msm/msm_drv.c| 201 
 drivers/gpu/drm/msm/msm_kms.h|   2 -
 5 files changed, 1 insertion(+), 452 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 8e464fa..387919a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -39,31 +39,6 @@
 #include "dpu_core_perf.h"
 #include "dpu_trace.h"
 
-struct dpu_crtc_irq_info {
-   struct dpu_irq_callback irq;
-   u32 event;
-   int (*func)(struct drm_crtc *crtc, bool en,
-   struct dpu_irq_callback *irq);
-   struct list_head list;
-};
-
-struct dpu_crtc_custom_events {
-   u32 event;
-   int (*func)(struct drm_crtc *crtc, bool en,
-   struct dpu_irq_callback *irq);
-};
-
-static int dpu_crtc_power_interrupt_handler(struct drm_crtc *crtc_drm,
-   bool en, struct dpu_irq_callback *ad_irq);
-static int dpu_crtc_idle_interrupt_handler(struct drm_crtc *crtc_drm,
-   bool en, struct dpu_irq_callback *idle_irq);
-
-static struct dpu_crtc_custom_events custom_events[] = {
-   {DRM_EVENT_AD_BACKLIGHT, dpu_cp_ad_interrupt},
-   {DRM_EVENT_CRTC_POWER, dpu_crtc_power_interrupt_handler},
-   {DRM_EVENT_IDLE_NOTIFY, dpu_crtc_idle_interrupt_handler}
-};
-
 /* layer mixer index on dpu_crtc */
 #define LEFT_MIXER 0
 #define RIGHT_MIXER 1
@@ -2455,9 +2430,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
void *arg)
struct drm_encoder *encoder;
struct dpu_crtc_mixer *m;
u32 i, misr_status;
-   unsigned long flags;
-   struct dpu_crtc_irq_info *node = NULL;
-   int ret = 0;
 
if (!crtc) {
DPU_ERROR("invalid crtc\n");
@@ -2479,17 +2451,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
void *arg)
dpu_encoder_virt_restore(encoder);
}
 
-   spin_lock_irqsave(_crtc->spin_lock, flags);
-   list_for_each_entry(node, _crtc->user_event_list, list) {
-   ret = 0;
-   if (node->func)
-   ret = node->func(crtc, true, >irq);
-   if (ret)
-   DPU_ERROR("%s failed to enable event %x\n",
-   dpu_crtc->name, node->event);
-   }
-   spin_unlock_irqrestore(_crtc->spin_lock, flags);
-
dpu_cp_crtc_post_ipc(crtc);
 
for (i = 0; i < dpu_crtc->num_mixers; ++i) {
@@ -2514,18 +2475,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
void *arg)
dpu_crtc->misr_data[i];
}
 
-   spin_lock_irqsave(_crtc->spin_lock, flags);
-   node = NULL;
-   list_for_each_entry(node, _crtc->user_event_list, list) {
-   ret = 0;
-   if (node->func)
-   ret = node->func(crtc, false, >irq);
-   if (ret)
-   DPU_ERROR("%s failed to disable event %x\n",
-   dpu_crtc->name, node->event);
-   }
-   spin_unlock_irqrestore(_crtc->spin_lock, flags);
-
dpu_cp_crtc_pre_ipc(crtc);
break;
case DPU_POWER_EVENT_POST_DISABLE:
@@ -2553,8 +2502,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
struct drm_display_mode *mode;
struct drm_encoder *encoder;
struct msm_drm_private *priv;
-   unsigned long flags;
-   struct dpu_crtc_irq_info *node = NULL;
struct drm_event event;
u32 power_on;
int ret;
@@ -2614,17 +2561,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
atomic_set(_crtc->frame_pending, 0);
}
 
-   spin_lock_irqsave(_crtc->spin_lock, flags);
-   list_for_each_entry(node, _crtc->user_event_list, list) {
-   ret = 0;
-   if (node->func)
-   ret = node->func(crtc, false, >irq);
-   if (ret)
-   DPU_ERROR("%s failed to disable event %x\n",
-   dpu_crtc->name, node->event);
-   }
-   spin_unlock_irqrestore(_crtc->spin_lock, flags);
-
dpu_core_perf_crtc_update(crtc, 0, true);
 
drm_for_each_encoder(encoder, crtc->dev) {
@@ -2656,8 +2592,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
struct dpu_crtc 

[DPU PATCH 3/6] drm/msm: remove panel autorefresh support for SDM845

[Jeykumar Sankaran]

Remove autorefresh support for smart panels in SDM845 for now.
It needs more discussion to figure out the user space
communication to set preference for the feature.

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  37 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |  20 --
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 298 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|  41 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|  18 --
 6 files changed, 11 insertions(+), 410 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index f7e9f76..dc0978d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -24,9 +24,6 @@
 
 #define BL_NODE_NAME_SIZE 32
 
-/* Autorefresh will occur after FRAME_CNT frames. Large values are unlikely */
-#define AUTOREFRESH_MAX_FRAME_CNT 6
-
 #define DPU_DEBUG_CONN(c, fmt, ...) DPU_DEBUG("conn%d " fmt,\
(c) ? (c)->base.base.id : -1, ##__VA_ARGS__)
 
@@ -1126,10 +1123,6 @@ struct drm_connector *dpu_connector_init(struct 
drm_device *dev,
CONNECTOR_PROP_AD_BL_SCALE);
 #endif
 
-   msm_property_install_range(_conn->property_info, "autorefresh",
-   0x0, 0, AUTOREFRESH_MAX_FRAME_CNT, 0,
-   CONNECTOR_PROP_AUTOREFRESH);
-
/* enum/bitmask properties */
msm_property_install_enum(_conn->property_info, "topology_name",
DRM_MODE_PROP_IMMUTABLE, 0, e_topology_name,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 32375b1..3004569 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -815,7 +815,6 @@ static void _dpu_encoder_resource_control_helper(struct 
drm_encoder *drm_enc,
 static int dpu_encoder_resource_control(struct drm_encoder *drm_enc,
u32 sw_event)
 {
-   bool autorefresh_enabled = false;
unsigned int lp, idle_timeout;
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
@@ -922,13 +921,6 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
return 0;
}
 
-   /* schedule delayed off work if autorefresh is disabled */
-   if (dpu_enc->cur_master &&
-   dpu_enc->cur_master->ops.is_autorefresh_enabled)
-   autorefresh_enabled =
-   dpu_enc->cur_master->ops.is_autorefresh_enabled(
-   dpu_enc->cur_master);
-
/* set idle timeout based on master connector's lp value */
if (dpu_enc->cur_master)
lp = dpu_connector_get_lp(
@@ -941,13 +933,12 @@ static int dpu_encoder_resource_control(struct 
drm_encoder *drm_enc,
else
idle_timeout = dpu_enc->idle_timeout;
 
-   if (!autorefresh_enabled)
-   kthread_queue_delayed_work(
-   _thread->worker,
-   _enc->delayed_off_work,
-   msecs_to_jiffies(idle_timeout));
+   kthread_queue_delayed_work(
+   _thread->worker,
+   _enc->delayed_off_work,
+   msecs_to_jiffies(idle_timeout));
+
DPU_EVT32(DRMID(drm_enc), sw_event, dpu_enc->rc_state,
-   autorefresh_enabled,
idle_timeout, DPU_EVTLOG_FUNC_CASE2);
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work scheduled\n",
sw_event);
@@ -1990,7 +1981,6 @@ static void dpu_encoder_vsync_event_handler(struct 
timer_list *t)
struct drm_encoder *drm_enc = _enc->base;
struct msm_drm_private *priv;
struct msm_drm_thread *event_thread;
-   bool autorefresh_enabled = false;
 
if (!drm_enc->dev || !drm_enc->dev->dev_private ||
!drm_enc->crtc) {
@@ -2011,22 +2001,7 @@ static void dpu_encoder_vsync_event_handler(struct 
timer_list *t)
return;
}
 
-   if (dpu_enc->cur_master &&
-   dpu_enc->cur_master->ops.is_autorefresh_enabled)
-   autorefresh_enabled =
-   dpu_enc->cur_master->ops.is_autorefresh_enabled(
-   dpu_enc->cur_master);
-
-   /*
-* Queue work to update the vsync event timer
-* if autorefresh is enabled.
-*/
-   DPU_EVT32_VERBOSE(autorefresh_enabled);
-   if (autorefresh_enabled)
-   kthread_queue_work(_thread->worker,
-

Re: [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel

[Sean Paul]

On Mon, Apr 16, 2018 at 12:41 PM Bjorn Andersson

wrote:

> On Sat 14 Apr 00:25 PDT 2018, Abhinav Kumar wrote:

> > Register truly panel as a backlight led device and
> > provide methods to control its backlight operation.
> >
> > Changes in v2:
> > - Removed redundant NULL checks
> > - Arranged headers alphabetically
> > - Formatting fixes

> The change log goes below the "---" line.

FYI: In drm, people generally prefer to put them above --- so the history
is preserved in the logs. Some choose to annotate with the name of the
person suggesting the change for added information/credit.

Sean



> >
> > Signed-off-by: Abhinav Kumar 
> > ---
> [..]
> > +static int truly_backlight_setup(struct truly_wqxga *ctx)
> > +{
> > + struct backlight_properties props;
> > + char bl_node_name[BL_NODE_NAME_SIZE];
> > +
> > + if (!ctx->backlight) {
> > + memset(, 0, sizeof(props));
> > + props.type = BACKLIGHT_RAW;
> > + props.power = FB_BLANK_UNBLANK;
> > + props.max_brightness = 4096;
> > +
> > + snprintf(bl_node_name, BL_NODE_NAME_SIZE,
"panel%u-backlight",
> > +  PRIM_DISPLAY_NODE);
> > +
> > + ctx->backlight =  backlight_device_register(bl_node_name,
> > + ctx->dev, ctx,
> > + _backlight_device_ops, );
> > +
> > + if (IS_ERR_OR_NULL(ctx->backlight)) {
> > + pr_err("Failed to register backlight\n");
> > + ctx->backlight = NULL;
> > + return -ENODEV;
> > + }
> > +
> > + /* Register with the LED driver interface */
> > + led_trigger_register_simple("bkl-trigger", >wled);
> > +
> > + if (!ctx->wled) {
> > + pr_err("backlight led registration failed\n");
> > + return -ENODEV;
> > + }

> It seems like you're registering a backlight driver for the sake of
> invoking the LED backlight trigger to control the WLED.

> The WLED is a backlight driver, so all you should have to do is add the
> following line to your probe:

>  ctx->backlight = devm_of_find_backlight(dev);

> and then add "backlight = <>" to your dt node.

> Regards,
> Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [[RFC]DPU PATCH 1/2] drm/bridge: add support for sn65dsi86 bridge driver

[Sean Paul]

On Mon, Apr 16, 2018 at 11:32:50AM +0530, spa...@codeaurora.org wrote:
> On 2018-04-14 00:59, Sean Paul wrote:
> > On Fri, Apr 13, 2018 at 10:53:00AM +0530, Sandeep Panda wrote:
> > > Add support for TI's sn65dsi86 dsi2edp bridge chip.
> > > The chip converts DSI transmitted signal to eDP signal,
> > > which is fed to the connected eDP panel.
> > > 
> > > This chip can be controlled via either i2c interface or
> > > dsi interface. Currently in driver all the control registers
> > > are being accessed through i2c interface only.
> > > Also as of now HPD support has not been added to bridge
> > > chip driver.
> > > 
> > > Signed-off-by: Sandeep Panda 



> > > +{
> > > + struct mipi_dsi_host *host;
> > > + struct mipi_dsi_device *dsi;
> > > + struct sn65dsi86 *pdata = bridge_to_sn65dsi86(bridge);
> > > + int ret;
> > > + const struct mipi_dsi_device_info info = { .type = "sn65dsi86",
> > > +.channel = 0,
> > > +.node = NULL,
> > > +  };
> > > +
> > > + if (!bridge->encoder) {
> > > + DRM_ERROR("Parent encoder object not found");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + /* HPD not supported */
> > > + pdata->connector.polled = 0;
> > > +
> > 
> > You'll need to refactor the below to accommodate panels. If you're not
> > planning
> > on supporting hotplug, you should probably remove all of the
> > connector-related
> > stuff from this driver, since you will always be using a panel driver.
> > 
> 
> Thanks for reviewing the patch in detail.
> 
> I have one doubt here. If we remove connector from bridge driver, then how
> will detect()
> and get_modes() called. If you are suggesting to use panel func's detect()
> and get_mode()
> then it might not work, because once upstream DSI driver sees an external
> bridge is connected
> to DSI, then it does not create a connector of it own, it expects the
> external bridge
> to create the connector node. I think here the external bridge has to create
> the connector
> and when detect() and get_modes() call come to external bridge then it
> should query connected
> panel's detect() and get_modes() API.
> 

Right, thanks for setting me straight. You'll need to call the drm_panel_*
helper functions if the panel is present for the connector hooks.

Sean




-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [DPU PATCH v2 1/2] drm/msm/dsi: check video mode engine status before waiting

[Sean Paul]

On Fri, Apr 13, 2018 at 03:04:48PM -0700, abhin...@codeaurora.org wrote:
> On 2018-04-13 14:10, abhin...@codeaurora.org wrote:
> > Hi Sean
> > 
> > Thanks for the review.
> > 
> > Reply inline.
> > 
> > On 2018-04-13 13:26, Sean Paul wrote:
> > > On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
> > > > Make sure the video mode engine is on before waiting
> > > > for the video done interrupt.
> > > > 
> > > > Otherwise it leads to silent timeouts increasing display
> > > > turn ON time.
> > > > 
> > > > Changes in v2:
> > > > - Replace pr_err with dev_err
> > > > - Changed error message
> > > > 
> > > > Signed-off-by: Abhinav Kumar 
> > > > ---
> > > >  drivers/gpu/drm/msm/dsi/dsi_host.c | 15 +++
> > > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > index 7a03a94..5b7b290 100644
> > > > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > @@ -173,6 +173,7 @@ struct msm_dsi_host {
> > > > 
> > > > bool registered;
> > > > bool power_on;
> > > > +   bool enabled;
> > > > int irq;
> > > >  };
> > > > 
> > > > @@ -986,13 +987,19 @@ static void dsi_set_tx_power_mode(int
> > > > mode, struct msm_dsi_host *msm_host)
> > > > 
> > > >  static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
> > > >  {
> > > > +   u32 ret = 0;
> > > > +   struct device *dev = _host->pdev->dev;
> > > > +
> > > > dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
> > > > 
> > > > reinit_completion(_host->video_comp);
> > > > 
> > > > -   wait_for_completion_timeout(_host->video_comp,
> > > > +   ret = wait_for_completion_timeout(_host->video_comp,
> > > > msecs_to_jiffies(70));
> > > > 
> > > > +   if (ret <= 0)
> > > > +   dev_err(dev, "wait for video done timed out\n");
> > > > +
> > > > dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0);
> > > >  }
> > > > 
> > > > @@ -1001,7 +1008,7 @@ static void dsi_wait4video_eng_busy(struct
> > > > msm_dsi_host *msm_host)
> > > > if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
> > > > return;
> > > > 
> > > > -   if (msm_host->power_on) {
> > > > +   if (msm_host->power_on && msm_host->enabled) {
> > > > dsi_wait4video_done(msm_host);
> > > > /* delay 4 ms to skip BLLP */
> > > > usleep_range(2000, 4000);
> > > > @@ -2203,7 +2210,7 @@ int msm_dsi_host_enable(struct
> > > > mipi_dsi_host *host)
> > > >  *  pm_runtime_put_autosuspend(_host->pdev->dev);
> > > >  * }
> > > >  */
> > > > -
> > > > +   msm_host->enabled = true;
> > > > return 0;
> > > >  }
> > > > 
> > > > @@ -2219,7 +2226,7 @@ int msm_dsi_host_disable(struct
> > > > mipi_dsi_host *host)
> > > >  * Reset to disable video engine so that we can send off cmd.
> > > >  */
> > > > dsi_sw_reset(msm_host);
> > > > -
> > > > +   msm_host->enabled = false;
> > > 
> > > This should go at the start of the function. Also, it's unclear from
> > > this patch,
> > > but I assume this is protected by a lock?
> > > 
> > > Sean
> > [Abhinav] Yes, will move this to the start.
> > No, there is no lock here but at this point doesnt need one.
> > The reason is that, this variable will be written to and read by the
> > same process
> > (suspend thread OR resume thread which sends the panel ON/OFF commands).
> > If we decide to expose other interfaces to send commands like debugfs
> > or sysfs and
> > introduce more threads, we will add the locking.
> [Abhinav] Correction to my prev comment, we do have the msm_host->cmd_mutex
> which will
> ensure this entire process is protected. That should suffice.

Ok, thanks for confirming. Could you also please split this patch into the
wait4video_done ret fix and the ->enabled addition? The 2 seem mostly unrelated.

Sean

> > > 
> > > 
> > > > return 0;
> > > >  }
> > > > 
> > > > --
> > > > The Qualcomm Innovation Center, Inc. is a member of the Code
> > > > Aurora Forum,
> > > > a Linux Foundation Collaborative Project
> > > > 
> > > > ___
> > > > Freedreno mailing list
> > > > freedr...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/freedreno
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> > in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH 2/6] drm/msm: remove support for ping pong split topology

[Jeykumar Sankaran]

Ping pong split topology was meant for low end soc's which
doesn't have enough layer mixers to support split panels.
Considering how uncommon the topology is for current chipset's and
also to simply the driver programming, striping off the support
for SDM845.

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  19 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 179 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   5 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 110 +
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  21 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |  33 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |  11 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h   |   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  37 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   2 -
 13 files changed, 15 insertions(+), 415 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index 1237efc..f7e9f76 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -41,8 +41,8 @@
{DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
{DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
{DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
-   {DPU_RM_TOPOLOGY_PPSPLIT,   "dpu_ppsplit"},
 };
+
 static const struct drm_prop_enum_list e_topology_control[] = {
{DPU_RM_TOPCTL_RESERVE_LOCK,"reserve_lock"},
{DPU_RM_TOPCTL_RESERVE_CLEAR,   "reserve_clear"},
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 516458e..8e464fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1914,23 +1914,6 @@ static void _dpu_crtc_setup_mixers(struct drm_crtc *crtc)
mutex_unlock(_crtc->crtc_lock);
 }
 
-static void _dpu_crtc_setup_is_ppsplit(struct drm_crtc_state *state)
-{
-   int i;
-   struct dpu_crtc_state *cstate;
-
-   cstate = to_dpu_crtc_state(state);
-
-   cstate->is_ppsplit = false;
-   for (i = 0; i < cstate->num_connectors; i++) {
-   struct drm_connector *conn = cstate->connectors[i];
-
-   if (dpu_connector_get_topology_name(conn) ==
-   DPU_RM_TOPOLOGY_PPSPLIT)
-   cstate->is_ppsplit = true;
-   }
-}
-
 static void _dpu_crtc_setup_lm_bounds(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
@@ -1993,7 +1976,6 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc,
 
if (!dpu_crtc->num_mixers) {
_dpu_crtc_setup_mixers(crtc);
-   _dpu_crtc_setup_is_ppsplit(crtc->state);
_dpu_crtc_setup_lm_bounds(crtc, crtc->state);
}
 
@@ -2901,7 +2883,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
 
mixer_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
 
-   _dpu_crtc_setup_is_ppsplit(state);
_dpu_crtc_setup_lm_bounds(crtc, state);
 
 /* get plane state for all drm planes associated with crtc state */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6f12355..32375b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,6 @@ void dpu_encoder_helper_split_config(
struct dpu_encoder_virt *dpu_enc;
struct split_pipe_cfg cfg = { 0 };
struct dpu_hw_mdp *hw_mdptop;
-   enum dpu_rm_topology_name topology;
struct msm_display_info *disp_info;
 
if (!phys_enc || !phys_enc->hw_mdptop || !phys_enc->parent) {
@@ -569,8 +568,6 @@ void dpu_encoder_helper_split_config(
if (phys_enc->split_role == ENC_ROLE_SOLO) {
if (hw_mdptop->ops.setup_split_pipe)
hw_mdptop->ops.setup_split_pipe(hw_mdptop, );
-   if (hw_mdptop->ops.setup_pp_split)
-   hw_mdptop->ops.setup_pp_split(hw_mdptop, );
return;
}
 
@@ -582,29 +579,11 @@ void dpu_encoder_helper_split_config(
phys_enc->ops.needs_single_flush(phys_enc))
cfg.split_flush_en = true;
 
-   topology = dpu_connector_get_topology_name(phys_enc->connector);
-   if (topology == DPU_RM_TOPOLOGY_PPSPLIT)
-   cfg.pp_split_slave = cfg.intf;
-   else
-   cfg.pp_split_slave = INTF_MAX;
-
if (phys_enc->split_role == ENC_ROLE_MASTER) {
DPU_DEBUG_ENC(dpu_enc, "enable %d\n", cfg.en);
 
if 

Re: [DPU PATCH 2/2] drm/panel: add backlight control support for truly panel

[Sean Paul]

On Fri, Apr 13, 2018 at 01:59:29PM -0700, abhin...@codeaurora.org wrote:
> Hi Sean
> 
> Thanks for the comments.
> 
> Some replies inline.
> 
> On 2018-04-13 13:46, Sean Paul wrote:
> > On Sat, Apr 07, 2018 at 12:06:53AM -0700, Abhinav Kumar wrote:
> > > Register truly panel as a backlight led device and
> > > provide methods to control its backlight operation.
> > > 
> > > Signed-off-by: Abhinav Kumar 
> > > ---



> > > + if (!ctx->backlight) {
> > > + memset(, 0, sizeof(props));
> > > + props.type = BACKLIGHT_RAW;
> > > + props.power = FB_BLANK_UNBLANK;
> > > + props.max_brightness = 4096;
> > > +
> > > + snprintf(bl_node_name, BL_NODE_NAME_SIZE, "panel%u-backlight",
> > > +  PRIM_DISPLAY_NODE);
> > 
> > Given that PRIM_DISPLAY_NODE is always 0, this seems like overkill for a
> > pretty
> > generic name "panel0-backlight". So let's just call it "truly_backlight"
> > in the
> > register call.
> > 
> [Abhinav] The reason for keeping it "panel0-backlight" is because userspace
> is using
> this node name to write the backlight. Changing the name will need more
> changes in our
> userspace.
> 

Unless the userspace is opensource (I'm guessing it's not?), that's not
something we need to code around. It sounds like this is mostly a moot point
given Bjorn's comments on the v2.

Sean



-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

[Eric Anholt]

The GPU subsystem node was a workaround to have a central device to
bind V3D and display to.  Following the lead of 246774d17fc0
("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
the subsystem node usage and just create a platform device for the DRM
device to attach to if any of the subsystem devices are present.

v2: Simplify the DT walking code.

Signed-off-by: Eric Anholt 
---
 .../bindings/display/brcm,bcm-vc4.txt |  7 -
 drivers/gpu/drm/vc4/vc4_drv.c | 29 ++-
 drivers/gpu/drm/vc4/vc4_hvs.c |  1 +
 drivers/gpu/drm/vc4/vc4_v3d.c |  1 +
 4 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 284e2b14cfbe..5fd4717101d6 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -4,9 +4,6 @@ The VC4 device present on the Raspberry Pi includes a display 
system
 with HDMI output and the HVS (Hardware Video Scaler) for compositing
 display planes.
 
-Required properties for VC4:
-- compatible:  Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
-
 Required properties for Pixel Valve:
 - compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
  "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
@@ -153,10 +150,6 @@ v3d: v3d@7ec0 {
interrupts = <1 10>;
 };
 
-vc4: gpu {
-   compatible = "brcm,bcm2835-vc4";
-};
-
 panel: panel {
compatible = "ontat,yx700wv03", "simple-panel";
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 7c95ed5c5cac..13b840b534b8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -364,22 +364,30 @@ static int vc4_platform_drm_remove(struct platform_device 
*pdev)
return 0;
 }
 
-static const struct of_device_id vc4_of_match[] = {
-   { .compatible = "brcm,bcm2835-vc4", },
-   { .compatible = "brcm,cygnus-vc4", },
-   {},
-};
-MODULE_DEVICE_TABLE(of, vc4_of_match);
-
 static struct platform_driver vc4_platform_driver = {
.probe  = vc4_platform_drm_probe,
.remove = vc4_platform_drm_remove,
.driver = {
.name   = "vc4-drm",
-   .of_match_table = vc4_of_match,
},
 };
 
+static bool
+driver_of_table_has_a_match(const struct platform_driver *driver)
+{
+   struct device_node *node;
+
+   node = of_find_matching_node_and_match(NULL,
+  driver->driver.of_match_table,
+  NULL);
+   if (of_device_is_available(node)) {
+   of_node_put(node);
+   return true;
+   }
+
+   return false;
+}
+
 static int __init vc4_drm_register(void)
 {
int ret;
@@ -389,6 +397,11 @@ static int __init vc4_drm_register(void)
if (ret)
return ret;
 
+   if (driver_of_table_has_a_match(_v3d_driver) ||
+   driver_of_table_has_a_match(_hvs_driver)) {
+   platform_device_register_simple("vc4-drm", -1, NULL, 0);
+   }
+
return platform_driver_register(_platform_driver);
 }
 
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2b62fc5b8d85..730813ee74ae 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -262,6 +262,7 @@ static const struct of_device_id vc4_hvs_dt_match[] = {
{ .compatible = "brcm,bcm2835-hvs" },
{}
 };
+MODULE_DEVICE_TABLE(of, vc4_hvs_dt_match);
 
 struct platform_driver vc4_hvs_driver = {
.probe = vc4_hvs_dev_probe,
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index bfc2fa73d2ae..e77e9ebbab4b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -459,6 +459,7 @@ static const struct of_device_id vc4_v3d_dt_match[] = {
{ .compatible = "brcm,vc4-v3d" },
{}
 };
+MODULE_DEVICE_TABLE(of, vc4_v3d_dt_match);
 
 struct platform_driver vc4_v3d_driver = {
.probe = vc4_v3d_dev_probe,
-- 
2.17.0

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

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
Is the driver build as a module or built into the kernel?

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

[Bug 199407] Radeon night light/redshift flickers

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
It's in 4.17 and should show up in 4.16 via stable updates over the next few
weeks.

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

[Bug 199407] Radeon night light/redshift flickers

[bugzilla-daemon]

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

--- Comment #4 from Dan (dan...@consultd.de) ---
excellent!! Thank you!!

Dan

On 4/16/2018 5:19 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=199407
>
> --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
> It's in 4.17 and should show up in 4.16 via stable updates over the next few
> weeks.
>

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

[PATCH] drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state

[Imre Deak]

LSPCON adapters in low-power state may ignore the first I2C write during
TMDS output buffer enabling, resulting in a blank screen even with an
otherwise enabled pipe. Fix this by reading back and validating the
written value a few times.

The problem was noticed on GLK machines with an onboard LSPCON adapter
after entering/exiting DC5 power state. Doing an I2C read of the adapter
ID as the first transaction - instead of the I2C write to enable the
TMDS buffers - returns the correct value. Based on this we assume that
the transaction itself is sent properly, it's only the adapter that is
not ready for some reason to accept this first write after waking from
low-power state. In my case the second I2C write attempt always
succeeded.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
Cc: Clinton Taylor 
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39 +--
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 02a50929af67..e7f4fe2848a5 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -350,19 +350,44 @@ int drm_dp_dual_mode_set_tmds_output(enum 
drm_dp_dual_mode_type type,
 {
uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
ssize_t ret;
+   int retry;
 
if (type < DRM_DP_DUAL_MODE_TYPE2_DVI)
return 0;
 
-   ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
-_oen, sizeof(tmds_oen));
-   if (ret) {
-   DRM_DEBUG_KMS("Failed to %s TMDS output buffers\n",
- enable ? "enable" : "disable");
-   return ret;
+   /*
+* LSPCON adapters in low-power state may ignore the first write, so
+* read back and verify the written value a few times.
+*/
+   for (retry = 0; retry < 3; retry++) {
+   uint8_t tmp;
+
+   ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
+_oen, sizeof(tmds_oen));
+   if (ret) {
+   DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d 
attempts)\n",
+ enable ? "enable" : "disable",
+ retry + 1);
+   return ret;
+   }
+
+   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
+   , sizeof(tmp));
+   if (ret) {
+   DRM_DEBUG_KMS("I2C read failed during TMDS output 
buffer %s (%d attempts)\n",
+ enable ? "enabling" : "disabling",
+ retry + 1);
+   return ret;
+   }
+
+   if (tmp == tmds_oen)
+   return 0;
}
 
-   return 0;
+   DRM_DEBUG_KMS("I2C write value mismatch during TMDS output buffer %s\n",
+ enable ? "enabling" : "disabling");
+
+   return -EIO;
 }
 EXPORT_SYMBOL(drm_dp_dual_mode_set_tmds_output);
 
-- 
2.13.2

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

Re: [Intel-gfx] [RFC v4 19/25] drm/client: Finish the in-kernel client API

[Noralf Trønnes]

Den 16.04.2018 10.27, skrev Daniel Vetter:

On Sat, Apr 14, 2018 at 01:53:12PM +0200, Noralf Trønnes wrote:

The modesetting code is already present, this adds the rest of the API.

Mentioning the TODO in the commit message would be good. Helps readers
like me who have an attention span measured in seconds :-)

Just commenting on the create_buffer leak here


+static struct drm_client_buffer *
+drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, 
u32 format)
+{
+   struct drm_mode_create_dumb dumb_args = { };
+   struct drm_prime_handle prime_args = { };
+   struct drm_client_buffer *buffer;
+   struct dma_buf *dma_buf;
+   void *vaddr;
+   int ret;
+
+   buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
+   if (!buffer)
+   return ERR_PTR(-ENOMEM);
+
+   buffer->client = client;
+   buffer->width = width;
+   buffer->height = height;
+   buffer->format = format;
+
+   dumb_args.width = buffer->width;
+   dumb_args.height = buffer->height;
+   dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
+   ret = drm_mode_create_dumb(client->dev, _args, client->file);
+   if (ret)
+   goto err_free;
+
+   buffer->handle = dumb_args.handle;
+   buffer->pitch = dumb_args.pitch;
+   buffer->size = dumb_args.size;
+
+   prime_args.handle = dumb_args.handle;
+   ret = drm_prime_handle_to_fd(client->dev, _args, client->file);
+   if (ret)
+   goto err_delete;
+
+   dma_buf = dma_buf_get(prime_args.fd);
+   if (IS_ERR(dma_buf)) {
+   ret = PTR_ERR(dma_buf);
+   goto err_delete;
+   }
+
+   /*
+* If called from a worker the dmabuf fd isn't closed and the ref
+* doesn't drop to zero on free.
+* If I use __close_fd() it's all fine, but that function is not 
exported.
+*
+* How do I get rid of this fd when in a worker/kernel thread?
+* The fd isn't used beyond this function.
+*/
+// WARN_ON(__close_fd(current->files, prime_args.fd));

Hm, this isn't 100% what I had in mind as the sequence for generic buffer
creation. Pseudo-code:

ret = drm_mode_create_dumb(client->dev, _args, client->file);
if (ret)
goto err_free;

gem_bo = drm_gem_object_lookup(client->file, dumb_args.handle);

gives you _really_ directly the underlying gem_bo. Of course this doesn't
work for non-gem based driver, but reality is that (almost) all of them
are. And we will not accept any new drivers which aren't gem based. So
ignoring vmwgfx for this drm_client work is imo perfectly fine. We should
ofc keep the option in the fb helpers to use non-gem buffers (so that
vmwgfx could switch over from their own in-driver fbdev helpers). All we
need for that is to keep the fb_probe callback.

Was there any other reason than vmwgfx for using prime buffers instead of
just directly using gem?


The reason for using a prime buffer is that it gives me easy access to a
dma_buf which I use to get the virtual address (dma_buf_vmap) and for
mmap (dma_buf_mmap).

Would this stripped down version of drm_gem_prime_handle_to_fd() work?

struct dma_buf *drm_gem_to_dmabuf(struct drm_gem_object *obj)
{
    struct dma_buf *dmabuf;

    mutex_lock(>dev->object_name_lock);
    /* re-export the original imported object */
    if (obj->import_attach) {
        dmabuf = obj->import_attach->dmabuf;
        get_dma_buf(dmabuf);
        goto out;
    }

    if (obj->dma_buf) {
        dmabuf = obj->dma_buf;
        get_dma_buf(dmabuf);
        goto out;
    }

    dmabuf = export_and_register_object(obj->dev, obj, 0);
out:
    mutex_unlock(>dev->object_name_lock);

    return dmabuf;
}

Now I could do this:

    ret = drm_mode_create_dumb(dev, _args, file);

    obj = drm_gem_object_lookup(file, dumb_args.handle);

    dmabuf = drm_gem_to_dmabuf(obj);

    vaddr = dma_buf_vmap(dmabuf);


Noralf.

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

Re: [PATCH v5] drm: Fix HDCP downstream dev count read

[Sean Paul]

On Thu, Apr 5, 2018 at 8:09 AM Ramalingam C  wrote:

> In both HDMI and DP, device count is represented by 6:0 bits of a
> register(BInfo/Bstatus)

> So macro for bitmasking the device_count is fixed(0x3F->0x7F).

> v3:
>Retained the Rb-ed.
> v4:
>%s/drm\/i915/drm [rodrigo]
> v5:
>Added "Fixes:" and HDCP keyword in subject [Rodrigo, Sean Paul]

> Signed-off-by: Ramalingam C 


Thank you for your patch, I've pushed it to -misc-fixes

Sean


> Fixes: 495eb7f877ab drm: Add some HDCP related #defines
> cc: Sean Paul 
> Reviewed-by: Sean Paul 
> ---
>   include/drm/drm_hdcp.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index 562fa7df2637..98e63d870139 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -19,7 +19,7 @@
>   #define DRM_HDCP_RI_LEN2
>   #define DRM_HDCP_V_PRIME_PART_LEN  4
>   #define DRM_HDCP_V_PRIME_NUM_PARTS 5
> -#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
> +#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
>   #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)   (x & BIT(3))
>   #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)(x & BIT(7))

> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

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

[Bug 106054] [vega10] powerplay non critical errors on vega 56 with vega 64bios

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
Flashing random vbioses is not supported and will likely void your warranty.

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

[PATCH v1 2/2] i915: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from
drm_connector_state within AVI infoframe in order to properly handle
external HDMI TV content-type setting.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   |  4 
 drivers/gpu/drm/i915/intel_modes.c  | 10 ++
 4 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..61ddb5871d8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5bd2263407b2..07fd7ba21f38 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1818,6 +1818,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct 
i2c_adapter *adapter);
 void intel_attach_force_audio_property(struct drm_connector *connector);
 void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_content_type_property(struct drm_connector *connector);
 
 
 /* intel_overlay.c */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..cd484276e9b0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   frame.avi.content_type = connector->state->content_type;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -2065,7 +2067,9 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+   intel_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   connector->state->content_type = HDMI_CONTENT_TYPE_GRAPHICS;
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index b39846613e3c..232811ab71a3 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -133,3 +133,13 @@ intel_attach_aspect_ratio_property(struct drm_connector 
*connector)
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
 }
+
+void
+intel_attach_content_type_property(struct drm_connector *connector)
+{
+   if (!drm_mode_create_content_type_property(connector->dev))
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.content_type_property,
+   DRM_MODE_CONTENT_TYPE_GRAPHICS);
+}
+
-- 
2.17.0

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

[PATCH v1 1/2] drm: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added content_type property to
drm_connector_state in order to properly handle
external HDMI TV content-type setting.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  4 
 drivers/gpu/drm/drm_connector.c  | 34 
 drivers/gpu/drm/drm_edid.c   |  1 +
 include/drm/drm_connector.h  | 10 
 include/drm/drm_mode_config.h|  5 
 include/uapi/drm/drm_mode.h  |  5 
 7 files changed, 60 insertions(+)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..7a02b2782f33 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""Graphics"", ""Photo"", ""Cinema"", 
""Game"" }",Connector,TDB
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..72fd2a1c801f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1353,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+   } else if (property == config->content_type_property) {
+   *val = state->content_type;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..d03586edd483 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,13 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+   { DRM_MODE_CONTENT_TYPE_GRAPHICS, "GRAPHICS" },
+   { DRM_MODE_CONTENT_TYPE_PHOTO, "PHOTO" },
+   { DRM_MODE_CONTENT_TYPE_CINEMA, "CINEMA" },
+   { DRM_MODE_CONTENT_TYPE_GAME, "GAME" },
+};
+
 static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
@@ -1260,6 +1267,33 @@ int drm_mode_create_aspect_ratio_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
 
+/**
+ * drm_mode_create_content_type_property - create content type property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_content_type_property(struct drm_device *dev)
+{
+   if (dev->mode_config.content_type_property)
+   return 0;
+
+   dev->mode_config.content_type_property =
+   drm_property_create_enum(dev, 0, "content type",
+   drm_content_type_enum_list,
+   ARRAY_SIZE(drm_content_type_enum_list));
+
+   if (dev->mode_config.content_type_property == NULL)
+   return -ENOMEM;
+
+   return 0;
+}

[PATCH v1 0/2] Enabling content-type setting for external HDMI displays.

[StanLis]

From: Stanislav Lisovskiy 

Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  4 
 drivers/gpu/drm/drm_connector.c  | 34 
 drivers/gpu/drm/drm_edid.c   |  1 +
 drivers/gpu/drm/i915/intel_atomic.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c|  4 
 drivers/gpu/drm/i915/intel_modes.c   | 10 
 include/drm/drm_connector.h  | 10 
 include/drm/drm_mode_config.h|  5 
 include/uapi/drm/drm_mode.h  |  5 
 11 files changed, 76 insertions(+)

-- 
2.17.0

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

[Bug 106054] [vega10] powerplay non critical errors on vega 56 with vega 64bios

[bugzilla-daemon]

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

--- Comment #2 from Tom Englund  ---
oh i know :), just thought it maybe might be useful to know about or look at if
there is something wrong in the driver, but i fully accept its my own fault if
otherwise :D

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

DRI3 WSEGL plugin for TI SGX

[Tomi Valkeinen]

Hi All,

I have implemented a WSEGL plugin library for Imagination's PVR driver
for SGX, which allows using SGX via DRI3. In other words, it is one
piece in the puzzle of using SGX with X11.

The project is not production quality, as I have not had time to perfect
it (and, to be honest, I'm not exactly an expert on X), but now that I
finally got all the permissions to publish it, I'm doing just that to
allow other people to use it and help making it fully usable.

You can find the code and a more detailed description here:

https://github.com/TexasInstruments/dri3wsegl

Hopefully with this code now public, we can get an SGX and GC320
accelerated X11 on TI devices.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #84 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey

I have removed the GALLIUM_DDEBUG=flush  hack and performed around 10 boots. I
have not been able to replicate the bug.

I am porting the patch to my current distro and will run the test there for a
couple of hours (hopefully tomorrow). But It looks pretty good!

Kudos!

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

[Bug 199407] Radeon night light/redshift flickers

[bugzilla-daemon]

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

--- Comment #2 from Dan (dan...@consultd.de) ---
Thx a million...

appreciate your support very much

as a newbie, sorry for the question: How can I know what the next kernel 
version with this amended will be?

4.16.2 still has this problem for me?

Thx a million


Dan


On 4/16/2018 3:47 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=199407
>
> Alex Deucher (alexdeuc...@gmail.com) changed:
>
> What|Removed |Added
> 
>   CC||alexdeuc...@gmail.com
>
> --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
> Should be fixed with:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1cb19e8267a57c5174da09e0d52d1477baceccca
>

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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #85 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #84)
> Hi Andrey
> 
> I have removed the GALLIUM_DDEBUG=flush  hack and performed around 10 boots.
> I have not been able to replicate the bug.
> 
> I am porting the patch to my current distro and will run the test there for
> a couple of hours (hopefully tomorrow). But It looks pretty good!
> 
> Kudos!

Ping me once it's done.

Thanks.

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

Re: [Intel-gfx] [RFC v4 21/25] drm/fb-helper: Add drm_fb_helper_fb_open/release()

[Noralf Trønnes]

Den 16.04.2018 10.46, skrev Daniel Vetter:

On Sat, Apr 14, 2018 at 01:53:14PM +0200, Noralf Trønnes wrote:

These helpers keep track of fbdev users and drm_driver.last_close will
only restore fbdev when actually in use. Additionally the display is
turned off when the last user is closing. fbcon is a user in this context.

If struct fb_ops is defined in a library, fb_open() takes a ref on the
library (fb_ops.owner) instead of the driver module. Fix that by ensuring
that the driver module is pinned.

The functions are not added to the DRM_FB_HELPER_DEFAULT_OPS() macro,
because some of its users do set fb_open/release themselves.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_helper.c | 54 -
  include/drm/drm_fb_helper.h | 29 ++
  2 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 98e5bc92c9f2..b1124c08b1ed 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -177,7 +177,7 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation || !fb_helper)
return -ENODEV;
  
-	if (READ_ONCE(fb_helper->deferred_setup))

+   if (READ_ONCE(fb_helper->deferred_setup) || 
!READ_ONCE(fb_helper->open_count))
return 0;
  
  	mutex_lock(_helper->lock);

@@ -368,6 +368,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
drm_fb_helper *helper,
INIT_WORK(>dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
mutex_init(>lock);
+   helper->open_count = 1;
helper->funcs = funcs;
helper->dev = dev;
  }
@@ -620,6 +621,53 @@ int drm_fb_helper_defio_init(struct drm_fb_helper 
*fb_helper)
  }
  EXPORT_SYMBOL(drm_fb_helper_defio_init);
  
+/**

+ * drm_fb_helper_fb_open - implementation for _ops.fb_open
+ * @info: fbdev registered by the helper
+ * @user: 1=userspace, 0=fbcon
+ *
+ * Increase fbdev use count.
+ * If _ops is wrapped in a library, pin the driver module.
+ */
+int drm_fb_helper_fb_open(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct drm_device *dev = fb_helper->dev;
+
+   if (info->fbops->owner != dev->driver->fops->owner) {
+   if (!try_module_get(dev->driver->fops->owner))
+   return -ENODEV;
+   }
+
+   fb_helper->open_count++;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_fb_open);
+
+/**
+ * drm_fb_helper_fb_release - implementation for _ops.fb_release
+ * @info: fbdev registered by the helper
+ * @user: 1=userspace, 0=fbcon
+ *
+ * Decrease fbdev use count and turn off if there are no users left.
+ * If _ops is wrapped in a library, unpin the driver module.
+ */
+int drm_fb_helper_fb_release(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct drm_device *dev = fb_helper->dev;
+
+   if (!(--fb_helper->open_count))
+   drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
+
+   if (info->fbops->owner != dev->driver->fops->owner)
+   module_put(dev->driver->fops->owner);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_fb_release);
+
  /**
   * drm_fb_helper_sys_read - wrapper around fb_sys_read
   * @info: fb_info struct pointer
@@ -1436,6 +1484,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
if (ret < 0)
return ret;
  
+	/* Block restore without users if we do track it */

+   if (fb_helper->fbdev->fbops->fb_open == drm_fb_helper_fb_open)
+   fb_helper->open_count = 0;

Since we kzcalloc, isn't this entirely redundant? Looks confusing to me at
least.


I have to keep the existing restore behaviour for those that don't use
drm_fb_helper_fb_open(). I do this by setting fb_helper->open_count = 1
in drm_fb_helper_prepare(). I have tried to give a describtion in the
@open_count docs.

Ofc I could have changed all drivers to use drm_fb_helper_fb_open(), but
I think that time is better spent moving drivers over to generic fbdev
instead.

Noralf.


Otherwise looks all reasonable.
-Daniel



+
strcpy(fb_helper->fb->comm, "[fbcon]");
return 0;
  }
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 5f66f253a97b..330983975d5e 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -184,6 +184,22 @@ struct drm_fb_helper {
 * See also: @deferred_setup
 */
int preferred_bpp;
+
+   /**
+* @open_count:
+*
+* Keeps track of fbdev use to know when to not restore fbdev and to
+* disable the pipeline when the last user is gone.
+*
+* Drivers that use drm_fb_helper_fb_open() as their \.fb_open
+* callback will get an initial value of 0 and get 

RE: [kbuild-all] [PATCH] drm: fix drm-get-put.cocci warnings

[Li, Philip]

> Subject: Re: [kbuild-all] [PATCH] drm: fix drm-get-put.cocci warnings
> 
> On Thu, Apr 12, 2018 at 07:54:10AM +0200, Julia Lawall wrote:
> > From: Fengguang Wu 
> >
> >  Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and
> >  drm_*_unreference() helpers.
> >
> > Generated by: scripts/coccinelle/api/drm-get-put.cocci
> >
> > Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver")
> > Signed-off-by: Fengguang Wu 
> > Signed-off-by: Julia Lawall 
> > ---
> >
> > tree:   https://github.com/shenki/linux drm-v1
> 
> This isn't an upstream tree (and the aspeed driver isn't in upstream
> afaict), so no need for spamming mailing lists I think.
thanks for feedback Daniel, we will mark this repo as private one to avoid
reporting to larger mailing list.

> 
> But thanks for doing all this, great motivation to put more of the drm
> refactorings into cocci files.
> 
> Cheers, Daniel
> > head:   9680ed7979d5d403c6bde36271a048d62c048180
> > commit: 6784ac15bc6889280522b04b97f1fb1208ee45e7 [23/27] drm: Add
> ASPEED
> > GFX
> > driver
> >
> >  aspeed_gfx_drv.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > @@ -268,7 +268,7 @@ static int aspeed_gfx_probe(struct platf
> >  err_unload:
> > aspeed_gfx_unload(drm);
> >  err_free:
> > -   drm_dev_unref(drm);
> > +   drm_dev_put(drm);
> >
> > return ret;
> >  }
> > @@ -279,7 +279,7 @@ static int aspeed_gfx_remove(struct plat
> >
> > drm_dev_unregister(drm);
> > aspeed_gfx_unload(drm);
> > -   drm_dev_unref(drm);
> > +   drm_dev_put(drm);
> >
> > return 0;
> >  }
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

[bugzilla-daemon]

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

--- Comment #11 from taij...@posteo.de ---
(In reply to Joshua Lee from comment #3)
> How do I find an prior boot's dmesg?

Try "journalctl -b -1" (for the boot attempt directly prior to this one, -2 for
the one before that, etc...).

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

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

Ok, confusion around backend is I think cleared up. The other
confusion seems to be around dma-buf:

dma-buf is the cross subsystem zerocopy abstraction. PRIME is the
drm-specific support for it, 100% based on top of the generic struct
dma_buf.

You need a dma_buf exporter to convert a xen grant references list
into a dma_buf, which you can then import in your drm driver (using
prime), v4l, or anything else that supports dma-buf. You do _not_ need
a prime implementation, that's only the marketing name we've given to
dma-buf import/export for drm drivers.
-Daniel


On Mon, Apr 16, 2018 at 12:14 PM, Oleksandr Andrushchenko
 wrote:
> On 04/16/2018 12:32 PM, Daniel Vetter wrote:
>>
>> On Mon, Apr 16, 2018 at 10:22 AM, Oleksandr Andrushchenko
>>  wrote:
>>>
>>> On 04/16/2018 10:43 AM, Daniel Vetter wrote:

 On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:
>
> On 04/13/2018 06:37 PM, Daniel Vetter wrote:
>>
>> On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko
>> wrote:
>>>
>>> On 04/10/2018 08:26 PM, Dongwon Kim wrote:

 On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko
 wrote:
>
> On 04/06/2018 09:57 PM, Dongwon Kim wrote:
>>
>> On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko
>> wrote:
>>>
>>> On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:

   Hi,

>> I fail to see any common ground for xen-zcopy and udmabuf ...
>
> Does the above mean you can assume that xen-zcopy and udmabuf
> can co-exist as two different solutions?

 Well, udmabuf route isn't fully clear yet, but yes.

 See also gvt (intel vgpu), where the hypervisor interface is
 abstracted
 away into a separate kernel modules even though most of the
 actual
 vgpu
 emulation code is common.
>>>
>>> Thank you for your input, I'm just trying to figure out
>>> which of the three z-copy solutions intersect and how much
>
> And what about hyper-dmabuf?
>>
>> xen z-copy solution is pretty similar fundamentally to
>> hyper_dmabuf
>> in terms of these core sharing feature:
>>
>> 1. the sharing process - import prime/dmabuf from the producer ->
>> extract
>> underlying pages and get those shared -> return references for
>> shared pages

 Another thing is danvet was kind of against to the idea of importing
 existing
 dmabuf/prime buffer and forward it to the other domain due to
 synchronization
 issues. He proposed to make hyper_dmabuf only work as an exporter so
 that it
 can have a full control over the buffer. I think we need to talk
 about
 this
 further as well.
>>>
>>> Yes, I saw this. But this limits the use-cases so much.
>>> For instance, running Android as a Guest (which uses ION to allocate
>>> buffers) means that finally HW composer will import dma-buf into
>>> the DRM driver. Then, in case of xen-front for example, it needs to
>>> be
>>> shared with the backend (Host side). Of course, we can change
>>> user-space
>>> to make xen-front allocate the buffers (make it exporter), but what
>>> we
>>> try
>>> to avoid is to change user-space which in normal world would have
>>> remain
>>> unchanged otherwise.
>>> So, I do think we have to support this use-case and just have to
>>> understand
>>> the complexity.
>>
>> Erm, why do you need importer capability for this use-case?
>>
>> guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy
>> exposes
>> that dma-buf -> import to the real display hw
>>
>> No where in this chain do you need xen-zcopy to be able to import a
>> dma-buf (within linux, it needs to import a bunch of pages from the
>> hypervisor).
>>
>> Now if your plan is to use xen-zcopy in the guest1 instead of
>> xen-front,
>> then you indeed need to import.
>
> This is the exact use-case I was referring to while saying
> we need to import on Guest1 side. If hyper-dmabuf is so
> generic that there is no xen-front in the picture, then
> it needs to import a dma-buf, so it can be exported at Guest2 side.
>>
>> But that imo doesn't make sense:
>> - xen-front gives you clearly defined flip events you can forward to
>> the
>>  hypervisor. xen-zcopy would need to add that again.
>
> xen-zcopy is a helper driver which doesn't handle page flips
> and is not a KMS driver as one might think of: the DRM UAPI it uses is
> just to export a dma-buf 

Re: Batched ww-mutexes, wound-wait vs wait-die etc.

[Daniel Vetter]

On Mon, Apr 16, 2018 at 2:15 PM, Thomas Hellstrom  wrote:
> On 04/16/2018 11:19 AM, Daniel Vetter wrote:
>>
>> On Mon, Apr 16, 2018 at 10:23 AM, Thomas Hellstrom
>>  wrote:
>>>
>>> On 04/14/2018 10:33 AM, Daniel Vetter wrote:

 Hi Thomas,

 On Fri, Apr 13, 2018 at 10:23 PM, Thomas Hellstrom
  wrote:
>
> On 04/13/2018 07:13 PM, Daniel Vetter wrote:
>>
>> On Wed, Apr 11, 2018 at 10:27:06AM +0200, Thomas Hellstrom wrote:
>>>
>>> 2) Should we add a *real* wound-wait choice to our wound-wait
>>> mutexes.
>>> Otherwise perhaps rename them or document that they're actually doing
>>> wait-die.
>>
>> I think a doc patch would be good at least. Including all the data you
>> assembled here.
>
>
> Actually, a further investigation appears to indicate that manipulating
> the
> lock state under a local spinlock is about fast as using atomic
> operations
> even for the completely uncontended cases.
>
> This means that we could have a solution where you decide on a
> per-mutex
> or
> per-reservation object basis whether you want to manipulate lock-state
> under
> a "batch group" spinlock, meaning certain performance characteristics
> or
> traditional local locking, meaning other performance characteristics.
>
> Like, vmwgfx could choose batching locks, radeon traditional locks, but
> the
> same API would work for both and locks could be shared between
> drivers..

 Don't we need to make this decision at least on a per-class level?
>>>
>>>
>>> No, I was thinking more in the line of the ww_mutex having a pointer to
>>> the
>>> spinlock. It could either be the local mutex "wait_lock", or a
>>> per-batch-group lock. The mutex code wouldn't care. We do need a special
>>> API
>>> for batched locking, though, but not for ordinary locking.
>>> Both APIs should be able to handle local or grouped spinlocks.
>>>
>>> Note that this would of course require that there would be no performance
>>> loss for users that don't use batch groups.
>>>
>>> I guess the most efficient use for GPU command submission would be to use
>>> per-process batch-groups. Then when the batch encounters a ww_mutex with
>>> a
>>> different batch group (for example the display server shared surface,
>>> it'll
>>> just switch batch lock), and this way the contention for
>>> the batch spinlock will be mostly eliminated.
>>
>> But won't this force us through the spinlock case for all ww_mutex?
>> The core mutex code goes to extreme lengths to avoid that for the
>> uncontended fast path. That's why I meant the batched and non-batch
>> ww_mutex look fundamentally incompatible. Or maybe I missed something
>> somewhere.
>
>
> Yes, this would require  the assumption to hold that a _local_ spinlock
> path, that is, taking a local spinlock also in the fastpath would be as fast
> as using the atomic operations directly. And that's what I'm seeing, (or
> perhaps a percent or so slower with 2 simulated CS'es taking 800
> uncontended locks each). Both running sequentially and in parallel. Guess I
> need to verify this on my rpi as well, so it's not an Intel specific thing.
>
> This is of course a prerequisite for the idea to work.
>
> Basically the spinlock fastpath appears to be an inlined atomic_cmpxchg, so
> even theoretically there should not be any noticeable performance loss. I'm
> not sure why the sleeping locks insist using atomic operations over
> spinlocks, but with the qspinlock implementation (seems to be 2014-ish), the
> atomic exchange on spin_unlock was elminated, and I guess that changed the
> playground...
>
> With a _shared_ spinlock, like with a batch group, we would see different
> performance characteristics, though.

Hm yeah, the performance characteristics have massively converged there.

Otoh I think spinlocks are still a lot more arch-dependent than struct
mutex locking, so not sure how well this holds over the gazillion of
other architectures Linux supports. And I think since we've moved
ww_mutex to be a core locking construct we should make sure stuff
doesn't get worse on those either, even if they practically have no
relevance for gpu drivers. ppc might be the only one, besides x86 and
arm/arm64.

Or
 how will the spinlock/batch-lock approach interact with the normal
 ww_mutex_lock path (which does require the atomics/ordered stores
 we're trying to avoid)?
>>>
>>>
>>> We can use the same code with some extra
>>> if (use_ww_ctx) in the common locking and unlocking path.
>>> Note that the "use_ww_ctx" parameter is defined at compile-time so the
>>> ordinary mutex path (binary) shouldn't change at all after optimization
>>> but
>>> I need to verify that, of course.
>>
>> Agreed, no issue there.
>>
>>> What you can't do with such a change is to lock / unlock a ww_mutex using
>>> the standard mutex API, 

Re: [Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

[Tomi Valkeinen]

On 09/04/18 11:41, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 09:10:43AM +0300, Tomi Valkeinen wrote:
>> On 05/04/18 19:50, Daniel Vetter wrote:
>>> On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote:
 From: Ville Syrjälä 

 omap_framebuffer_get_next_connector() uses plane->fb which we want to
 deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
 is unused just nuke the entire function.

 Cc: Tomi Valkeinen 
 Signed-off-by: Ville Syrjälä 
>>>
>>> Yeah was slightly worried how to fix up this one, but we're lucky!
>>>
>>> Reviewed-by: Daniel Vetter 
>>
>> I tried to remove it just a week ago, but Sebastian said that it's used
>> by a unmerged series about DSI command mode displays, so I dropped the
>> patch.
>>
>> In the unmerged series, it's used by omap_framebuffer_dirty() ([PATCHv3
>> 3/8] drm/omap: add support for manually updated displays). So we have a
>> framebuffer, and we want to know which crtcs need to be flushed.
> 
> You can't do that in atomic drivers.
> 
> You need to take appropriate locks and do the full ->state->fb deref.
> Also, there's a gazillion of copies for generic framebuffer_dirty
> implementations floating around, pleas try to coordinate with those.

Ok. In that case we need to refresh the manual update series to do
things differently. For this patch:

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

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

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

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

[bugzilla-daemon]

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

--- Comment #9 from taij...@posteo.de ---
This is possibly the same bug described  in bug #105760.

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

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

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

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

Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

Hello, all!

After discussing xen-zcopy and hyper-dmabuf [1] approaches

it seems that xen-zcopy can be made not depend on DRM core any more

and be dma-buf centric (which it in fact is).

The DRM code was mostly there for dma-buf's FD import/export

with DRM PRIME UAPI and with DRM use-cases in mind, but it comes out that if

the proposed 2 IOCTLs (DRM_XEN_ZCOPY_DUMB_FROM_REFS and 
DRM_XEN_ZCOPY_DUMB_TO_REFS)


are extended to also provide a file descriptor of the corresponding 
dma-buf, then


PRIME stuff in the driver is not needed anymore.

That being said, xen-zcopy can safely be detached from DRM and moved from

drivers/gpu/drm/xen into drivers/xen/dma-buf-backend(?).

This driver then becomes a universal way to turn any shared buffer 
between Dom0/DomD


and DomU(s) into a dma-buf, e.g. one can create a dma-buf from any grant 
references


or represent a dma-buf as grant-references for export.

This way the driver can be used not only for DRM use-cases, but also for 
other


use-cases which may require zero copying between domains.

For example, the use-cases we are about to work in the nearest future 
will use


V4L, e.g. we plan to support cameras, codecs etc. and all these will benefit

from zero copying much. Potentially, even block/net devices may benefit,

but this needs some evaluation.


I would love to hear comments for authors of the hyper-dmabuf

and Xen community, as well as DRI-Devel and other interested parties.


Thank you,

Oleksandr


On 03/29/2018 04:19 PM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Hello!

When using Xen PV DRM frontend driver then on backend side one will need
to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames per seconds
it may result in unneeded huge data bus occupation and performance loss.

This helper driver allows implementing zero-copying use-cases
when using Xen para-virtualized frontend display driver by
implementing a DRM/KMS helper driver running on backend's side.
It utilizes PRIME buffers API to share frontend's buffers with
physical device drivers on backend's side:

  - a dumb buffer created on backend's side can be shared
with the Xen PV frontend driver, so it directly writes
into backend's domain memory (into the buffer exported from
DRM/KMS driver of a physical display device)
  - a dumb buffer allocated by the frontend can be imported
into physical device DRM/KMS driver, thus allowing to
achieve no copying as well

For that reason number of IOCTLs are introduced:
  -  DRM_XEN_ZCOPY_DUMB_FROM_REFS
 This will create a DRM dumb buffer from grant references provided
 by the frontend
  - DRM_XEN_ZCOPY_DUMB_TO_REFS
This will grant references to a dumb/display buffer's memory provided
by the backend
  - DRM_XEN_ZCOPY_DUMB_WAIT_FREE
This will block until the dumb buffer with the wait handle provided
be freed

With this helper driver I was able to drop CPU usage from 17% to 3%
on Renesas R-Car M3 board.

This was tested with Renesas' Wayland-KMS and backend running as DRM master.

Thank you,
Oleksandr

Oleksandr Andrushchenko (1):
   drm/xen-zcopy: Add Xen zero-copy helper DRM driver

  Documentation/gpu/drivers.rst   |   1 +
  Documentation/gpu/xen-zcopy.rst |  32 +
  drivers/gpu/drm/xen/Kconfig |  25 +
  drivers/gpu/drm/xen/Makefile|   5 +
  drivers/gpu/drm/xen/xen_drm_zcopy.c | 880 
  drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c | 154 +
  drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h |  38 ++
  include/uapi/drm/xen_zcopy_drm.h| 129 
  8 files changed, 1264 insertions(+)
  create mode 100644 Documentation/gpu/xen-zcopy.rst
  create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy.c
  create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c
  create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h
  create mode 100644 include/uapi/drm/xen_zcopy_drm.h

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html

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

Re: [PATCH 1/2] drm/imx: imx-ldb: disable LDB on driver bind

[Philipp Zabel]

On Wed, 2018-04-11 at 17:31 +0200, Lucas Stach wrote:
> The LVDS signal integrity is only guaranteed when the correct enable
> sequence (first IPU DI, then LDB) is used. If the LDB display output was
> active before the imx-drm driver is loaded (like when a bootsplash was
> active) the DI will be disabled by the full IPU reset we do when loading
> the driver. The LDB control registers are not part of the IPU range and
> thus will remain unchanged.
> 
> This leads to the LDB still being active when the DI is getting enabled,
> effectively reversing the required enable sequence. Fix this by also
> disabling the LDB on driver bind.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/imx-ldb.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
> index 56dd7a9a8e25..17974c0b4be8 100644
> --- a/drivers/gpu/drm/imx/imx-ldb.c
> +++ b/drivers/gpu/drm/imx/imx-ldb.c
> @@ -612,6 +612,9 @@ static int imx_ldb_bind(struct device *dev, struct device 
> *master, void *data)
>   return PTR_ERR(imx_ldb->regmap);
>   }
>  
> + /* disable LDB by resetting the control register to POR default */
> + regmap_write(imx_ldb->regmap, IOMUXC_GPR2, 0);
> +

On second thought, this is nice and clear. Moving it into encoder .reset
would unnecessarily complicate things, as both channels share this
register and .reset is called twice, once per channel.

I've applied both patches to imx-drm/next.

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix drm-get-put.cocci warnings

[Julia Lawall]

On Mon, 16 Apr 2018, Daniel Vetter wrote:

> On Thu, Apr 12, 2018 at 07:54:10AM +0200, Julia Lawall wrote:
> > From: Fengguang Wu 
> >
> >  Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and
> >  drm_*_unreference() helpers.
> >
> > Generated by: scripts/coccinelle/api/drm-get-put.cocci
> >
> > Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver")
> > Signed-off-by: Fengguang Wu 
> > Signed-off-by: Julia Lawall 
> > ---
> >
> > tree:   https://github.com/shenki/linux drm-v1
>
> This isn't an upstream tree (and the aspeed driver isn't in upstream
> afaict), so no need for spamming mailing lists I think.

Perhaps you can contact Fengguang about this?  I just forward to whoever
the automatically generated message says to forward to.  And I don't
always remember to include the information about the tree, which comes to
me in another message, so it can indeed be confusing.

>
> But thanks for doing all this, great motivation to put more of the drm
> refactorings into cocci files.

Most welcome :)

julia

> Cheers, Daniel
> > head:   9680ed7979d5d403c6bde36271a048d62c048180
> > commit: 6784ac15bc6889280522b04b97f1fb1208ee45e7 [23/27] drm: Add ASPEED
> > GFX
> > driver
> >
> >  aspeed_gfx_drv.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > @@ -268,7 +268,7 @@ static int aspeed_gfx_probe(struct platf
> >  err_unload:
> > aspeed_gfx_unload(drm);
> >  err_free:
> > -   drm_dev_unref(drm);
> > +   drm_dev_put(drm);
> >
> > return ret;
> >  }
> > @@ -279,7 +279,7 @@ static int aspeed_gfx_remove(struct plat
> >
> > drm_dev_unregister(drm);
> > aspeed_gfx_unload(drm);
> > -   drm_dev_unref(drm);
> > +   drm_dev_put(drm);
> >
> > return 0;
> >  }
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] dt-bindings: display: atmel: add optional output-mode property

[Rob Herring]

On Sat, Apr 14, 2018 at 8:54 AM, Peter Rosin  wrote:
> On 2018-04-13 19:46, Rob Herring wrote:
>> On Mon, Apr 09, 2018 at 12:59:15PM +0200, Peter Rosin wrote:
>>> Useful for beating cases where an output mode selection heuristic
>>> fails.
>>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt 
>>> b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>>> index 82f2acb3d374..dc478455b883 100644
>>> --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>>> +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>>> @@ -10,6 +10,10 @@ Required properties:
>>>   - #address-cells: should be set to 1.
>>>   - #size-cells: should be set to 0.
>>>
>>> +Optional properties:
>>> + - output-mode: override any output mode selection hueristic and force a
>>> +   particular output mode. One of "rgb444", "rgb565", "rgb666" and 
>>> "rgb888".
>>> +
>>
>> This needs to be generic, not just added to some random display
>> controller binding.
>>
>> It also belongs in the port or endpoint node as is done for camera
>> interfaces.
>
> Hmm, should I extend media/video-interfaces.txt with more bus types (or since
> I'm targeting parallel interfaces, perhaps the new bus types should be
> autodetected from other props?) or should a write a new binding similar to
> it?

Ultimately, I'd like it documented in one place. It can stay in
media/video-interfaces.txt for now, but we should probably move it or
portions of it out of media/. I don't have a good suggestion other
than up a level where people will find it easily.

> One question regarding bus-width, should it include hsync/vsync/de/clk?
> If yes, how to distinguish rgb565 with all those four from rgb666 with
> only de/clk (some panels do not need hsync/vsync)? 20 lines in both
> cases...

I'd say no, it is just the data lines.

> Or are rgb444/rgb565/rgb666/rgb888 already supported by the media video
> interface binding? That's not at all obvious to me.

Not sure, I'd guess not.

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

Re: [PATCH hwc v2 01/18] drm_hwcomposer: vsyncworker: Fix uninitialized enabled_ field

[Alexandru-Cosmin Gheorghe]

On Mon, Apr 16, 2018 at 12:30:13PM +0200, Robert Foss wrote:

Hi Rob,

Thanks for the review.

> Hey Alexandru,
> 
> Feel free to add:
> Signed-off-by: Robert Foss 
>

Should I re-send this 3 patches or could you just pushed them to
master and adding your SoB in the process?
 
> 
> Rob.
> 
> On 04/11/2018 05:22 PM, Alexandru Gheorghe wrote:
> >Signed-off-by: Alexandru Gheorghe 
> >---
> >  vsyncworker.cpp | 1 +
> >  1 file changed, 1 insertion(+)
> >
> >diff --git a/vsyncworker.cpp b/vsyncworker.cpp
> >index 3ad16fe..3bfe4be 100644
> >--- a/vsyncworker.cpp
> >+++ b/vsyncworker.cpp
> >@@ -35,6 +35,7 @@ VSyncWorker::VSyncWorker()
> >  : Worker("vsync", HAL_PRIORITY_URGENT_DISPLAY),
> >drm_(NULL),
> >display_(-1),
> >+  enabled_(false),
> >last_timestamp_(-1) {
> >  }
> >

-- 
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

[bugzilla-daemon]

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

--- Comment #10 from taij...@posteo.de ---
And yes, Arch has had CONFIG_DRM_AMD_DC_DCN1_0=y since 4.15.

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

[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #13 from Marta Löfstedt  ---
The discussed patch is not merged yet. Please changed the bug to resolved/fixed
when that patch is merged.

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

Re: [PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier

[Tomasz Figa]

Hi Andrzej,

On Mon, Apr 16, 2018 at 6:57 PM Andrzej Hajda <a.ha...@samsung.com> wrote:

> On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
> > From: Tomasz Figa <tf...@chromium.org>
> >
> > It looks like the driver subsystem detaches devices from power domains
> > at shutdown without consent of the drivers.

> It looks bit strange. Could you elaborate more on it. Could you show the
> code performing the detach?

It not only looks strange, but it is strange. The code was present in 4.4:

https://elixir.bootlin.com/linux/v4.4.128/source/drivers/base/platform.c#L553

but was apparently removed in 4.5:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/base/platform.c?h=next-20180416=2d30bb0b3889adf09b342722b2ce596c0763bc93

So we might not need this patch anymore.

Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Noralf Trønnes]

Den 16.04.2018 10.21, skrev Daniel Vetter:

On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote:

This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.

In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This avoids code duplication, carries
over lessons learned and the modesetting code is bisectable. The
downside is that it takes +10 patches to rip drm_fb_helper in two, so
maybe it's not worth it wrt possible breakage and a challenging review.

So my idea wasn't to rip the fbdev helper in  half first (that's indeed a
lot of work). But start out right away with using every piece of the
drm_client infrastructure you're adding in the existing fbdev code.

That way there's not a huge patch series which just adds code, with no
users, but every step of the way and every addition is tested almost right
away. That makes more gradual merging also easier. The things I have in
mind here is the generic fb_probe, or the drm_client block/unblock masters
and all that stuff.

Then, once we've demonstrated all these auxiliary pieces necessary for
drm_client.c work, we can cut the fb-helper in half and move the modeset
code into the drm_client library.


I agree. I wished for a way to cut this patchset in half, but I just
couldn't see how. I was tired of working on this, so I just put it out
hoping that you would provide some clarity. Which you did, thanks :-)

So, I think I'll strip this down to just the buffer part of the client API
and use that in the generic fbdev emulation, and start converting some
drivers.

I'll pick up the rest of the client API when I'm done with moving tinydrm
over to vmalloc buffers and have added support for device unplug.

Noralf.



I still prefer an even more gradual path like this compared to what you
have in your patch series, but I understand that's yet another huge
shuffle. And the current series seems like a good enough approach to get
to essentially the same place.


Does the Intel CI test the fbdev emulation?

We have fbdev emulation enabled, and iirc there's even a few tests for
fbdev. Just booting it on 20+ machines is a lot of testing itsefl already.


Daniel had this concern with the previous version:

 The register/unregister model needs more thought. Allowing both clients
 to register whenever they want to, and drm_device instances to come and
 go is what fbcon has done, and the resulting locking is a horror show.

 I think if we require that all in-kernel drm_clients are registers when
 loading drm.ko (and enabled/disabled only per module options and
 Kconfig), then we can throw out all the locking. That avoids a lot of
 the headaches.

I have solved this by adding a notifier that fires when a new DRM device
is registered (I've removed the new() callback). Currently only
bootsplash uses this. The fbdev client needs to be setup from the driver
since it can't know on device registration if the driver will setup it's
own fbdev emulation later and the vtcon client hooks up to a user
provided device id.

Ugh, notifier is exactly what fbcon also uses. It just hides the locking
horror show slightly, but it's equally bad. I'm working on a multi-year
plan to rip out the fbcon notifier, please don't start another one. See

commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter 
Date:   Tue Aug 1 17:32:07 2017 +0200

 fbcon: Make fbcon a built-time depency for fbdev

for full details.


Since fbcon can't handle fb_open failing, the buffer has to be
pre-allocated. Exporting a GEM buffer pins the driver module making it
impossible to unload it.
I have included 2 solutions to the problem:
- sysfs file to remove/close clients: remove_internal_clients

This is the same thing that defacto happens already with fbcon: You have
to remove fbcon first (which holds a full ref on the fbdev, which prevents
the drm driver from unloading). I think explicitly asking for that
reference to disappear is ok.

It does mean everyone has to update their unload scripts, but oh well.


- Change drm_gem_prime_export() so it doesn't pin on client buffers

The double-loop in that patch definitely doesn't cut it, but worst case I
think something like that could be made to work.


If a dumb buffer is exported from a kernel thread (worker) context, the
file descriptor isn't closed and I leak a reference so the buffer isn't
freed. Please look at drm_client_buffer_create() in patch
'drm/client: Finish the in-kernel client API'.
This is a blocker that needs a solution.

Hm, missed that in my first cursory read of the series, I'l take another
look.
-Daniel



Noralf.

Changes since version 3:
Client API changes:
- Drop drm_client_register_funcs() which attached clients indirectly.
   Let clients attach directly using drm_client_new{_from_id}(). Clients
   

[PATCH] drm/rockchip: Filter out alpha formats for primary plane

[Kristian H. Kristensen]

Rockchip doesn't support per-pixel alpha blending for the lowest
window in the stack. While the hw supports restacking the windows, we
don't expose that in KMS, so just filter out alpha formats for the
primary plane.

Change-Id: I7828d5bf0f0b5c6dd23f9e52aa01a5a683131d2f
Signed-off-by: Kristian H. Kristensen 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fae37b1cd691..2efe78600fd0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1547,6 +1547,28 @@ static irqreturn_t vop_isr(int irq, void *data)
return ret;
 }
 
+static uint32_t formats_for_win(const struct vop_win_phy *phy, uint32_t win,
+   uint32_t *formats, uint32_t max_formats)
+{
+   uint32_t i, j;
+
+   BUG_ON(max_formats < phy->nformats);
+
+   j = 0;
+   for (i = 0; i < phy->nformats; i++) {
+   /*
+* win0 doesn't support per-pixel alpha, so don't add any RGBA
+* formats for that plane.
+*/
+   if (win == 0 && is_alpha_support(phy->data_formats[i]))
+   continue;
+
+   formats[j++] = phy->data_formats[i];
+   }
+
+   return j;
+}
+
 static int vop_create_crtc(struct vop *vop)
 {
const struct vop_data *vop_data = vop->data;
@@ -1568,15 +1590,17 @@ static int vop_create_crtc(struct vop *vop)
for (i = 0; i < vop_data->win_size; i++) {
struct vop_win *vop_win = >win[i];
const struct vop_win_data *win_data = vop_win->data;
+   uint32_t nformats, formats[16];
 
if (win_data->type != DRM_PLANE_TYPE_PRIMARY &&
win_data->type != DRM_PLANE_TYPE_CURSOR)
continue;
 
+   nformats = formats_for_win(win_data->phy, i,
+  formats, ARRAY_SIZE(formats));
ret = drm_universal_plane_init(vop->drm_dev, _win->base,
   0, _plane_funcs,
-  win_data->phy->data_formats,
-  win_data->phy->nformats,
+  formats, nformats,
   win_data->phy->format_modifiers,
   win_data->type, NULL);
if (ret) {
-- 
2.13.5

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

Re: [PATCH hwc v2 02/18] drm_hwcomposer: vsyncworker: Fix deadlock on exit path

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:13PM +0100, Alexandru Gheorghe wrote:
> vsyncworker::Routine assumes that when -EINTR is returned by
> WaitForSignalOrExitLocked the lock as been released, which is not
> true, so it hangs if a vsyncworker is never enabled and Exit is
> called.
> 
> There are two code paths in WaitForSignalOrExitLocked that return
> -EINTR, one releases the lock the other doesn't.
> Looking at the clients of WaitForSignalOrExitLocked all assume the lock
> is still held, except vsyncworker::Routine.
> So, the proper fix needs two changes:
> - Make WaitForSignalOrExitLocked consistent and always hold the lock
>   when exiting.
> - Release lock in vsynworker::Routine on all code paths.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  vsyncworker.cpp | 1 +
>  worker.cpp  | 6 +++---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/vsyncworker.cpp b/vsyncworker.cpp
> index 3bfe4be..7c0c741 100644
> --- a/vsyncworker.cpp
> +++ b/vsyncworker.cpp
> @@ -120,6 +120,7 @@ void VSyncWorker::Routine() {
>if (!enabled_) {
>  ret = WaitForSignalOrExitLocked();
>  if (ret == -EINTR) {
> +  Unlock();
>return;
>  }
>}
> diff --git a/worker.cpp b/worker.cpp
> index da6c580..5b351e0 100644
> --- a/worker.cpp
> +++ b/worker.cpp
> @@ -66,13 +66,13 @@ int Worker::WaitForSignalOrExitLocked(int64_t 
> max_nanoseconds) {
>  ret = -ETIMEDOUT;
>}
>  
> +  // release leaves mutex locked when going out of scope
> +  lk.release();
> +
>// exit takes precedence on timeout
>if (should_exit())
>  ret = -EINTR;
>  
> -  // release leaves mutex locked when going out of scope
> -  lk.release();
> -

I'm not sure why this chunk makes a difference? If the above was
"return -EINTR;" it would, but it's just assigning ret.

Sean

>return ret;
>  }
>  
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 07/18] drm_hwcomposer: Add display field to Drmencoder

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:18PM +0100, Alexandru Gheorghe wrote:
> In the current implementation TryEncoderForDisplay just looks
> at the crtc linked to the display, if that's not assigned to
> a display it means the encoder could be used, otherwise iterate
> to the list of possible_crtcs and find one which is not used.
> 
> This logic works fine when you have just one encoder connected to a
> crtc but with two or more, like is the case when we attach a writeback
> connector, we need to know if we already assigned the encoder to a
> display.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmencoder.cpp | 14 ++
>  drmencoder.h   |  4 
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drmencoder.cpp b/drmencoder.cpp
> index 3d762f3..1da7ec3 100644
> --- a/drmencoder.cpp
> +++ b/drmencoder.cpp
> @@ -27,6 +27,7 @@ DrmEncoder::DrmEncoder(drmModeEncoderPtr e, DrmCrtc 
> *current_crtc,
> const std::vector _crtcs)
>  : id_(e->encoder_id),
>crtc_(current_crtc),
> +  display_(-1),
>possible_crtcs_(possible_crtcs) {
>  }
>  
> @@ -40,5 +41,18 @@ DrmCrtc *DrmEncoder::crtc() const {
>  
>  void DrmEncoder::set_crtc(DrmCrtc *crtc) {
>crtc_ = crtc;
> +  set_display(crtc->display());
> +}
> +
> +int DrmEncoder::display() const {
> +  return display_;
> +}
> +
> +void DrmEncoder::set_display(int display) {
> +  display_ = display;
> +}

Instead of adding this, just call set_crtc() in TryEncoderForDisplay() for the
already-bound case. That way we only have one entry point for this.

> +
> +bool DrmEncoder::can_bind(int display) const {
> +  return display_ == -1 || display_ == display;
>  }
>  }
> diff --git a/drmencoder.h b/drmencoder.h
> index 58ccbfb..7e06691 100644
> --- a/drmencoder.h
> +++ b/drmencoder.h
> @@ -36,6 +36,9 @@ class DrmEncoder {
>  
>DrmCrtc *crtc() const;
>void set_crtc(DrmCrtc *crtc);
> +  bool can_bind(int display) const;
> +  void set_display(int display);
> +  int display() const;
>  
>const std::vector _crtcs() const {
>  return possible_crtcs_;
> @@ -44,6 +47,7 @@ class DrmEncoder {
>   private:
>uint32_t id_;
>DrmCrtc *crtc_;
> +  int display_;
>  
>std::vector possible_crtcs_;
>  };
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

[Rob Herring]

On Mon, Apr 16, 2018 at 12:25 PM, Eric Anholt  wrote:
> The GPU subsystem node was a workaround to have a central device to
> bind V3D and display to.  Following the lead of 246774d17fc0
> ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
> the subsystem node usage and just create a platform device for the DRM
> device to attach to if any of the subsystem devices are present.
>
> v2: Simplify the DT walking code.

> +static bool
> +driver_of_table_has_a_match(const struct platform_driver *driver)
> +{
> +   struct device_node *node;
> +
> +   node = of_find_matching_node_and_match(NULL,
> +  driver->driver.of_match_table,
> +  NULL);
> +   if (of_device_is_available(node)) {
> +   of_node_put(node);

You need to put the node regardless.

> +   return true;
> +   }
> +
> +   return false;
> +}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [DPU PATCH v2 1/2] drm/msm/dsi: check video mode engine status before waiting

[Sean Paul]

On Mon, Apr 16, 2018 at 10:44:57AM -0700, abhin...@codeaurora.org wrote:
> Hi Sean
> 
> Thanks for reviewing.
> 
> Reply inline.
> 
> On 2018-04-16 10:07, Sean Paul wrote:
> > On Fri, Apr 13, 2018 at 03:04:48PM -0700, abhin...@codeaurora.org wrote:
> > > On 2018-04-13 14:10, abhin...@codeaurora.org wrote:
> > > > Hi Sean
> > > >
> > > > Thanks for the review.
> > > >
> > > > Reply inline.
> > > >
> > > > On 2018-04-13 13:26, Sean Paul wrote:
> > > > > On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
> > > > > > Make sure the video mode engine is on before waiting
> > > > > > for the video done interrupt.
> > > > > >
> > > > > > Otherwise it leads to silent timeouts increasing display
> > > > > > turn ON time.
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Replace pr_err with dev_err
> > > > > > - Changed error message
> > > > > >
> > > > > > Signed-off-by: Abhinav Kumar 
> > > > > > ---
> > > > > >  drivers/gpu/drm/msm/dsi/dsi_host.c | 15 +++
> > > > > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > > > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > > > index 7a03a94..5b7b290 100644
> > > > > > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > > > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > > > > > @@ -173,6 +173,7 @@ struct msm_dsi_host {
> > > > > >
> > > > > > bool registered;
> > > > > > bool power_on;
> > > > > > +   bool enabled;
> > > > > > int irq;
> > > > > >  };
> > > > > >
> > > > > > @@ -986,13 +987,19 @@ static void dsi_set_tx_power_mode(int
> > > > > > mode, struct msm_dsi_host *msm_host)
> > > > > >
> > > > > >  static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
> > > > > >  {
> > > > > > +   u32 ret = 0;
> > > > > > +   struct device *dev = _host->pdev->dev;
> > > > > > +
> > > > > > dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
> > > > > >
> > > > > > reinit_completion(_host->video_comp);
> > > > > >
> > > > > > -   wait_for_completion_timeout(_host->video_comp,
> > > > > > +   ret = wait_for_completion_timeout(_host->video_comp,
> > > > > > msecs_to_jiffies(70));
> > > > > >
> > > > > > +   if (ret <= 0)
> > > > > > +   dev_err(dev, "wait for video done timed out\n");
> > > > > > +
> > > > > > dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0);
> > > > > >  }
> > > > > >
> > > > > > @@ -1001,7 +1008,7 @@ static void dsi_wait4video_eng_busy(struct
> > > > > > msm_dsi_host *msm_host)
> > > > > > if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
> > > > > > return;
> > > > > >
> > > > > > -   if (msm_host->power_on) {
> > > > > > +   if (msm_host->power_on && msm_host->enabled) {
> > > > > > dsi_wait4video_done(msm_host);
> > > > > > /* delay 4 ms to skip BLLP */
> > > > > > usleep_range(2000, 4000);
> > > > > > @@ -2203,7 +2210,7 @@ int msm_dsi_host_enable(struct
> > > > > > mipi_dsi_host *host)
> > > > > >  *  pm_runtime_put_autosuspend(_host->pdev->dev);
> > > > > >  * }
> > > > > >  */
> > > > > > -
> > > > > > +   msm_host->enabled = true;
> > > > > > return 0;
> > > > > >  }
> > > > > >
> > > > > > @@ -2219,7 +2226,7 @@ int msm_dsi_host_disable(struct
> > > > > > mipi_dsi_host *host)
> > > > > >  * Reset to disable video engine so that we can send off cmd.
> > > > > >  */
> > > > > > dsi_sw_reset(msm_host);
> > > > > > -
> > > > > > +   msm_host->enabled = false;
> > > > >
> > > > > This should go at the start of the function. Also, it's unclear from
> > > > > this patch,
> > > > > but I assume this is protected by a lock?
> > > > >
> > > > > Sean
> > > > [Abhinav] Yes, will move this to the start.
> > > > No, there is no lock here but at this point doesnt need one.
> > > > The reason is that, this variable will be written to and read by the
> > > > same process
> > > > (suspend thread OR resume thread which sends the panel ON/OFF commands).
> > > > If we decide to expose other interfaces to send commands like debugfs
> > > > or sysfs and
> > > > introduce more threads, we will add the locking.
> > > [Abhinav] Correction to my prev comment, we do have the
> > > msm_host->cmd_mutex
> > > which will
> > > ensure this entire process is protected. That should suffice.
> > 
> > Ok, thanks for confirming. Could you also please split this patch into
> > the
> > wait4video_done ret fix and the ->enabled addition? The 2 seem mostly
> > unrelated.
> > 
> > Sean
> 
> They are quite related actually. So we were not able to catch this earlier
> because the wait was silently timing out. Hence along with the fix I wanted
> to change the ret to add the error log because such condition should not
> happen with the ->enabled fix. To signify that I clubbed them together.
> I can split them, if this still feels unrelated.

Thanks for the explanation, they're unrelated in the sense that you're fixing 2
things in 

Re: [PATCH] display: panel: Add KOE tx14d24vm1bpa display support (320x240)

[Rob Herring]

On Thu, Apr 12, 2018 at 04:37:15PM +0200, Lukasz Majewski wrote:
> This commit adds support for KOE's 5.7" display.
> 
> Signed-off-by: Lukasz Majewski 
> ---
>  .../bindings/display/panel/koe,tx14d24vm1bpa.txt   | 42 
> ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 ++
>  2 files changed, 68 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt

Reviewed-by: Rob Herring 

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

Re: [[RFC]DPU PATCH 2/2] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Rob Herring]

On Fri, Apr 13, 2018 at 10:53:01AM +0530, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
> 
> Signed-off-by: Sandeep Panda 
> ---
>  .../bindings/display/bridge/ti,sn65dsi86.txt   | 75 
> ++
>  1 file changed, 75 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 000..cbd2f0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,75 @@
> +SN65DSI86 DSI to eDP bridge chip
> +
> +
> +This is the binding for Texas Instruments SN65DSI86 bridge.
> +
> +Required properties:
> +- compatible: Must be "ti,sn65dsi86"
> +- reg: i2c address of the chip, 0x2d as per datasheet
> +- enable-gpios: OF device-tree gpio specification for EDP_BRIJ_EN pin
> +- aux-sda-gpios: OF device-tree gpio specification for EDP_BRIJ_I2C_SDA pin 
> of AUX channel
> +- aux-scl-gpios: OF device-tree gpio specification for EDP_BRIJ_I2C_SCL pin 
> of AUX channel

What if I use I2C host on my device? If your board design uses bitbanged 
I2C, that is outside the scope of this binding and it should use 
i2c-gpio binding.

> +- bias-en-gpios: OF device-tree gpio specification for EN_PP3300_DX_EDP pin 
> to
> + enable 3.3V supply to eDP connector
> +- bklt-en-gpios: OF device-tree gpio specification for AP_EDP_BKLTEN 
pin
> +
> +- vccio-supply: A 1.8V supply that powers up the PHY.
> +- vcca-supply: A 1.2V supply that powers up the Controller.
> +- vccs-supply: A 3.3V supply that power the eDP connector
> +
> +Optional properties:
> +
> +- irq-gpios: OF device-tree gpio specification for interrupt pin

Use "interrupts" property instead.

> +- bklt-ctrl-gpios: OF device-tree gpio specification for EDP_BKLTCTL pin
> +
> +- sn,is-pluggable: boolean property to specify if HPD supported or not
> +- sn,custom-modes: OF device-tree specifiction to add support for custom 
> modes

"sn" is not a vendor.

> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modelled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for DSI input
> +- Video port 1 for eDP output
> +
> +Example
> +---
> +
> +edp-bridge@2d {
> + compatible = "ti,sn65dsi86";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2d>;
> +
> + enable-gpios = < 33 GPIO_ACTIVE_HIGH>;
> + aux-sda-gpios = < 34 GPIO_ACTIVE_HIGH>;
> + aux-scl-gpios = < 35 GPIO_ACTIVE_HIGH>;
> + bias-en-gpios = < 36 GPIO_ACTIVE_HIGH>;
> + bklt-en-gpios = < 37 GPIO_ACTIVE_HIGH>;
> +
> + vccio-supply = <_l17>;
> + vcca-supply = <_l6>;
> + vccs-supply = <_l7>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + edp_bridge_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + edp_bridge_out: endpoint {
> + remote-endpoint = <_panel_in>;
> + };
> + };
> + };
> +}
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 05/18] drm_hwcomposer: Enable resource manager support

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:16PM +0100, Alexandru Gheorghe wrote:
> Use the newly added ResourceManager for creating and detecting all the
> drm devices instead of assuming that there is only one device.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmhwctwo.cpp| 34 +-
>  drmhwctwo.h  |  4 +---
>  drmresources.cpp | 25 ++---
>  drmresources.h   | 14 +++---
>  4 files changed, 43 insertions(+), 34 deletions(-)
> 
> diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
> index dfca1a6..cddd5da 100644
> --- a/drmhwctwo.cpp
> +++ b/drmhwctwo.cpp
> @@ -58,40 +58,32 @@ DrmHwcTwo::DrmHwcTwo() {
>  }
>  
>  HWC2::Error DrmHwcTwo::Init() {
> -  int ret = drm_.Init();
> +  int ret = resource_manager_.Init();
>if (ret) {
> -ALOGE("Can't initialize drm object %d", ret);
> +ALOGE("Can't initialize the resource manager %d", ret);
>  return HWC2::Error::NoResources;
>}
>  
> -  importer_.reset(Importer::CreateInstance(_));
> -  if (!importer_) {
> -ALOGE("Failed to create importer instance");
> +  DrmResources *drm = resource_manager_.GetDrmResources(HWC_DISPLAY_PRIMARY);
> +  std::shared_ptr importer =
> +  resource_manager_.GetImporter(HWC_DISPLAY_PRIMARY);
> +  if (!drm || !importer) {
> +ALOGE("Failed to get a valid drmresource and importer");
>  return HWC2::Error::NoResources;
>}
> +  displays_.emplace(
> +  std::piecewise_construct, std::forward_as_tuple(HWC_DISPLAY_PRIMARY),
> +  std::forward_as_tuple(drm, importer, resource_manager_.GetGralloc(),
> +HWC_DISPLAY_PRIMARY, 
> HWC2::DisplayType::Physical));
>  
> -  ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
> -  (const hw_module_t **)_);
> -  if (ret) {
> -ALOGE("Failed to open gralloc module %d", ret);
> -return HWC2::Error::NoResources;
> -  }
> -
> -  displays_.emplace(std::piecewise_construct,
> -std::forward_as_tuple(HWC_DISPLAY_PRIMARY),
> -std::forward_as_tuple(_, importer_, gralloc_,
> -  HWC_DISPLAY_PRIMARY,
> -  HWC2::DisplayType::Physical));
> -
> -  DrmCrtc *crtc = 
> drm_.GetCrtcForDisplay(static_cast(HWC_DISPLAY_PRIMARY));
> +  DrmCrtc *crtc = 
> drm->GetCrtcForDisplay(static_cast(HWC_DISPLAY_PRIMARY));
>if (!crtc) {
>  ALOGE("Failed to get crtc for display %d",
>static_cast(HWC_DISPLAY_PRIMARY));
>  return HWC2::Error::BadDisplay;
>}
> -
>std::vector display_planes;
> -  for (auto  : drm_.planes()) {
> +  for (auto  : drm->planes()) {
>  if (plane->GetCrtcSupported(*crtc))
>display_planes.push_back(plane.get());
>}
> diff --git a/drmhwctwo.h b/drmhwctwo.h
> index 0490e2a..beb5d2d 100644
> --- a/drmhwctwo.h
> +++ b/drmhwctwo.h
> @@ -262,9 +262,7 @@ class DrmHwcTwo : public hwc2_device_t {
>HWC2::Error RegisterCallback(int32_t descriptor, hwc2_callback_data_t data,
> hwc2_function_pointer_t function);
>  
> -  DrmResources drm_;
> -  std::shared_ptr importer_;  // Shared with HwcDisplay
> -  const gralloc_module_t *gralloc_;
> +  ResourceManager resource_manager_;
>std::map displays_;
>std::map callbacks_;
>  };
> diff --git a/drmresources.cpp b/drmresources.cpp
> index 32dd376..a5ddda0 100644
> --- a/drmresources.cpp
> +++ b/drmresources.cpp
> @@ -42,10 +42,9 @@ DrmResources::~DrmResources() {
>event_listener_.Exit();
>  }
>  
> -int DrmResources::Init() {
> -  char path[PROPERTY_VALUE_MAX];
> -  property_get("hwc.drm.device", path, "/dev/dri/card0");
> -
> +int DrmResources::Init(ResourceManager *resource_manager, char *path,
> +   int start_display_index) {
> +  resource_manager_ = resource_manager;

You can avoid the backpointer if you just pass the RM to the right places (looks
like compositor + composition). Bonus points if you can remove drm_ from those
objects once you've done that.

>/* TODO: Use drmOpenControl here instead */
>fd_.Set(open(path, O_RDWR));
>if (fd() < 0) {
> @@ -76,8 +75,8 @@ int DrmResources::Init() {
>max_resolution_ =
>std::pair(res->max_width, res->max_height);
>  
> -  bool found_primary = false;
> -  int display_num = 1;
> +  bool found_primary = start_display_index != 0;
> +  int display_num = found_primary ? start_display_index : 1;

This could use a comment. AFAICT, you're assuming the primary display will
always be in the first drm device, which is fine, but should be explained
_somewhere_.

>  
>for (int i = 0; !ret && i < res->count_crtcs; ++i) {
>  drmModeCrtcPtr c = drmModeGetCrtc(fd(), res->crtcs[i]);
> @@ -161,9 +160,11 @@ int DrmResources::Init() {
>for (auto  : connectors_) {
>  if (conn->internal() && !found_primary) {
>conn->set_display(0);
> +  

Re: [PATCH v6 0/5] drm/blend: Support generic plane-wide alpha

[Maxime Ripard]

On Wed, Apr 11, 2018 at 09:39:24AM +0200, Maxime Ripard wrote:
> Hi,
> 
> This serie aims at enhancing the support for plane-wide alpha in the
> drivers that are implementing it at the moment, by turning it into a
> generic property and converting the drivers (rcar-du and atmel-hclcdc). It
> also introduces support for it in the sun4i driver.

Applied with Sean and Maarten's Acked-by, as reported on IRC.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/4] drm/vc4: Add CTM support

[Eric Anholt]

Stefan Schake  writes:

> The hardware has a single block for applying a CTM prior to gamma lut.
> It can be fed with pixels from one of our CRTC at a time and uses a
> matrix with S0.9 scalars. Use private atomic state to reject attempts
> from userland to apply CTM for more than one CRTC at a time and reject
> matrices with scalars that we can't approximate without integer bits.
>
> Signed-off-by: Stefan Schake 
> ---
> v3: New in the series

Patch 2-3 get my r-b, and I've sent Stefan a small series of fixups for
the modeset locking as was patiently explained to me by danvet.  With
that, it'll have my r-b, and hopefully danvet can confirm that it's what
he meant :)


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 08/18] drm_hwcomposer: Parse and store possible_clones information

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:19PM +0100, Alexandru Gheorghe wrote:
> drmModeEncoder has a field called possible_clones. It's a bit mask
> which tells if the encoder could be simultaneously connected, to the
> same CRTC, with the encoders specified in the possible_clones mask.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmencoder.cpp   | 8 
>  drmencoder.h | 4 
>  drmresources.cpp | 9 -
>  3 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drmencoder.cpp b/drmencoder.cpp
> index 1da7ec3..ff675f5 100644
> --- a/drmencoder.cpp
> +++ b/drmencoder.cpp
> @@ -39,6 +39,14 @@ DrmCrtc *DrmEncoder::crtc() const {
>return crtc_;
>  }
>  
> +bool DrmEncoder::can_clone(DrmEncoder *encoder) {
> +  return possible_clones_.find(encoder) != possible_clones_.end();
> +}

The find() call is probably enough to justify CamelCase for this function. FTR,
I _hate_ this part of the style guide and wish I had just picked one or the
other.

To improve readability, can you also change the name of "encoder" to
"possible_clone" like below so it's super obvious what this does?

> +
> +void DrmEncoder::add_possible_clone(DrmEncoder *possible_clone) {
> +  possible_clones_[possible_clone] = true;
> +}
> +
>  void DrmEncoder::set_crtc(DrmCrtc *crtc) {
>crtc_ = crtc;
>set_display(crtc->display());
> diff --git a/drmencoder.h b/drmencoder.h
> index 7e06691..5e7c010 100644
> --- a/drmencoder.h
> +++ b/drmencoder.h
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 

Alphabetical

>  #include 
>  
>  namespace android {
> @@ -43,6 +44,8 @@ class DrmEncoder {
>const std::vector _crtcs() const {
>  return possible_crtcs_;
>}
> +  bool can_clone(DrmEncoder *encoder);
> +  void add_possible_clone(DrmEncoder *possible_clone);
>  
>   private:
>uint32_t id_;
> @@ -50,6 +53,7 @@ class DrmEncoder {
>int display_;
>  
>std::vector possible_crtcs_;
> +  std::map possible_clones_;
>  };
>  }
>  
> diff --git a/drmresources.cpp b/drmresources.cpp
> index a5ddda0..39f50be 100644
> --- a/drmresources.cpp
> +++ b/drmresources.cpp
> @@ -97,6 +97,7 @@ int DrmResources::Init(ResourceManager *resource_manager, 
> char *path,
>  crtcs_.emplace_back(std::move(crtc));
>}
>  
> +  std::vector possible_clones;
>for (int i = 0; !ret && i < res->count_encoders; ++i) {
>  drmModeEncoderPtr e = drmModeGetEncoder(fd(), res->encoders[i]);
>  if (!e) {
> @@ -117,12 +118,18 @@ int DrmResources::Init(ResourceManager 
> *resource_manager, char *path,
>  
>  std::unique_ptr enc(
>  new DrmEncoder(e, current_crtc, possible_crtcs));
> -
> +possible_clones.push_back(e->possible_clones);
>  drmModeFreeEncoder(e);
>  
>  encoders_.emplace_back(std::move(enc));
>}
>  
> +  for (uint32_t i = 0; i < encoders_.size(); i++) {
> +for (uint32_t j = 0; j < encoders_.size(); j++)

for (auto : encoders_) {
  for (auto : encoders_) {

Or something similarly C++'y, looping through indices is sooo last decade :-)


> +  if (possible_clones[i] & (1 << j))
> +encoders_[i]->add_possible_clone(encoders_[j].get());
> +  }
> +
>for (int i = 0; !ret && i < res->count_connectors; ++i) {
>  drmModeConnectorPtr c = drmModeGetConnector(fd(), res->connectors[i]);
>  if (!c) {
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Dongwon Kim]

Yeah, I definitely agree on the idea of expanding the use case to the 
general domain where dmabuf sharing is used. However, what you are
targetting with proposed changes is identical to the core design of
hyper_dmabuf.

On top of this basic functionalities, hyper_dmabuf has driver level
inter-domain communication, that is needed for dma-buf remote tracking
(no fence forwarding though), event triggering and event handling, extra
meta data exchange and hyper_dmabuf_id that represents grefs
(grefs are shared implicitly on driver level)

Also it is designed with frontend (common core framework) + backend
(hyper visor specific comm and memory sharing) structure for portability.
We just can't limit this feature to Xen because we want to use the same
uapis not only for Xen but also other applicable hypervisor, like ACORN.

So I am wondering we can start with this hyper_dmabuf then modify it for
your use-case if needed and polish and fix any glitches if we want to 
to use this for all general dma-buf usecases.

Also, I still have one unresolved question regarding the export/import flow
in both of hyper_dmabuf and xen-zcopy.

@danvet: Would this flow (guest1->import existing dmabuf->share underlying
pages->guest2->map shared pages->create/export dmabuf) be acceptable now?

Regards,
DW
 
On Mon, Apr 16, 2018 at 05:33:46PM +0300, Oleksandr Andrushchenko wrote:
> Hello, all!
> 
> After discussing xen-zcopy and hyper-dmabuf [1] approaches
> 
> it seems that xen-zcopy can be made not depend on DRM core any more
> 
> and be dma-buf centric (which it in fact is).
> 
> The DRM code was mostly there for dma-buf's FD import/export
> 
> with DRM PRIME UAPI and with DRM use-cases in mind, but it comes out that if
> 
> the proposed 2 IOCTLs (DRM_XEN_ZCOPY_DUMB_FROM_REFS and
> DRM_XEN_ZCOPY_DUMB_TO_REFS)
> 
> are extended to also provide a file descriptor of the corresponding dma-buf,
> then
> 
> PRIME stuff in the driver is not needed anymore.
> 
> That being said, xen-zcopy can safely be detached from DRM and moved from
> 
> drivers/gpu/drm/xen into drivers/xen/dma-buf-backend(?).
> 
> This driver then becomes a universal way to turn any shared buffer between
> Dom0/DomD
> 
> and DomU(s) into a dma-buf, e.g. one can create a dma-buf from any grant
> references
> 
> or represent a dma-buf as grant-references for export.
> 
> This way the driver can be used not only for DRM use-cases, but also for
> other
> 
> use-cases which may require zero copying between domains.
> 
> For example, the use-cases we are about to work in the nearest future will
> use
> 
> V4L, e.g. we plan to support cameras, codecs etc. and all these will benefit
> 
> from zero copying much. Potentially, even block/net devices may benefit,
> 
> but this needs some evaluation.
> 
> 
> I would love to hear comments for authors of the hyper-dmabuf
> 
> and Xen community, as well as DRI-Devel and other interested parties.
> 
> 
> Thank you,
> 
> Oleksandr
> 
> 
> On 03/29/2018 04:19 PM, Oleksandr Andrushchenko wrote:
> >From: Oleksandr Andrushchenko 
> >
> >Hello!
> >
> >When using Xen PV DRM frontend driver then on backend side one will need
> >to do copying of display buffers' contents (filled by the
> >frontend's user-space) into buffers allocated at the backend side.
> >Taking into account the size of display buffers and frames per seconds
> >it may result in unneeded huge data bus occupation and performance loss.
> >
> >This helper driver allows implementing zero-copying use-cases
> >when using Xen para-virtualized frontend display driver by
> >implementing a DRM/KMS helper driver running on backend's side.
> >It utilizes PRIME buffers API to share frontend's buffers with
> >physical device drivers on backend's side:
> >
> >  - a dumb buffer created on backend's side can be shared
> >with the Xen PV frontend driver, so it directly writes
> >into backend's domain memory (into the buffer exported from
> >DRM/KMS driver of a physical display device)
> >  - a dumb buffer allocated by the frontend can be imported
> >into physical device DRM/KMS driver, thus allowing to
> >achieve no copying as well
> >
> >For that reason number of IOCTLs are introduced:
> >  -  DRM_XEN_ZCOPY_DUMB_FROM_REFS
> > This will create a DRM dumb buffer from grant references provided
> > by the frontend
> >  - DRM_XEN_ZCOPY_DUMB_TO_REFS
> >This will grant references to a dumb/display buffer's memory provided
> >by the backend
> >  - DRM_XEN_ZCOPY_DUMB_WAIT_FREE
> >This will block until the dumb buffer with the wait handle provided
> >be freed
> >
> >With this helper driver I was able to drop CPU usage from 17% to 3%
> >on Renesas R-Car M3 board.
> >
> >This was tested with Renesas' Wayland-KMS and backend running as DRM master.
> >
> >Thank you,
> >Oleksandr
> >
> >Oleksandr Andrushchenko (1):
> >   drm/xen-zcopy: Add Xen zero-copy helper DRM driver
> >
> >  Documentation/gpu/drivers.rst   |   1 +
> 

Re: [PATCH hwc v2 06/18] drm_hwcomposer: Add writeback connector support

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:17PM +0100, Alexandru Gheorghe wrote:
> Writeback connector is a special case of connector, which can be
> linked to a CRTC in order to get the result of the composition back to
> a memory buffer. This had not been merged to the mainline kernel yet,
> latest version of the kernel patches could be found here [1].
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmconnector.cpp | 42 +-
>  drmconnector.h   |  7 +++
>  2 files changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/drmconnector.cpp b/drmconnector.cpp
> index 145518f..e482832 100644
> --- a/drmconnector.cpp
> +++ b/drmconnector.cpp
> @@ -52,6 +52,26 @@ int DrmConnector::Init() {
>  ALOGE("Could not get CRTC_ID property\n");
>  return ret;
>}
> +  if (writeback()) {
> +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_PIXEL_FORMATS",
> + _pixel_formats_);
> +if (ret) {
> +  ALOGE("Could not get WRITEBACK_PIXEL_FORMATS connector_id = %d\n", 
> id_);
> +  return ret;
> +}
> +ret =
> +drm_->GetConnectorProperty(*this, "WRITEBACK_FB_ID", 
> _fb_id_);

Please break on the function arguments instead of the =


> +if (ret) {
> +  ALOGE("Could not get WRITEBACK_FB_ID connector_id = %d\n", id_);
> +  return ret;
> +}
> +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_OUT_FENCE_PTR",
> + _out_fence_);

Like this :)

With that,

Reviewed-by: Sean Paul 




> +if (ret) {
> +  ALOGE("Could not get WRITEBACK_OUT_FENCE_PTR connector_id = %d\n", 
> id_);
> +  return ret;
> +}
> +  }
>return 0;
>  }
>  
> @@ -78,8 +98,16 @@ bool DrmConnector::external() const {
>   type_ == DRM_MODE_CONNECTOR_VGA;
>  }
>  
> +bool DrmConnector::writeback() const {
> +#ifdef DRM_MODE_CONNECTOR_WRITEBACK
> +  return type_ == DRM_MODE_CONNECTOR_WRITEBACK;
> +#else
> +  return false;
> +#endif
> +}
> +
>  bool DrmConnector::valid_type() const {
> -  return internal() || external();
> +  return internal() || external() || writeback();
>  }
>  
>  int DrmConnector::UpdateModes() {
> @@ -130,6 +158,18 @@ const DrmProperty ::crtc_id_property() 
> const {
>return crtc_id_property_;
>  }
>  
> +const DrmProperty ::writeback_pixel_formats() const {
> +  return writeback_pixel_formats_;
> +}
> +
> +const DrmProperty ::writeback_fb_id() const {
> +  return writeback_fb_id_;
> +}
> +
> +const DrmProperty ::writeback_out_fence() const {
> +  return writeback_out_fence_;
> +}
> +
>  DrmEncoder *DrmConnector::encoder() const {
>return encoder_;
>  }
> diff --git a/drmconnector.h b/drmconnector.h
> index 5601e06..e139730 100644
> --- a/drmconnector.h
> +++ b/drmconnector.h
> @@ -46,6 +46,7 @@ class DrmConnector {
>  
>bool internal() const;
>bool external() const;
> +  bool writeback() const;
>bool valid_type() const;
>  
>int UpdateModes();
> @@ -58,6 +59,9 @@ class DrmConnector {
>  
>const DrmProperty _property() const;
>const DrmProperty _id_property() const;
> +  const DrmProperty _pixel_formats() const;
> +  const DrmProperty _fb_id() const;
> +  const DrmProperty _out_fence() const;
>  
>const std::vector _encoders() const {
>  return possible_encoders_;
> @@ -88,6 +92,9 @@ class DrmConnector {
>  
>DrmProperty dpms_property_;
>DrmProperty crtc_id_property_;
> +  DrmProperty writeback_pixel_formats_;
> +  DrmProperty writeback_fb_id_;
> +  DrmProperty writeback_out_fence_;
>  
>std::vector possible_encoders_;
>  };
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: Filter out alpha formats for primary plane

[Sean Paul]

On Mon, Apr 16, 2018 at 12:01:03PM -0700, Kristian H. Kristensen wrote:
> Rockchip doesn't support per-pixel alpha blending for the lowest
> window in the stack. While the hw supports restacking the windows, we
> don't expose that in KMS, so just filter out alpha formats for the
> primary plane.
> 
> Change-Id: I7828d5bf0f0b5c6dd23f9e52aa01a5a683131d2f

Can you please strip this from upstream commit msgs?

> Signed-off-by: Kristian H. Kristensen 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fae37b1cd691..2efe78600fd0 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1547,6 +1547,28 @@ static irqreturn_t vop_isr(int irq, void *data)
>   return ret;
>  }
>  
> +static uint32_t formats_for_win(const struct vop_win_phy *phy, uint32_t win,
> + uint32_t *formats, uint32_t max_formats)
> +{
> + uint32_t i, j;
> +
> + BUG_ON(max_formats < phy->nformats);
> +
> + j = 0;
> + for (i = 0; i < phy->nformats; i++) {
> + /*
> +  * win0 doesn't support per-pixel alpha, so don't add any RGBA
> +  * formats for that plane.
> +  */
> + if (win == 0 && is_alpha_support(phy->data_formats[i]))
> + continue;
> +
> + formats[j++] = phy->data_formats[i];
> + }
> +
> + return j;
> +}
> +
>  static int vop_create_crtc(struct vop *vop)
>  {
>   const struct vop_data *vop_data = vop->data;
> @@ -1568,15 +1590,17 @@ static int vop_create_crtc(struct vop *vop)
>   for (i = 0; i < vop_data->win_size; i++) {
>   struct vop_win *vop_win = >win[i];
>   const struct vop_win_data *win_data = vop_win->data;
> + uint32_t nformats, formats[16];

I guess 16 is probably a safe bet, but perhaps either pull it out into a define,
or just devm_kzalloc the format to phy->nformats. If you choose the former, the
loop in formats_for_win should ensure it doesn't overrun formats.

Sean

>  
>   if (win_data->type != DRM_PLANE_TYPE_PRIMARY &&
>   win_data->type != DRM_PLANE_TYPE_CURSOR)
>   continue;
>  
> + nformats = formats_for_win(win_data->phy, i,
> +formats, ARRAY_SIZE(formats));
>   ret = drm_universal_plane_init(vop->drm_dev, _win->base,
>  0, _plane_funcs,
> -win_data->phy->data_formats,
> -win_data->phy->nformats,
> +formats, nformats,
>  win_data->phy->format_modifiers,
>  win_data->type, NULL);
>   if (ret) {
> -- 
> 2.13.5
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: fix VOP vblank race

[Heiko Stuebner]

Hi John,

Am Montag, 16. April 2018, 18:46:56 CEST schrieb John Keeping:
> Hi Sandy,
> 
> On Tue, 10 Apr 2018 20:40:06 +0800, Sandy Huang wrote:
> 
> > Reviewed-by: Sandy huang 
> 
> Thanks for the review, but I don't see this in drm-misc yet.  Are you
> planning to pick this up?

I was occupied with merge-window stuff recently, but I guess either
Sandy or myself is going to pick it up shortly.


Heiko

> > 在 2018/3/29 0:03, John Keeping 写道:
> > > We have seen a case of a bad reference count for vblanks with the
> > > Rockchip VOP:
> > >
> > >   [ cut here ]
> > >   WARNING: CPU: 1 PID: 383 at drivers/gpu/drm/drm_irq.c:1198 
> > > drm_vblank_put+0x40/0xcc
> > >   Modules linked in: brcmfmac brcmutil
> > >   CPU: 1 PID: 383 Comm: kworker/u8:2 Not tainted 4.9.75-rt60 #1
> > >   Hardware name: Rockchip (Device Tree)
> > >   Workqueue: events_unbound flip_worker
> > >   Backtrace:
> > >   [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
> > >r7:c0b1b13c r6:600b0013 r5: r4:c0b1b13c
> > >   [] (show_stack) from [] (dump_stack+0x78/0x94)
> > >   [] (dump_stack) from [] (__warn+0xe4/0x104)
> > >r7:0009 r6:c03cf26c r5: r4:
> > >   [] (__warn) from [] (warn_slowpath_null+0x28/0x30)
> > >r9:eeb443a0 r8:eeb443c8 r7:ee8a5ec0 r6:ee8a5ec0 r5:edb47f00 r4:ee096200
> > >   [] (warn_slowpath_null) from [] 
> > > (drm_vblank_put+0x40/0xcc)
> > >   [] (drm_vblank_put) from [] 
> > > (drm_crtc_vblank_put+0x18/0x1c)
> > >r5:edb47f00 r4:ee3c8a80
> > >   [] (drm_crtc_vblank_put) from [] 
> > > (vop_fb_unref_worker+0x18/0x24)
> > >   [] (vop_fb_unref_worker) from [] 
> > > (flip_worker+0x98/0xb4)
> > >r5:edb47f00 r4:eeb443a8
> > >   [] (flip_worker) from [] 
> > > (process_one_work+0x1a8/0x2fc)
> > >r9: r8:ee807d00 r7: r6:ee809c00 r5:eeb443a8 r4:edfe5f80
> > >   [] (process_one_work) from [] 
> > > (worker_thread+0x2ac/0x458)
> > >r10:0088 r9:edfe5f98 r8:ee809c2c r7:c0b04100 r6:ee809c00 
> > > r5:ee809c00
> > >r4:edfe5f80
> > >   [] (worker_thread) from [] (kthread+0xfc/0x10c)
> > >r10: r9: r8:c0135640 r7:edfe5f80 r6: 
> > > r5:edf0e240
> > >r4:ee8a4000 r3:ed194e00
> > >   [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> > >r8: r7: r6: r5:c0139fc0 r4:edf0e240
> > >   ---[ end trace 0002 ]---
> > >
> > > It seems that this is caused by unfortunate timing between
> > > vop_crtc_atomic_flush() and vop_handle_vblank() given the following
> > > ordering:
> > >
> > >   atomic_flushhandle_vblank
> > >   -
> > >
> > >   drm_flip_work_queue
> > >   set_bit
> > >   if (test_and_clear_bit(...))
> > >   drm_flip_work_commit
> > >   drm_vblank_get
> > >
> > > This results in vop_fb_unref_worker (called as flip work) decrementing
> > > the vblank refcount before it has been incremented.
> > >
> > > Signed-off-by: John Keeping 
> > > ---
> > >   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > index 6755a9eea4b2..d4e1400aedf3 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > @@ -1017,9 +1017,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc 
> > > *crtc,
> > >   continue;
> > >   
> > >   drm_framebuffer_get(old_plane_state->fb);
> > > + WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > >   drm_flip_work_queue(>fb_unref_work, 
> > > old_plane_state->fb);
> > >   set_bit(VOP_PENDING_FB_UNREF, >pending);
> > > - WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > >   }
> > >   }
> > > 
> > 
> > 
> 


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

[PATCH v3 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

[Eric Anholt]

The GPU subsystem node was a workaround to have a central device to
bind V3D and display to.  Following the lead of 246774d17fc0
("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
the subsystem node usage and just create a platform device for the DRM
device to attach to if any of the subsystem devices are present.

v2: Simplify the DT walking code.
v3: Always put the node.

Signed-off-by: Eric Anholt 
---
 .../bindings/display/brcm,bcm-vc4.txt |  7 -
 drivers/gpu/drm/vc4/vc4_drv.c | 28 +--
 drivers/gpu/drm/vc4/vc4_hvs.c |  1 +
 drivers/gpu/drm/vc4/vc4_v3d.c |  1 +
 4 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 284e2b14cfbe..5fd4717101d6 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -4,9 +4,6 @@ The VC4 device present on the Raspberry Pi includes a display 
system
 with HDMI output and the HVS (Hardware Video Scaler) for compositing
 display planes.
 
-Required properties for VC4:
-- compatible:  Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
-
 Required properties for Pixel Valve:
 - compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
  "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
@@ -153,10 +150,6 @@ v3d: v3d@7ec0 {
interrupts = <1 10>;
 };
 
-vc4: gpu {
-   compatible = "brcm,bcm2835-vc4";
-};
-
 panel: panel {
compatible = "ontat,yx700wv03", "simple-panel";
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 7c95ed5c5cac..e8ba9e7c71d2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -364,22 +364,29 @@ static int vc4_platform_drm_remove(struct platform_device 
*pdev)
return 0;
 }
 
-static const struct of_device_id vc4_of_match[] = {
-   { .compatible = "brcm,bcm2835-vc4", },
-   { .compatible = "brcm,cygnus-vc4", },
-   {},
-};
-MODULE_DEVICE_TABLE(of, vc4_of_match);
-
 static struct platform_driver vc4_platform_driver = {
.probe  = vc4_platform_drm_probe,
.remove = vc4_platform_drm_remove,
.driver = {
.name   = "vc4-drm",
-   .of_match_table = vc4_of_match,
},
 };
 
+static bool
+driver_of_table_has_a_match(const struct platform_driver *driver)
+{
+   struct device_node *node;
+   bool ret;
+
+   node = of_find_matching_node_and_match(NULL,
+  driver->driver.of_match_table,
+  NULL);
+   ret = of_device_is_available(node);
+   of_node_put(node);
+
+   return ret;
+}
+
 static int __init vc4_drm_register(void)
 {
int ret;
@@ -389,6 +396,11 @@ static int __init vc4_drm_register(void)
if (ret)
return ret;
 
+   if (driver_of_table_has_a_match(_v3d_driver) ||
+   driver_of_table_has_a_match(_hvs_driver)) {
+   platform_device_register_simple("vc4-drm", -1, NULL, 0);
+   }
+
return platform_driver_register(_platform_driver);
 }
 
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2b62fc5b8d85..730813ee74ae 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -262,6 +262,7 @@ static const struct of_device_id vc4_hvs_dt_match[] = {
{ .compatible = "brcm,bcm2835-hvs" },
{}
 };
+MODULE_DEVICE_TABLE(of, vc4_hvs_dt_match);
 
 struct platform_driver vc4_hvs_driver = {
.probe = vc4_hvs_dev_probe,
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index bfc2fa73d2ae..e77e9ebbab4b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -459,6 +459,7 @@ static const struct of_device_id vc4_v3d_dt_match[] = {
{ .compatible = "brcm,vc4-v3d" },
{}
 };
+MODULE_DEVICE_TABLE(of, vc4_v3d_dt_match);
 
 struct platform_driver vc4_v3d_driver = {
.probe = vc4_v3d_dev_probe,
-- 
2.17.0

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

[Bug 106053] Drawing at screen boundary is very slow.

[bugzilla-daemon]

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

--- Comment #3 from Roland Scheidegger  ---
(In reply to Marek Olšák from comment #2)
> r300g on RC410 uses software emulation for vertex shaders and clipping (the
> same code as llvmpipe), because the hardware doesn't have any vertex
> processor and clipper.
Can't the chip do guardband clipping? I thought all radeon chips (starting from
r100) could do this, regardless if they support hw tnl.
I could be wrong though (and I wouldn't know how large the guardband would be,
and certainly draw's handling of guardband if you enable it is a bit lacking,
since hw has fixed limits whereas draw will use a guardband twice the size of
the viewport).

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

Re: [PATCH] drm/rockchip: Filter out alpha formats for primary plane

[Eric Anholt]

"Kristian H. Kristensen"  writes:

> Rockchip doesn't support per-pixel alpha blending for the lowest
> window in the stack. While the hw supports restacking the windows, we
> don't expose that in KMS, so just filter out alpha formats for the
> primary plane.

In discussing this for VC4, we noted that an alternative is to just set
up the lowest plane as an RGBX format, since alpha is premultiplied and
the background is black.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106053] Drawing at screen boundary is very slow.

[bugzilla-daemon]

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

--- Comment #4 from Marek Olšák  ---
I think the hw doesn't have a clipper, though it shouldn't be hard to verify if
it's true. Yeah, draw could use some optimizations for the clipper, e.g. the
guardband, but simply doing culling (not clipping) should be enough for point
sprites.

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

Re: [PATCH] drm/rockchip: Filter out alpha formats for primary plane

[Kristian Høgsberg]

On Mon, Apr 16, 2018 at 2:59 PM Eric Anholt  wrote:

> "Kristian H. Kristensen"  writes:

> > Rockchip doesn't support per-pixel alpha blending for the lowest
> > window in the stack. While the hw supports restacking the windows, we
> > don't expose that in KMS, so just filter out alpha formats for the
> > primary plane.

> In discussing this for VC4, we noted that an alternative is to just set
> up the lowest plane as an RGBX format, since alpha is premultiplied and
> the background is black.

Doh, of course. Thanks Eric.

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

[PATCH] CHROMIUM: drm/rockchip: Disable blending for win0

[Kristian H. Kristensen]

Blending win0 with the background color doesn't seem to work
correctly. We only get the background color, no matter the contents of
the win0 framebuffer.  However, blending pre-multiplied color with the
default opaque black default background color is a no-op, so we can
just disable blending to get the correct result.

Signed-off-by: Kristian H. Kristensen 
Cc: Sandy Huang 
Cc: Sean Paul 
---
As per Eric's suggestion, we can just disable blending. This replaces
the previous "Filter out alpha formats for primary plane" patch.

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fae37b1cd691..1c1dd11d489a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -961,7 +961,14 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
rb_swap = has_rb_swapped(fb->format->format);
VOP_WIN_SET(vop, win, rb_swap, rb_swap);
 
-   if (is_alpha_support(fb->format->format)) {
+   /*
+* Blending win0 with the background color doesn't seem to work
+* correctly. We only get the background color, no matter the contents
+* of the win0 framebuffer.  However, blending pre-multiplied color
+* with the default opaque black default background color is a no-op,
+* so we can just disable blending to get the correct result.
+*/
+   if (is_alpha_support(fb->format->format) && win_index > 0) {
VOP_WIN_SET(vop, win, dst_alpha_ctl,
DST_FACTOR_M0(ALPHA_SRC_INVERSE));
val = SRC_ALPHA_EN(1) | SRC_COLOR_M0(ALPHA_SRC_PRE_MUL) |
-- 
2.17.0.484.g0c8726318c-goog

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

Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel

[abhinavk]

Hi Bjorn

Thanks for the review.

Reply inline.

On 2018-04-16 09:41, Bjorn Andersson wrote:

On Sat 14 Apr 00:25 PDT 2018, Abhinav Kumar wrote:


Register truly panel as a backlight led device and
provide methods to control its backlight operation.

Changes in v2:
- Removed redundant NULL checks
- Arranged headers alphabetically
- Formatting fixes


The change log goes below the "---" line.

[Abhinav] As sean mentioned, its quite common to list it to view it in 
the log.

This practice has been followed by quite a few in DRM
Another reference here https://patchwork.freedesktop.org/patch/211361/



Signed-off-by: Abhinav Kumar 
---

[..]

+static int truly_backlight_setup(struct truly_wqxga *ctx)
+{
+   struct backlight_properties props;
+   char bl_node_name[BL_NODE_NAME_SIZE];
+
+   if (!ctx->backlight) {
+   memset(, 0, sizeof(props));
+   props.type = BACKLIGHT_RAW;
+   props.power = FB_BLANK_UNBLANK;
+   props.max_brightness = 4096;
+
+   snprintf(bl_node_name, BL_NODE_NAME_SIZE, "panel%u-backlight",
+PRIM_DISPLAY_NODE);
+
+   ctx->backlight =  backlight_device_register(bl_node_name,
+   ctx->dev, ctx,
+   _backlight_device_ops, );
+
+   if (IS_ERR_OR_NULL(ctx->backlight)) {
+   pr_err("Failed to register backlight\n");
+   ctx->backlight = NULL;
+   return -ENODEV;
+   }
+
+   /* Register with the LED driver interface */
+   led_trigger_register_simple("bkl-trigger", >wled);
+
+   if (!ctx->wled) {
+   pr_err("backlight led registration failed\n");
+   return -ENODEV;
+   }


It seems like you're registering a backlight driver for the sake of
invoking the LED backlight trigger to control the WLED.

The WLED is a backlight driver, so all you should have to do is add the
following line to your probe:

ctx->backlight = devm_of_find_backlight(dev);

and then add "backlight = <>" to your dt node.

Regards,
Bjorn

[Abhinav] Thats not the only purpose of backlight_device_register().
We want to hook up our panel with the parent backlight driver in
drivers/video/backlight/backlight.c and also route all the 
update_backlight_status()

calls through the sysfs of the newly registered node.

The of_find_backlight() method doesnt seem to allow us to register our 
own

sysfs method.

BTW, this isnt something which we are doing uniquely.
There are other panels which seem to be doing this :

drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

Can you please comment on whether we can have our own sysfs without
the device_register()?


___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

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

RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Srivatsa, Anusha]

>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Wednesday, April 11, 2018 5:27 AM
>To: Ian W MORRISON 
>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
>; Wajdeczko, Michal
>; Greg KH ;
>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>linux-ker...@vger.kernel.org;
>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
>Geminilake
>
>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
>> 
>>
>>>
>>> NAK on indiscriminate Cc: stable. There are zero guarantees that
>>> older kernels will work with whatever firmware you throw at them.
>>>
>>
>> I included 'Cc: stable' so the patch would get added to the v4.16 and
>> v4.15 kernels which I have tested with the patch. I found that earlier
>> kernels didn't support the 'linux-firmware' package required to get
>> wifi working on Intel's new Gemini Lake NUC.
>
>You realize that this patch should have nothing to do with wifi?
>
>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate the 
>specific
>versions of stable it is appropriate for.

Hi Jani,

The stable kernel version is 4.12 and beyond.
It is appropriate to add the CC: stable in my opinion

Anusha
>BR,
>Jani.
>
>>
>>>
>>> PS. How is this a "RESEND"? I haven't seen this before.
>>>
>>
>> It is a 'RESEND' for that very reason. I initially sent the patch to
>> the same people as a similar patch
>> (https://patchwork.kernel.org/patch/10143637/) however after realising
>> this omitted required addresses I added them and resent the patch.
>>
>> Best regards,
>> Ian
>
>--
>Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] Add udmabuf misc device

[Oleksandr Andrushchenko]

On 04/13/2018 06:37 PM, Daniel Vetter wrote:

On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:

On 04/10/2018 08:26 PM, Dongwon Kim wrote:

On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:

On 04/06/2018 09:57 PM, Dongwon Kim wrote:

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:

On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:

Hi,


I fail to see any common ground for xen-zcopy and udmabuf ...

Does the above mean you can assume that xen-zcopy and udmabuf
can co-exist as two different solutions?

Well, udmabuf route isn't fully clear yet, but yes.

See also gvt (intel vgpu), where the hypervisor interface is abstracted
away into a separate kernel modules even though most of the actual vgpu
emulation code is common.

Thank you for your input, I'm just trying to figure out
which of the three z-copy solutions intersect and how much

And what about hyper-dmabuf?

xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
in terms of these core sharing feature:

1. the sharing process - import prime/dmabuf from the producer -> extract
underlying pages and get those shared -> return references for shared pages

Another thing is danvet was kind of against to the idea of importing existing
dmabuf/prime buffer and forward it to the other domain due to synchronization
issues. He proposed to make hyper_dmabuf only work as an exporter so that it
can have a full control over the buffer. I think we need to talk about this
further as well.

Yes, I saw this. But this limits the use-cases so much.
For instance, running Android as a Guest (which uses ION to allocate
buffers) means that finally HW composer will import dma-buf into
the DRM driver. Then, in case of xen-front for example, it needs to be
shared with the backend (Host side). Of course, we can change user-space
to make xen-front allocate the buffers (make it exporter), but what we try
to avoid is to change user-space which in normal world would have remain
unchanged otherwise.
So, I do think we have to support this use-case and just have to understand
the complexity.

Erm, why do you need importer capability for this use-case?

guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy exposes
that dma-buf -> import to the real display hw

No where in this chain do you need xen-zcopy to be able to import a
dma-buf (within linux, it needs to import a bunch of pages from the
hypervisor).

Now if your plan is to use xen-zcopy in the guest1 instead of xen-front,
then you indeed need to import.

This is the exact use-case I was referring to while saying
we need to import on Guest1 side. If hyper-dmabuf is so
generic that there is no xen-front in the picture, then
it needs to import a dma-buf, so it can be exported at Guest2 side.

  But that imo doesn't make sense:
- xen-front gives you clearly defined flip events you can forward to the
   hypervisor. xen-zcopy would need to add that again.

xen-zcopy is a helper driver which doesn't handle page flips
and is not a KMS driver as one might think of: the DRM UAPI it uses is
just to export a dma-buf as a PRIME buffer, but that's it.
Flipping etc. is done by the backend [1], not xen-zcopy.

  Same for
   hyperdmabuf (and really we're not going to shuffle struct dma_fence over
   the wire in a generic fashion between hypervisor guests).

- xen-front already has the idea of pixel format for the buffer (and any
   other metadata). Again, xen-zcopy and hyperdmabuf lack that, would need
   to add it shoehorned in somehow.

Again, here you are talking of something which is implemented in
Xen display backend, not xen-zcopy, e.g. display backend can
implement para-virtual display w/o xen-zcopy at all, but in this case
there is a memory copying for each frame. With the help of xen-zcopy
the backend feeds xen-front's buffers directly into Guest2 DRM/KMS or
Weston or whatever as xen-zcopy exports remote buffers as PRIME buffers,
thus no buffer copying is required.


Ofc you won't be able to shovel sound or media stream data over to another
guest like this, but that's what you have xen-v4l and xen-sound or
whatever else for. Trying to make a new uapi, which means userspace must
be changed for all the different use-case, instead of reusing standard
linux driver uapi (which just happens to send the data to another
hypervisor guest instead of real hw) imo just doesn't make much sense.

Also, at least for the gpu subsystem: Any new uapi must have full
userspace available for it, see:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

Adding more uapi is definitely the most painful way to fix a use-case.
Personally I'd go as far and also change the xen-zcopy side on the
receiving guest to use some standard linux uapi. E.g. you could write an
output v4l driver to receive the frames from guest1.

So, we now know that xen-zcopy was not meant to handle page flips,
but to implement new UAPI to let user-space 

Re: [RFC v4 00/25] drm: Add generic fbdev emulation

[Daniel Vetter]

On Thu, Apr 12, 2018 at 06:34:46PM +0200, Noralf Trønnes wrote:
> I hit a 'Sending rate exceeded' error with this patchset, so it didn't go
> out as it should.
> I will resend the patchset when I find out how to avoid this problem.

That's generally an issue with your ISP. gmail works ime for mail bombs,
even big ones.
-Daniel

> 
> Noralf.
> 
> 
> Den 12.04.2018 15.17, skrev Noralf Trønnes:
> > This patchset explores the possibility of having generic fbdev emulation
> > in DRM for drivers that supports dumb buffers which they can export. An
> > API is added to support in-kernel clients in general.
> > 
> > In this version I was able to reuse the modesetting code from
> > drm_fb_helper in the client API. This avoids code duplication, carries
> > over lessons learned and the modesetting code is bisectable. The
> > downside is that it takes +10 patches to rip drm_fb_helper in two, so
> > maybe it's not worth it wrt possible breakage and a challenging review.
> > 
> > Does the Intel CI test the fbdev emulation?
> > 
> > Daniel had this concern with the previous version:
> > 
> >  The register/unregister model needs more thought. Allowing both clients
> >  to register whenever they want to, and drm_device instances to come and
> >  go is what fbcon has done, and the resulting locking is a horror show.
> > 
> >  I think if we require that all in-kernel drm_clients are registers when
> >  loading drm.ko (and enabled/disabled only per module options and
> >  Kconfig), then we can throw out all the locking. That avoids a lot of
> >  the headaches.
> > 
> > I have solved this by adding a notifier that fires when a new DRM device
> > is registered (I've removed the new() callback). Currently only
> > bootsplash uses this. The fbdev client needs to be setup from the driver
> > since it can't know on device registration if the driver will setup it's
> > own fbdev emulation later and the vtcon client hooks up to a user
> > provided device id.
> > 
> > Since fbcon can't handle fb_open failing, the buffer has to be
> > pre-allocated. Exporting a GEM buffer pins the driver module making it
> > impossible to unload it.
> > I have included 2 solutions to the problem:
> > - sysfs file to remove/close clients: remove_internal_clients
> > - Change drm_gem_prime_export() so it doesn't pin on client buffers
> > 
> > If a dumb buffer is exported from a kernel thread (worker) context, the
> > file descriptor isn't closed and I leak a reference so the buffer isn't
> > freed. Please look at drm_client_buffer_create() in patch
> > 'drm/client: Finish the in-kernel client API'.
> > This is a blocker that needs a solution.
> > 
> > 
> > Noralf.
> > 
> > Changes since version 3:
> > Client API changes:
> > - Drop drm_client_register_funcs() which attached clients indirectly.
> >Let clients attach directly using drm_client_new{_from_id}(). Clients
> >that wants to attach to all devices must be linked into drm.ko and use
> >the DRM device notifier. This is done to avoid the lock/race
> >register/unregister hell we have with fbcon. (Daniel Vetter)
> > - drm_client_display_restore() checks if there is a master and if so
> >returns -EBUSY. (Daniel Vetter)
> > - Allocate drm_file up front instead of on-demand. Since fbdev can't do
> >on demand buffer allocation because of fbcon, there's no need for this.
> > - Add sysfs file to remove clients
> > - Don't pin driver module when exporting gem client buffers
> > - Dropped page flip support since drm_fb_helper is now used for fbdev
> >emulation.
> > 
> > - The bootsplash client now switches over to fbdev on keypress.
> > 
> > Changes since version 2:
> > - Don't set drm master for in-kernel clients. (Daniel Vetter)
> > - Add in-kernel client API
> > 
> > Changes since version 1:
> > - Don't add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
> >DRM_FB_HELPER_DEFAULT_OPS(). (Fi.CI.STATIC)
> >The following uses that macro and sets fb_open/close: udlfb_ops,
> >amdgpufb_ops, drm_fb_helper_generic_fbdev_ops, nouveau_fbcon_ops,
> >nouveau_fbcon_sw_ops, radeonfb_ops.
> >This results in: warning: Initializer entry defined twice
> > - Support CONFIG_DRM_KMS_HELPER=m (kbuild test robot)
> >ERROR:  [drivers/gpu/drm/drm_kms_helper.ko] undefined!
> > - Drop buggy patch: (Chris Wilson)
> >drm/prime: Clear drm_gem_object->dma_buf on release
> > - Defer buffer creation until fb_open.
> > 
> > 
> > David Herrmann (1):
> >drm: provide management functions for drm_file
> > 
> > Noralf Trønnes (24):
> >drm/file: Don't set master on in-kernel clients
> >drm/fb-helper: No need to cache rotation and sw_rotations
> >drm/fb-helper: Remove drm_fb_helper_debug_enter/leave()
> >drm/fb-helper: dpms_legacy(): Only set on connectors in use
> >drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
> >drm: Begin an API for in-kernel clients
> >drm/fb-helper: Use struct drm_client_display
> >

Re: [PATCH] drm: fix drm-get-put.cocci warnings

[Daniel Vetter]

On Thu, Apr 12, 2018 at 07:54:10AM +0200, Julia Lawall wrote:
> From: Fengguang Wu 
> 
>  Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and
>  drm_*_unreference() helpers.
> 
> Generated by: scripts/coccinelle/api/drm-get-put.cocci
> 
> Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver")
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 
> ---
> 
> tree:   https://github.com/shenki/linux drm-v1

This isn't an upstream tree (and the aspeed driver isn't in upstream
afaict), so no need for spamming mailing lists I think.

But thanks for doing all this, great motivation to put more of the drm
refactorings into cocci files.

Cheers, Daniel
> head:   9680ed7979d5d403c6bde36271a048d62c048180
> commit: 6784ac15bc6889280522b04b97f1fb1208ee45e7 [23/27] drm: Add ASPEED
> GFX
> driver
> 
>  aspeed_gfx_drv.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -268,7 +268,7 @@ static int aspeed_gfx_probe(struct platf
>  err_unload:
>   aspeed_gfx_unload(drm);
>  err_free:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> 
>   return ret;
>  }
> @@ -279,7 +279,7 @@ static int aspeed_gfx_remove(struct plat
> 
>   drm_dev_unregister(drm);
>   aspeed_gfx_unload(drm);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> 
>   return 0;
>  }
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Batched ww-mutexes, wound-wait vs wait-die etc.

[Thomas Hellstrom]

On 04/14/2018 10:33 AM, Daniel Vetter wrote:

Hi Thomas,

On Fri, Apr 13, 2018 at 10:23 PM, Thomas Hellstrom
 wrote:

On 04/13/2018 07:13 PM, Daniel Vetter wrote:

On Wed, Apr 11, 2018 at 10:27:06AM +0200, Thomas Hellstrom wrote:

2) Should we add a *real* wound-wait choice to our wound-wait mutexes.
Otherwise perhaps rename them or document that they're actually doing
wait-die.

I think a doc patch would be good at least. Including all the data you
assembled here.


Actually, a further investigation appears to indicate that manipulating the
lock state under a local spinlock is about fast as using atomic operations
even for the completely uncontended cases.

This means that we could have a solution where you decide on a per-mutex or
per-reservation object basis whether you want to manipulate lock-state under
a "batch group" spinlock, meaning certain performance characteristics or
traditional local locking, meaning other performance characteristics.

Like, vmwgfx could choose batching locks, radeon traditional locks, but the
same API would work for both and locks could be shared between drivers..

Don't we need to make this decision at least on a per-class level?


No, I was thinking more in the line of the ww_mutex having a pointer to 
the spinlock. It could either be the local mutex "wait_lock", or a
per-batch-group lock. The mutex code wouldn't care. We do need a special 
API for batched locking, though, but not for ordinary locking.

Both APIs should be able to handle local or grouped spinlocks.

Note that this would of course require that there would be no 
performance loss for users that don't use batch groups.


I guess the most efficient use for GPU command submission would be to 
use per-process batch-groups. Then when the batch encounters a ww_mutex 
with a different batch group (for example the display server shared 
surface, it'll just switch batch lock), and this way the contention for

the batch spinlock will be mostly eliminated.


  Or
how will the spinlock/batch-lock approach interact with the normal
ww_mutex_lock path (which does require the atomics/ordered stores
we're trying to avoid)?


We can use the same code with some extra
if (use_ww_ctx) in the common locking and unlocking path.
Note that the "use_ww_ctx" parameter is defined at compile-time so the 
ordinary mutex path (binary) shouldn't change at all after optimization 
but I need to verify that, of course.


What you can't do with such a change is to lock / unlock a ww_mutex 
using the standard mutex API, like mutex_lock(_mutex->base), but I 
guess that would be OK?





If we can't mix them I'm kinda leaning towards a
ww_batch_mutex/ww_batch_acquire_ctx, but exactly matching api
otherwise. We probably do need the new batch_start/end api, since
ww_acquire_done isn't quite the right place ...


I'll see if I get time to put together an RFC.

Yeah I think there's definitely some use for batched ww locks, where
parallelism is generally low, or at least the ratio between "time
spent acquiring locks" and "time spent doing stuff while holding
locks" small enough to not make the reduced parallelism while
acquiring an issue.


Yes. At least it's worth bringing up for discussion. The reduced 
parallelism shouldn't be an issue if per-process batch-groups are used, 
or, like for vmwgfx the command submission itself is serialized, due to 
a single FIFO.


/Thomas



-Daniel



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

Re: [Intel-gfx] [RFC v4 19/25] drm/client: Finish the in-kernel client API

[Daniel Vetter]

On Sat, Apr 14, 2018 at 01:53:12PM +0200, Noralf Trønnes wrote:
> The modesetting code is already present, this adds the rest of the API.

Mentioning the TODO in the commit message would be good. Helps readers
like me who have an attention span measured in seconds :-)

Just commenting on the create_buffer leak here

> +static struct drm_client_buffer *
> +drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 
> height, u32 format)
> +{
> + struct drm_mode_create_dumb dumb_args = { };
> + struct drm_prime_handle prime_args = { };
> + struct drm_client_buffer *buffer;
> + struct dma_buf *dma_buf;
> + void *vaddr;
> + int ret;
> +
> + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> + if (!buffer)
> + return ERR_PTR(-ENOMEM);
> +
> + buffer->client = client;
> + buffer->width = width;
> + buffer->height = height;
> + buffer->format = format;
> +
> + dumb_args.width = buffer->width;
> + dumb_args.height = buffer->height;
> + dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
> + ret = drm_mode_create_dumb(client->dev, _args, client->file);
> + if (ret)
> + goto err_free;
> +
> + buffer->handle = dumb_args.handle;
> + buffer->pitch = dumb_args.pitch;
> + buffer->size = dumb_args.size;
> +
> + prime_args.handle = dumb_args.handle;
> + ret = drm_prime_handle_to_fd(client->dev, _args, client->file);
> + if (ret)
> + goto err_delete;
> +
> + dma_buf = dma_buf_get(prime_args.fd);
> + if (IS_ERR(dma_buf)) {
> + ret = PTR_ERR(dma_buf);
> + goto err_delete;
> + }
> +
> + /*
> +  * If called from a worker the dmabuf fd isn't closed and the ref
> +  * doesn't drop to zero on free.
> +  * If I use __close_fd() it's all fine, but that function is not 
> exported.
> +  *
> +  * How do I get rid of this fd when in a worker/kernel thread?
> +  * The fd isn't used beyond this function.
> +  */
> +//   WARN_ON(__close_fd(current->files, prime_args.fd));

Hm, this isn't 100% what I had in mind as the sequence for generic buffer
creation. Pseudo-code:

ret = drm_mode_create_dumb(client->dev, _args, client->file);
if (ret)
goto err_free;

gem_bo = drm_gem_object_lookup(client->file, dumb_args.handle);

gives you _really_ directly the underlying gem_bo. Of course this doesn't
work for non-gem based driver, but reality is that (almost) all of them
are. And we will not accept any new drivers which aren't gem based. So
ignoring vmwgfx for this drm_client work is imo perfectly fine. We should
ofc keep the option in the fb helpers to use non-gem buffers (so that
vmwgfx could switch over from their own in-driver fbdev helpers). All we
need for that is to keep the fb_probe callback.

Was there any other reason than vmwgfx for using prime buffers instead of
just directly using gem?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

[Andrzej Hajda]

+CC: linux-input list and maintainer


On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
> From: "Kristian H. Kristensen" 
>
> To improve PSR exit latency, we speculatively start exiting when we
> receive input events. Occasionally, this may lead to false positives,
> but most of the time we get a head start on coming out of PSR. Depending
> on how userspace takes to produce a new frame in response to the event,
> this can completely hide the exit latency. In case of Chrome OS, we
> typically get the input notifier 50ms or more before the dirty_fb
> triggered exit.

As I see from the code below, you just need notification from input
subsystem on user activity.
Maybe there is some simpler notification mechanism for such things?
If not, maybe such helper should be created in input subsystem, I
suppose it could be reused in other places as well.

Regards
Andrzej

>
> Signed-off-by: Kristian H. Kristensen 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 
> ---
>
>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
> 
>  1 file changed, 134 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> index 9376f4396b6b..a107845ba97c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
> @@ -12,6 +12,8 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +
>  #include 
>  #include 
>  
> @@ -35,6 +37,9 @@ struct psr_drv {
>   enum psr_state  state;
>  
>   struct delayed_work flush_work;
> + struct work_struct  disable_work;
> +
> + struct input_handlerinput_handler;
>  
>   int (*set)(struct drm_encoder *encoder, bool enable);
>  };
> @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
>   mutex_unlock(>lock);
>  }
>  
> +static void psr_disable_handler(struct work_struct *work)
> +{
> + struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
> +
> + /* If the state has changed since we initiated the flush, do nothing */
> + mutex_lock(>lock);
> + if (psr->state == PSR_ENABLE)
> + psr_set_state_locked(psr, PSR_FLUSH);
> + mutex_unlock(>lock);
> + mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
> +}
> +
>  /**
>   * rockchip_drm_psr_activate - activate PSR on the given pipe
>   * @encoder: encoder to obtain the PSR encoder
> @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
> *encoder)
>   psr->active = false;
>   mutex_unlock(>lock);
>   cancel_delayed_work_sync(>flush_work);
> + cancel_work_sync(>disable_work);
>  
>   return 0;
>  }
> @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
>  
> +static void psr_input_event(struct input_handle *handle,
> + unsigned int type, unsigned int code,
> + int value)
> +{
> + struct psr_drv *psr = handle->handler->private;
> +
> + schedule_work(>disable_work);
> +}
> +
> +static int psr_input_connect(struct input_handler *handler,
> +  struct input_dev *dev,
> +  const struct input_device_id *id)
> +{
> + struct input_handle *handle;
> + int error;
> +
> + handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
> + if (!handle)
> + return -ENOMEM;
> +
> + handle->dev = dev;
> + handle->handler = handler;
> + handle->name = "rockchip-psr";
> +
> + error = input_register_handle(handle);
> + if (error)
> + goto err2;
> +
> + error = input_open_device(handle);
> + if (error)
> + goto err1;
> +
> + return 0;
> +
> +err1:
> + input_unregister_handle(handle);
> +err2:
> + kfree(handle);
> + return error;
> +}
> +
> +static void psr_input_disconnect(struct input_handle *handle)
> +{
> + input_close_device(handle);
> + input_unregister_handle(handle);
> + kfree(handle);
> +}
> +
> +/* Same device ids as cpu-boost */
> +static const struct input_device_id psr_ids[] = {
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
> +  INPUT_DEVICE_ID_MATCH_ABSBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
> + BIT_MASK(ABS_MT_POSITION_X) |
> + BIT_MASK(ABS_MT_POSITION_Y) },
> + }, /* multi-touch touchscreen */
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> + .evbit = { BIT_MASK(EV_ABS) },
> + .absbit = { [BIT_WORD(ABS_X)] = BIT_MASK(ABS_X) }
> +
> + }, /* stylus or joystick 

Re: [[RFC]DPU PATCH 1/2] drm/bridge: add support for sn65dsi86 bridge driver

[spanda]

On 2018-04-14 00:59, Sean Paul wrote:

On Fri, Apr 13, 2018 at 10:53:00AM +0530, Sandeep Panda wrote:

Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.

This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c interface only.
Also as of now HPD support has not been added to bridge
chip driver.

Signed-off-by: Sandeep Panda 


Hi Sandeep,
Thank you for your patch!


---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1019 
+

 1 file changed, 1019 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c

new file mode 100644
index 000..93aa1ad
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,1019 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__


Instead of using pr_* for logging, please use the DRM_* variants. Since 
there
is unlikely to be more than one of these bridge drivers in a system, 
you won't

need to use the DRM_DEV_* versions.


+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SN_DEVICE_REV_REG 0x08
+
+/* Link Training specific registers */
+#define SN_REFCLK_FREQ_REG 0x0A
+#define SN_DSI_LANES_REG 0x10
+#define SN_DSIA_CLK_FREQ_REG 0x12
+#define SN_ENH_FRAME_REG 0x5A
+#define SN_SSC_CONFIG_REG 0x93
+#define SN_DATARATE_CONFIG_REG 0x94
+#define SN_PLL_ENABLE_REG 0x0D
+#define SN_SCRAMBLE_CONFIG_REG 0x95
+#define SN_AUX_WDATA0_REG 0x64
+#define SN_AUX_ADDR_19_16_REG 0x74
+#define SN_AUX_ADDR_15_8_REG 0x75
+#define SN_AUX_ADDR_7_0_REG 0x76
+#define SN_AUX_LENGTH_REG 0x77
+#define SN_AUX_CMD_REG 0x78
+#define SN_ML_TX_MODE_REG 0x96
+#define SN_PAGE_SELECT_REG 0xFF
+#define SN_AUX_RDATA0_REG 0x79
+
+/* video config specific registers */
+#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
+#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG 0x25
+#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
+#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG 0x2D
+#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
+#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG 0x31
+#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
+#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
+#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
+#define SN_CHA_VERTICAL_FRONT_PORCH_REG 0x3A
+#define SN_DATA_FORMAT_REG 0x5B
+#define SN_COLOR_BAR_CONFIG_REG 0x3C


It'd be nice if you could tab-align the values.


+
+struct sn65dsi86_reg_cfg {
+   u8 reg;
+   u8 val;
+   int sleep_in_ms;
+};
+
+struct sn65dsi86_video_cfg {
+   u32 h_active;
+   u32 h_front_porch;
+   u32 h_pulse_width;
+   u32 h_back_porch;
+   bool h_polarity;
+   u32 v_active;
+   u32 v_front_porch;
+   u32 v_pulse_width;
+   u32 v_back_porch;
+   bool v_polarity;
+   u32 pclk_khz;
+   u32 num_of_lanes;
+};


All of these can be derived from drm_display_mode except for 
num_of_lanes which

is hardcoded. So let's just use drm_display_mode directly.


+
+struct sn65dsi86_gpios {
+   struct gpio_desc *irq_gpio;
+   struct gpio_desc *enable_gpio;
+   struct gpio_desc *aux_i2c_sda;
+   struct gpio_desc *aux_i2c_scl;
+   struct gpio_desc *edp_bias_en;
+   struct gpio_desc *edp_bklt_en;
+   struct gpio_desc *edp_bklt_ctrl;
+};


I see IRQ and EN in the datasheet, but not the others. It seems like 
the aux_*
and edp_* gpios are always equal to en. So if you actually need them, 
don't
specify a new struct, just add irq_gpio to the main struct and add an 
array of

en_gpios to handle the rest.


+
+struct sn65dsi86 {


I will have fits trying to type this name. Could you please use 
something
simple, like sn_bridge? Same comment applies to all of the function 
names.



+   struct device *dev;
+   struct drm_bridge bridge;
+   struct drm_connector connector;
+
+   struct device_node *host_node;
+   struct mipi_dsi_device *dsi;
+
+   u8 i2c_addr;


Unused


+   int irq;
+
+   struct sn65dsi86_gpios gpios;
+
+   unsigned int num_supplies;
+   struct regulator_bulk_data *supplies;
+
+   struct i2c_client *i2c_client;
+
+   enum drm_connector_status connector_status;


You never use the value of this, you just assign it. So you can remove 
this.



+   bool power_on;
+
+   bool is_pluggable;


As I mentioned in the dt review, you can determine this via panel. You 
should

also take this into account in detect().


+   u32 num_of_modes;
+   struct list_head mode_list;
+   struct edid *edid;
+
+   struct 

[PATCH] gpu/drm/amd/amdkfd: fix build, select MMU_NOTIFIER

[Randy Dunlap]

From: Randy Dunlap 

When CONFIG_MMU_NOTIFIER is not enabled, struct mmu_notifier has an
incomplete type definition, which causes build errors.

../drivers/gpu/drm/amd/amdkfd/kfd_priv.h:607:22: error: field 'mmu_notifier' 
has incomplete type
../include/linux/kernel.h:979:32: error: dereferencing pointer to incomplete 
type
../include/linux/kernel.h:980:18: error: dereferencing pointer to incomplete 
type
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:434:2: error: implicit declaration 
of function 'mmu_notifier_unregister_no_release' 
[-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:435:2: error: implicit declaration 
of function 'mmu_notifier_call_srcu' [-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:438:21: error: variable 
'kfd_process_mmu_notifier_ops' has initializer but incomplete type
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: error: unknown field 
'release' specified in initializer
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: excess elements in 
struct initializer [enabled by default]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: (near 
initialization for 'kfd_process_mmu_notifier_ops') [enabled by default]
../drivers/gpu/drm/amd/amdkfd/kfd_process.c:534:2: error: implicit declaration 
of function 'mmu_notifier_register' [-Werror=implicit-function-declaration]

Signed-off-by: Randy Dunlap 
Cc: Oded Gabbay 
Cc: dri-devel@lists.freedesktop.org
---
From linux-next, not mmotm, but found in mmotm builds.

 drivers/gpu/drm/amd/amdkfd/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- mmotm-2018-0413-1728.orig/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ mmotm-2018-0413-1728/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -6,5 +6,6 @@ config HSA_AMD
tristate "HSA kernel driver for AMD GPU devices"
depends on DRM_AMDGPU && X86_64
imply AMD_IOMMU_V2
+   select MMU_NOTIFIER
help
  Enable this if you want to use HSA features on AMD GPU devices.

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

Re: [PATCH 2/5] dt-bindings: display: atmel: add optional output-mode property

[Peter Rosin]

On 2018-04-13 19:46, Rob Herring wrote:
> On Mon, Apr 09, 2018 at 12:59:15PM +0200, Peter Rosin wrote:
>> Useful for beating cases where an output mode selection heuristic
>> fails.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt 
>> b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> index 82f2acb3d374..dc478455b883 100644
>> --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> @@ -10,6 +10,10 @@ Required properties:
>>   - #address-cells: should be set to 1.
>>   - #size-cells: should be set to 0.
>>  
>> +Optional properties:
>> + - output-mode: override any output mode selection hueristic and force a
>> +   particular output mode. One of "rgb444", "rgb565", "rgb666" and "rgb888".
>> +
> 
> This needs to be generic, not just added to some random display 
> controller binding.
> 
> It also belongs in the port or endpoint node as is done for camera 
> interfaces.

Hmm, should I extend media/video-interfaces.txt with more bus types (or since
I'm targeting parallel interfaces, perhaps the new bus types should be
autodetected from other props?) or should a write a new binding similar to
it?

One question regarding bus-width, should it include hsync/vsync/de/clk?
If yes, how to distinguish rgb565 with all those four from rgb666 with
only de/clk (some panels do not need hsync/vsync)? 20 lines in both
cases...

Or are rgb444/rgb565/rgb666/rgb888 already supported by the media video
interface binding? That's not at all obvious to me.

Cheers,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: drm: gma500: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler
in struct vm_operations_struct.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 drivers/gpu/drm/gma500/framebuffer.c | 14 +-
 drivers/gpu/drm/gma500/gem.c | 27 ++-
 drivers/gpu/drm/gma500/psb_drv.h |  3 ++-
 3 files changed, 17 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae..7635ce8 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -111,7 +111,7 @@ static int psbfb_pan(struct fb_var_screeninfo *var, struct 
fb_info *info)
 return 0;
 }
 
-static int psbfb_vm_fault(struct vm_fault *vmf)
+static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct psb_framebuffer *psbfb = vma->vm_private_data;
@@ -120,7 +120,7 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
int page_num;
int i;
unsigned long address;
-   int ret;
+   vm_fault_t ret;
unsigned long pfn;
unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
  psbfb->gtt->offset;
@@ -133,18 +133,14 @@ static int psbfb_vm_fault(struct vm_fault *vmf)
for (i = 0; i < page_num; i++) {
pfn = (phys_addr >> PAGE_SHIFT);
 
-   ret = vm_insert_mixed(vma, address,
+   ret = vmf_insert_mixed(vma, address,
__pfn_to_pfn_t(pfn, PFN_DEV));
-   if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
+   if (unlikely(ret & VM_FAULT_ERROR))
break;
-   else if (unlikely(ret != 0)) {
-   ret = (ret == -ENOMEM) ? VM_FAULT_OOM : VM_FAULT_SIGBUS;
-   return ret;
-   }
address += PAGE_SIZE;
phys_addr += PAGE_SIZE;
}
-   return VM_FAULT_NOPAGE;
+   return ret;
 }
 
 static void psbfb_vm_open(struct vm_area_struct *vma)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 1312397..e7be5c9 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -134,12 +134,13 @@ int psb_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
  * vma->vm_private_data points to the GEM object that is backing this
  * mapping.
  */
-int psb_gem_fault(struct vm_fault *vmf)
+vm_fault_t psb_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj;
struct gtt_range *r;
-   int ret;
+   int err;
+   vm_fault_t ret;
unsigned long pfn;
pgoff_t page_offset;
struct drm_device *dev;
@@ -158,9 +159,10 @@ int psb_gem_fault(struct vm_fault *vmf)
/* For now the mmap pins the object and it stays pinned. As things
   stand that will do us no harm */
if (r->mmapping == 0) {
-   ret = psb_gtt_pin(r);
-   if (ret < 0) {
-   dev_err(dev->dev, "gma500: pin failed: %d\n", ret);
+   err = psb_gtt_pin(r);
+   if (err < 0) {
+   dev_err(dev->dev, "gma500: pin failed: %d\n", err);
+   ret = vmf_error(err);
goto fail;
}
r->mmapping = 1;
@@ -175,18 +177,9 @@ int psb_gem_fault(struct vm_fault *vmf)
pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
else
pfn = page_to_pfn(r->pages[page_offset]);
-   ret = vm_insert_pfn(vma, vmf->address, pfn);
-
+   ret = vmf_insert_pfn(vma, vmf->address, pfn);
 fail:
mutex_unlock(_priv->mmap_mutex);
-   switch (ret) {
-   case 0:
-   case -ERESTARTSYS:
-   case -EINTR:
-   return VM_FAULT_NOPAGE;
-   case -ENOMEM:
-   return VM_FAULT_OOM;
-   default:
-   return VM_FAULT_SIGBUS;
-   }
+
+   return ret;
 }
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e8300f5..93d2f40 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -21,6 +21,7 @@
 #define _PSB_DRV_H_
 
 #include 
+#include 
 
 #include 
 #include 
@@ -749,7 +750,7 @@ extern int psb_gem_get_aperture(struct drm_device *dev, 
void *data,
struct drm_file *file);
 extern int psb_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
-extern int psb_gem_fault(struct vm_fault *vmf);
+extern vm_fault_t psb_gem_fault(struct vm_fault *vmf);
 
 /* psb_device.c */
 extern const struct psb_ops psb_chip_ops;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH v4 0/8] drm/sun4i: Allwinner MIPI-DSI support

[Jagan Teki]

On Fri, Apr 13, 2018 at 5:39 PM, Maxime Ripard
 wrote:
> On Fri, Apr 13, 2018 at 05:30:04PM +0530, Jagan Teki wrote:
>> On Wed, Apr 11, 2018 at 6:13 PM, Maxime Ripard
>>  wrote:
>> > On Wed, Apr 04, 2018 at 11:57:08AM +0200, Maxime Ripard wrote:
>> >> Hi,
>> >>
>> >> Here is an preliminary version of the MIPI-DSI support for the Allwinner
>> >> SoCs.
>> >>
>> >> This controller can be found on a number of recent SoCs, such as the
>> >> A31, A33 or the A64.
>> >>
>> >> Given the sparse documentation, there's a number of obscure areas, but
>> >> the current implementation has been tested with a 4-lanes DSI panel on
>> >> an A33.
>> >>
>> >> The support is a bit rough around the edges at the time, and some 
>> >> artifacts
>> >> are still shown on the screen for some reasons. Wider testing with
>> >> different display will hopefully nail those down.
>> >>
>> >> This needs the regmap_mmio_attach_clk, on its way to Linus in 4.17.
>> >>
>> >> Let me know what you think,
>> >> Maxime
>> >>
>> >> Changes from v3:
>> >>   - Rebased on top of current drm-misc-next
>> >>   - Switched to SPDX license header
>> >>   - Made the ECC array const
>> >>   - Split the big DSI patch into two, one to add the DSI driver and one to
>> >> add the TCON bits.
>> >>   - Removed the dithering code
>> >>   - Changed the DT labels to remove the indices
>> >>   - Used sleeps instead of delays in the panel driver
>> >>   - Used the backlight_enable / _disable functions
>> >>   - Added Chen-Yu's Reviewed-by
>> >>
>> >> Changes from v2:
>> >>   - Added a ports node under the DSI node
>> >>   - Changed the huarui panel driver to an ili9881c driver
>> >>   - Changed the panel vendor to bananapi
>> >>   - Made the init table static in the panel driver
>> >>   - Dropped the huarui vendor patch for the DT doc.
>> >>
>> >> Changes from v1:
>> >>   - Rebased on 4.16-rc1
>> >>   - Constified a few function arguments and structures
>> >>   - Reworked the DT binding example a bit
>> >>   - Reworked the panel driver to check for DSI return codes, and use DCS
>> >> helpers when possible
>> >>
>> >> Maxime Ripard (8):
>> >>   drm/sun4i: tcon: Add TRI finish interrupt for vblank
>> >>   dt-bindings: display: Add Allwinner MIPI-DSI bindings
>> >>   drm/sun4i: Add Allwinner A31 MIPI-DSI controller support
>> >>   drm/sun4i: Tie the DSI controller in the TCON
>> >>   dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
>> >>   drm/panel: Add Ilitek ILI9881c panel driver
>> >>   ARM: dts: sun8i: a33: Add the DSI-related nodes
>> >>   [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display
>>
>> I have reviewed most of the patches and reused for A64 all look fine
>> to me (except the panel driver). May be my issue is not relevant to
>> this thread, but I'm looking for help If I miss anything for A64 [1]
>> and [2] are changes made for A64, the issue is kernel hang while
>> loading sun6i_dsi.
>
> My guess would be that you're not claiming the DE2 SRAM. See:
> https://lkml.org/lkml/2018/3/16/1096

Thanks Maxime, will try.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: drm: exynos: Change return type to vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler
in struct vm_operations_struct.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 -
 drivers/gpu/drm/exynos/exynos_drm_gem.h |  3 ++-
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 11cc01b..6e1494f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -431,37 +431,24 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
return 0;
 }
 
-int exynos_drm_gem_fault(struct vm_fault *vmf)
+vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
unsigned long pfn;
pgoff_t page_offset;
-   int ret;
 
page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
 
if (page_offset >= (exynos_gem->size >> PAGE_SHIFT)) {
DRM_ERROR("invalid page offset\n");
-   ret = -EINVAL;
-   goto out;
+   return VM_FAULT_SIGBUS;
}
 
pfn = page_to_pfn(exynos_gem->pages[page_offset]);
-   ret = vm_insert_mixed(vma, vmf->address, __pfn_to_pfn_t(pfn, PFN_DEV));
-
-out:
-   switch (ret) {
-   case 0:
-   case -ERESTARTSYS:
-   case -EINTR:
-   return VM_FAULT_NOPAGE;
-   case -ENOMEM:
-   return VM_FAULT_OOM;
-   default:
-   return VM_FAULT_SIGBUS;
-   }
+   return vmf_insert_mixed(vma, vmf->address,
+   __pfn_to_pfn_t(pfn, PFN_DEV));
 }
 
 static int exynos_drm_gem_mmap_obj(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 5a4c7de..9057d7f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -13,6 +13,7 @@
 #define _EXYNOS_DRM_GEM_H_
 
 #include 
+#include 
 
 #define to_exynos_gem(x)   container_of(x, struct exynos_drm_gem, base)
 
@@ -111,7 +112,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
   struct drm_mode_create_dumb *args);
 
 /* page fault handler and mmap fault address(virtual) to physical memory. */
-int exynos_drm_gem_fault(struct vm_fault *vmf);
+vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf);
 
 /* set vm_flags and we can change the vm attribute to other one at here. */
 int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-- 
1.9.1

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

[RFC] Rewrite page fault interception in TTM drivers

[Matthew Wilcox]

Three^W Two of the TTM drivers intercept the pagefault handler in a rather
un-Linuxy and racy way.  If they really must intercept the fault call
(and it's not clear to me that they need to), I'd rather see them do it
like this.

The QXL driver seems least likely to need it; as the virtio driver has
exactly the same code in it, only commented out.  The radeon driver takes
its own lock ... maybe there's a way to avoid that since no other driver
needs to take its own lock at this point?

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index ee2340e31f06..d2c76a3d6816 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -102,21 +102,23 @@ static void qxl_ttm_global_fini(struct qxl_device *qdev)
}
 }
 
-static struct vm_operations_struct qxl_ttm_vm_ops;
-static const struct vm_operations_struct *ttm_vm_ops;
-
 static int qxl_ttm_fault(struct vm_fault *vmf)
 {
struct ttm_buffer_object *bo;
-   int r;
 
bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
if (bo == NULL)
return VM_FAULT_NOPAGE;
-   r = ttm_vm_ops->fault(vmf);
-   return r;
+   return ttm_bo_vm_fault(vmf);
 }
 
+static const struct vm_operations_struct qxl_ttm_vm_ops = {
+   .fault = qxl_ttm_fault,
+   .open = ttm_bo_vm_open,
+   .close = ttm_bo_vm_close,
+   .access = ttm_bo_vm_access,
+};
+
 int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
 {
struct drm_file *file_priv;
@@ -139,11 +141,6 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
r = ttm_bo_mmap(filp, vma, >mman.bdev);
if (unlikely(r != 0))
return r;
-   if (unlikely(ttm_vm_ops == NULL)) {
-   ttm_vm_ops = vma->vm_ops;
-   qxl_ttm_vm_ops = *ttm_vm_ops;
-   qxl_ttm_vm_ops.fault = _ttm_fault;
-   }
vma->vm_ops = _ttm_vm_ops;
return 0;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 8689fcca051c..08cc0c5b9e94 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -944,9 +944,6 @@ void radeon_ttm_set_active_vram_size(struct radeon_device 
*rdev, u64 size)
man->size = size >> PAGE_SHIFT;
 }
 
-static struct vm_operations_struct radeon_ttm_vm_ops;
-static const struct vm_operations_struct *ttm_vm_ops = NULL;
-
 static int radeon_ttm_fault(struct vm_fault *vmf)
 {
struct ttm_buffer_object *bo;
@@ -959,11 +956,18 @@ static int radeon_ttm_fault(struct vm_fault *vmf)
}
rdev = radeon_get_rdev(bo->bdev);
down_read(>pm.mclk_lock);
-   r = ttm_vm_ops->fault(vmf);
+   r = ttm_bo_vm_fault(vmf);
up_read(>pm.mclk_lock);
return r;
 }
 
+static const struct vm_operations_struct radeon_ttm_vm_ops = {
+   .fault = radeon_ttm_fault,
+   .open = ttm_bo_vm_open,
+   .close = ttm_bo_vm_close,
+   .access = ttm_bo_vm_access,
+};
+
 int radeon_mmap(struct file *filp, struct vm_area_struct *vma)
 {
struct drm_file *file_priv;
@@ -983,11 +987,6 @@ int radeon_mmap(struct file *filp, struct vm_area_struct 
*vma)
if (unlikely(r != 0)) {
return r;
}
-   if (unlikely(ttm_vm_ops == NULL)) {
-   ttm_vm_ops = vma->vm_ops;
-   radeon_ttm_vm_ops = *ttm_vm_ops;
-   radeon_ttm_vm_ops.fault = _ttm_fault;
-   }
vma->vm_ops = _ttm_vm_ops;
return 0;
 }
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b3c737..f59a8f41aae0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -104,7 +104,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct 
ttm_buffer_object *bo,
+ page_offset;
 }
 
-static int ttm_bo_vm_fault(struct vm_fault *vmf)
+int ttm_bo_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
@@ -294,8 +294,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
ttm_bo_unreserve(bo);
return ret;
 }
+EXPORT_SYMBOL_GPL(ttm_bo_vm_fault);
 
-static void ttm_bo_vm_open(struct vm_area_struct *vma)
+void ttm_bo_vm_open(struct vm_area_struct *vma)
 {
struct ttm_buffer_object *bo =
(struct ttm_buffer_object *)vma->vm_private_data;
@@ -304,14 +305,16 @@ static void ttm_bo_vm_open(struct vm_area_struct *vma)
 
(void)ttm_bo_reference(bo);
 }
+EXPORT_SYMBOL_GPL(ttm_bo_vm_open);
 
-static void ttm_bo_vm_close(struct vm_area_struct *vma)
+void ttm_bo_vm_close(struct vm_area_struct *vma)
 {
struct ttm_buffer_object *bo = (struct ttm_buffer_object 
*)vma->vm_private_data;
 
ttm_bo_unref();
vma->vm_private_data = NULL;
 }
+EXPORT_SYMBOL_GPL(ttm_bo_vm_close);
 
 static int ttm_bo_vm_access_kmap(struct ttm_buffer_object *bo,
 unsigned long offset,

Re: [PATCH v4 0/8] drm/sun4i: Allwinner MIPI-DSI support

[Jagan Teki]

On Wed, Apr 11, 2018 at 6:13 PM, Maxime Ripard
 wrote:
> On Wed, Apr 04, 2018 at 11:57:08AM +0200, Maxime Ripard wrote:
>> Hi,
>>
>> Here is an preliminary version of the MIPI-DSI support for the Allwinner
>> SoCs.
>>
>> This controller can be found on a number of recent SoCs, such as the
>> A31, A33 or the A64.
>>
>> Given the sparse documentation, there's a number of obscure areas, but
>> the current implementation has been tested with a 4-lanes DSI panel on
>> an A33.
>>
>> The support is a bit rough around the edges at the time, and some artifacts
>> are still shown on the screen for some reasons. Wider testing with
>> different display will hopefully nail those down.
>>
>> This needs the regmap_mmio_attach_clk, on its way to Linus in 4.17.
>>
>> Let me know what you think,
>> Maxime
>>
>> Changes from v3:
>>   - Rebased on top of current drm-misc-next
>>   - Switched to SPDX license header
>>   - Made the ECC array const
>>   - Split the big DSI patch into two, one to add the DSI driver and one to
>> add the TCON bits.
>>   - Removed the dithering code
>>   - Changed the DT labels to remove the indices
>>   - Used sleeps instead of delays in the panel driver
>>   - Used the backlight_enable / _disable functions
>>   - Added Chen-Yu's Reviewed-by
>>
>> Changes from v2:
>>   - Added a ports node under the DSI node
>>   - Changed the huarui panel driver to an ili9881c driver
>>   - Changed the panel vendor to bananapi
>>   - Made the init table static in the panel driver
>>   - Dropped the huarui vendor patch for the DT doc.
>>
>> Changes from v1:
>>   - Rebased on 4.16-rc1
>>   - Constified a few function arguments and structures
>>   - Reworked the DT binding example a bit
>>   - Reworked the panel driver to check for DSI return codes, and use DCS
>> helpers when possible
>>
>> Maxime Ripard (8):
>>   drm/sun4i: tcon: Add TRI finish interrupt for vblank
>>   dt-bindings: display: Add Allwinner MIPI-DSI bindings
>>   drm/sun4i: Add Allwinner A31 MIPI-DSI controller support
>>   drm/sun4i: Tie the DSI controller in the TCON
>>   dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
>>   drm/panel: Add Ilitek ILI9881c panel driver
>>   ARM: dts: sun8i: a33: Add the DSI-related nodes
>>   [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display

I have reviewed most of the patches and reused for A64 all look fine
to me (except the panel driver). May be my issue is not relevant to
this thread, but I'm looking for help If I miss anything for A64 [1]
and [2] are changes made for A64, the issue is kernel hang while
loading sun6i_dsi.

Log:

# modprobe -a sun6i_dsi
[   18.798684] sun6i-mipi-dsi 1ca.dsi: Attached device ts8550b
[   18.819628] sun4i-drm display-engine: bound 110.mixer (ops
sun8i_mixer_ops)
[   18.827336] sun4i-drm display-engine: No panel or bridge found...
RGB output disabled
[   18.835200] sun4i-drm display-engine: bound 1c0c000.lcd-controller
(ops sun4i_tcon_ops)
[   18.843246] sun4i-drm display-engine: bound 1ca.dsi (ops
sun6i_dsi_ops [sun6i_dsi])
[   18.851263] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   18.857878] [drm] No driver support for vblank timestamp query.

<< hang here >>

[1] 
https://github.com/openedev/linux-openedev/commit/9030929673b21971ff77b7593e88c26e84ed3742
[2] 
https://github.com/openedev/linux-openedev/commit/725afe3ce4507fa975fcb4a04b1bbb90d9d44a91

Jagan.

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:
> On 04/13/2018 06:37 PM, Daniel Vetter wrote:
> > On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/10/2018 08:26 PM, Dongwon Kim wrote:
> > > > On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
> > > > > On 04/06/2018 09:57 PM, Dongwon Kim wrote:
> > > > > > On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko 
> > > > > > wrote:
> > > > > > > On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > > > I fail to see any common ground for xen-zcopy and udmabuf 
> > > > > > > > > > ...
> > > > > > > > > Does the above mean you can assume that xen-zcopy and udmabuf
> > > > > > > > > can co-exist as two different solutions?
> > > > > > > > Well, udmabuf route isn't fully clear yet, but yes.
> > > > > > > > 
> > > > > > > > See also gvt (intel vgpu), where the hypervisor interface is 
> > > > > > > > abstracted
> > > > > > > > away into a separate kernel modules even though most of the 
> > > > > > > > actual vgpu
> > > > > > > > emulation code is common.
> > > > > > > Thank you for your input, I'm just trying to figure out
> > > > > > > which of the three z-copy solutions intersect and how much
> > > > > > > > > And what about hyper-dmabuf?
> > > > > > xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
> > > > > > in terms of these core sharing feature:
> > > > > > 
> > > > > > 1. the sharing process - import prime/dmabuf from the producer -> 
> > > > > > extract
> > > > > > underlying pages and get those shared -> return references for 
> > > > > > shared pages
> > > > Another thing is danvet was kind of against to the idea of importing 
> > > > existing
> > > > dmabuf/prime buffer and forward it to the other domain due to 
> > > > synchronization
> > > > issues. He proposed to make hyper_dmabuf only work as an exporter so 
> > > > that it
> > > > can have a full control over the buffer. I think we need to talk about 
> > > > this
> > > > further as well.
> > > Yes, I saw this. But this limits the use-cases so much.
> > > For instance, running Android as a Guest (which uses ION to allocate
> > > buffers) means that finally HW composer will import dma-buf into
> > > the DRM driver. Then, in case of xen-front for example, it needs to be
> > > shared with the backend (Host side). Of course, we can change user-space
> > > to make xen-front allocate the buffers (make it exporter), but what we try
> > > to avoid is to change user-space which in normal world would have remain
> > > unchanged otherwise.
> > > So, I do think we have to support this use-case and just have to 
> > > understand
> > > the complexity.
> > Erm, why do you need importer capability for this use-case?
> > 
> > guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy exposes
> > that dma-buf -> import to the real display hw
> > 
> > No where in this chain do you need xen-zcopy to be able to import a
> > dma-buf (within linux, it needs to import a bunch of pages from the
> > hypervisor).
> > 
> > Now if your plan is to use xen-zcopy in the guest1 instead of xen-front,
> > then you indeed need to import.
> This is the exact use-case I was referring to while saying
> we need to import on Guest1 side. If hyper-dmabuf is so
> generic that there is no xen-front in the picture, then
> it needs to import a dma-buf, so it can be exported at Guest2 side.
> >   But that imo doesn't make sense:
> > - xen-front gives you clearly defined flip events you can forward to the
> >hypervisor. xen-zcopy would need to add that again.
> xen-zcopy is a helper driver which doesn't handle page flips
> and is not a KMS driver as one might think of: the DRM UAPI it uses is
> just to export a dma-buf as a PRIME buffer, but that's it.
> Flipping etc. is done by the backend [1], not xen-zcopy.
> >   Same for
> >hyperdmabuf (and really we're not going to shuffle struct dma_fence over
> >the wire in a generic fashion between hypervisor guests).
> > 
> > - xen-front already has the idea of pixel format for the buffer (and any
> >other metadata). Again, xen-zcopy and hyperdmabuf lack that, would need
> >to add it shoehorned in somehow.
> Again, here you are talking of something which is implemented in
> Xen display backend, not xen-zcopy, e.g. display backend can
> implement para-virtual display w/o xen-zcopy at all, but in this case
> there is a memory copying for each frame. With the help of xen-zcopy
> the backend feeds xen-front's buffers directly into Guest2 DRM/KMS or
> Weston or whatever as xen-zcopy exports remote buffers as PRIME buffers,
> thus no buffer copying is required.

Why do you need to copy on every frame for xen-front? In the above
pipeline, using xen-front I see 0 architectural reasons to have a copy
anywhere.

This seems to be the core of the confusion we're having here.

> > Ofc you won't be able to shovel sound or media 

Re: [RfC PATCH] Add udmabuf misc device

[Oleksandr Andrushchenko]

On 04/16/2018 10:43 AM, Daniel Vetter wrote:

On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:

On 04/13/2018 06:37 PM, Daniel Vetter wrote:

On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:

On 04/10/2018 08:26 PM, Dongwon Kim wrote:

On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:

On 04/06/2018 09:57 PM, Dongwon Kim wrote:

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:

On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:

 Hi,


I fail to see any common ground for xen-zcopy and udmabuf ...

Does the above mean you can assume that xen-zcopy and udmabuf
can co-exist as two different solutions?

Well, udmabuf route isn't fully clear yet, but yes.

See also gvt (intel vgpu), where the hypervisor interface is abstracted
away into a separate kernel modules even though most of the actual vgpu
emulation code is common.

Thank you for your input, I'm just trying to figure out
which of the three z-copy solutions intersect and how much

And what about hyper-dmabuf?

xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
in terms of these core sharing feature:

1. the sharing process - import prime/dmabuf from the producer -> extract
underlying pages and get those shared -> return references for shared pages

Another thing is danvet was kind of against to the idea of importing existing
dmabuf/prime buffer and forward it to the other domain due to synchronization
issues. He proposed to make hyper_dmabuf only work as an exporter so that it
can have a full control over the buffer. I think we need to talk about this
further as well.

Yes, I saw this. But this limits the use-cases so much.
For instance, running Android as a Guest (which uses ION to allocate
buffers) means that finally HW composer will import dma-buf into
the DRM driver. Then, in case of xen-front for example, it needs to be
shared with the backend (Host side). Of course, we can change user-space
to make xen-front allocate the buffers (make it exporter), but what we try
to avoid is to change user-space which in normal world would have remain
unchanged otherwise.
So, I do think we have to support this use-case and just have to understand
the complexity.

Erm, why do you need importer capability for this use-case?

guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy exposes
that dma-buf -> import to the real display hw

No where in this chain do you need xen-zcopy to be able to import a
dma-buf (within linux, it needs to import a bunch of pages from the
hypervisor).

Now if your plan is to use xen-zcopy in the guest1 instead of xen-front,
then you indeed need to import.

This is the exact use-case I was referring to while saying
we need to import on Guest1 side. If hyper-dmabuf is so
generic that there is no xen-front in the picture, then
it needs to import a dma-buf, so it can be exported at Guest2 side.

   But that imo doesn't make sense:
- xen-front gives you clearly defined flip events you can forward to the
hypervisor. xen-zcopy would need to add that again.

xen-zcopy is a helper driver which doesn't handle page flips
and is not a KMS driver as one might think of: the DRM UAPI it uses is
just to export a dma-buf as a PRIME buffer, but that's it.
Flipping etc. is done by the backend [1], not xen-zcopy.

   Same for
hyperdmabuf (and really we're not going to shuffle struct dma_fence over
the wire in a generic fashion between hypervisor guests).

- xen-front already has the idea of pixel format for the buffer (and any
other metadata). Again, xen-zcopy and hyperdmabuf lack that, would need
to add it shoehorned in somehow.

Again, here you are talking of something which is implemented in
Xen display backend, not xen-zcopy, e.g. display backend can
implement para-virtual display w/o xen-zcopy at all, but in this case
there is a memory copying for each frame. With the help of xen-zcopy
the backend feeds xen-front's buffers directly into Guest2 DRM/KMS or
Weston or whatever as xen-zcopy exports remote buffers as PRIME buffers,
thus no buffer copying is required.

Why do you need to copy on every frame for xen-front? In the above
pipeline, using xen-front I see 0 architectural reasons to have a copy
anywhere.

This seems to be the core of the confusion we're having here.

Ok, so I'll try to explain:
1. xen-front - produces a display buffer to be shown at Guest2
by the backend, shares its grant references with the backend
2. xen-front sends page flip event to the backend specifying the
buffer in question
3. Backend takes the shared buffer (which is only a buffer mapped into
backend's memory, it is not a dma-buf/PRIME one) and makes memcpy from
it to a local dumb/surface
4. Backend flips that local dumb buffer/surface

If I have a xen-zcopy helper driver then I can avoid doing step 3):
1) 2) remain the same as above
3) Initially for a new display buffer, backend calls xen-zcopy to create
a local PRIME buffer from the 

Re: [RFC v4 11/25] drm/connector: Add connector array functions

[Daniel Vetter]

On Sat, Apr 14, 2018 at 01:53:04PM +0200, Noralf Trønnes wrote:
> Add functions to deal with the registred connectors as an array:
> - drm_connector_get_all()
> - drm_connector_put_all()
> 
> And to get the enabled status of those connectors:
> drm_connector_get_enabled_status()
> 
> This is prep work to remove struct drm_fb_helper_connector.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_connector.c | 105 
> 
>  include/drm/drm_connector.h |   5 ++
>  2 files changed, 110 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b9eb143d70fc..25c333c05a4e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1854,3 +1854,108 @@ drm_connector_pick_cmdline_mode(struct drm_connector 
> *connector)
>   return mode;
>  }
>  EXPORT_SYMBOL(drm_connector_pick_cmdline_mode);
> +
> +/**
> + * drm_connector_get_all - Get all connectors into an array
> + * @dev: DRM device
> + * @connectors: Returned connector array
> + *
> + * This function iterates through all registered connectors and adds them to 
> an
> + * array allocated by this function. A ref is taken on the connectors.
> + *
> + * Use drm_connector_put_all() to drop refs and free the array.
> + *
> + * Returns:
> + * Number of connectors or -ENOMEM on failure.
> + */
> +int drm_connector_get_all(struct drm_device *dev, struct drm_connector 
> ***connectors)

I honestly don't like the fbdev pattern of having connector arrays all
that much. I think in a world of hotplug we should have as much code as
possible iterating over the life connector list using the special
functions.

Given that these functions here set a bit a bad example imo I'd drop them
and just live with the code duplication.
-Daniel

> +{
> + struct drm_connector *connector, **temp, **conns = NULL;
> + struct drm_connector_list_iter conn_iter;
> + int connector_count = 0;
> +
> + drm_connector_list_iter_begin(dev, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + temp = krealloc(conns, (connector_count + 1) * sizeof(*conns), 
> GFP_KERNEL);
> + if (!temp)
> + goto err_put_free;
> +
> + conns = temp;
> + conns[connector_count++] = connector;
> + drm_connector_get(connector);
> + }
> + drm_connector_list_iter_end(_iter);
> +
> + *connectors = conns;
> +
> + return connector_count;
> +
> +err_put_free:
> + drm_connector_list_iter_end(_iter);
> + drm_connector_put_all(conns, connector_count);
> +
> + return -ENOMEM;
> +}
> +EXPORT_SYMBOL(drm_connector_get_all);
> +
> +/**
> + * drm_connector_put_all - Put and free connector array
> + * @connectors: Array of connectors
> + * @connector_count: Number of connectors in the array (can be negative or 
> zero)
> + *
> + * This function drops the ref on the connectors an frees the array.
> + */
> +void drm_connector_put_all(struct drm_connector **connectors, int 
> connector_count)
> +{
> + int i;
> +
> + if (connector_count < 1)
> + return;
> +
> + for (i = 0; i < connector_count; i++)
> + drm_connector_put(connectors[i]);
> + kfree(connectors);
> +}
> +EXPORT_SYMBOL(drm_connector_put_all);
> +
> +/**
> + * drm_connector_get_enabled_status - Get enabled status on connectors
> + * @connectors: Array of connectors
> + * @connector_count: Number of connectors in the array
> + *
> + * This loops over the connector array and sets enabled if connector status 
> is
> + * _connected_. If no connectors are connected, a new pass is done and
> + * connectors that are not _disconnected_ are set enabled.
> + *
> + * The caller is responsible for freeing the array using kfree().
> + *
> + * Returns:
> + * A boolean array of connector enabled statuses or NULL on allocation 
> failure.
> + */
> +bool *drm_connector_get_enabled_status(struct drm_connector **connectors,
> +unsigned int connector_count)
> +{
> + bool *enabled, any_enabled = false;
> + unsigned int i;
> +
> + enabled = kcalloc(connector_count, sizeof(*enabled), GFP_KERNEL);
> + if (!enabled)
> + return NULL;
> +
> + for (i = 0; i < connector_count; i++) {
> + if (connectors[i]->status == connector_status_connected) {
> + enabled[i] = true;
> + any_enabled = true;
> + }
> + }
> +
> + if (any_enabled)
> + return enabled;
> +
> + for (i = 0; i < connector_count; i++)
> + if (connectors[i]->status != connector_status_disconnected)
> + enabled[i] = true;
> +
> + return enabled;
> +}
> +EXPORT_SYMBOL(drm_connector_get_enabled_status);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 9cb4ca42373c..c3556a5f40c9 100644
> --- 

Re: [Intel-gfx] [RFC v4 00/25] drm: Add generic fbdev emulation

[Daniel Vetter]

On Sat, Apr 14, 2018 at 01:52:53PM +0200, Noralf Trønnes wrote:
> This patchset explores the possibility of having generic fbdev emulation
> in DRM for drivers that supports dumb buffers which they can export. An
> API is added to support in-kernel clients in general.
> 
> In this version I was able to reuse the modesetting code from
> drm_fb_helper in the client API. This avoids code duplication, carries
> over lessons learned and the modesetting code is bisectable. The
> downside is that it takes +10 patches to rip drm_fb_helper in two, so
> maybe it's not worth it wrt possible breakage and a challenging review.

So my idea wasn't to rip the fbdev helper in  half first (that's indeed a
lot of work). But start out right away with using every piece of the
drm_client infrastructure you're adding in the existing fbdev code.

That way there's not a huge patch series which just adds code, with no
users, but every step of the way and every addition is tested almost right
away. That makes more gradual merging also easier. The things I have in
mind here is the generic fb_probe, or the drm_client block/unblock masters
and all that stuff.

Then, once we've demonstrated all these auxiliary pieces necessary for
drm_client.c work, we can cut the fb-helper in half and move the modeset
code into the drm_client library.

I still prefer an even more gradual path like this compared to what you
have in your patch series, but I understand that's yet another huge
shuffle. And the current series seems like a good enough approach to get
to essentially the same place.

> Does the Intel CI test the fbdev emulation?

We have fbdev emulation enabled, and iirc there's even a few tests for
fbdev. Just booting it on 20+ machines is a lot of testing itsefl already.

> 
> Daniel had this concern with the previous version:
> 
> The register/unregister model needs more thought. Allowing both clients
> to register whenever they want to, and drm_device instances to come and
> go is what fbcon has done, and the resulting locking is a horror show.
> 
> I think if we require that all in-kernel drm_clients are registers when
> loading drm.ko (and enabled/disabled only per module options and
> Kconfig), then we can throw out all the locking. That avoids a lot of
> the headaches.
> 
> I have solved this by adding a notifier that fires when a new DRM device
> is registered (I've removed the new() callback). Currently only
> bootsplash uses this. The fbdev client needs to be setup from the driver
> since it can't know on device registration if the driver will setup it's
> own fbdev emulation later and the vtcon client hooks up to a user
> provided device id.

Ugh, notifier is exactly what fbcon also uses. It just hides the locking
horror show slightly, but it's equally bad. I'm working on a multi-year
plan to rip out the fbcon notifier, please don't start another one. See

commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter 
Date:   Tue Aug 1 17:32:07 2017 +0200

fbcon: Make fbcon a built-time depency for fbdev

for full details.

> Since fbcon can't handle fb_open failing, the buffer has to be
> pre-allocated. Exporting a GEM buffer pins the driver module making it
> impossible to unload it.
> I have included 2 solutions to the problem:
> - sysfs file to remove/close clients: remove_internal_clients

This is the same thing that defacto happens already with fbcon: You have
to remove fbcon first (which holds a full ref on the fbdev, which prevents
the drm driver from unloading). I think explicitly asking for that
reference to disappear is ok.

It does mean everyone has to update their unload scripts, but oh well.

> - Change drm_gem_prime_export() so it doesn't pin on client buffers

The double-loop in that patch definitely doesn't cut it, but worst case I
think something like that could be made to work.

> If a dumb buffer is exported from a kernel thread (worker) context, the
> file descriptor isn't closed and I leak a reference so the buffer isn't
> freed. Please look at drm_client_buffer_create() in patch
> 'drm/client: Finish the in-kernel client API'.
> This is a blocker that needs a solution.

Hm, missed that in my first cursory read of the series, I'l take another
look.
-Daniel

> 
> 
> Noralf.
> 
> Changes since version 3:
> Client API changes:
> - Drop drm_client_register_funcs() which attached clients indirectly.
>   Let clients attach directly using drm_client_new{_from_id}(). Clients
>   that wants to attach to all devices must be linked into drm.ko and use
>   the DRM device notifier. This is done to avoid the lock/race
>   register/unregister hell we have with fbcon. (Daniel Vetter)
> - drm_client_display_restore() checks if there is a master and if so
>   returns -EBUSY. (Daniel Vetter)
> - Allocate drm_file up front instead of on-demand. Since fbdev can't do
>   on demand buffer allocation because of fbcon, there's no need for this.
> - Add sysfs file to 

Re: [RFC v4 06/25] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()

[Daniel Vetter]

On Sat, Apr 14, 2018 at 01:52:59PM +0200, Noralf Trønnes wrote:
> Prepare for moving drm_fb_helper modesetting code to drm_client.
> drm_client will be linked to drm.ko, so move
> __drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
> out of drm_kms_helper.ko.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_atomic.c| 168 
> 
>  drivers/gpu/drm/drm_atomic_helper.c | 168 
> +---
>  drivers/gpu/drm/drm_fb_helper.c |   8 +-
>  include/drm/drm_atomic.h|   5 ++
>  include/drm/drm_atomic_helper.h |   4 -
>  5 files changed, 179 insertions(+), 174 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..1fb602b6c8b1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2060,6 +2060,174 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>  
> +/* just used from drm_client and atomic-helper: */

In that case please put the prototype for these into the internal header
drm_crtc_internal.h. Just to avoid drivers abusing this (they really
shouldn't).
-Daniel

> +int drm_atomic_disable_plane(struct drm_plane *plane,
> +  struct drm_plane_state *plane_state)
> +{
> + int ret;
> +
> + ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> + if (ret != 0)
> + return ret;
> +
> + drm_atomic_set_fb_for_plane(plane_state, NULL);
> + plane_state->crtc_x = 0;
> + plane_state->crtc_y = 0;
> + plane_state->crtc_w = 0;
> + plane_state->crtc_h = 0;
> + plane_state->src_x = 0;
> + plane_state->src_y = 0;
> + plane_state->src_w = 0;
> + plane_state->src_h = 0;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_disable_plane);
> +
> +static int update_output_state(struct drm_atomic_state *state,
> +struct drm_mode_set *set)
> +{
> + struct drm_device *dev = set->crtc->dev;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_connector *connector;
> + struct drm_connector_state *new_conn_state;
> + int ret, i;
> +
> + ret = drm_modeset_lock(>mode_config.connection_mutex,
> +state->acquire_ctx);
> + if (ret)
> + return ret;
> +
> + /* First disable all connectors on the target crtc. */
> + ret = drm_atomic_add_affected_connectors(state, set->crtc);
> + if (ret)
> + return ret;
> +
> + for_each_new_connector_in_state(state, connector, new_conn_state, i) {
> + if (new_conn_state->crtc == set->crtc) {
> + ret = drm_atomic_set_crtc_for_connector(new_conn_state,
> + NULL);
> + if (ret)
> + return ret;
> +
> + /* Make sure legacy setCrtc always re-trains */
> + new_conn_state->link_status = DRM_LINK_STATUS_GOOD;
> + }
> + }
> +
> + /* Then set all connectors from set->connectors on the target crtc */
> + for (i = 0; i < set->num_connectors; i++) {
> + new_conn_state = drm_atomic_get_connector_state(state,
> + set->connectors[i]);
> + if (IS_ERR(new_conn_state))
> + return PTR_ERR(new_conn_state);
> +
> + ret = drm_atomic_set_crtc_for_connector(new_conn_state,
> + set->crtc);
> + if (ret)
> + return ret;
> + }
> +
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + /*
> +  * Don't update ->enable for the CRTC in the set_config request,
> +  * since a mismatch would indicate a bug in the upper layers.
> +  * The actual modeset code later on will catch any
> +  * inconsistencies here.
> +  */
> + if (crtc == set->crtc)
> + continue;
> +
> + if (!new_crtc_state->connector_mask) {
> + ret = drm_atomic_set_mode_prop_for_crtc(new_crtc_state,
> + NULL);
> + if (ret < 0)
> + return ret;
> +
> + new_crtc_state->active = false;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/* just used from drm_client and atomic-helper: */
> +int drm_atomic_set_config(struct drm_mode_set *set,
> +   struct drm_atomic_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_plane_state *primary_state;
> + struct drm_crtc *crtc = set->crtc;
> + int hdisplay, vdisplay;
> + int ret;
> +
> +   

[DPU PATCH v2 0/2] Connector virtualization for Dual-DSI

[Chandan Uddaraju]

This patch series adds support to DSI connector
virtualization for Dual-DSI configuration.

These changes have been tested using dual-dsi truly panel on sdm845 platform.

Additional changes that will be needed to have end-to-end functionality:
 --> DSI6G-v2 changes: https://patchwork.kernel.org/patch/10294605/
 --> truly panel patches: https://patchwork.kernel.org/patch/10327749/
 --> DPU changes that will be uploaded soon.

Changes in V2:
  Addressed Sean's review comments:
-Removed Change-Id from the commit text tags.
-Remove extra parentheses


Chandan Uddaraju (2):
  drm/msm/dsi: adjust dsi timing for dual dsi mode
  drm/msm/dsi: Use one connector for dual DSI mode

 drivers/gpu/drm/msm/dsi/dsi.c |   3 +
 drivers/gpu/drm/msm/dsi/dsi.h |   2 +
 drivers/gpu/drm/msm/dsi/dsi_host.c|  17 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 125 +++---
 4 files changed, 62 insertions(+), 85 deletions(-)

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

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

[Bug 106053] Drawing at screen boundary is very slow.

[bugzilla-daemon]

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

--- Comment #5 from Roland Scheidegger  ---
(In reply to Marek Olšák from comment #4)
> I think the hw doesn't have a clipper, though it shouldn't be hard to verify
> if it's true. Yeah, draw could use some optimizations for the clipper, e.g.
> the guardband, but simply doing culling (not clipping) should be enough for
> point sprites.

That's what I meant with guardband clipping: there's no actual clipping, but
the hw will still cull pixels outside the viewport. Hence it probably would be
better if draw wouldn't clip if a primitive doesn't fit into the viewport, but
fits into the (hw) guardband. (And you are right that point sprites are a bit
of a special case.)

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

Re: [PATCH] drm/rockchip: fix VOP vblank race

[Sandy Huang]

Applied to drm-misc-next. Thanks！


在 2018/4/17 5:43, Heiko Stuebner 写道:

Hi John,

Am Montag, 16. April 2018, 18:46:56 CEST schrieb John Keeping:

Hi Sandy,

On Tue, 10 Apr 2018 20:40:06 +0800, Sandy Huang wrote:


Reviewed-by: Sandy huang 

Thanks for the review, but I don't see this in drm-misc yet.  Are you
planning to pick this up?

I was occupied with merge-window stuff recently, but I guess either
Sandy or myself is going to pick it up shortly.


Heiko


在 2018/3/29 0:03, John Keeping 写道:

We have seen a case of a bad reference count for vblanks with the
Rockchip VOP:

[ cut here ]
WARNING: CPU: 1 PID: 383 at drivers/gpu/drm/drm_irq.c:1198 
drm_vblank_put+0x40/0xcc
Modules linked in: brcmfmac brcmutil
CPU: 1 PID: 383 Comm: kworker/u8:2 Not tainted 4.9.75-rt60 #1
Hardware name: Rockchip (Device Tree)
Workqueue: events_unbound flip_worker
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r7:c0b1b13c r6:600b0013 r5: r4:c0b1b13c
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (__warn+0xe4/0x104)
 r7:0009 r6:c03cf26c r5: r4:
[] (__warn) from [] (warn_slowpath_null+0x28/0x30)
 r9:eeb443a0 r8:eeb443c8 r7:ee8a5ec0 r6:ee8a5ec0 r5:edb47f00 r4:ee096200
[] (warn_slowpath_null) from [] 
(drm_vblank_put+0x40/0xcc)
[] (drm_vblank_put) from [] 
(drm_crtc_vblank_put+0x18/0x1c)
 r5:edb47f00 r4:ee3c8a80
[] (drm_crtc_vblank_put) from [] 
(vop_fb_unref_worker+0x18/0x24)
[] (vop_fb_unref_worker) from [] 
(flip_worker+0x98/0xb4)
 r5:edb47f00 r4:eeb443a8
[] (flip_worker) from [] 
(process_one_work+0x1a8/0x2fc)
 r9: r8:ee807d00 r7: r6:ee809c00 r5:eeb443a8 r4:edfe5f80
[] (process_one_work) from [] 
(worker_thread+0x2ac/0x458)
 r10:0088 r9:edfe5f98 r8:ee809c2c r7:c0b04100 r6:ee809c00 
r5:ee809c00
 r4:edfe5f80
[] (worker_thread) from [] (kthread+0xfc/0x10c)
 r10: r9: r8:c0135640 r7:edfe5f80 r6: 
r5:edf0e240
 r4:ee8a4000 r3:ed194e00
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
 r8: r7: r6: r5:c0139fc0 r4:edf0e240
---[ end trace 0002 ]---

It seems that this is caused by unfortunate timing between
vop_crtc_atomic_flush() and vop_handle_vblank() given the following
ordering:

atomic_flushhandle_vblank
-

drm_flip_work_queue
set_bit
if (test_and_clear_bit(...))
drm_flip_work_commit
drm_vblank_get

This results in vop_fb_unref_worker (called as flip work) decrementing
the vblank refcount before it has been incremented.

Signed-off-by: John Keeping 
---
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6755a9eea4b2..d4e1400aedf3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1017,9 +1017,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
continue;
   
   		drm_framebuffer_get(old_plane_state->fb);

+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
drm_flip_work_queue(>fb_unref_work, old_plane_state->fb);
set_bit(VOP_PENDING_FB_UNREF, >pending);
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
}
   }
 





___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



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