[RFC PATCH v1 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

[Yakir Yang]

Hi Heiko,

On 11/22/2015 04:14 AM, Heiko Stuebner wrote:
> Hi Yakir,
>
> Am Mittwoch, 11. November 2015, 15:47:32 schrieb Yakir Yang:
>> Signed-off-by: Yakir Yang 
>> ---
>>   .../display/rockchip/inno_hdmi-rockchip.txt| 50 
>> ++
>>   1 file changed, 50 insertions(+)
>>   create mode 100644 
>> Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt 
>> b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>> new file mode 100644
>> index 000..1898408
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>> @@ -0,0 +1,50 @@
>> +Rockchip specific extensions to the Innosilicon HDMI
>> +
>> +
>> +Required properties:
>> +- compatible:
>> +"rockchip,rk3036-dw-hdmi";
> should be "rockchip,rk3036-inno-hdmi"; instead I guess

Right, thanks

- Yakir

>
> Heiko
>
>
>

[PATCH v2 00/13] drm/exynos: async G2D and g2d_move()

[Hyungwon Hwang]

Hello Tobias,

I reviewed this whole patchset, and it looks good to me. Also I tested
it on my odroid u3, and all works fine. Thanks you for your effort.

Tested-by: Hyungwon Hwang 
Reviewed-by: Hyungwon Hwang 

BRs,
Hyungwon Hwang

On Sun, 22 Nov 2015 19:48:30 +0100
Tobias Jakobi  wrote:

> Hello,
> 
> this series mostly touches G2D code. It introduces the following:
> 
> (1) drmHandleEvent2() is added to enable processing of vendor-specific
> events. This will be used to expose asynchronous operation of the
> G2D. The necessary kernel infrastructure is already there since
> a lot of kernel versions. [This touches libdrm core code!]
> 
> (2) The necessary infrastructure to handle G2D events. This includes
> adding g2d_config_event() and g2d_exec2() to the public API.
> A test application is provided to ensure that everything works
> as expected.
> 
> (3) A small performance test application which can be used to measure
> the speed of solid color clear operations. Interesting for
> benchmarking and plotting colorful graphs (e.g. through
> Mathematica).
> 
> (4) g2d_move() which works similar to g2d_copy() but like the C
> memmove() properly handles overlapping buffer copies.
> Again a test application is present to check that this
> indeed does what it should.
> 
> (5) Various small changes. A framebuffer colorformat fix for the
> general G2D test application. Moving the currently unused
> g2d_reset() to the public API. Adding a counterpart to
> exynos_bo_map() to unmap buffers again.
> 
> (6) Last but not least a small bump of the Exynos version number.
> 
> Please review and let me know what I should change/improve.
> 
> 
> With best wishes,
> Tobias
> 
> P.S.: Most patches were submitted already some time ago but never
> made it upstream. So if something looks familiar, don't worry! ;)
> 
> Changes since v1:
> - Added wording changes suggested by Hyungwon Hwang.
> - Added binaries for new test applications to .gitignore.
> - Collected r-b and t-b tags.
> 
> Tobias Jakobi (13):
>   drm: Implement drmHandleEvent2()
>   exynos: Introduce exynos_handle_event()
>   tests/exynos: add fimg2d performance analysis
>   exynos/fimg2d: add g2d_config_event
>   exynos: fimg2d: add g2d_exec2
>   tests/exynos: add fimg2d event test
>   tests/exynos: use XRGB for framebuffer
>   exynos: fimg2d: add g2d_set_direction
>   exynos/fimg2d: add g2d_move
>   tests/exynos: add test for g2d_move
>   exynos/fimg2d: add exynos_bo_unmap()
>   exynos/fimg2d: add g2d_reset() to public API
>   exynos: bump version number
> 
>  .gitignore |   2 +
>  exynos/exynos-symbol-check |   5 +
>  exynos/exynos_drm.c|  48 ++
>  exynos/exynos_drm.h|  12 ++
>  exynos/exynos_drmif.h  |  27 +++
>  exynos/exynos_fimg2d.c | 165 +--
>  exynos/exynos_fimg2d.h |  49 ++
>  exynos/libdrm_exynos.pc.in |   2 +-
>  tests/exynos/Makefile.am   |  26 ++-
>  tests/exynos/exynos_fimg2d_event.c | 326
> 
> tests/exynos/exynos_fimg2d_perf.c  | 327
> +
> tests/exynos/exynos_fimg2d_test.c  | 134 ++-
> xf86drm.h  |  21 +++
> xf86drmMode.c  |  10 +- 14 files changed, 1138
> insertions(+), 16 deletions(-) create mode 100644
> tests/exynos/exynos_fimg2d_event.c create mode 100644
> tests/exynos/exynos_fimg2d_perf.c
> 

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

--- Comment #6 from bellamorte42 at gmail.com ---
I loaded up XCOM again just to see if I would have the same issue.  Yes, I do. 
The second shot the aliens fired apprently hung radeon rings 0,3, and 4 on my
computer forcing a restart.

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

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

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

--- Comment #7 from Paulo Dias  ---
i cant get a reliable apitrace neither from xcom or civbe (damn you steam).

if someone has a reliable howto on how to get a good apitrace from steam games,
please share it!

anyway, i did some more testing and at least with xcom, it i disable vsync from
kf5 (5.4) and enable it in-game, the crash takes much longer to occur, i dont
know its related, but thats all i have to report.

please devs, do you have any info on how to produce an apitrace that works with
steam games?

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

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #61 from Paulo Dias  ---
@david,have you tried with vsync on and off? i find out that if i disable the
SO sync and just leave the in-game one, the hangup takes much longer to
occur,might be worth a shot?

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

[PATCH v2 00/13] drm/exynos: async G2D and g2d_move()

[Inki Dae]

2015년 11월 23일 11:35에 Hyungwon Hwang 이(가) 쓴 글:
> Hello Tobias,
> 
> I reviewed this whole patchset, and it looks good to me. Also I tested
> it on my odroid u3, and all works fine. Thanks you for your effort.
> 
> Tested-by: Hyungwon Hwang 
> Reviewed-by: Hyungwon Hwang 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> BRs,
> Hyungwon Hwang
> 
> On Sun, 22 Nov 2015 19:48:30 +0100
> Tobias Jakobi  wrote:
> 
>> Hello,
>>
>> this series mostly touches G2D code. It introduces the following:
>>
>> (1) drmHandleEvent2() is added to enable processing of vendor-specific
>> events. This will be used to expose asynchronous operation of the
>> G2D. The necessary kernel infrastructure is already there since
>> a lot of kernel versions. [This touches libdrm core code!]
>>
>> (2) The necessary infrastructure to handle G2D events. This includes
>> adding g2d_config_event() and g2d_exec2() to the public API.
>> A test application is provided to ensure that everything works
>> as expected.
>>
>> (3) A small performance test application which can be used to measure
>> the speed of solid color clear operations. Interesting for
>> benchmarking and plotting colorful graphs (e.g. through
>> Mathematica).
>>
>> (4) g2d_move() which works similar to g2d_copy() but like the C
>> memmove() properly handles overlapping buffer copies.
>> Again a test application is present to check that this
>> indeed does what it should.
>>
>> (5) Various small changes. A framebuffer colorformat fix for the
>> general G2D test application. Moving the currently unused
>> g2d_reset() to the public API. Adding a counterpart to
>> exynos_bo_map() to unmap buffers again.
>>
>> (6) Last but not least a small bump of the Exynos version number.
>>
>> Please review and let me know what I should change/improve.
>>
>>
>> With best wishes,
>> Tobias
>>
>> P.S.: Most patches were submitted already some time ago but never
>> made it upstream. So if something looks familiar, don't worry! ;)
>>
>> Changes since v1:
>> - Added wording changes suggested by Hyungwon Hwang.
>> - Added binaries for new test applications to .gitignore.
>> - Collected r-b and t-b tags.
>>
>> Tobias Jakobi (13):
>>   drm: Implement drmHandleEvent2()
>>   exynos: Introduce exynos_handle_event()
>>   tests/exynos: add fimg2d performance analysis
>>   exynos/fimg2d: add g2d_config_event
>>   exynos: fimg2d: add g2d_exec2
>>   tests/exynos: add fimg2d event test
>>   tests/exynos: use XRGB for framebuffer
>>   exynos: fimg2d: add g2d_set_direction
>>   exynos/fimg2d: add g2d_move
>>   tests/exynos: add test for g2d_move
>>   exynos/fimg2d: add exynos_bo_unmap()
>>   exynos/fimg2d: add g2d_reset() to public API
>>   exynos: bump version number
>>
>>  .gitignore |   2 +
>>  exynos/exynos-symbol-check |   5 +
>>  exynos/exynos_drm.c|  48 ++
>>  exynos/exynos_drm.h|  12 ++
>>  exynos/exynos_drmif.h  |  27 +++
>>  exynos/exynos_fimg2d.c | 165 +--
>>  exynos/exynos_fimg2d.h |  49 ++
>>  exynos/libdrm_exynos.pc.in |   2 +-
>>  tests/exynos/Makefile.am   |  26 ++-
>>  tests/exynos/exynos_fimg2d_event.c | 326
>> 
>> tests/exynos/exynos_fimg2d_perf.c  | 327
>> +
>> tests/exynos/exynos_fimg2d_test.c  | 134 ++-
>> xf86drm.h  |  21 +++
>> xf86drmMode.c  |  10 +- 14 files changed, 1138
>> insertions(+), 16 deletions(-) create mode 100644
>> tests/exynos/exynos_fimg2d_event.c create mode 100644
>> tests/exynos/exynos_fimg2d_perf.c
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

On 11/21/2015 1:29 AM, Rob Herring wrote:
> +Stephen
>
> On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja  
> wrote:
>> Hi Rob,
>>
>> On 11/18/2015 6:48 PM, Rob Herring wrote:
>>>
>>> +dt list
>>>
>>> On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja 
>>> wrote:

 Add additional property info needed for DSIv2 DT.
>>>
>>>
>>> Please use get_maintainers.pl.
>>
>>
>> Sorry about that, missed out doing that posting this time.
>>
>>>
 Signed-off-by: Archit Taneja 
 ---
Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
 b/Documentation/devicetree/bindings/display/msm/dsi.txt
 index f344b9e..ca65a34 100644
 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
 +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
 @@ -13,18 +13,25 @@ Required properties:
- power-domains: Should be < MDSS_GDSC>.
- clocks: device clocks
  See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
 details.
 -- clock-names: the following clocks are required:
 +- clock-names: these vary based on the DSI version. For DSI6G:
  * "bus_clk"
  * "byte_clk"
 +  * "byte_clk_src
>>>
>>>
>>> This sounds like the parent of byte_clk. Is that really a clock within
>>> the block?
>>
>>
>> byte_clk_src isn't in the block, but byte_clk_src's parent is one of
>> the PLLs in this block. We take this clock so that we can re-parent
>> it to an appropriate PLL. The decision of what PLL to choose needs to
>> be done by the DSI block's driver.
>
> Seems like abuse to me. The list of clocks should match what are
> inputs to the block, not what the driver happens to need. Without a
> full understanding of the clock tree here, I don't have a suggestion.
> Maybe Stephen does.

We don't need specify byte_clk_src (and other xyz_clk_src clocks) via
DT. There is a static link set up between byte_clk and byte_clk_src by
our clock driver that never changes. We can retrieve it in the driver
itself using clk_get_parent(byte_clk). This way we stick to only
input clocks.

Stephen, does that sound okay?

>
  * "core_clk"
  * "core_mmss_clk"
  * "iface_clk"
  * "mdp_core_clk"
  * "pixel_clk"
 +  * "pixel_clk_src"
 +  For DSIv2, we need a few more:
>>>
>>>
>>> What is the overall order of clocks? As listed?
>>
>>
>> Order in which the driver does clk_get? It uses the clock
>> name to get each one individually, so the order doesn't matter
>> as such.
>
> The order in DT. You may use the names, but the order should still be 
> specified.

Okay. I'll cross check and make sure the order is as in our DT files.

Archit

>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[PATCH v2 1/5] drm/exynos: mixer: refactor layer setup

[Inki Dae]

Hi Tobias,

2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글:
> First step in allowing a more generic way to setup complex
> blending for the different layers.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 84 
> ++-
>  1 file changed, 73 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e..2c1cea3 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -63,6 +63,11 @@ struct mixer_resources {
>   struct clk  *mout_mixer;
>  };
>  
> +struct layer_cfg {
> + unsigned int index;
> + unsigned int priority;
> +};
> +
>  enum mixer_version_id {
>   MXR_VER_0_0_0_16,
>   MXR_VER_16_0_33_0,
> @@ -92,6 +97,8 @@ struct mixer_context {
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + const struct layer_cfg  *layer_cfg;
> + unsigned intnum_layer;
>   int pipe;
>   unsigned long   flags;
>   boolinterlace;
> @@ -110,6 +117,34 @@ struct mixer_drv_data {
>   boolhas_sclk;
>  };
>  
> +/*
> + * The default layer priorities for non-VP (video processor)
> + * and VP mixer configurations.
> + *
> + * A higher priority means that the layer is at the top of
> + * the layer stack.
> + * Configurations have to be specified with its entries
> + * sorted with increasing priority.
> + *
> + * The default config assumes the following usage scenario:
> + * layer1: OSD [top]
> + * layer0: main framebuffer
> + * video layer: video overlay [bottom]
> + * Note that the video layer is only usable when the
> + * VP is available.
> + */
> +
> +static const struct layer_cfg nonvp_default_cfg[] = {
> + { .index = 0, .priority = 1 },  /* layer0 */
> + { .index = 1, .priority = 2 },  /* layer1 */
> +};
> +
> +static const struct layer_cfg vp_default_cfg[] = {
> + { .index = 2, .priority = 1 },  /* video layer */
> + { .index = 0, .priority = 2 },  /* layer0 */
> + { .index = 1, .priority = 3 },  /* layer1 */
> +};
> +
>  static const u8 filter_y_horiz_tap8[] = {
>   0,  -1, -1, -1, -1, -1, -1, -1,
>   -1, -1, -1, -1, -1, 0,  0,  0,
> @@ -268,6 +303,34 @@ static void vp_default_filter(struct mixer_resources 
> *res)
>   filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
>  }
>  
> +static void mixer_layer_priority(struct mixer_context *ctx)
> +{
> + u32 val = 0;
> + unsigned int i, priority;
> +
> + for (i = 0; i < ctx->num_layer; ++i) {
> + priority = ctx->layer_cfg[i].priority;
> + BUG_ON(priority > 15);

What doesn constant, 15 mean? You need to clarify the meaning
and please, use a macro instead.
And it'd better to just return in this case so that the layer
configuration can be set with a default value.
I think it'd be enough to print out warning message.

Thanks,
Inki Dae

> +
> + switch (ctx->layer_cfg[i].index) {
> + case 0:
> + val |= MXR_LAYER_CFG_GRP0_VAL(priority);
> + break;
> + case 1:
> + val |= MXR_LAYER_CFG_GRP1_VAL(priority);
> + break;
> + case 2:
> + val |= MXR_LAYER_CFG_VP_VAL(priority);
> + break;
> + default:
> + BUG_ON(true);
> + break;
> + }
> + }
> +
> + mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
> +}
> +
>  static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
>  {
>   struct mixer_resources *res = >mixer_res;
> @@ -673,17 +736,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
>   mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
>   MXR_STATUS_BURST_MASK);
>  
> - /* setting default layer priority: layer1 > layer0 > video
> -  * because typical usage scenario would be
> -  * layer1 - OSD
> -  * layer0 - framebuffer
> -  * video - video overlay
> -  */
> - val = MXR_LAYER_CFG_GRP1_VAL(3);
> - val |= MXR_LAYER_CFG_GRP0_VAL(2);
> - if (ctx->vp_enabled)
> - val |= MXR_LAYER_CFG_VP_VAL(1);
> - mixer_reg_write(res, MXR_LAYER_CFG, val);
> + mixer_layer_priority(ctx);
>  
>   /* setting background color */
>   mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
> @@ -1209,6 +1262,15 @@ static int mixer_probe(struct platform_device *pdev)
>   ctx->vp_enabled = drv->is_vp_enabled;
>   ctx->has_sclk = drv->has_sclk;
>   ctx->mxr_ver = drv->version;
> +
> + if (drv->is_vp_enabled) {
> + ctx->layer_cfg = vp_default_cfg;

[PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()

[Inki Dae]

2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글:
> This updates the blending setup when the layer configuration
> changes (triggered by mixer_win_{commit,disable}).
> 
> To avoid unnecesary reconfigurations we cache the layer
> state in the mixer context.
> 
> Extra care has to be taken for the layer that is currently
> being enabled/disabled.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 41 
> +--
>  1 file changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index ec9659e..1c24fb5 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -99,6 +99,7 @@ struct mixer_context {
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
>   const struct layer_cfg  *layer_cfg;
>   unsigned intnum_layer;
> + u32 layer_state;
>   int pipe;
>   unsigned long   flags;
>   boolinterlace;
> @@ -189,6 +190,27 @@ static inline bool is_alpha_format(const struct 
> mixer_context* ctx, unsigned int
>   }
>  }
>  
> +static inline u32 get_layer_state(const struct mixer_context *ctx,
> + unsigned int win, bool enable)
> +{
> + u32 enable_state, alpha_state;
> +
> + enable_state = ctx->layer_state & 0x;
> + alpha_state = ctx->layer_state >> 16;
> +
> + if (enable)
> + enable_state |= (1 << win);
> + else
> + enable_state &= ~(1 << win);
> +
> + if (enable && is_alpha_format(ctx, win))
> + alpha_state |= (1 << win);
> + else
> + alpha_state &= ~(1 << win);
> +
> + return ((alpha_state << 16) | enable_state);
> +}
> +
>  static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
>  {
>   return readl(res->vp_regs + reg_id);
> @@ -370,8 +392,9 @@ static void mixer_general_layer(struct mixer_context *ctx,
>  {
>   u32 val;
>   struct mixer_resources *res = >mixer_res;
> + const u32 alpha_state = ctx->layer_state >> 16;
>  
> - if (is_alpha_format(ctx, cfg->index)) {
> + if (alpha_state & (1 << cfg->index)) {
>   val  = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
>   val |= MXR_GRP_CFG_BLEND_PRE_MUL;
>   val |= MXR_GRP_CFG_PIXEL_BLEND_EN; /* blending based on pixel 
> alpha */
> @@ -397,10 +420,11 @@ static void mixer_general_layer(struct mixer_context 
> *ctx,
>   }
>  }
>  
> -static void mixer_layer_blending(struct mixer_context *ctx, unsigned int 
> enable_state)
> +static void mixer_layer_blending(struct mixer_context *ctx)
>  {
>   unsigned int i, index;
>   bool bottom_layer = false;
> + const u32 enable_state = ctx->layer_state & 0x;
>  
>   for (i = 0; i < ctx->num_layer; ++i) {
>   index = ctx->layer_cfg[i].index;
> @@ -503,8 +527,19 @@ static void mixer_cfg_layer(struct mixer_context *ctx, 
> unsigned int win,
>   bool enable)
>  {
>   struct mixer_resources *res = >mixer_res;
> + u32 new_layer_state;
>   u32 val = enable ? ~0 : 0;
>  
> + new_layer_state = get_layer_state(ctx, win, enable);
> + if (new_layer_state == ctx->layer_state)
> + return;
> +
> + /*
> +  * Update the layer state so that mixer_layer_blending()
> +  * below can use it.
> +  */
> + ctx->layer_state = new_layer_state;

It may be trivial but I think it'd be better to move above line to most bottom 
of this function.

> +
>   switch (win) {
>   case 0:
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> @@ -520,6 +555,8 @@ static void mixer_cfg_layer(struct mixer_context *ctx, 
> unsigned int win,
>   }
>   break;
>   }
> +
> + mixer_layer_blending(ctx);

Here.

Thanks,
Inki Dae

>  }
>  
>  static void mixer_run(struct mixer_context *ctx)
> 

[PATCH v4 10/13] of: add vendor prefix for boe

[Thierry Reding]

On Fri, Nov 20, 2015 at 04:15:36PM +0800, Chris Zhong wrote:
> Signed-off-by: Chris Zhong 
> Acked-by: Rob Herring 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied, with slightly modified commit message.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/88dc5b8d/attachment.sig>

[PATCH v4 11/13] drm/panel: simple: Add support for BOE TV080WUM-NL0

[Thierry Reding]

On Fri, Nov 20, 2015 at 04:15:37PM +0800, Chris Zhong wrote:
> This adds support for the BOE TV080WUM-NL0 1200x1920 mipi panel to the
> DRM simple panel driver.
> 
> Signed-off-by: Chris Zhong 
> 
> ---
> 
> Changes in v4:
> Alphabetically arranged the name
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/panel/panel-simple.c | 34 ++
>  1 file changed, 34 insertions(+)

Applied, with slightly modified commit message.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/462e78f7/attachment-0001.sig>

[PATCH v4 12/13] drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree binding

[Thierry Reding]

On Fri, Nov 20, 2015 at 04:15:38PM +0800, Chris Zhong wrote:
> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
> Bindings for three specific panels are provided to show how the
> simple panel binding can be used.
> 
> Signed-off-by: Chris Zhong 
> Acked-by: Rob Herring 
> 
> ---
> 
> Changes in v4: None
> Changes in v3:
> move boe,tv080wum-nl0.txt to bindings/display/panel/
> 
> Changes in v2:
> As Thierry.Reding comment, add a documentation for this panel.
> 
>  .../devicetree/bindings/display/panel/boe,tv080wum-nl0.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt

Applied, with a rewritten commit message. The one above seems to be
copied from the original commit that added the simple-panel binding.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/6672/attachment.sig>

[Bug 92953] Segfault loading UT4 map/server

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

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

--- Comment #14 from Nicolai Hähnle  ---
Your dmesg log has a non-standard timestamp format (the [] prefix in each
line), which causes the debug handling in radeonsi to get tripped up. The
fastest way to make forward progress is for you to revert your dmesg timestamp
format to the default and repeat.

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

[PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()

[Inki Dae]

2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글:
> This analyses the current layer configuration (which layers
> are enabled, which have alpha-pixelformat, etc.) and setups
> blending accordingly.
> 
> We currently disable all kinds of blending for the bottom-most
> layer, since configuration of the mixer background is not
> yet exposed.
> Also blending is only enabled when the layer has a pixelformat
> with alpha attached.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 88 
> +++
>  drivers/gpu/drm/exynos/regs-mixer.h   |  1 +
>  2 files changed, 89 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2c1cea3..ec77aad 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -174,6 +174,21 @@ static const u8 filter_cr_horiz_tap4[] = {
>   70, 59, 48, 37, 27, 19, 11, 5,
>  };
>  
> +static inline bool is_alpha_format(const struct mixer_context* ctx, unsigned 
> int win)
> +{
> + const struct drm_plane_state *state = ctx->planes[win].base.state;
> + const struct drm_framebuffer *fb = state->fb;
> +
> + switch (fb->pixel_format) {
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ARGB1555:
> + case DRM_FORMAT_ARGB:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
>  static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
>  {
>   return readl(res->vp_regs + reg_id);
> @@ -331,6 +346,79 @@ static void mixer_layer_priority(struct mixer_context 
> *ctx)
>   mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
>  }
>  
> +/* Configure blending for bottom-most layer. */
> +static void mixer_bottom_layer(struct mixer_context *ctx,
> + const struct layer_cfg *cfg)
> +{
> + u32 val;
> + struct mixer_resources *res = >mixer_res;
> +
> + if (cfg->index == 2) {
> + val = 0; /* use defaults for video layer */
> + mixer_reg_write(res, MXR_VIDEO_CFG, val);
> + } else {
> + val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
> +
> + /* Don't blend bottom-most layer onto the mixer background. */
> + mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
> + val, MXR_GRP_CFG_MISC_MASK);
> + }
> +}
> +
> +static void mixer_general_layer(struct mixer_context *ctx,
> + const struct layer_cfg *cfg)
> +{
> + u32 val;
> + struct mixer_resources *res = >mixer_res;
> +
> + if (is_alpha_format(ctx, cfg->index)) {
> + val  = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
> + val |= MXR_GRP_CFG_BLEND_PRE_MUL;
> + val |= MXR_GRP_CFG_PIXEL_BLEND_EN; /* blending based on pixel 
> alpha */
> +
> + /* The video layer never has an alpha pixelformat. */

Looks like above comment isn't related to graphics layer.

> + mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
> + val, MXR_GRP_CFG_MISC_MASK);
> + } else {
> + if (cfg->index == 2) {
> + /*
> +  * No blending at the moment since the NV12/NV21 
> pixelformats don't
> +  * have an alpha channel. However the mixer supports a 
> global alpha
> +  * value for a layer. Once this functionality is 
> exposed, we can
> +  * support blending of the video layer through this.
> +  */
> + val = 0;
> + mixer_reg_write(res, MXR_VIDEO_CFG, val);

Above 'if statement' wouldn't be called because cfg->index has always a value 
less than 2
so it should be removed.

> + } else {
> + val = MXR_GRP_CFG_COLOR_KEY_DISABLE;
> + mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
> + val, MXR_GRP_CFG_MISC_MASK);
> + }
> + }
> +}
> +
> +static void mixer_layer_blending(struct mixer_context *ctx, unsigned int 
> enable_state)
> +{
> + unsigned int i, index;
> + bool bottom_layer = false;
> +
> + for (i = 0; i < ctx->num_layer; ++i) {
> + index = ctx->layer_cfg[i].index;
> +
> + /* Skip layer if it's not enabled. */
> + if (!(enable_state & (1 << index)))
> + continue;
> +
> + /* Bottom layer needs special handling. */
> + if (bottom_layer) {
> + mixer_general_layer(ctx, >layer_cfg[i]);
> + } else {
> + mixer_bottom_layer(ctx, >layer_cfg[i]);
> + bottom_layer = true;
> + }

I think above codes could be more cleanned up like below if I understood 
correctly,

if (cfg->index == 2) {
 

[Bug 92850] Segfault loading War Thunder

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

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

--- Comment #13 from Nicolai Hähnle  ---
Thanks! The crash happens in the Gallium state-tracker, i.e.
hardware-independent code. About that apitrace: perhaps you can upload it
somewhere like Dropbox or Google Drive?

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

[PATCH i915 v5 2/2] i915: wait for fence in prepare_plane_fb

[Maarten Lankhorst]

Op 20-11-15 om 23:09 schreef Alex Goins:
> In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive
> fence
>
> v2: First commit
> v3: Remove object_name_lock acquire
> Move wait from intel_atomic_commit() to intel_prepare_plane_fb()
> v4: Wait only on exclusive fences, interruptible with no timeout
> v5: Style tweaks to more closely match rest of file
>
> Signed-off-by: Alex Goins 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index eef3475..f5ab8a7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13347,6 +13347,12 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>   if (!obj)
>   return 0;
>  
> + /* For framebuffer backed by dmabuf, wait for fence */
> + if (obj->base.dma_buf)
> + reservation_object_wait_timeout_rcu(obj->base.dma_buf->resv,
> + false, true,
> + MAX_SCHEDULE_TIMEOUT);
>
This is missing -ERESTARTSYS handling for interruptible waits here.

Full error handling could be fun with radeon fences, which may return -EDEADLK. 
Maybe it's best to only warn if an error other than -ERESTARTSYS is returned, 
and continue.
There's not much recovery we can do if someone else's fence returns an error.

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Daniel Vetter]

On Sat, Nov 21, 2015 at 03:22:07PM +0100, Christian König wrote:
> On 20.11.2015 16:52, cpaul at redhat.com wrote:
> >From: Stephen Chandler Paul 
> >
> >HPD signals on DVI ports can be fired off before the pins required for
> >DDC probing actually make contact, due to the pins for HPD making
> >contact first. This results in a HPD signal being asserted but DDC
> >probing failing, resulting in hotplugging occasionally failing.
> >
> >This is somewhat rare on most cards (depending on what angle you plug
> >the DVI connector in), but on some cards it happens constantly. The
> >Radeon R5 on the machine used for testing this patch for instance, runs
> >into this issue just about every time I try to hotplug a DVI monitor and
> >as a result hotplugging almost never works.
> >
> >Rescheduling the hotplug work for a second when we run into an HPD
> >signal with a failing DDC probe usually gives enough time for the rest
> >of the connector's pins to make contact, and fixes this issue.
> >
> >Signed-off-by: Stephen Chandler Paul 
> 
> Yeah, that's something I always wondered a about bit as well.
> 
> Debouncing is something very common done in electronics, but as far as I
> know the HPD pins don't necessary have an RC circuit so we might need to
> handle this case in software here.
> 
> A delay of something between 10-30ms between the last HPD interrupt and
> further processing of the signal doesn't sounds like such a bad idea.
> 
> Retrying on the other hand doesn't necessarily improve the situation cause
> the delay introduced by this might not be enough.
> 
> So I would rather vote for a fixed delay between an HPD interrupt and
> actually starting to process anything.

Might be interesting to compare what we do in i915 in latest kernels:

- in the hpd handler we check the hpd status bits before probing the edid.
  This will take care of slow unplug case where we get the hpd
  interrupt/status change, but i2c is still working.

- but because crap screens (or whatever it is) if hpd is _not_ set we
  retest the status for 30ms (and bail out as soon as hpd status is
  asserted). This seems to be enough time to settle all screens.

Note that this is in intel_hdmi.c since native dvi ports on intel hw also
always supported hdmi features. Not sure whether we could extract this
into some kind of helper and share.
-Daniel


> 
> Regards,
> Christian.
> 
> >---
> >So this one has kind of been a tough sell with Jerome, mostly because it's
> >somewhat of a hack. Unfortunately however I've managed to find machines where
> >DVI hotplugging literally doesn't work without a patch like this. We've 
> >already
> >tried a couple of ways of handling the situation of retriggering ddc probes:
> >
> >* Trying the DDC probe in the radeon_dvi_detect() function multiple times.
> >* Trying to reschedule the hotplug_work task whenever DDC probing fails on 
> >DVI
> >   but we got a hpd signal (this ended up being a much more complicated patch
> >   then anticipated)
> >* Doing what we do right now, which is just triggering userspace to rescan 
> >all
> >   the ports when the hpd signal is asserted by the DVI port but there's no 
> > DDC
> >   probe, and repeating until at least a second passes.
> >
> >All of these actually work, but I guess it's a question of which one is less 
> >of
> >a hack. If anyone here can think of a cleaner way of handling this feel free 
> >to
> >let me know.
> >
> >  drivers/gpu/drm/radeon/radeon.h|  3 +++
> >  drivers/gpu/drm/radeon/radeon_connectors.c | 20 +---
> >  drivers/gpu/drm/radeon/radeon_irq_kms.c|  2 ++
> >  3 files changed, 22 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/radeon/radeon.h 
> >b/drivers/gpu/drm/radeon/radeon.h
> >index b6cbd81..d63f0fe 100644
> >--- a/drivers/gpu/drm/radeon/radeon.h
> >+++ b/drivers/gpu/drm/radeon/radeon.h
> >@@ -2460,6 +2460,9 @@ struct radeon_device {
> > /* amdkfd interface */
> > struct kfd_dev  *kfd;
> >+/* last time we received an hpd signal */
> >+unsigned long hpd_time;
> >+
> > struct mutexmn_lock;
> > DECLARE_HASHTABLE(mn_hash, 7);
> >  };
> >diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> >b/drivers/gpu/drm/radeon/radeon_connectors.c
> >index 5a2cafb..4ee9440 100644
> >--- a/drivers/gpu/drm/radeon/radeon_connectors.c
> >+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> >@@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, 
> >bool force)
> > const struct drm_encoder_helper_funcs *encoder_funcs;
> > int i, r;
> > enum drm_connector_status ret = connector_status_disconnected;
> >-bool dret = false, broken_edid = false;
> >+bool dret = false, broken_edid = false, hpd_unchanged;
> > r = pm_runtime_get_sync(connector->dev->dev);
> > if (r < 0)
> > return connector_status_disconnected;
> >-if (!force && radeon_check_hpd_status_unchanged(connector)) {
> >+hpd_unchanged = 

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Daniel Vetter]

On Sat, Nov 21, 2015 at 02:49:20PM +, Daniel Stone wrote:
> Hi,
> 
> On 21 November 2015 at 14:22, Christian König  
> wrote:
> > On 20.11.2015 16:52, cpaul at redhat.com wrote:
> >> This is somewhat rare on most cards (depending on what angle you plug
> >> the DVI connector in), but on some cards it happens constantly. The
> >> Radeon R5 on the machine used for testing this patch for instance, runs
> >> into this issue just about every time I try to hotplug a DVI monitor and
> >> as a result hotplugging almost never works.
> >>
> >> Rescheduling the hotplug work for a second when we run into an HPD
> >> signal with a failing DDC probe usually gives enough time for the rest
> >> of the connector's pins to make contact, and fixes this issue.
> >>
> >> Signed-off-by: Stephen Chandler Paul 
> >
> >
> > Yeah, that's something I always wondered a about bit as well.
> >
> > Debouncing is something very common done in electronics, but as far as I
> > know the HPD pins don't necessary have an RC circuit so we might need to
> > handle this case in software here.
> >
> > A delay of something between 10-30ms between the last HPD interrupt and
> > further processing of the signal doesn't sounds like such a bad idea.
> >
> > Retrying on the other hand doesn't necessarily improve the situation cause
> > the delay introduced by this might not be enough.
> >
> > So I would rather vote for a fixed delay between an HPD interrupt and
> > actually starting to process anything.
> 
> Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. those
> on marginal power) which send you HPD storms as well. But DP relies on
> 'short HPD' pulses which can be as brief as 2ms. So attempting to
> totally debounce all HPD won't work.

In our experience in i915 DP hpd works perfectly on all machines. At least
we never had to add timeout hacks to settle hpd, storm handling code isn't
enabled for DP either and we always checked hpd status bits to decide
whether something is connected or not.

hdmi/dvi is the troublemaker which needs settling time and storm handling.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/8] drm/i915: Use EAGAIN instead EBUSY for aux retry.

[Daniel Vetter]

On Fri, Nov 20, 2015 at 04:46:25PM -0800, Rodrigo Vivi wrote:
> Current EBUSY meaning is immediately retry, but this is
> about to change. DRM aux transfer is about to change and
> make EAGAIN the immediately retry and use EBUSY to wait
> a bit for aux channels to recover for any error or wake up.
> 
> This has no functional change if the EAGAIN support is in
> place already for drm aux transfer.
> 
> Signed-off-by: Rodrigo Vivi 

Please document the EAGAIN and EBUSY return codes for the ->transfer
member fo drm_dp_aux in the kerneldoc properly. While at it would be great
if you could document any other error codes that are treated specially for
this function.

Since this will be a bit more text please convert the kerneldoc to the new
per-member comment layout that 4.4 supports, i.e.

/**
 * struct foo - foo structure
 *
 * top-level blabla
 */
struct foo {
/**
 * @bar:
 *
 * Long text (with paragraphs) explaining bar.
 */
};

Otherwise this looks really tidy and I really like how this allows us to
get rid of the intel_read_wake hack.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index bec443a..ed07f0a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -835,7 +835,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   last_status = status;
>   }
>  
> - ret = -EBUSY;
> + ret = -EAGAIN;
>   goto out;
>   }
>  
> @@ -890,7 +890,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  
>   if ((status & DP_AUX_CH_CTL_DONE) == 0) {
>   DRM_ERROR("dp_aux_ch not done status 0x%08x\n", status);
> - ret = -EBUSY;
> + ret = -EAGAIN;
>   goto out;
>   }
>  
> -- 
> 2.4.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH v2] drm/mm: rewrite drm_mm_for_each_hole

[Daniel Vetter]

On Sat, Nov 21, 2015 at 10:04:04PM +0800, Geliang Tang wrote:
> When backwards is 0, __drm_mm_for_each_hole is same as
> drm_mm_for_each_hole. So I rewrite drm_mm_for_each_hole
> by using __drm_mm_for_each_hole.
> 
> Signed-off-by: Geliang Tang 

Applied to drm-misc, thanks.
-Daniel

> ---
> Changes in v2:
>  - fix make htmldocs warning
> ---
>  include/drm/drm_mm.h | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
> index 0de6290..a58cc6c 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -180,6 +180,14 @@ static inline u64 drm_mm_hole_node_end(struct 
> drm_mm_node *hole_node)
>   &(mm)->head_node.node_list, \
>   node_list)
>  
> +#define __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, backwards) \
> + for (entry = list_entry((backwards) ? (mm)->hole_stack.prev : 
> (mm)->hole_stack.next, struct drm_mm_node, hole_stack); \
> +  >hole_stack != &(mm)->hole_stack ? \
> +  hole_start = drm_mm_hole_node_start(entry), \
> +  hole_end = drm_mm_hole_node_end(entry), \
> +  1 : 0; \
> +  entry = list_entry((backwards) ? entry->hole_stack.prev : 
> entry->hole_stack.next, struct drm_mm_node, hole_stack))
> +
>  /**
>   * drm_mm_for_each_hole - iterator to walk over all holes
>   * @entry: drm_mm_node used internally to track progress
> @@ -200,20 +208,7 @@ static inline u64 drm_mm_hole_node_end(struct 
> drm_mm_node *hole_node)
>   * going backwards.
>   */
>  #define drm_mm_for_each_hole(entry, mm, hole_start, hole_end) \
> - for (entry = list_entry((mm)->hole_stack.next, struct drm_mm_node, 
> hole_stack); \
> -  >hole_stack != &(mm)->hole_stack ? \
> -  hole_start = drm_mm_hole_node_start(entry), \
> -  hole_end = drm_mm_hole_node_end(entry), \
> -  1 : 0; \
> -  entry = list_entry(entry->hole_stack.next, struct drm_mm_node, 
> hole_stack))
> -
> -#define __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, backwards) \
> - for (entry = list_entry((backwards) ? (mm)->hole_stack.prev : 
> (mm)->hole_stack.next, struct drm_mm_node, hole_stack); \
> -  >hole_stack != &(mm)->hole_stack ? \
> -  hole_start = drm_mm_hole_node_start(entry), \
> -  hole_end = drm_mm_hole_node_end(entry), \
> -  1 : 0; \
> -  entry = list_entry((backwards) ? entry->hole_stack.prev : 
> entry->hole_stack.next, struct drm_mm_node, hole_stack))
> + __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, 0)
>  
>  /*
>   * Basic range manager support (drm_mm.c)
> -- 
> 2.5.0
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 00/29] dev->struct_mutex crusade, once more

[Daniel Vetter]

Hi all,

Since Daniel Stone pointed out in the last round that I fumbled one locked vs.
unlocked case I audited all the drivers once more and uprooted a bunch more
offenders. They're mostly in error paths, but in case anyone wants to pick them
up I put them at the beginning of the patch series.

Again review, comments and acks highly welcome. I'd like to get this all in for
4.5 if possible, and will send out a pull request to Dave with the leftovers.

Cheers, Daniel

Daniel Vetter (29):
  drm/armada: Use unlocked gem unreferencing
  drm/nouveau: Use unlocked gem unreferencing
  drm/omapdrm: Use unlocked gem unreferencing
  drm/amdgpu: Use unlocked gem unreferencing
  drm/radeon: Use unlocked gem unreferencing
  drm/qxl: Use unlocked gem unreferencing
  drm/tegra: Use unlocked gem unreferencing
  drm/msm: Use unlocked gem unreferencing
  drm/udl: Use unlocked gem unreferencing
  drm/armada: Plug leak in dumb_map_offset
  drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/armada: Drop struct_mutex from cursor paths
  drm/armada: Use a private mutex to protect priv->linear
  drm/tegra: don't take dev->struct_mutex in mmap offset ioctl
  drm/tegra: Use drm_gem_object_unreference_unlocked
  drm/gma500: Use correct unref in the gem bo create function
  drm/gma500: Drop dev->struct_mutex from modeset code
  drm/gma500: Drop dev->struct_mutex from fbdev init/teardown code
  drm/gma500: Drop dev->struct_mutex from mmap offset function
  drm/gma500: Add driver private mutex for the fault handler
  drm/nouveau: Drop dev->struct_mutex from fbdev init
  drm/exynos: Drop dev->struct_mutex from mmap offset function
  drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma
  drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl
  drm/exynos: drop struct_mutex from fbdev setup
  drm/vgem: Simplify dum_map
  drm/vgem: Move get_pages to gem_create
  drm/vgem: Drop dev->struct_mutex
  drm/vma_manage: Drop has_offset

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  2 +-
 drivers/gpu/drm/armada/armada_crtc.c  |  8 ++-
 drivers/gpu/drm/armada/armada_debugfs.c   |  4 ++--
 drivers/gpu/drm/armada/armada_drm.h   |  3 ++-
 drivers/gpu/drm/armada/armada_drv.c   |  1 +
 drivers/gpu/drm/armada/armada_gem.c   | 25 ++---
 drivers/gpu/drm/drm_gem.c | 17 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 19 +++-
 drivers/gpu/drm/gma500/framebuffer.c  | 12 ++-
 drivers/gpu/drm/gma500/gem.c  | 19 ++--
 drivers/gpu/drm/gma500/gma_display.c  | 13 +++
 drivers/gpu/drm/gma500/gtt.c  |  1 +
 drivers/gpu/drm/gma500/psb_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_gem.c   |  3 ---
 drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  5 -
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  2 +-
 drivers/gpu/drm/qxl/qxl_fb.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_fb.c|  2 +-
 drivers/gpu/drm/tegra/drm.c   | 14 ++--
 drivers/gpu/drm/tegra/gem.c   | 13 ++-
 drivers/gpu/drm/udl/udl_fb.c  |  2 +-
 drivers/gpu/drm/udl/udl_gem.c |  2 +-
 drivers/gpu/drm/vgem/vgem_drv.c   | 36 ++-
 include/drm/drm_vma_manager.h | 15 +
 27 files changed, 89 insertions(+), 161 deletions(-)

-- 
2.5.1

[PATCH 01/29] drm/armada: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_crtc.c | 2 +-
 drivers/gpu/drm/armada/armada_gem.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index cebcab560626..7ea35bee7cd5 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -972,7 +972,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
struct armada_private *priv = crtc->dev->dev_private;

if (dcrtc->cursor_obj)
-   drm_gem_object_unreference(>cursor_obj->obj);
+   drm_gem_object_unreference_unlocked(>cursor_obj->obj);

priv->dcrtc[dcrtc->num] = NULL;
drm_crtc_cleanup(>crtc);
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 60a688ef81c7..aaf88641bfc5 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -352,13 +352,13 @@ int armada_gem_mmap_ioctl(struct drm_device *dev, void 
*data,
return -ENOENT;

if (!dobj->obj.filp) {
-   drm_gem_object_unreference(>obj);
+   drm_gem_object_unreference_unlocked(>obj);
return -EINVAL;
}

addr = vm_mmap(dobj->obj.filp, 0, args->size, PROT_READ | PROT_WRITE,
   MAP_SHARED, args->offset);
-   drm_gem_object_unreference(>obj);
+   drm_gem_object_unreference_unlocked(>obj);
if (IS_ERR_VALUE(addr))
return addr;

-- 
2.5.1

[PATCH 02/29] drm/nouveau: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 025504911b39..62633b110d70 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -295,7 +295,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
 err:
kfree(nouveau_fb);
 err_unref:
-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);
return ERR_PTR(ret);
 }

-- 
2.5.1

[PATCH 03/29] drm/omapdrm: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Tomi Valkeinen 
Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..c59090e8d23f 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -156,7 +156,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
/* note: if fb creation failed, we can't rely on fb destroy
 * to unref the bo:
 */
-   drm_gem_object_unreference(fbdev->bo);
+   drm_gem_object_unreference_unlocked(fbdev->bo);
ret = PTR_ERR(fb);
goto fail;
}
-- 
2.5.1

[PATCH 04/29] drm/amdgpu: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 6fcbbcc2e99e..cfb6caad2a73 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -263,7 +263,7 @@ out_unref:

}
if (fb && ret) {
-   drm_gem_object_unreference(gobj);
+   drm_gem_object_unreference_unlocked(gobj);
drm_framebuffer_unregister_private(fb);
drm_framebuffer_cleanup(fb);
kfree(fb);
-- 
2.5.1

[PATCH 05/29] drm/radeon: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index adc44bbc81a9..d2e628eea53d 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -282,7 +282,7 @@ out_unref:

}
if (fb && ret) {
-   drm_gem_object_unreference(gobj);
+   drm_gem_object_unreference_unlocked(gobj);
drm_framebuffer_unregister_private(fb);
drm_framebuffer_cleanup(fb);
kfree(fb);
-- 
2.5.1

[PATCH 06/29] drm/qxl: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 7136e521e6db..bb7ce07b788b 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -443,11 +443,11 @@ out_unref:
}
}
if (fb && ret) {
-   drm_gem_object_unreference(gobj);
+   drm_gem_object_unreference_unlocked(gobj);
drm_framebuffer_cleanup(fb);
kfree(fb);
}
-   drm_gem_object_unreference(gobj);
+   drm_gem_object_unreference_unlocked(gobj);
return ret;
 }

-- 
2.5.1

[PATCH 07/29] drm/tegra: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e0f827790a5e..3479c57151af 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -473,7 +473,7 @@ static int tegra_gem_mmap(struct drm_device *drm, void 
*data,

args->offset = drm_vma_node_offset_addr(>gem.vma_node);

-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
@@ -683,7 +683,7 @@ static int tegra_gem_set_tiling(struct drm_device *drm, 
void *data,
bo->tiling.mode = mode;
bo->tiling.value = value;

-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
@@ -723,7 +723,7 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
void *data,
break;
}

-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);

return err;
 }
@@ -748,7 +748,7 @@ static int tegra_gem_set_flags(struct drm_device *drm, void 
*data,
if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
bo->flags |= TEGRA_BO_BOTTOM_UP;

-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
@@ -770,7 +770,7 @@ static int tegra_gem_get_flags(struct drm_device *drm, void 
*data,
if (bo->flags & TEGRA_BO_BOTTOM_UP)
args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;

-   drm_gem_object_unreference(gem);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
-- 
2.5.1

[PATCH 08/29] drm/msm: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index 3f6ec077b51d..d95af6eba602 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -121,7 +121,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
/* note: if fb creation failed, we can't rely on fb destroy
 * to unref the bo:
 */
-   drm_gem_object_unreference(fbdev->bo);
+   drm_gem_object_unreference_unlocked(fbdev->bo);
ret = PTR_ERR(fb);
goto fail;
}
-- 
2.5.1

[PATCH 09/29] drm/udl: Use unlocked gem unreferencing

[Daniel Vetter]

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter 
Date:   Thu Oct 15 09:36:25 2015 +0200

drm/gem: Check locking in drm_gem_object_unreference

Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/udl/udl_fb.c  | 2 +-
 drivers/gpu/drm/udl/udl_gem.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 200419d4d43c..18a2acbccb7d 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -538,7 +538,7 @@ static int udlfb_create(struct drm_fb_helper *helper,
 out_destroy_fbi:
drm_fb_helper_release_fbi(helper);
 out_gfree:
-   drm_gem_object_unreference(>ufb.obj->base);
+   drm_gem_object_unreference_unlocked(>ufb.obj->base);
 out:
return ret;
 }
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 2a0a784ab6ee..d7528e0d8442 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -52,7 +52,7 @@ udl_gem_create(struct drm_file *file,
return ret;
}

-   drm_gem_object_unreference(>base);
+   drm_gem_object_unreference_unlocked(>base);
*handle_p = handle;
return 0;
 }
-- 
2.5.1

[PATCH 10/29] drm/armada: Plug leak in dumb_map_offset

[Daniel Vetter]

We need to drop the gem bo reference if it's an imported one.

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index aaf88641bfc5..2a3ef7938f30 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -285,7 +285,7 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
/* Don't allow imported objects to be mapped */
if (obj->obj.import_attach) {
ret = -EINVAL;
-   goto err_unlock;
+   goto err_unref;
}

ret = drm_gem_create_mmap_offset(>obj);
@@ -294,6 +294,7 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
DRM_DEBUG_DRIVER("handle %#x offset %llx\n", handle, *offset);
}

+ err_unref:
drm_gem_object_unreference(>obj);
  err_unlock:
mutex_unlock(>struct_mutex);
-- 
2.5.1

[PATCH 11/29] drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl

[Daniel Vetter]

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

v2: Split out the leak fix in dump_map_offset into a separate patch as
requested by Russell. Also align labels the same way as before to
stick with local coding style.

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_gem.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 2a3ef7938f30..e3a86b96af2a 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -274,12 +274,10 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
struct armada_gem_object *obj;
int ret = 0;

-   mutex_lock(>struct_mutex);
obj = armada_gem_object_lookup(dev, file, handle);
if (!obj) {
DRM_ERROR("failed to lookup gem object\n");
-   ret = -EINVAL;
-   goto err_unlock;
+   return -EINVAL;
}

/* Don't allow imported objects to be mapped */
@@ -295,9 +293,7 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
}

  err_unref:
-   drm_gem_object_unreference(>obj);
- err_unlock:
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(>obj);

return ret;
 }
-- 
2.5.1

[PATCH 12/29] drm/armada: Drop struct_mutex from cursor paths

[Daniel Vetter]

The kms state itself is already protected by the modeset locks
acquired by the drm core. The only thing left is gem bo state, and
since the cursor code expects small objects which are statically
mapped at create time and then invariant over the lifetime of the gem
bo there's nothing to protect.

See armada_gem_dumb_create -> armada_gem_linear_back which assigns
obj->addr which is the only thing used by the cursor code.

Only tricky bit is to switch to the _unlocked unreference function.

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_crtc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 7ea35bee7cd5..4bd1ce75a9f7 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -928,11 +928,10 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc 
*crtc,
}
}

-   mutex_lock(>struct_mutex);
if (dcrtc->cursor_obj) {
dcrtc->cursor_obj->update = NULL;
dcrtc->cursor_obj->update_data = NULL;
-   drm_gem_object_unreference(>cursor_obj->obj);
+   drm_gem_object_unreference_unlocked(>cursor_obj->obj);
}
dcrtc->cursor_obj = obj;
dcrtc->cursor_w = w;
@@ -942,7 +941,6 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc *crtc,
obj->update_data = dcrtc;
obj->update = cursor_update;
}
-   mutex_unlock(>struct_mutex);

return ret;
 }
@@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc 
*crtc, int x, int y)
if (!dcrtc->variant->has_spu_adv_reg)
return -EFAULT;

-   mutex_lock(>struct_mutex);
dcrtc->cursor_x = x;
dcrtc->cursor_y = y;
ret = armada_drm_crtc_cursor_update(dcrtc, false);
-   mutex_unlock(>struct_mutex);

return ret;
 }
-- 
2.5.1

[PATCH 13/29] drm/armada: Use a private mutex to protect priv->linear

[Daniel Vetter]

Reusing the Big DRM Lock just leaks, and the few things left that
dev->struct_mutex protected are very well contained - it's just the
linear drm_mm manager.

With this armada is completely struct_mutex free!

Cc: Russell King 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_debugfs.c |  4 ++--
 drivers/gpu/drm/armada/armada_drm.h |  3 ++-
 drivers/gpu/drm/armada/armada_drv.c |  1 +
 drivers/gpu/drm/armada/armada_gem.c | 10 +-
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_debugfs.c 
b/drivers/gpu/drm/armada/armada_debugfs.c
index 471e45627f1e..d4f7ab0a30d4 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -21,9 +21,9 @@ static int armada_debugfs_gem_linear_show(struct seq_file *m, 
void *data)
struct armada_private *priv = dev->dev_private;
int ret;

-   mutex_lock(>struct_mutex);
+   mutex_lock(>linear_lock);
ret = drm_mm_dump_table(m, >linear);
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>linear_lock);

return ret;
 }
diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index 4df6f2af2b21..6d2d8be38297 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -57,7 +57,8 @@ struct armada_private {
DECLARE_KFIFO(fb_unref, struct drm_framebuffer *, 8);
struct drm_fb_helper*fbdev;
struct armada_crtc  *dcrtc[2];
-   struct drm_mm   linear;
+   struct drm_mm   linear; /* protectec by linear_lock */
+   struct mutexlinear_lock;
struct drm_property *csc_yuv_prop;
struct drm_property *csc_rgb_prop;
struct drm_property *colorkey_prop;
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 77ab93d60125..3bd7e1cde99e 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -102,6 +102,7 @@ static int armada_drm_load(struct drm_device *dev, unsigned 
long flags)
dev->mode_config.preferred_depth = 24;
dev->mode_config.funcs = _drm_mode_config_funcs;
drm_mm_init(>linear, mem->start, resource_size(mem));
+   mutex_init(>linear_lock);

ret = component_bind_all(dev->dev, dev);
if (ret)
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index e3a86b96af2a..a43690ab18b9 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -46,7 +46,7 @@ static size_t roundup_gem_size(size_t size)
return roundup(size, PAGE_SIZE);
 }

-/* dev->struct_mutex is held here */
+/* dev_priv->linear_lock is held here */
 void armada_gem_free_object(struct drm_gem_object *obj)
 {
struct armada_gem_object *dobj = drm_to_armada_gem(obj);
@@ -144,10 +144,10 @@ armada_gem_linear_back(struct drm_device *dev, struct 
armada_gem_object *obj)
if (!node)
return -ENOSPC;

-   mutex_lock(>struct_mutex);
+   mutex_lock(>linear_lock);
ret = drm_mm_insert_node(>linear, node, size, align,
 DRM_MM_SEARCH_DEFAULT);
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>linear_lock);
if (ret) {
kfree(node);
return ret;
@@ -158,9 +158,9 @@ armada_gem_linear_back(struct drm_device *dev, struct 
armada_gem_object *obj)
/* Ensure that the memory we're returning is cleared. */
ptr = ioremap_wc(obj->linear->start, size);
if (!ptr) {
-   mutex_lock(>struct_mutex);
+   mutex_lock(>linear_lock);
drm_mm_remove_node(obj->linear);
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>linear_lock);
kfree(obj->linear);
obj->linear = NULL;
return -ENOMEM;
-- 
2.5.1

[PATCH 14/29] drm/tegra: don't take dev->struct_mutex in mmap offset ioctl

[Daniel Vetter]

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

v2: Finally get rid of the copypasta from another commit in this
commit message. And convert to _unlocked like we need to (Patrik).

Cc: Patrik Jakobsson 
Cc: Thierry Reding 
Acked-by: Thierry Reding 
Reviewed-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/gem.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 01e16e146bfe..fb712316c522 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -408,12 +408,9 @@ int tegra_bo_dumb_map_offset(struct drm_file *file, struct 
drm_device *drm,
struct drm_gem_object *gem;
struct tegra_bo *bo;

-   mutex_lock(>struct_mutex);
-
gem = drm_gem_object_lookup(drm, file, handle);
if (!gem) {
dev_err(drm->dev, "failed to lookup GEM object\n");
-   mutex_unlock(>struct_mutex);
return -EINVAL;
}

@@ -421,9 +418,7 @@ int tegra_bo_dumb_map_offset(struct drm_file *file, struct 
drm_device *drm,

*offset = drm_vma_node_offset_addr(>gem.vma_node);

-   drm_gem_object_unreference(gem);
-
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(gem);

return 0;
 }
-- 
2.5.1

[PATCH 15/29] drm/tegra: Use drm_gem_object_unreference_unlocked

[Daniel Vetter]

This only grabs the mutex when really needed, but still has a
might-acquire lockdep check to make sure that's always possible.
With this patch tegra is officially struct_mutex free, yay!

v2: refernce_unlocked doesn't exist as kbuild spotted.

Cc: Thierry Reding 
Acked-by: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 4 +---
 drivers/gpu/drm/tegra/gem.c | 6 +-
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3479c57151af..34d067b677bd 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -277,9 +277,7 @@ host1x_bo_lookup(struct drm_device *drm, struct drm_file 
*file, u32 handle)
if (!gem)
return NULL;

-   mutex_lock(>struct_mutex);
-   drm_gem_object_unreference(gem);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(gem);

bo = to_tegra_bo(gem);
return >base;
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index fb712316c522..fbec29516bcb 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -30,9 +30,7 @@ static void tegra_bo_put(struct host1x_bo *bo)
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
struct drm_device *drm = obj->gem.dev;

-   mutex_lock(>struct_mutex);
-   drm_gem_object_unreference(>gem);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(>gem);
 }

 static dma_addr_t tegra_bo_pin(struct host1x_bo *bo, struct sg_table **sgt)
@@ -74,9 +72,7 @@ static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
struct drm_device *drm = obj->gem.dev;

-   mutex_lock(>struct_mutex);
drm_gem_object_reference(>gem);
-   mutex_unlock(>struct_mutex);

return bo;
 }
-- 
2.5.1

[PATCH 16/29] drm/gma500: Use correct unref in the gem bo create function

[Daniel Vetter]

This is called without dev->struct_mutex held, we need to use the
_unlocked variant.

Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index c707fa6fca85..e3bdc8b1c32c 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -130,7 +130,7 @@ int psb_gem_create(struct drm_file *file, struct drm_device 
*dev, u64 size,
return ret;
}
/* We have the initial and handle reference but need only one now */
-   drm_gem_object_unreference(>gem);
+   drm_gem_object_unreference_unlocked(>gem);
*handlep = handle;
return 0;
 }
-- 
2.5.1

[PATCH 17/29] drm/gma500: Drop dev->struct_mutex from modeset code

[Daniel Vetter]

It's either init code or already protected by other means. Note
that psb_gtt_pin/unpin has it's own lock, and that's really the
only piece of driver private state - all the modeset state is
protected with modeset locks already.

The only important bit is to switch all gem_obj_unref calls to the
_unlocked variant.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gma_display.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gma_display.c 
b/drivers/gpu/drm/gma500/gma_display.c
index 001b450b27b3..ff17af4cfc64 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -349,8 +349,6 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
/* If we didn't get a handle then turn the cursor off */
if (!handle) {
temp = CURSOR_MODE_DISABLE;
-   mutex_lock(>struct_mutex);
-
if (gma_power_begin(dev, false)) {
REG_WRITE(control, temp);
REG_WRITE(base, 0);
@@ -362,11 +360,9 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
gt = container_of(gma_crtc->cursor_obj,
  struct gtt_range, gem);
psb_gtt_unpin(gt);
-   drm_gem_object_unreference(gma_crtc->cursor_obj);
+   
drm_gem_object_unreference_unlocked(gma_crtc->cursor_obj);
gma_crtc->cursor_obj = NULL;
}
-
-   mutex_unlock(>struct_mutex);
return 0;
}

@@ -376,7 +372,6 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
return -EINVAL;
}

-   mutex_lock(>struct_mutex);
obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj) {
ret = -ENOENT;
@@ -441,17 +436,15 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
if (gma_crtc->cursor_obj) {
gt = container_of(gma_crtc->cursor_obj, struct gtt_range, gem);
psb_gtt_unpin(gt);
-   drm_gem_object_unreference(gma_crtc->cursor_obj);
+   drm_gem_object_unreference_unlocked(gma_crtc->cursor_obj);
}

gma_crtc->cursor_obj = obj;
 unlock:
-   mutex_unlock(>struct_mutex);
return ret;

 unref_cursor:
-   drm_gem_object_unreference(obj);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);
return ret;
 }

-- 
2.5.1

[PATCH 18/29] drm/gma500: Drop dev->struct_mutex from fbdev init/teardown code

[Daniel Vetter]

This is init/teardown code, locking is just to appease locking checks.
And since gem create/free doesn't need this any more there's really no
reason for grabbing dev->struct_mutex.

Again important to switch obj_unref to _unlocked variants.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/framebuffer.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index dc0508dca1d4..ee95c03a8c54 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -406,8 +406,6 @@ static int psbfb_create(struct psb_fbdev *fbdev,

memset(dev_priv->vram_addr + backing->offset, 0, size);

-   mutex_lock(>struct_mutex);
-
info = drm_fb_helper_alloc_fbi(>psb_fb_helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
@@ -463,17 +461,15 @@ static int psbfb_create(struct psb_fbdev *fbdev,
dev_dbg(dev->dev, "allocated %dx%d fb\n",
psbfb->base.width, psbfb->base.height);

-   mutex_unlock(>struct_mutex);
return 0;
 out_unref:
if (backing->stolen)
psb_gtt_free_range(dev, backing);
else
-   drm_gem_object_unreference(>gem);
+   drm_gem_object_unreference_unlocked(>gem);

drm_fb_helper_release_fbi(>psb_fb_helper);
 out_err1:
-   mutex_unlock(>struct_mutex);
psb_gtt_free_range(dev, backing);
return ret;
 }
@@ -569,7 +565,7 @@ static int psb_fbdev_destroy(struct drm_device *dev, struct 
psb_fbdev *fbdev)
drm_framebuffer_cleanup(>base);

if (psbfb->gtt)
-   drm_gem_object_unreference(>gtt->gem);
+   drm_gem_object_unreference_unlocked(>gtt->gem);
return 0;
 }

@@ -784,12 +780,8 @@ void psb_modeset_cleanup(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
if (dev_priv->modeset) {
-   mutex_lock(>struct_mutex);
-
drm_kms_helper_poll_fini(dev);
psb_fbdev_fini(dev);
drm_mode_config_cleanup(dev);
-
-   mutex_unlock(>struct_mutex);
}
 }
-- 
2.5.1

[PATCH 19/29] drm/gma500: Drop dev->struct_mutex from mmap offset function

[Daniel Vetter]

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gem.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index e3bdc8b1c32c..f0357f525f56 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -62,15 +62,10 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,
int ret = 0;
struct drm_gem_object *obj;

-   mutex_lock(>struct_mutex);
-
/* GEM does all our handle to object mapping */
obj = drm_gem_object_lookup(dev, file, handle);
-   if (obj == NULL) {
-   ret = -ENOENT;
-   goto unlock;
-   }
-   /* What validation is needed here ? */
+   if (obj == NULL)
+   return -ENOENT;

/* Make it mmapable */
ret = drm_gem_create_mmap_offset(obj);
@@ -78,9 +73,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,
goto out;
*offset = drm_vma_node_offset_addr(>vma_node);
 out:
-   drm_gem_object_unreference(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);
return ret;
 }

-- 
2.5.1

[PATCH 20/29] drm/gma500: Add driver private mutex for the fault handler

[Daniel Vetter]

There's currently two places where the gma500 fault handler relies
upon dev->struct_mutex:
- To protect r->mappping
- To make sure vm_insert_pfn isn't called concurrently (in which case
  the 2nd thread would get an error code).

Everything else (specifically psb_gtt_pin) is already protected by
some other locks. Hence just create a new driver-private mmap_mutex
just for this function.

With this gma500 is complete dev->struct_mutex free!

Cc: Patrik Jakobsson 
Acked-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/gem.c | 4 ++--
 drivers/gpu/drm/gma500/gtt.c | 1 +
 drivers/gpu/drm/gma500/psb_drv.h | 2 ++
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index f0357f525f56..506224b3a0ad 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -182,7 +182,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)

/* Make sure we don't parallel update on a fault, nor move or remove
   something from beneath our feet */
-   mutex_lock(>struct_mutex);
+   mutex_lock(_priv->mmap_mutex);

/* For now the mmap pins the object and it stays pinned. As things
   stand that will do us no harm */
@@ -208,7 +208,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);

 fail:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(_priv->mmap_mutex);
switch (ret) {
case 0:
case -ERESTARTSYS:
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index ce015db59dc6..8f69225ce2b4 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -425,6 +425,7 @@ int psb_gtt_init(struct drm_device *dev, int resume)

if (!resume) {
mutex_init(_priv->gtt_mutex);
+   mutex_init(_priv->mmap_mutex);
psb_gtt_alloc(dev);
}

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e21726ecac32..3bd2c726dd61 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -465,6 +465,8 @@ struct drm_psb_private {
struct mutex gtt_mutex;
struct resource *gtt_mem;   /* Our PCI resource */

+   struct mutex mmap_mutex;
+
struct psb_mmu_driver *mmu;
struct psb_mmu_pd *pf_pd;

-- 
2.5.1

[PATCH 21/29] drm/nouveau: Drop dev->struct_mutex from fbdev init

[Daniel Vetter]

Doesn't protect anything at all.

With this patch nouveau is completely dev->struct_mutex free!

Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 59f27e774acb..3bae706126bd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -386,8 +386,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
}
}

-   mutex_lock(>struct_mutex);
-
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
@@ -426,8 +424,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,

/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */

-   mutex_unlock(>struct_mutex);
-
if (chan)
nouveau_fbcon_accel_init(dev);
nouveau_fbcon_zfill(dev, fbcon);
@@ -441,7 +437,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
return 0;

 out_unlock:
-   mutex_unlock(>struct_mutex);
if (chan)
nouveau_bo_vma_del(nvbo, >nouveau_fb.vma);
nouveau_bo_unmap(nvbo);
-- 
2.5.1

[PATCH 23/29] drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma

[Daniel Vetter]

The sg table isn't refcounted, there's no corresponding locking for
unmapping and drm_map_sg is ok with being called concurrently.

So drop the locking since it doesn't protect anything.

Cc: Inki Dae 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 44e710ab84de..b198fa560106 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -378,16 +378,12 @@ int exynos_gem_map_sgt_with_dma(struct drm_device 
*drm_dev,
 {
int nents;

-   mutex_lock(_dev->struct_mutex);
-
nents = dma_map_sg(drm_dev->dev, sgt->sgl, sgt->nents, dir);
if (!nents) {
DRM_ERROR("failed to map sgl with dma.\n");
-   mutex_unlock(_dev->struct_mutex);
return nents;
}

-   mutex_unlock(_dev->struct_mutex);
return 0;
 }

-- 
2.5.1

[PATCH 24/29] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

[Daniel Vetter]

The only things this protects is reading ->flags and ->size, both of
which are invariant over the lifetime of an exynos gem bo. So no
locking needed at all (besides that, nothing protects the writers
anyway).

Aside: exynos_gem_obj->size is redundant with
exynos_gem_obj->base.size and probably should be removed.

v2: Use _unlocked unreference (Daniel Stone).

Cc: Daniel Stone 
Cc: Inki Dae 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index b198fa560106..e735827e0c6d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -352,12 +352,9 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void 
*data,
struct drm_exynos_gem_info *args = data;
struct drm_gem_object *obj;

-   mutex_lock(>struct_mutex);
-
obj = drm_gem_object_lookup(dev, file_priv, args->handle);
if (!obj) {
DRM_ERROR("failed to lookup gem object.\n");
-   mutex_unlock(>struct_mutex);
return -EINVAL;
}

@@ -366,8 +363,7 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void 
*data,
args->flags = exynos_gem->flags;
args->size = exynos_gem->size;

-   drm_gem_object_unreference(obj);
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);

return 0;
 }
-- 
2.5.1

[PATCH 25/29] drm/exynos: drop struct_mutex from fbdev setup

[Daniel Vetter]

Doesn't protect anything at all, and probably just here because a long
time ago dev->struct_mutex was required to allocate gem objects.

With this patch exynos is completely struct_mutex free!

Cc: Inki Dae 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f6118baa8e3e..e1f7abaa61df 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -138,8 +138,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
  sizes->surface_depth);

-   mutex_lock(>struct_mutex);
-
size = mode_cmd.pitches[0] * mode_cmd.height;

exynos_gem = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
@@ -154,10 +152,8 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
   size);
}

-   if (IS_ERR(exynos_gem)) {
-   ret = PTR_ERR(exynos_gem);
-   goto out;
-   }
+   if (IS_ERR(exynos_gem))
+   return PTR_ERR(exynos_gem);

exynos_fbdev->exynos_gem = exynos_gem;

@@ -173,7 +169,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
if (ret < 0)
goto err_destroy_framebuffer;

-   mutex_unlock(>struct_mutex);
return ret;

 err_destroy_framebuffer:
@@ -181,13 +176,12 @@ err_destroy_framebuffer:
 err_destroy_gem:
exynos_drm_gem_destroy(exynos_gem);

-/*
- * if failed, all resources allocated above would be released by
- * drm_mode_config_cleanup() when drm_load() had been called prior
- * to any specific driver such as fimd or hdmi driver.
- */
-out:
-   mutex_unlock(>struct_mutex);
+   /*
+* if failed, all resources allocated above would be released by
+* drm_mode_config_cleanup() when drm_load() had been called prior
+* to any specific driver such as fimd or hdmi driver.
+*/
+
return ret;
 }

-- 
2.5.1

[PATCH 22/29] drm/exynos: Drop dev->struct_mutex from mmap offset function

[Daniel Vetter]

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Aside: DRM_ERROR for userspace controlled input isn't great, but
that's for another patch.

v2: Use _unlocked unreference (Daniel Stone).

Cc: Daniel Stone 
Cc: Inki Dae 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 252eb301470c..44e710ab84de 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -448,8 +448,6 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
struct drm_gem_object *obj;
int ret = 0;

-   mutex_lock(>struct_mutex);
-
/*
 * get offset of memory allocated for drm framebuffer.
 * - this callback would be called by user application
@@ -459,16 +457,13 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj) {
DRM_ERROR("failed to lookup gem object.\n");
-   ret = -EINVAL;
-   goto unlock;
+   return -EINVAL;
}

*offset = drm_vma_node_offset_addr(>vma_node);
DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);

-   drm_gem_object_unreference(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);
return ret;
 }

-- 
2.5.1

[PATCH 26/29] drm/vgem: Simplify dum_map

[Daniel Vetter]

The offset manager already checks for existing offsets internally,
while holding suitable locks. We can drop this check.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 02ae60c395b7..63026d4324ad 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -208,11 +208,9 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
goto unlock;
}

-   if (!drm_vma_node_has_offset(>vma_node)) {
-   ret = drm_gem_create_mmap_offset(obj);
-   if (ret)
-   goto unref;
-   }
+   ret = drm_gem_create_mmap_offset(obj);
+   if (ret)
+   goto unref;

BUG_ON(!obj->filp);

-- 
2.5.1

[PATCH 28/29] drm/vgem: Drop dev->struct_mutex

[Daniel Vetter]

With the previous two changes it doesn't protect anything any more.

v2: Use _unlocked unreference variant.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 1a609347236b..807a24d3c0a8 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -103,12 +103,8 @@ static int vgem_gem_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
if (page_offset > num_pages)
return VM_FAULT_SIGBUS;

-   mutex_lock(>struct_mutex);
-
ret = vm_insert_page(vma, (unsigned long)vmf->virtual_address,
 obj->pages[page_offset]);
-
-   mutex_unlock(>struct_mutex);
switch (ret) {
case 0:
return VM_FAULT_NOPAGE;
@@ -205,12 +201,9 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
int ret = 0;
struct drm_gem_object *obj;

-   mutex_lock(>struct_mutex);
obj = drm_gem_object_lookup(dev, file, handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;

ret = drm_gem_create_mmap_offset(obj);
if (ret)
@@ -223,9 +216,8 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
*offset = drm_vma_node_offset_addr(>vma_node);

 unref:
-   drm_gem_object_unreference(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   drm_gem_object_unreference_unlocked(obj);
+
return ret;
 }

-- 
2.5.1

[PATCH 29/29] drm/vma_manage: Drop has_offset

[Daniel Vetter]

It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.

The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.

While at it add a note in the create_mmap_offset kerneldoc that
drivers must release it again. And then I also noticed that
drm_gem_object_release entirely lacks kerneldoc.

Cc: David Herrmann 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c   | 17 +
 drivers/gpu/drm/i915/i915_gem.c |  3 ---
 include/drm/drm_vma_manager.h   | 15 +--
 3 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2e10bba4468b..5c5001171dd3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -392,6 +392,10 @@ EXPORT_SYMBOL(drm_gem_handle_create);
  * @obj: obj in question
  *
  * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ *
+ * Note that drm_gem_object_release() already calls this function, so drivers
+ * don't have to take care of releasing the mmap offset themselves when freeing
+ * the GEM object.
  */
 void
 drm_gem_free_mmap_offset(struct drm_gem_object *obj)
@@ -415,6 +419,9 @@ EXPORT_SYMBOL(drm_gem_free_mmap_offset);
  * This routine allocates and attaches a fake offset for @obj, in cases where
  * the virtual size differs from the physical size (ie. obj->size).  Otherwise
  * just use drm_gem_create_mmap_offset().
+ *
+ * This function is idempotent and handles an already allocated mmap offset
+ * transparently. Drivers do not need to check for this case.
  */
 int
 drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size)
@@ -436,6 +443,9 @@ EXPORT_SYMBOL(drm_gem_create_mmap_offset_size);
  * structures.
  *
  * This routine allocates and attaches a fake offset for @obj.
+ *
+ * Drivers can call drm_gem_free_mmap_offset() before freeing @obj to release
+ * the fake offset again.
  */
 int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
 {
@@ -754,6 +764,13 @@ drm_gem_release(struct drm_device *dev, struct drm_file 
*file_private)
idr_destroy(_private->object_idr);
 }

+/**
+ * drm_gem_object_release - release GEM buffer object resources
+ * @obj: GEM buffer object
+ *
+ * This releases any structures and resources used by @obj and is the invers of
+ * drm_gem_object_init().
+ */
 void
 drm_gem_object_release(struct drm_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33adc8f8ab20..f10a5d57377e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1972,9 +1972,6 @@ static int i915_gem_object_create_mmap_offset(struct 
drm_i915_gem_object *obj)
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
int ret;

-   if (drm_vma_node_has_offset(>base.vma_node))
-   return 0;
-
dev_priv->mm.shrinker_no_lock_stealing = true;

ret = drm_gem_create_mmap_offset(>base);
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 2f63dd5e05eb..06ea8e077ec2 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -176,19 +176,6 @@ static inline unsigned long drm_vma_node_size(struct 
drm_vma_offset_node *node)
 }

 /**
- * drm_vma_node_has_offset() - Check whether node is added to offset manager
- * @node: Node to be checked
- *
- * RETURNS:
- * true iff the node was previously allocated an offset and added to
- * an vma offset manager.
- */
-static inline bool drm_vma_node_has_offset(struct drm_vma_offset_node *node)
-{
-   return drm_mm_node_allocated(>vm_node);
-}
-
-/**
  * drm_vma_node_offset_addr() - Return sanitized offset for user-space mmaps
  * @node: Linked offset node
  *
@@ -220,7 +207,7 @@ static inline __u64 drm_vma_node_offset_addr(struct 
drm_vma_offset_node *node)
 static inline void drm_vma_node_unmap(struct drm_vma_offset_node *node,
  struct address_space *file_mapping)
 {
-   if (drm_vma_node_has_offset(node))
+   if (drm_mm_node_allocated(>vm_node))
unmap_mapping_range(file_mapping,
drm_vma_node_offset_addr(node),
drm_vma_node_size(node) << PAGE_SHIFT, 1);
-- 
2.5.1

[PATCH 27/29] drm/vgem: Move get_pages to gem_create

[Daniel Vetter]

vgem doesn't have a shrinker or anything like that and drops backing
storage only at object_free time. There's no use in trying to be
clever and allocating backing storage delayed, it only causes trouble
by requiring locking.

Instead grab pages when we allocate the object right away.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 63026d4324ad..1a609347236b 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -154,6 +154,10 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
if (err)
goto out;

+   ret = vgem_gem_get_pages(to_vgem_bo(obj));
+   if (ret)
+   goto out;
+
err = drm_gem_handle_create(file, gem_object, handle);
if (err)
goto handle_out;
@@ -216,16 +220,8 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,

obj->filp->private_data = obj;

-   ret = vgem_gem_get_pages(to_vgem_bo(obj));
-   if (ret)
-   goto fail_get_pages;
-
*offset = drm_vma_node_offset_addr(>vma_node);

-   goto unref;
-
-fail_get_pages:
-   drm_gem_free_mmap_offset(obj);
 unref:
drm_gem_object_unreference(obj);
 unlock:
-- 
2.5.1

[PATCH] v2: Also add a DRIVER_* check like for all other maps functions to really short-circuit the code. And give drm_legacy_rmmap used by the dev unregister code the same treatment.

[Daniel Vetter]

---
 drivers/gpu/drm/drm_bufs.c | 14 ++
 include/drm/drm_legacy.h   |  2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index de18b8b78a26..5a51633da033 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -542,15 +542,17 @@ int drm_legacy_rmmap_locked(struct drm_device *dev, 
struct drm_local_map *map)
 }
 EXPORT_SYMBOL(drm_legacy_rmmap_locked);

-int drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
+void drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
 {
-   int ret;
+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
+   drm_core_check_feature(dev, DRIVER_MODESET))
+   return;

mutex_lock(>struct_mutex);
-   ret = drm_legacy_rmmap_locked(dev, map);
+   drm_legacy_rmmap_locked(dev, map);
mutex_unlock(>struct_mutex);

-   return ret;
+   return;
 }
 EXPORT_SYMBOL(drm_legacy_rmmap);

@@ -558,6 +560,10 @@ void drm_legacy_master_rmmaps(struct drm_device *dev, 
struct drm_master *master)
 {
struct drm_map_list *r_list, *list_temp;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
+   drm_core_check_feature(dev, DRIVER_MODESET))
+   return;
+
mutex_lock(>struct_mutex);
list_for_each_entry_safe(r_list, list_temp, >maplist, head) {
if (r_list->master == master) {
diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
index 24504b0eafea..a5ef2c7e40f8 100644
--- a/include/drm/drm_legacy.h
+++ b/include/drm/drm_legacy.h
@@ -154,7 +154,7 @@ struct drm_map_list {
 int drm_legacy_addmap(struct drm_device *d, resource_size_t offset,
  unsigned int size, enum drm_map_type type,
  enum drm_map_flags flags, struct drm_local_map **map_p);
-int drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
+void drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
 int drm_legacy_rmmap_locked(struct drm_device *d, struct drm_local_map *map);
 void drm_legacy_master_rmmaps(struct drm_device *dev,
  struct drm_master *master);
-- 
2.5.1

[Intel-gfx] [PATCH 1/8] drm: Introduce EAGAIN handling for immediatelly aux retries

[Jani Nikula]

On Sat, 21 Nov 2015, Rodrigo Vivi  wrote:
> The goal here is to offload aux retries handling from the
> drivers to drm.
>
> However there are 2 differents cases for retry:
> 1. Immediately retry - Hardware already took care of needed timeouts
>  before answering that a retry is possible.
> 2. Busy - Wait some time and retry.
>
> This driver introduce the support for EAGAIN that can handle the
> first case and a following patch will introduce EBUSY waits,
> after all drivers counting on immediately retries are changed.
>
> Cc: Dave Airlie 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 9535c5b..ee7c955 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -198,6 +198,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   err = aux->transfer(aux, );
>   mutex_unlock(>hw_mutex);
>   if (err < 0) {
> + /* Immediately retry */
> + if (err == -EAGAIN)
> + continue;

How about the ->transfer call in drm_dp_i2c_do_msg? If we leave that for
the i2c layer (which does do retries on -EAGAIN, but also handles
timeouts for repeated -EAGAINs) it deserves a comment in in
drm_dp_i2c_do_msg.

BR,
Jani.

> +
> + /* FIXME: On BUSY we could wait before retrying */
>   if (err == -EBUSY)
>   continue;

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 3/8] drm/i915: Use EAGAIN instead EBUSY for aux retry.

[Jani Nikula]

On Mon, 23 Nov 2015, Daniel Vetter  wrote:
> On Fri, Nov 20, 2015 at 04:46:25PM -0800, Rodrigo Vivi wrote:
>> Current EBUSY meaning is immediately retry, but this is
>> about to change. DRM aux transfer is about to change and
>> make EAGAIN the immediately retry and use EBUSY to wait
>> a bit for aux channels to recover for any error or wake up.
>> 
>> This has no functional change if the EAGAIN support is in
>> place already for drm aux transfer.
>> 
>> Signed-off-by: Rodrigo Vivi 
>
> Please document the EAGAIN and EBUSY return codes for the ->transfer
> member fo drm_dp_aux in the kerneldoc properly. While at it would be great
> if you could document any other error codes that are treated specially for
> this function.

See my comment in reply to patch 1 about the difference in handling of
the ->transfer return values for native aux and i2c-over-aux.

BR,
Jani.

>
> Since this will be a bit more text please convert the kerneldoc to the new
> per-member comment layout that 4.4 supports, i.e.
>
> /**
>  * struct foo - foo structure
>  *
>  * top-level blabla
>  */
> struct foo {
>   /**
>* @bar:
>*
>* Long text (with paragraphs) explaining bar.
>*/
> };
>
> Otherwise this looks really tidy and I really like how this allows us to
> get rid of the intel_read_wake hack.
> -Daniel
>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index bec443a..ed07f0a 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -835,7 +835,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>>  last_status = status;
>>  }
>>  
>> -ret = -EBUSY;
>> +ret = -EAGAIN;
>>  goto out;
>>  }
>>  
>> @@ -890,7 +890,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>>  
>>  if ((status & DP_AUX_CH_CTL_DONE) == 0) {
>>  DRM_ERROR("dp_aux_ch not done status 0x%08x\n", status);
>> -ret = -EBUSY;
>> +ret = -EAGAIN;
>>  goto out;
>>  }
>>  
>> -- 
>> 2.4.3
>> 
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2 2/2] drm/rockchip: Convert the probe function to the generic drm_of_component_probe()

[Mark yao]

On 2015年11月20日 22:22, Liviu Dudau wrote:
> Initial attempt to convert rockchip to drm_of_component_probe() missed the
> difference between ports and encoders when using the compare_of() function.
> Now that drm_of_component_probe() has been enhanced, let's try again the
> conversion.
>
> Signed-off-by: Liviu Dudau

Looks good for me, and it works on popmetal board, so
  Acked-by: Mark Yao 

Thanks.

-- 
ï¼­ark Yao

[Intel-gfx] [PATCH 4/8] drm: Wait 1ms before retrying aux transactions on EBUSY.

[Jani Nikula]

On Sat, 21 Nov 2015, Rodrigo Vivi  wrote:
> DP Specs isn't really clear about the amount of retries,
> but for cases it mentions retries it also mention times that
> vary from 300us to 1ms.
>
> For many cases hardware can handled the timeouts before retry
> is possible and allowed, but for many other cases it is better
> to wait and give time so the aux channels can recover.
>
> For instance one general case there is when downstream device
> is waking up from sleep states generating HPD so it might take
> up to 1ms before getting responsive.
>
> I believe with this msleep we could minimize the 32 times retries
> and still let Dell monitors happy, but I don't have this monitor
> to test here so let's just add the sleep for now and still retry
> 32 times.
>
> Cc: Dave Airlie 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ee7c955..1d6016d 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -202,9 +202,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   if (err == -EAGAIN)
>   continue;
>  
> - /* FIXME: On BUSY we could wait before retrying */
> - if (err == -EBUSY)
> + /* Give a time for aux channels to recover */
> + if (err == -EBUSY) {
> + msleep(1);

usleep_range please; msleep(1) may take *much* longer than 1 ms, and
that could throw us off with our retry logic.

BR,
Jani.

>   continue;
> + }
>  
>   return err;
>   }

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 6/8] drm/i915: Remove remaining retries from intel_dp_aux_ch.

[Jani Nikula]

On Sat, 21 Nov 2015, Rodrigo Vivi  wrote:
> drm level already takes care of the needed retries so instead of
> duplicate the effort here.
>
> If the retry is possible immediately we return EAGAIN. Otherwise,
> if we have no idea what caused the error let's assume something
> was busy and let drm level handle the wait and retries.
>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 64 
> ++---
>  1 file changed, 35 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a8ba243..35048d6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -795,7 +795,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   uint32_t aux_clock_divider;
>   int i, ret, recv_bytes;
>   uint32_t status;
> - int try, clock = 0;
> + int clock = 0;
>   bool has_aux_irq = HAS_AUX_IRQ(dev);
>   bool vdd;
>  
> @@ -835,41 +835,47 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> send_bytes,
> aux_clock_divider);
>  
> - /* Must try at least 3 times according to DP spec */
> - for (try = 0; try < 5; try++) {

This now inverses the retries wrt the aux clock divider retries, which
probably breaks the non-ULT HSW workaround:

"WA: For the PCH Aux channels (Aux B/C/D) use an aux divider value of 63
decimal (03Fh). If there is a failure, retry at least three times with
63, then retry at least three times with 72 decimal (048h). See South
Display Engine Registers, DP_AUX_CTL."

It is sad.

BR,
Jani.


> - /* Load the send data into the aux channel data 
> registers */
> - for (i = 0; i < send_bytes; i += 4)
> - I915_WRITE(intel_dp->aux_ch_data_reg[i >> 2],
> -intel_dp_pack_aux(send + i,
> -  send_bytes - i));
> + /* Load the send data into the aux channel data registers */
> + for (i = 0; i < send_bytes; i += 4)
> + I915_WRITE(intel_dp->aux_ch_data_reg[i >> 2],
> +intel_dp_pack_aux(send + i,
> +  send_bytes - i));
>  
> - /* Send the command and wait for it to complete */
> - I915_WRITE(ch_ctl, send_ctl);
> + /* Send the command and wait for it to complete */
> + I915_WRITE(ch_ctl, send_ctl);
>  
> - status = intel_dp_aux_wait_done(intel_dp, has_aux_irq);
> + status = intel_dp_aux_wait_done(intel_dp, has_aux_irq);
>  
> - /* Clear done status and any errors */
> - I915_WRITE(ch_ctl,
> -status |
> -DP_AUX_CH_CTL_DONE |
> -DP_AUX_CH_CTL_TIME_OUT_ERROR |
> -DP_AUX_CH_CTL_RECEIVE_ERROR);
> + /* Clear done status and any errors */
> + I915_WRITE(ch_ctl,
> +status |
> +DP_AUX_CH_CTL_DONE |
> +DP_AUX_CH_CTL_TIME_OUT_ERROR |
> +DP_AUX_CH_CTL_RECEIVE_ERROR);
>  
> - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> - continue;
> + if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR) {
> + /*
> +  * DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
> +  * 400us delay required for errors and timeouts
> +  * Timeout errors from the HW already meet this
> +  * requirement so skip to next iteration
> +  */
> + ret = -EAGAIN;
> + goto out;
> + }
>  
> - /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
> -  *   400us delay required for errors and timeouts
> -  *   Timeout errors from the HW already meet this
> -  *   requirement so skip to next iteration
> + if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> + /*
> +  * We don't know what caused the error, so let's
> +  * return -EBUSY so drm level takes care of
> +  * the necessary wait for recover and retries
>*/
> - if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> - usleep_range(400, 500);
> - continue;
> - }
> - if (status & DP_AUX_CH_CTL_DONE)
> - goto done;
> + ret = -EBUSY;
> 

[PATCH 04/29] drm/amdgpu: Use unlocked gem unreferencing

[Christian König]

On 23.11.2015 10:32, Daniel Vetter wrote:
> For drm_gem_object_unreference callers are required to hold
> dev->struct_mutex, which these paths don't. Enforcing this requirement
> has become a bit more strict with
>
> commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
> Author: Daniel Vetter 
> Date:   Thu Oct 15 09:36:25 2015 +0200
>
>  drm/gem: Check locking in drm_gem_object_unreference
>
> Cc: Alex Deucher 
> Signed-off-by: Daniel Vetter 

For this and the radeon patch Reviewed-by: Christian König 


> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 6fcbbcc2e99e..cfb6caad2a73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -263,7 +263,7 @@ out_unref:
>   
>   }
>   if (fb && ret) {
> - drm_gem_object_unreference(gobj);
> + drm_gem_object_unreference_unlocked(gobj);
>   drm_framebuffer_unregister_private(fb);
>   drm_framebuffer_cleanup(fb);
>   kfree(fb);

[PATCH 7/8] drm/i915: Fix random aux transactions failures.

[Jani Nikula]

On Sat, 21 Nov 2015, Rodrigo Vivi  wrote:
> Mainly aux communications on sink_crc
> were failing a lot randomly on recent platforms.
> The first solution was to try to use intel_dp_dpcd_read_wake, but then
> it was suggested to move retries to drm level.
>
> Since drm level was already taking care of retries and didn't want
> to through random retries on that level the second solution was to
> put the retries at aux_transfer layer what was nacked.
>
> So I realized we had so many retries in different places and
> started to organize that a bit. During this organization I noticed
> that we weren't handing at all the case were the message size was
> zeroed. And this was exactly the case that was affecting sink_crc.
>
> Also we weren't respect BSPec who says this size message = 0 or > 20
> are forbidden.
>
> It is a fact that we still have no clue why we are getting this
> forbidden value there. But anyway we need to handle that for now
> so we return -EBUSY and drm level takes care of the retries that
> are already in place.
>
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 35048d6..c87e937 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -905,6 +905,17 @@ done:
>   /* Unload any bytes sent back from the other side */
>   recv_bytes = ((status & DP_AUX_CH_CTL_MESSAGE_SIZE_MASK) >>
> DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
> +
> + /*
> +  * By BSpec: "Message sizes of 0 or >20 are not allowed."
> +  * We have no idea of what happened so we return -EBUSY so
> +  * drm layer takes care for the necessary retries.
> +  */
> + if (recv_bytes == 0 || recv_bytes > 20) {
> + ret = -EBUSY;

This deserves debug logging at the very least.

BR,
Jani.


> + goto out;
> + }
> +
>   if (recv_bytes > recv_size)
>   recv_bytes = recv_size;

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 25/29] drm/exynos: drop struct_mutex from fbdev setup

[Daniel Stone]

Hi,

On 23 November 2015 at 09:32, Daniel Vetter  wrote:
> Doesn't protect anything at all, and probably just here because a long
> time ago dev->struct_mutex was required to allocate gem objects.
>
> With this patch exynos is completely struct_mutex free!
>
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Daniel Stone 

Cheers,
Daniel

[PATCH 22/29] drm/exynos: Drop dev->struct_mutex from mmap offset function

[Daniel Stone]

Hi,

On 23 November 2015 at 09:32, Daniel Vetter  wrote:
> Simply forgotten about this when I was doing my general cleansing of
> simple gem mmap offset functions. There's nothing but core functions
> called here, and they all have their own protection already.
>
> Aside: DRM_ERROR for userspace controlled input isn't great, but
> that's for another patch.
>
> v2: Use _unlocked unreference (Daniel Stone).
>
> Cc: Daniel Stone 
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Daniel Stone 

Cheers,
Daniel

[PATCH 24/29] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

[Daniel Stone]

Hi,

On 23 November 2015 at 09:32, Daniel Vetter  wrote:
> The only things this protects is reading ->flags and ->size, both of
> which are invariant over the lifetime of an exynos gem bo. So no
> locking needed at all (besides that, nothing protects the writers
> anyway).
>
> Aside: exynos_gem_obj->size is redundant with
> exynos_gem_obj->base.size and probably should be removed.
>
> v2: Use _unlocked unreference (Daniel Stone).
>
> Cc: Daniel Stone 
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Daniel Stone 

Cheers,
Daniel

[PATCH 07/29] drm/tegra: Use unlocked gem unreferencing

[Thierry Reding]

On Mon, Nov 23, 2015 at 10:32:40AM +0100, Daniel Vetter wrote:
> For drm_gem_object_unreference callers are required to hold
> dev->struct_mutex, which these paths don't. Enforcing this requirement
> has become a bit more strict with
> 
> commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
> Author: Daniel Vetter 
> Date:   Thu Oct 15 09:36:25 2015 +0200
> 
> drm/gem: Check locking in drm_gem_object_unreference
> 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/drm.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/3d5abad2/attachment.sig>

[PATCH 14/29] drm/tegra: don't take dev->struct_mutex in mmap offset ioctl

[Thierry Reding]

On Mon, Nov 23, 2015 at 10:32:47AM +0100, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm core still cares).
> 
> v2: Finally get rid of the copypasta from another commit in this
> commit message. And convert to _unlocked like we need to (Patrik).
> 
> Cc: Patrik Jakobsson 
> Cc: Thierry Reding 
> Acked-by: Thierry Reding 
> Reviewed-by: Patrik Jakobsson 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/gem.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/ef1ff25c/attachment.sig>

[PATCH 15/29] drm/tegra: Use drm_gem_object_unreference_unlocked

[Thierry Reding]

On Mon, Nov 23, 2015 at 10:32:48AM +0100, Daniel Vetter wrote:
> This only grabs the mutex when really needed, but still has a
> might-acquire lockdep check to make sure that's always possible.
> With this patch tegra is officially struct_mutex free, yay!
> 
> v2: refernce_unlocked doesn't exist as kbuild spotted.
> 
> Cc: Thierry Reding 
> Acked-by: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/drm.c | 4 +---
>  drivers/gpu/drm/tegra/gem.c | 6 +-
>  2 files changed, 2 insertions(+), 8 deletions(-)

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/47e04a6b/attachment.sig>

[PATCH 23/29] drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma

[Daniel Stone]

Hi,

On 23 November 2015 at 09:32, Daniel Vetter  wrote:
> The sg table isn't refcounted, there's no corresponding locking for
> unmapping and drm_map_sg is ok with being called concurrently.
>
> So drop the locking since it doesn't protect anything.
>
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Daniel Stone 

Cheers,
Daniel

[PATCH 7/8] drm/i915: Fix random aux transactions failures.

[Jani Nikula]

I don't see how the subject matches the commit.

On Sat, 21 Nov 2015, Rodrigo Vivi  wrote:
> This read wake with retries were initially added by 2 commits:
>
> commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure")
> commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times when 
> detecting")
>
> Both mentioning section 9.1 of the 1.1a DisplayPort spec, that actually
> tell us to retry three times on certain case when "writing 01h to DPCD 
> address 600h"
> and this code is already in place in our driver. Added by:
>
> commit c7ad3810 ("drm/i915/dp: manage sink power state if possible")

I still think what we currently do for the sink power state management
works by coincidence. We should still look into it.

However, I think this series overall (apart from patch 6/8 which really
is a bummer, the comment inline below, and the minor other comments)
looks like worthwhile changes. We can leave the power state management
for later. Or rip it out for now...

> At this point we have no visibility if those patches were added to workaround 
> certain
> corner cases like lazy dongles or what, but also at that time there wasn't 
> enough
> retries on the proper places.
>
> So my proposal is to remove these retries for now that we have drm handling 
> the retries
> and if we face any corner case back again we study it to return EAGAIN or 
> EBUSY
> to force retries at drm instead of handling them here.
>
> v2: Improve commit message trying to explain the origin of the retries.
>
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Jesse Barnes 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 95 
> ++---
>  1 file changed, 32 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c87e937..2ce6527 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -985,7 +985,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   if (WARN_ON(rxsize > 20))
>   return -E2BIG;
>  
> - ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
> + ret = intel_dp_aux_ch(intel_dp, txbuf, txsize,
> +   rxbuf, rxsize);
>   if (ret > 0) {
>   msg->reply = rxbuf[0] >> 4;
>   /*
> @@ -3150,47 +3151,16 @@ static void chv_dp_post_pll_disable(struct 
> intel_encoder *encoder)
>  }
>  
>  /*
> - * Native read with retry for link status and receiver capability reads for
> - * cases where the sink may still be asleep.
> - *
> - * Sinks are *supposed* to come up within 1ms from an off state, but we're 
> also
> - * supposed to retry 3 times per the spec.
> - */
> -static ssize_t
> -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> - void *buffer, size_t size)
> -{
> - ssize_t ret;
> - int i;
> -
> - /*
> -  * Sometime we just get the same incorrect byte repeated
> -  * over the entire buffer. Doing just one throw away read
> -  * initially seems to "solve" it.
> -  */
> - drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);

This still needs to be addressed somehow. Maybe it's sufficient for
Ville to test with his monitor?

commit f6a1906674005377b64ee5431c1418077c1b2425
Author: Ville Syrjälä 
Date:   Thu Oct 16 20:46:09 2014 +0300

drm/i915: Do a dummy DPCD read before the actual read

> -
> - for (i = 0; i < 3; i++) {
> - ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> - if (ret == size)
> - return ret;
> - msleep(1);
> - }
> -
> - return ret;
> -}
> -
> -/*
>   * Fetch AUX CH registers 0x202 - 0x207 which contain
>   * link status information
>   */
>  bool
>  intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
> link_status[DP_LINK_STATUS_SIZE])
>  {
> - return intel_dp_dpcd_read_wake(_dp->aux,
> -DP_LANE0_1_STATUS,
> -link_status,
> -DP_LINK_STATUS_SIZE) == 
> DP_LINK_STATUS_SIZE;
> + return drm_dp_dpcd_read(_dp->aux,
> + DP_LANE0_1_STATUS,
> + link_status,
> + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
>  }
>  
>  /* These are source-specific values. */
> @@ -3825,8 +3795,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint8_t rev;
>  
> - if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
> - sizeof(intel_dp->dpcd)) < 0)
> + if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
> +  sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  
>   

[Intel-gfx] [PATCH] v2: Also add a DRIVER_* check like for all other maps functions to really short-circuit the code. And give drm_legacy_rmmap used by the dev unregister code the same treatment.

[Jani Nikula]

Accidental patch?

On Mon, 23 Nov 2015, Daniel Vetter  wrote:
> ---
>  drivers/gpu/drm/drm_bufs.c | 14 ++
>  include/drm/drm_legacy.h   |  2 +-
>  2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index de18b8b78a26..5a51633da033 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -542,15 +542,17 @@ int drm_legacy_rmmap_locked(struct drm_device *dev, 
> struct drm_local_map *map)
>  }
>  EXPORT_SYMBOL(drm_legacy_rmmap_locked);
>  
> -int drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
> +void drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
>  {
> - int ret;
> + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> + drm_core_check_feature(dev, DRIVER_MODESET))
> + return;
>  
>   mutex_lock(>struct_mutex);
> - ret = drm_legacy_rmmap_locked(dev, map);
> + drm_legacy_rmmap_locked(dev, map);
>   mutex_unlock(>struct_mutex);
>  
> - return ret;
> + return;
>  }
>  EXPORT_SYMBOL(drm_legacy_rmmap);
>  
> @@ -558,6 +560,10 @@ void drm_legacy_master_rmmaps(struct drm_device *dev, 
> struct drm_master *master)
>  {
>   struct drm_map_list *r_list, *list_temp;
>  
> + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> + drm_core_check_feature(dev, DRIVER_MODESET))
> + return;
> +
>   mutex_lock(>struct_mutex);
>   list_for_each_entry_safe(r_list, list_temp, >maplist, head) {
>   if (r_list->master == master) {
> diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> index 24504b0eafea..a5ef2c7e40f8 100644
> --- a/include/drm/drm_legacy.h
> +++ b/include/drm/drm_legacy.h
> @@ -154,7 +154,7 @@ struct drm_map_list {
>  int drm_legacy_addmap(struct drm_device *d, resource_size_t offset,
> unsigned int size, enum drm_map_type type,
> enum drm_map_flags flags, struct drm_local_map **map_p);
> -int drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
> +void drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
>  int drm_legacy_rmmap_locked(struct drm_device *d, struct drm_local_map *map);
>  void drm_legacy_master_rmmaps(struct drm_device *dev,
> struct drm_master *master);

-- 
Jani Nikula, Intel Open Source Technology Center

[Intel-gfx] [PATCH] v2: Also add a DRIVER_* check like for all other maps functions to really short-circuit the code. And give drm_legacy_rmmap used by the dev unregister code the same treatment.

[Daniel Vetter]

On Mon, Nov 23, 2015 at 12:15:18PM +0200, Jani Nikula wrote:
> 
> Accidental patch?

Yup, dunno how that one ended up in there ...
-Daniel

> 
> On Mon, 23 Nov 2015, Daniel Vetter  wrote:
> > ---
> >  drivers/gpu/drm/drm_bufs.c | 14 ++
> >  include/drm/drm_legacy.h   |  2 +-
> >  2 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> > index de18b8b78a26..5a51633da033 100644
> > --- a/drivers/gpu/drm/drm_bufs.c
> > +++ b/drivers/gpu/drm/drm_bufs.c
> > @@ -542,15 +542,17 @@ int drm_legacy_rmmap_locked(struct drm_device *dev, 
> > struct drm_local_map *map)
> >  }
> >  EXPORT_SYMBOL(drm_legacy_rmmap_locked);
> >  
> > -int drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
> > +void drm_legacy_rmmap(struct drm_device *dev, struct drm_local_map *map)
> >  {
> > -   int ret;
> > +   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> > +   drm_core_check_feature(dev, DRIVER_MODESET))
> > +   return;
> >  
> > mutex_lock(>struct_mutex);
> > -   ret = drm_legacy_rmmap_locked(dev, map);
> > +   drm_legacy_rmmap_locked(dev, map);
> > mutex_unlock(>struct_mutex);
> >  
> > -   return ret;
> > +   return;
> >  }
> >  EXPORT_SYMBOL(drm_legacy_rmmap);
> >  
> > @@ -558,6 +560,10 @@ void drm_legacy_master_rmmaps(struct drm_device *dev, 
> > struct drm_master *master)
> >  {
> > struct drm_map_list *r_list, *list_temp;
> >  
> > +   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> > +   drm_core_check_feature(dev, DRIVER_MODESET))
> > +   return;
> > +
> > mutex_lock(>struct_mutex);
> > list_for_each_entry_safe(r_list, list_temp, >maplist, head) {
> > if (r_list->master == master) {
> > diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> > index 24504b0eafea..a5ef2c7e40f8 100644
> > --- a/include/drm/drm_legacy.h
> > +++ b/include/drm/drm_legacy.h
> > @@ -154,7 +154,7 @@ struct drm_map_list {
> >  int drm_legacy_addmap(struct drm_device *d, resource_size_t offset,
> >   unsigned int size, enum drm_map_type type,
> >   enum drm_map_flags flags, struct drm_local_map **map_p);
> > -int drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
> > +void drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
> >  int drm_legacy_rmmap_locked(struct drm_device *d, struct drm_local_map 
> > *map);
> >  void drm_legacy_master_rmmaps(struct drm_device *dev,
> >   struct drm_master *master);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

[PATCH] drm/atomic_helper: Add drm_atomic_helper_disable_planes_on_crtc()

[Jyri Sarha]

Add drm_atomic_helper_disable_planes_on_crtc() for disabling all
planes associated with the given CRTC. This can be used for instance
in the CRTC helper disable callback to disable all planes before
shutting down the display pipeline.

Signed-off-by: Jyri Sarha 
---
This a follow version to "[PATCH RFC] drm/crtc_helper: Add
drm_crtc_helper_disable_planes()"-patch [1], with Daniel Vetter's
review comments [2] implemented. Hope I got everything right this
time. Thanks a lot for the prompt review.

Best regards,
Jyri

[1] http://www.spinics.net/lists/dri-devel/msg94720.html
[2] http://www.spinics.net/lists/dri-devel/msg94722.html

 drivers/gpu/drm/drm_atomic_helper.c | 52 +
 include/drm/drm_atomic_helper.h |  2 ++
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index a53ed7a..229c810 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1281,6 +1281,58 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
 EXPORT_SYMBOL(drm_atomic_helper_commit_planes);

 /**
+ * drm_atomic_helper_disable_planes_on_crtc - helper to disable CRTC's planes
+ * @crtc: CRTC
+ * @atomic: if set, synchronize with CRTC's atomic_begin/flush hooks
+ *
+ * Disables all planes associated with the given CRTC. This can be
+ * used for instance in the CRTC helper disable callback to disable
+ * all planes before shutting down the display pipeline.
+ *
+ * If there are planes to disable and the atomic-parameter is set the
+ * function calls the CRTC's atomic_begin hook before and atomic_flush
+ * hook after disabling the planes.
+ *
+ * It is a bug to call this function without having implemented the
+ * ->atomic_disable() plane hook.
+ */
+void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
+ bool atomic)
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs =
+   crtc->helper_private;
+   struct drm_plane *plane;
+   bool flush = false;
+
+   if (!crtc_funcs || !crtc_funcs->atomic_begin)
+   atomic = false;
+
+   drm_for_each_plane(plane, crtc->dev) {
+   const struct drm_plane_helper_funcs *plane_funcs =
+   plane->helper_private;
+
+   if (plane->state->crtc != crtc || !plane_funcs)
+   continue;
+
+   if (atomic && !flush) {
+   crtc_funcs->atomic_begin(crtc, NULL);
+   flush = true;
+   }
+
+   WARN_ON(!plane_funcs->atomic_disable);
+   if (plane_funcs->atomic_disable)
+   plane_funcs->atomic_disable(plane, NULL);
+   }
+
+   if (flush) {
+   WARN_ON(!crtc_funcs->atomic_flush);
+   if (crtc_funcs->atomic_flush)
+   crtc_funcs->atomic_flush(crtc, NULL);
+   }
+}
+EXPORT_SYMBOL(drm_atomic_helper_disable_planes_on_crtc);
+
+/**
  * drm_atomic_helper_commit_planes_on_crtc - commit plane state for a crtc
  * @old_crtc_state: atomic state object with the old crtc state
  *
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 8cba54a..b7d4237 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -62,6 +62,8 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
 void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
  struct drm_atomic_state *old_state);
 void drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state 
*old_crtc_state);
+void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
+ bool atomic);

 void drm_atomic_helper_swap_state(struct drm_device *dev,
  struct drm_atomic_state *state);
-- 
1.9.1

[PATCH] drm/panel: simple: Add support for G121X1-L03

[Thierry Reding]

On Wed, Nov 18, 2015 at 03:57:47PM -0500, Akshay Bhat wrote:
> Add support for Innolux CheMei 12" G121X1-L03 XGA LVDS display.
> 
> Datasheet: http://www.azdisplays.com/PDF/G121X1-L03.pdf
> Signed-off-by: Akshay Bhat 
> ---
>  .../bindings/display/panel/innolux,g121x1-l03.txt  |  7 +
>  drivers/gpu/drm/panel/panel-simple.c   | 31 
> ++
>  2 files changed, 38 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt

Applied, thanks.

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

[PATCH] drm/panel: simple: Add Innolux N133HSE panel support

[Thierry Reding]

On Wed, Nov 18, 2015 at 10:47:43AM +0100, Marek Vasut wrote:
> From: Sean Cross 
> 
> The Innolux N133HSE panel is a 13.3" 1920x1080 panel that contains an
> integrated backlight, and connects via eDP.
> 
> It is used in the Kosagi Novena.
> 
> Signed-off-by: Sean Cross 
> Cc: Shawn Guo 
> Cc: Fabio Estevam 
> Cc: Thierry Reding 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 26 ++
>  1 file changed, 26 insertions(+)

This is missing a device tree binding document. Otherwise looks good,
except one minor nit below.

> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73e..d0fd427 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -856,6 +856,29 @@ static const struct panel_desc innolux_n116bge = {
>   },
>  };
>  
> +static const struct drm_display_mode innolux_n133hse_ea1_mode = {
> + .clock = 138500,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 46,
> + .hsync_end = 1920 + 46 + 30,
> + .htotal = 1920 + 160,

Can you split out the .htotal into its various components, for
consistency with the entries for other panels?

> + .vdisplay = 1080,
> + .vsync_start = 1080 + 2,
> + .vsync_end = 1080 + 2 + 4,
> + .vtotal = 1080 + 32,

Same for .vtotal here.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/4592bcf8/attachment.sig>

[PATCH 2/3] panel/panasonic-vvx10f034n00: Add DT bindings

[Thierry Reding]

On Fri, Oct 30, 2015 at 05:38:27PM -0700, bjorn at kryo.se wrote:
> From: Werner Johansson 
> 
> This patch adds bindings for the Panasonic VVX10F034N00
> WUXGA panel.
> 
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 
> ---
>  .../bindings/panel/panasonic,vvx10f034n00.txt| 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/2d2400f0/attachment.sig>

[PATCH 3/3] drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel

[Thierry Reding]

On Fri, Oct 30, 2015 at 05:38:28PM -0700, bjorn at kryo.se wrote:
> From: Werner Johansson 
> 
> This adds support for the Panasonic panel found in some Xperia Z2
> tablets.
> 
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/gpu/drm/panel/Kconfig  |  10 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   | 334 
> +
>  3 files changed, 345 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c

Applied, though I had to reorder Makefile and Kconfig entries to keep
alphabetic ordering.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/3fe29412/attachment.sig>

[PATCH v2 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

[Thierry Reding]

On Fri, Oct 30, 2015 at 03:34:29PM -0700, Bjorn Andersson wrote:
> From: Werner Johansson 
> 
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Change since v1:
> - Dropped -vid suffix from compatible
> 
>  .../bindings/display/panel/sharp,ls043t1le01.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/7d017ad9/attachment.sig>

[PATCH v2 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

[Thierry Reding]

On Fri, Oct 30, 2015 at 03:34:30PM -0700, Bjorn Andersson wrote:
> From: Werner Johansson 
> 
> This adds support for the Sharp panel found on the Qualcomm
> Snapdragon 800 Dragonboard (APQ8074)
> 
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Change since v1:
> - Dropped -vid suffix from compatible

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/9eb76c67/attachment.sig>

[PATCH 2/5] drm/imx: ipuv3 crtc: Cleanup ipu planes in ipu_crtc_init() when necessary

[Philipp Zabel]

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying:
> To avoid memory leakage, we need to cleanup the initialized ipu planes in
> the bailout path of ipu_crtc_init().
> 
> Signed-off-by: Liu Ying 
> ---
> This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.
> 
>  drivers/gpu/drm/imx/ipuv3-crtc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 67813ca..59f44df 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -371,7 +371,7 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>   ipu_crtc->dev->of_node);
>   if (ret) {
>   dev_err(ipu_crtc->dev, "adding crtc failed with %d.\n", ret);
> - goto err_put_resources;
> + goto err_cleanup_plane0;
>   }
>  
>   ret = ipu_plane_get_resources(ipu_crtc->plane[0]);
> @@ -402,9 +402,14 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>   return 0;
>  
>  err_put_plane_res:
> + if (ipu_crtc->plane[1])
> + ipu_plane_cleanup(ipu_crtc->plane[1]);
> +
>   ipu_plane_put_resources(ipu_crtc->plane[0]);
>  err_remove_crtc:
>   imx_drm_remove_crtc(ipu_crtc->imx_crtc);
> +err_cleanup_plane0:
> + ipu_plane_cleanup(ipu_crtc->plane[0]);
>  err_put_resources:
>   ipu_put_resources(ipu_crtc);

I think we can use ipu_plane_destroy as-is instead of
ipu_plane_put_resources + ipu_plane_cleanup.

regards
Philipp

[PATCH 4/5] drm/imx: ipuv3 plane: Use the helper ipu_plane_cleanup() in ipu_plane_destroy()

[Philipp Zabel]

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying:
> To reduce code duplication, we can use the helper ipu_plane_cleanup() in
> ipu_plane_destroy().
> 
> Signed-off-by: Liu Ying 
> ---
> This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.
> 
>  drivers/gpu/drm/imx/ipuv3-plane.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index e60b382..b3ed207 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -369,8 +369,7 @@ static void ipu_plane_destroy(struct drm_plane *plane)
>   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>  
>   ipu_disable_plane(plane);
> - drm_plane_cleanup(plane);
> - kfree(ipu_plane);
> + ipu_plane_cleanup(ipu_plane);
>  }
>  
>  static struct drm_plane_funcs ipu_plane_funcs = {

This could be merged into the first patch, but I don't think
ipu_plane_cleanup is necessary at all.

regards
Philipp

[PATCH 1/5] drm/imx: ipuv3 plane: Introduce ipu_plane_cleanup()

[Philipp Zabel]

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying:
> This patch adds a helper ipu_plane_cleanup() to cleanup a IPU plane.
> It can be used in the bailout path of ipu_crtc_init(), for instance.
> 
> Signed-off-by: Liu Ying 
> ---
> This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.
> 
>  drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
>  drivers/gpu/drm/imx/ipuv3-plane.h | 2 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index e2ff410..e60b382 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -410,3 +410,9 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
> struct ipu_soc *ipu,
>  
>   return ipu_plane;
>  }
> +
> +void ipu_plane_cleanup(struct ipu_plane *ipu_plane)
> +{
> + drm_plane_cleanup(_plane->base);
> + kfree(ipu_plane);
> +}

The name says cleanup, but that's not what it does. This function should
be named ipu_plane_free, or ipu_plane_destroy. Actually, we have that
already.

regards
Philipp

[PATCH 3/5] drm/imx: ipuv3 crtc: Cleanup ipu planes in ipu_drm_unbind()

[Philipp Zabel]

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying:
> To avoid memory leakage, we need to cleanup ipu planes in ipu_drm_unbind().
> 
> Signed-off-by: Liu Ying 
> ---
> This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.
> 
>  drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 59f44df..467905c 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -446,6 +446,11 @@ static void ipu_drm_unbind(struct device *dev, struct 
> device *master,
>   imx_drm_remove_crtc(ipu_crtc->imx_crtc);
>  
>   ipu_plane_put_resources(ipu_crtc->plane[0]);
> +
> + if (ipu_crtc->plane[1])
> + ipu_plane_cleanup(ipu_crtc->plane[1]);
> + ipu_plane_cleanup(ipu_crtc->plane[0]);
> +
>   ipu_put_resources(ipu_crtc);
>  }
>  

Shouldn't this already be handled by the DRM core calling the
plane->destroy callbacks from drm_mode_config_cleanup (called by
imx_drm_driver_unload shortly after component_unbind_all)?

regards
Philipp

[PATCH 5/5] drm/imx: ipuv3 plane: Replace dev_info with dev_dbg if a plane's CRTC changes

[Philipp Zabel]

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying:
> This patch changes the dev_info() call to dev_dbg() in ipu_plane_update()
> to print out the information that a plane's CRTC is changed, because this
> kind of information is only useful for debugging.
> 
> Signed-off-by: Liu Ying 
> ---
> This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git.
> 
>  drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index b3ed207..b24bf94 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -338,7 +338,7 @@ static int ipu_update_plane(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   }
>  
>   if (crtc != plane->crtc)
> - dev_info(plane->dev->dev, "crtc change: %p -> %p\n",
> + dev_dbg(plane->dev->dev, "crtc change: %p -> %p\n",
>   plane->crtc, crtc);
>   plane->crtc = crtc;

This change is separate from the others, I have applied it.

thanks
Philipp

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #62 from Kamil Páral  ---
Paulo, what's "the SO sync"?

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

[PATCH 2/2] drm/rockchip: Send events for same-fb flips

[Caesar Wang]

Hi,

于 2015年11月16日 20:50, Daniel Stone 写道:
> Rockchip previously treated a pageflip to the same framebuffer as a
> no-op, discarding the event if one was requested. This breaks Weston,
> which, when idle, sends a no-op vblank event to discover vblank
> timings if the vblank query interface is not usable.
>
> Silently dropping events is also quite a hostile thing to do to
> userspace in general.
>
> Signed-off-by: Daniel Stone 
> Cc: Sjoerd Simons 
> Cc: Heiko Stuebner 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 
> ++---
>   1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index ddf6dc2..dad607e 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -916,25 +916,23 @@ static int vop_update_plane_event(struct drm_plane 
> *plane,
>* unreference any previous framebuffers.
>*/
>   mutex_lock(>vsync_mutex);
> - if (fb != vop_win_last_pending_fb(vop_win)) {

There is a warning for building.

CC drivers/gpu/drm/rockchip/rockchip_drm_vop.o
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:753:32: warning: 
'vop_win_last_pending_fb' defined but not used [-Wunused-function]

Maybe, we can also remove the vop_win_last_pending_fb() function.

> - ret = drm_vblank_get(plane->dev, vop->pipe);
> - if (ret) {
> - DRM_ERROR("failed to get vblank, %d\n", ret);
> - mutex_unlock(>vsync_mutex);
> - return ret;
> - }
> + ret = drm_vblank_get(plane->dev, vop->pipe);
> + if (ret) {
> + DRM_ERROR("failed to get vblank, %d\n", ret);
> + mutex_unlock(>vsync_mutex);
> + return ret;
> + }
>   
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_reference(fb);
>   
> - ret = vop_win_queue_fb(vop_win, fb, yrgb_mst, event);
> - if (ret) {
> - drm_vblank_put(plane->dev, vop->pipe);
> - mutex_unlock(>vsync_mutex);
> - return ret;
> - }
> -
> - vop->vsync_work_pending = true;
> + ret = vop_win_queue_fb(vop_win, fb, yrgb_mst, event);
> + if (ret) {
> + drm_vblank_put(plane->dev, vop->pipe);
> + mutex_unlock(>vsync_mutex);
> + return ret;
>   }
> +
> + vop->vsync_work_pending = true;
>   mutex_unlock(>vsync_mutex);
>   
>   spin_lock(>reg_lock);

[PATCH v5 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Change since v4
-fix build error, change Kconfig DRM_PARADE_PS8640 from bool to tristate
---
 drivers/gpu/drm/bridge/Kconfig |   10 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c |  471 
 3 files changed, 482 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..dcfdbc9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..272e3c01 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..7c83afa
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,471 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define PAGE2_I2C_BYPASS   0xea
+#define I2C_BYPASS_EN  0xd0
+
+#define PAGE3_SET_ADD  0xfe
+#define PAGE3_SET_VAL  0xff
+#define VDO_CTL_ADD0x13
+#define VDO_DIS0x18
+#define VDO_EN 0x1c
+
+#define PAGE4_REV_L0xf0
+#define PAGE4_REV_H0xf1
+#define PAGE4_CHIP_L   0xf2
+#define PAGE4_CHIP_H   0xf3
+
+#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
+#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
+
+struct ps8640 {
+   struct drm_connector connector;
+   struct drm_bridge bridge;
+   struct i2c_client *page[6];
+   struct ps8640_driver_data *driver_data;
+   struct regulator *pwr_1v2_supply;
+   struct regulator *pwr_3v3_supply;
+   struct drm_panel *panel;
+   struct gpio_desc *gpio_rst_n;
+   struct gpio_desc *gpio_slp_n;
+   struct gpio_desc *gpio_mode_sel_n;
+   bool enabled;
+};
+
+static int ps8640_regr(struct i2c_client *client, u8 reg, u8 *value)
+{
+   int ret;
+
+   ret = i2c_master_send(client, , 1);
+   if (ret <= 0) {
+   dev_err(>dev, "Failed to send i2c command, ret=%d\n",
+   ret);
+   return ret;
+   }
+
+   ret = i2c_master_recv(client, value, 1);
+   if (ret <= 0) {
+   dev_err(>dev, "Failed to recv i2c data, ret=%d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int ps8640_regw(struct i2c_client *client, u8 reg, u8 value)
+{
+   int ret;
+   char buf[2];
+
+   buf[0] = reg;
+   buf[1] = value;
+   ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
+   if (ret <= 0) {
+   dev_err(>dev, "Failed to send i2c command, ret=%d\n",
+   ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static bool ps8640_check_valid_id(struct ps8640 *ps_bridge)
+{
+   struct i2c_client *client = ps_bridge->page[4];
+   u8 rev_id_low, rev_id_high, chip_id_low, chip_id_high;
+   int retry_cnt = 0;
+
+   do {
+   ps8640_regr(client, PAGE4_CHIP_H, _id_high);
+   if (chip_id_high != 0x30)
+   dev_info(>dev, "chip_id_high = 0x%x\n",
+chip_id_high);
+   } while ((retry_cnt++ < 2) && (chip_id_high != 0x30));
+
+   

[PATCH v5 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

[Jitao Shi]

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Changes since v4
-no change
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..a3e0971
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0> 
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP 
out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = < 116 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 115 GPIO_ACTIVE_HIGH>;
+   mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <_fixed_1v2>;
+   vdd33-supply = <_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello,

On 11/21/2015 11:59 AM, Inki Dae wrote:
> Hi Daniel,
> 
> 
> 2015-11-21 22:40 GMT+09:00 Daniel Stone :
>> Hi Inki,
>>
>> On 21 November 2015 at 09:38, Inki Dae  wrote:
>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas >> osg.samsung.com>:
 On 11/20/2015 08:13 AM, Inki Dae wrote:
> The boot log says,
> [5.754493] vdd_ldo9: supplied by vdd_2v
> [5.765510] of_graph_get_next_endpoint(): no port node found in 
> /dp-controller at 145B
>

 This message is a red herring for the reported issue, the message is also
 present when the machine boots and the display is brought correctly.

> Seems this error is because exynos5800-peach-pit.dts file doesn't have 
> 'ports' node in dp node.
>
> Below is dp node description of exynos5420-peach-pit.dts file.
>  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
>   samsung,dynamic-range = <0>;
>   samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x06>;
>   samsung,lane-count = <2>;
>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>
>   ports {
>   port at 0 {
>   dp_out: endpoint {
>   remote-endpoint = <_in>;
>   };
>   };
>   };
> };
>
> And below is for exynos5800-peash-pit.dts,
>  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
>   samsung,dynamic-range = <0>;
>   samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <2>;
>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>   panel = <>;
> };
>

 The difference is because the Exynos5420 Peach Pit Display Port is not
 attached directly to the display panel, there is an eDP/LVDS bridge chip
 in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.

 The Exynos DP driver lookups for either a panel phandle or an OF graph
 endpoint that points to a bridge chip and the bridge enpoint has a port
 that points to the panel.

 So the DT is correct but of_graph_get_next_endpoint() always prints an
>>>
>>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800 Peach 
>>> PI
>>> board doesn't use eDP, then the dp node __should be removed__ from
>>> exynos5800-peach-pit.dts.
>>>
>>> From a common-sense standpoint, there is no any reason to build
>>> and probe dp driver if the board doesn't use dp hardware.
>>
>> I agree with what you say, but unfortunately you've slightly misread
>> what Javier has said. :) exynos5420-peach-pit has an LVDS panel, with
>> the eDP -> LVDS bridge in between (ps8622). exynos5800-peach-pi (from
>> which I am writing this) has an eDP panel directly connected. The DT

Thanks a lot Daniel for clarifying my comments to Inki :)

>> describes both the eDP connector from FIMD and the eDP panel, except
>> that there is no connection between the DT nodes.

There *is* a connection between the FIMD eDP connector and the eDP panel
nodes but these are connected using a phandle while the connection for
the FIMD eDP connector and the eDP/LVDS bridge is using the OF graph DT
bindings (Documentation/devicetree/bindings/graph.txt).

And also the connection between the eDP/LVDS bridge and the LVDS panel
is using an OF graph node, so what I meant is that it would be much more
consistent if both the eDP -> panel and eDP -> eDP/LVDS bridge -> panel
connections used the OF graph DT bindings.

>
> Right. I misread what Javier said. :)
>
>>
 error if the port so OF graph endpoints it seems can't be optional as
 used in this driver. Maybe that message should be change to debug then?

 Another option is to extend the DP driver DT binding to be more generic
 supporting having a port to a panel besides a bridge, so we could have
 something like this for Exynos5800 Peach and be consistent in both cases:
>>>
>>> It's really not good. This would make it more complex. The best
>>> solution is just to
>>> remove the dt node from the device tree file.
>>
>> Given the above, not really. Javier's patch seems correct to me - as
>> you can see, there is a panel node, and that is the panel that's
>> really connected.
> 
> Indeed. Javier's patch will correct it.
>

Just to be clear, my patch is not correct since the Exynos DP driver and
its DT binding does not support to connect an FIMD eDP connector to an
eDP panel directly using OF graph ports / endpoints (only a phandle). But
is an example of how the DT will look like if we extend to support that.

IIRC at the beginning only eDP -> panel was supported and the phandle
was used and later 

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Deucher, Alexander]

> -Original Message-
> From: Lyude [mailto:cpaul at redhat.com]
> Sent: Sunday, November 22, 2015 9:45 PM
> To: Koenig, Christian; Daniel Stone
> Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing List;
> Jerome Glisse; Benjamin Tissoires
> Subject: Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we
> got an HPD interrupt
> 
> On Sat, 2015-11-21 at 16:22 +0100, Christian König wrote:
> > On 21.11.2015 15:49, Daniel Stone wrote:
> > > Hi,
> > >
> > > On 21 November 2015 at 14:22, Christian König  > > .com> wrote:
> > > > On 20.11.2015 16:52, cpaul at redhat.com wrote:
> > > > > This is somewhat rare on most cards (depending on what angle
> > > > > you plug
> > > > > the DVI connector in), but on some cards it happens constantly.
> > > > > The
> > > > > Radeon R5 on the machine used for testing this patch for
> > > > > instance, runs
> > > > > into this issue just about every time I try to hotplug a DVI
> > > > > monitor and
> > > > > as a result hotplugging almost never works.
> > > > >
> > > > > Rescheduling the hotplug work for a second when we run into an
> > > > > HPD
> > > > > signal with a failing DDC probe usually gives enough time for
> > > > > the rest
> > > > > of the connector's pins to make contact, and fixes this issue.
> > > > >
> > > > > Signed-off-by: Stephen Chandler Paul 
> > > >
> > > > Yeah, that's something I always wondered a about bit as well.
> > > >
> > > > Debouncing is something very common done in electronics, but as
> > > > far as I
> > > > know the HPD pins don't necessary have an RC circuit so we might
> > > > need to
> > > > handle this case in software here.
> > > >
> > > > A delay of something between 10-30ms between the last HPD
> > > > interrupt and
> > > > further processing of the signal doesn't sounds like such a bad
> > > > idea.
> Unfortunately the delay needed to make hotplugging work on the system
> mentioned in the commit log can actually be over 700ms.
> > > >
> > > > Retrying on the other hand doesn't necessarily improve the
> > > > situation cause
> > > > the delay introduced by this might not be enough.
> Yeah, but I would think it would make sense to retry here so long as we
> back off after a certain time. This would also have the benefit of
> skipping this delay on systems that don't need it.
> > > >
> > > > So I would rather vote for a fixed delay between an HPD interrupt
> > > > and
> > > > actually starting to process anything.
> > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g.
> > > those
> > > on marginal power) which send you HPD storms as well. But DP relies
> > > on
> > > 'short HPD' pulses which can be as brief as 2ms. So attempting to
> > > totally debounce all HPD won't work.
> > Well the discussion so far was about HPD on DVI only.
> >
> > I'm not so deep into DP, but why should it uses HPD pulses of less
> > than 2ms?
> This is part of the DP spec iirc. This being said though, the issue
> here with the HPD signal coming before the connector is ready only
> happens on DVI. I haven't ever run into this issue with any HDMI cables
> or DP cables, so I'm against imposing this on all connectors.
> 
> One of the solutions I've been thinking about with this: In
> radeon_dvi_detect(), if we get a real hotplug signal retry the DDC
> probe until at least a second has passed, after which we back off and
> assume the port is disconnected.

FWIW, there are registers to adjust how long the hpd needs to be asserted 
before the hpd connection and short pulse interrupts are triggered.  See 
DC_HPDx_CONTROL.  Maybe adjusting them would help.  We currently just write the 
default value, but it might be better to RMW the value in case there is a 
special golden value set by the vbios at init time.

Alex

> >
> > Regards,
> > Christian.
> >
> > >
> > > Cheers,
> > > Daniel
> >
> --
> Cheers,
>   Lyude

[Bug 108221] amdgpu: mouse cursor flickers + black boxes

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Can you bisect?

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

[Bug 92996] [Fiji/amdgpu/Powerplay] Problems with vsync, interactivity, performance, EQ overflow with Powerplay

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

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

--- Comment #5 from Ernst Sjöstrand  ---
My system only support PCI-Express 2.0, not 3.0. Could that be something?
Does someone _not_ have these problems with Fiji?

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

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Lyude]

On Mon, 2015-11-23 at 14:20 +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Lyude [mailto:cpaul at redhat.com]
> > Sent: Sunday, November 22, 2015 9:45 PM
> > To: Koenig, Christian; Daniel Stone
> > Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing List;
> > Jerome Glisse; Benjamin Tissoires
> > Subject: Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we
> > got an HPD interrupt
> > 
> > On Sat, 2015-11-21 at 16:22 +0100, Christian König wrote:
> > > On 21.11.2015 15:49, Daniel Stone wrote:
> > > > Hi,
> > > > 
> > > > On 21 November 2015 at 14:22, Christian König  > > > .com> wrote:
> > > > > On 20.11.2015 16:52, cpaul at redhat.com wrote:
> > > > > > This is somewhat rare on most cards (depending on what angle
> > > > > > you plug
> > > > > > the DVI connector in), but on some cards it happens constantly.
> > > > > > The
> > > > > > Radeon R5 on the machine used for testing this patch for
> > > > > > instance, runs
> > > > > > into this issue just about every time I try to hotplug a DVI
> > > > > > monitor and
> > > > > > as a result hotplugging almost never works.
> > > > > > 
> > > > > > Rescheduling the hotplug work for a second when we run into an
> > > > > > HPD
> > > > > > signal with a failing DDC probe usually gives enough time for
> > > > > > the rest
> > > > > > of the connector's pins to make contact, and fixes this issue.
> > > > > > 
> > > > > > Signed-off-by: Stephen Chandler Paul 
> > > > > 
> > > > > Yeah, that's something I always wondered a about bit as well.
> > > > > 
> > > > > Debouncing is something very common done in electronics, but as
> > > > > far as I
> > > > > know the HPD pins don't necessary have an RC circuit so we might
> > > > > need to
> > > > > handle this case in software here.
> > > > > 
> > > > > A delay of something between 10-30ms between the last HPD
> > > > > interrupt and
> > > > > further processing of the signal doesn't sounds like such a bad
> > > > > idea.
> > Unfortunately the delay needed to make hotplugging work on the system
> > mentioned in the commit log can actually be over 700ms.
> > > > > 
> > > > > Retrying on the other hand doesn't necessarily improve the
> > > > > situation cause
> > > > > the delay introduced by this might not be enough.
> > Yeah, but I would think it would make sense to retry here so long as we
> > back off after a certain time. This would also have the benefit of
> > skipping this delay on systems that don't need it.
> > > > > 
> > > > > So I would rather vote for a fixed delay between an HPD interrupt
> > > > > and
> > > > > actually starting to process anything.
> > > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g.
> > > > those
> > > > on marginal power) which send you HPD storms as well. But DP relies
> > > > on
> > > > 'short HPD' pulses which can be as brief as 2ms. So attempting to
> > > > totally debounce all HPD won't work.
> > > Well the discussion so far was about HPD on DVI only.
> > > 
> > > I'm not so deep into DP, but why should it uses HPD pulses of less
> > > than 2ms?
> > This is part of the DP spec iirc. This being said though, the issue
> > here with the HPD signal coming before the connector is ready only
> > happens on DVI. I haven't ever run into this issue with any HDMI cables
> > or DP cables, so I'm against imposing this on all connectors.
> > 
> > One of the solutions I've been thinking about with this: In
> > radeon_dvi_detect(), if we get a real hotplug signal retry the DDC
> > probe until at least a second has passed, after which we back off and
> > assume the port is disconnected.
> 
> FWIW, there are registers to adjust how long the hpd needs to be asserted
> before the hpd connection and short pulse interrupts are triggered.  See
> DC_HPDx_CONTROL.  Maybe adjusting them would help.  We currently just 
> write
> the default value, but it might be better to RMW the value in case there is a
> special golden value set by the vbios at init time.
> 
This sounds like a much better idea. I'm going to try to come up with a patch
that adjusts these by default for DVI ports.
> Alex
> 
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > 
> > > > Cheers,
> > > > Daniel
> > > 
> > --
> > Cheers,
> > Lyude
> 
-- 
Cheers,
Lyude

[PATCH] drm/imx: parallel-display: allow to determine bus format from the connected panel

[Gary Bisson]

Philipp, All,

On Fri, Nov 20, 2015 at 01:46:39PM +0100, Philipp Zabel wrote:
> Similarly to commit 5e501ed7253b3 ("drm/imx: imx-ldb: allow to determine
> bus format from the connected panel"), if a panel is connected to the ldb
> output port via the of_graph bindings, the data mapping is determined from
> the display_info.bus_format field provided by the panel instead of from the
> optional interface_pix_fmt device tree property.

Tested with a SabreLite + Okaya rs800480t LCD display on 4.4-rc1 kernel.

Tested-by: Gary Bisson 

One question though, do you want people to remove the interface_pix_fmt
property from the device trees to make it clear the interface depends on
the panel selected?

Regards,
Gary

[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4

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

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

Bug ID: 93079
   Summary: Tonga faults and oopses on agd5f drm-fixes-4.4
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

Created attachment 120050
  --> https://bugs.freedesktop.org/attachment.cgi?id=120050=edit
some backtraces

Haven't tried agd5f drm-fixes-4.4 before today.

It seems that it is unstable on R9 285.

Twice I've been close to submitting a bisect, but false goods have spoilt
things.

Varying backtraces attached.

Will try to bisect again but it's not going to be quick.

I am stable on powerplay and was OK on 4.4-next-wip.

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

[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4

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

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

--- Comment #1 from Andy Furniss  ---
Created attachment 120051
  --> https://bugs.freedesktop.org/attachment.cgi?id=120051=edit
dmesg

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

[Bug 92850] Segfault loading War Thunder

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

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

--- Comment #14 from bellamorte42 at gmail.com ---
Link to apitrace
https://www.dropbox.com/s/wxoywdk1pa0el2p/aces.7.trace?dl=0

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

[PATCH 0/4] Component helper updates

[Russell King - ARM Linux]

Greg,

These four patches update the component helper by:
* Removing the legacy matching code with the .add_components method
  in the master's operation structure.  Nothing in -rc1 appears to be
  using the legacy functions or method, according to my git greps.

* A slight code reorganisation which results in slightly easier to read
  code.

* Switch to tracking components via an array rather than a list, which
  allows us to keep the matching and matched components together, and
  more importantly allows us to reduce the amount of matching - with
  this structure, we can incrementally add the component devices as
  they become available, rather than re-running the list of matches
  each time something changes.

* Fix the lack of match release functionality, which Liviu Dudau
  reminded me was missing.  This allows people who want to pass
  device_node structures in to (correctly) retain the reference to the
  node, and drop the node when the need to do matches is no longer
  required.

The first three patches have been well tested over the last year as I've
had them in my tree that long.  I hadn't considered them important enough
to send as they're only removing and cleaning up functionality.  However,
with the need to fix something, it now makes sense to get them merged.

The last patch has been tested with etnaviv DRM to prove that the match
release works by unloading the module.  On unload, the release function
is correctly called.

This is intended for the next merge window.  Please apply.

 drivers/base/component.c  | 281 --
 include/linux/component.h |  33 --
 2 files changed, 167 insertions(+), 147 deletions(-)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 93080] War Thunder launcher no longer loads

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

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

Bug ID: 93080
   Summary: War Thunder launcher no longer loads
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: bellamorte42 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 120052
  --> https://bugs.freedesktop.org/attachment.cgi?id=120052=edit
backtrace

An empty window will pop up and quickly disappear.

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

[Bug 93080] War Thunder launcher no longer loads

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

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

--- Comment #1 from bellamorte42 at gmail.com ---
Created attachment 120053
  --> https://bugs.freedesktop.org/attachment.cgi?id=120053=edit
apitrace

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

[PATCH] drm/atomic_helper: Add drm_atomic_helper_disable_planes_on_crtc()

[Daniel Vetter]

On Mon, Nov 23, 2015 at 12:44:35PM +0200, Jyri Sarha wrote:
> Add drm_atomic_helper_disable_planes_on_crtc() for disabling all
> planes associated with the given CRTC. This can be used for instance
> in the CRTC helper disable callback to disable all planes before
> shutting down the display pipeline.
> 
> Signed-off-by: Jyri Sarha 
> ---
> This a follow version to "[PATCH RFC] drm/crtc_helper: Add
> drm_crtc_helper_disable_planes()"-patch [1], with Daniel Vetter's
> review comments [2] implemented. Hope I got everything right this
> time. Thanks a lot for the prompt review.

When resending a patch please add a revision log to remind reviewers of
what you changed. Otherwise they have to dig out the old thread again to
figure that out. E.g.

v2 per Daniel's feedback:
- Improve kerneldoc.
- WARN_ON when atomic_disable is missing.
- Also use crtc_funcs->atomic_begin/atomic_flush optionally.
> 
> Best regards,
> Jyri
> 
> [1] http://www.spinics.net/lists/dri-devel/msg94720.html
> [2] http://www.spinics.net/lists/dri-devel/msg94722.html
> 
>  drivers/gpu/drm/drm_atomic_helper.c | 52 
> +
>  include/drm/drm_atomic_helper.h |  2 ++
>  2 files changed, 54 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a53ed7a..229c810 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1281,6 +1281,58 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>  EXPORT_SYMBOL(drm_atomic_helper_commit_planes);
>  
>  /**
> + * drm_atomic_helper_disable_planes_on_crtc - helper to disable CRTC's planes
> + * @crtc: CRTC
> + * @atomic: if set, synchronize with CRTC's atomic_begin/flush hooks
> + *
> + * Disables all planes associated with the given CRTC. This can be
> + * used for instance in the CRTC helper disable callback to disable
> + * all planes before shutting down the display pipeline.
> + *
> + * If there are planes to disable and the atomic-parameter is set the
> + * function calls the CRTC's atomic_begin hook before and atomic_flush
> + * hook after disabling the planes.
> + *
> + * It is a bug to call this function without having implemented the
> + * ->atomic_disable() plane hook.
> + */
> +void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
> +   bool atomic)
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs =
> + crtc->helper_private;
> + struct drm_plane *plane;
> + bool flush = false;
> +
> + if (!crtc_funcs || !crtc_funcs->atomic_begin)
> + atomic = false;
> +
> + drm_for_each_plane(plane, crtc->dev) {
> + const struct drm_plane_helper_funcs *plane_funcs =
> + plane->helper_private;
> +
> + if (plane->state->crtc != crtc || !plane_funcs)
> + continue;
> +
> + if (atomic && !flush) {
> + crtc_funcs->atomic_begin(crtc, NULL);
> + flush = true;

I think it's clearer if you do that upfront with a simple

if (crtc_funcs->atomic_begin && atomic)
crtc_funcs->atomic_begin();

> + }
> +
> + WARN_ON(!plane_funcs->atomic_disable);
> + if (plane_funcs->atomic_disable)
> + plane_funcs->atomic_disable(plane, NULL);
> + }
> +
> + if (flush) {
> + WARN_ON(!crtc_funcs->atomic_flush);
> + if (crtc_funcs->atomic_flush)
> + crtc_funcs->atomic_flush(crtc, NULL);
> + }

Same here below. Imo the tracking you do in flush isn't required, since
drivers can opt to not implement either atomic_begin or atomic_flush (on
some hw you only need atomic_flush, and your code would break such a
driver here).

In short the code flow for atomic_begin/flush should look exactly like in
drm_atomic_helper_commit_planes_on_crtc, except for the added && atomic
check.

Otherwise looks good.

Cheers, Daniel

> +}
> +EXPORT_SYMBOL(drm_atomic_helper_disable_planes_on_crtc);
> +
> +/**
>   * drm_atomic_helper_commit_planes_on_crtc - commit plane state for a crtc
>   * @old_crtc_state: atomic state object with the old crtc state
>   *
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 8cba54a..b7d4237 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -62,6 +62,8 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
>  void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
> struct drm_atomic_state *old_state);
>  void drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state 
> *old_crtc_state);
> +void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
> +   bool atomic);
>  
>  void drm_atomic_helper_swap_state(struct drm_device *dev,
>  

[PATCH 1/4] component: remove old add_components method

[Russell King]

Now that drivers create an array of component matches at probe time, we
can retire the old methods.  This involves removing the add_components
master method, and removing component_master_add_child() from public
view.  We also remove component_add_master() as that interface is no
longer useful.

Signed-off-by: Russell King 
---
 drivers/base/component.c  | 31 +--
 include/linux/component.h |  5 -
 2 files changed, 5 insertions(+), 31 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index f748430bb654..2ca22738ae92 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -84,7 +84,7 @@ static void component_detach_master(struct master *master, 
struct component *c)
  * function and compare data.  This is safe to call for duplicate matches
  * and will not result in the same component being added multiple times.
  */
-int component_master_add_child(struct master *master,
+static int component_master_add_child(struct master *master,
int (*compare)(struct device *, void *), void *compare_data)
 {
struct component *c;
@@ -104,7 +104,6 @@ int component_master_add_child(struct master *master,

return ret;
 }
-EXPORT_SYMBOL_GPL(component_master_add_child);

 static int find_components(struct master *master)
 {
@@ -112,14 +111,6 @@ static int find_components(struct master *master)
size_t i;
int ret = 0;

-   if (!match) {
-   /*
-* Search the list of components, looking for components that
-* belong to this master, and attach them to the master.
-*/
-   return master->ops->add_components(master->dev, master);
-   }
-
/*
 * Scan the array of match functions and attach
 * any components which are found to this master.
@@ -290,15 +281,10 @@ int component_master_add_with_match(struct device *dev,
struct master *master;
int ret;

-   if (ops->add_components && match)
-   return -EINVAL;
-
-   if (match) {
-   /* Reallocate the match array for its true size */
-   match = component_match_realloc(dev, match, match->num);
-   if (IS_ERR(match))
-   return PTR_ERR(match);
-   }
+   /* Reallocate the match array for its true size */
+   match = component_match_realloc(dev, match, match->num);
+   if (IS_ERR(match))
+   return PTR_ERR(match);

master = kzalloc(sizeof(*master), GFP_KERNEL);
if (!master)
@@ -326,13 +312,6 @@ int component_master_add_with_match(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(component_master_add_with_match);

-int component_master_add(struct device *dev,
-   const struct component_master_ops *ops)
-{
-   return component_master_add_with_match(dev, ops, NULL);
-}
-EXPORT_SYMBOL_GPL(component_master_add);
-
 void component_master_del(struct device *dev,
const struct component_master_ops *ops)
 {
diff --git a/include/linux/component.h b/include/linux/component.h
index c00dcc302611..71c434a6a5ee 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -17,18 +17,13 @@ void component_unbind_all(struct device *, void *);
 struct master;

 struct component_master_ops {
-   int (*add_components)(struct device *, struct master *);
int (*bind)(struct device *);
void (*unbind)(struct device *);
 };

-int component_master_add(struct device *, const struct component_master_ops *);
 void component_master_del(struct device *,
const struct component_master_ops *);

-int component_master_add_child(struct master *master,
-   int (*compare)(struct device *, void *), void *compare_data);
-
 struct component_match;

 int component_master_add_with_match(struct device *,
-- 
2.1.0

[PATCH 3/4] component: track components via array rather than list

[Russell King]

Since we now have an array which defines each component, maintain the
components to be bound in the array rather than a separate list.  We
also need duplicate tracking so we can eliminate multiple bind calls
for the same component: we preserve the list-based component order in
that the first match which adds the component determines its position.

Signed-off-by: Russell King 
---
 drivers/base/component.c | 154 ---
 1 file changed, 80 insertions(+), 74 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index cd70b68d9780..d99b06b341fb 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -18,18 +18,21 @@
 #include 
 #include 

+struct component;
+
 struct component_match {
size_t alloc;
size_t num;
struct {
void *data;
int (*fn)(struct device *, void *);
+   struct component *component;
+   bool duplicate;
} compare[0];
 };

 struct master {
struct list_head node;
-   struct list_head components;
bool bound;

const struct component_master_ops *ops;
@@ -39,7 +42,6 @@ struct master {

 struct component {
struct list_head node;
-   struct list_head master_node;
struct master *master;
bool bound;

@@ -63,46 +65,20 @@ static struct master *__master_find(struct device *dev,
return NULL;
 }

-/* Attach an unattached component to a master. */
-static void component_attach_master(struct master *master, struct component *c)
-{
-   c->master = master;
-
-   list_add_tail(>master_node, >components);
-}
-
-/* Detach a component from a master. */
-static void component_detach_master(struct master *master, struct component *c)
-{
-   list_del(>master_node);
-
-   c->master = NULL;
-}
-
-/*
- * Add a component to a master, finding the component via the compare
- * function and compare data.  This is safe to call for duplicate matches
- * and will not result in the same component being added multiple times.
- */
-static int component_master_add_child(struct master *master,
+static struct component *find_component(struct master *master,
int (*compare)(struct device *, void *), void *compare_data)
 {
struct component *c;
-   int ret = -ENXIO;

list_for_each_entry(c, _list, node) {
if (c->master && c->master != master)
continue;

-   if (compare(c->dev, compare_data)) {
-   if (!c->master)
-   component_attach_master(master, c);
-   ret = 0;
-   break;
-   }
+   if (compare(c->dev, compare_data))
+   return c;
}

-   return ret;
+   return NULL;
 }

 static int find_components(struct master *master)
@@ -116,26 +92,39 @@ static int find_components(struct master *master)
 * any components which are found to this master.
 */
for (i = 0; i < match->num; i++) {
-   ret = component_master_add_child(master,
-match->compare[i].fn,
-match->compare[i].data);
-   if (ret)
+   struct component *c;
+
+   dev_dbg(master->dev, "Looking for component %zu\n", i);
+
+   if (match->compare[i].component)
+   continue;
+
+   c = find_component(master, match->compare[i].fn,
+  match->compare[i].data);
+   if (!c) {
+   ret = -ENXIO;
break;
+   }
+
+   dev_dbg(master->dev, "found component %s, duplicate %u\n", 
dev_name(c->dev), !!c->master);
+
+   /* Attach this component to the master */
+   match->compare[i].duplicate = !!c->master;
+   match->compare[i].component = c;
+   c->master = master;
}
return ret;
 }

-/* Detach all attached components from this master */
-static void master_remove_components(struct master *master)
+/* Detach component from associated master */
+static void remove_component(struct master *master, struct component *c)
 {
-   while (!list_empty(>components)) {
-   struct component *c = list_first_entry(>components,
-   struct component, master_node);
-
-   WARN_ON(c->master != master);
+   size_t i;

-   component_detach_master(master, c);
-   }
+   /* Detach the component from this master. */
+   for (i = 0; i < master->match->num; i++)
+   if (master->match->compare[i].component == c)
+   master->match->compare[i].component = NULL;
 }

 /*
@@ -150,37 +139,32 @@ static int try_to_bring_up_master(struct master 

[PATCH 4/4] component: add support for releasing match data

[Russell King]

The component helper treats the void match data pointer as an opaque
object which needs no further management.  When device nodes being
passed, this is not true: the caller should pass its refcount to the
component helper, and there should be a way to drop the refcount when
the matching information is destroyed.

This patch provides a per-match release method in addition to the match
method to solve this issue.  Rather than using component_match_add(),
users should use component_match_add_release() which takes an additional
function pointer for releasing this reference.

Signed-off-by: Russell King 
---
 drivers/base/component.c  | 101 ++
 include/linux/component.h |  28 +
 2 files changed, 87 insertions(+), 42 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index d99b06b341fb..89f5cf68d80a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -20,15 +20,18 @@

 struct component;

+struct component_match_array {
+   void *data;
+   int (*compare)(struct device *, void *);
+   void (*release)(struct device *, void *);
+   struct component *component;
+   bool duplicate;
+};
+
 struct component_match {
size_t alloc;
size_t num;
-   struct {
-   void *data;
-   int (*fn)(struct device *, void *);
-   struct component *component;
-   bool duplicate;
-   } compare[0];
+   struct component_match_array *compare;
 };

 struct master {
@@ -92,6 +95,7 @@ static int find_components(struct master *master)
 * any components which are found to this master.
 */
for (i = 0; i < match->num; i++) {
+   struct component_match_array *mc = >compare[i];
struct component *c;

dev_dbg(master->dev, "Looking for component %zu\n", i);
@@ -99,8 +103,7 @@ static int find_components(struct master *master)
if (match->compare[i].component)
continue;

-   c = find_component(master, match->compare[i].fn,
-  match->compare[i].data);
+   c = find_component(master, mc->compare, mc->data);
if (!c) {
ret = -ENXIO;
break;
@@ -192,41 +195,55 @@ static void take_down_master(struct master *master)
}
 }

-static size_t component_match_size(size_t num)
+static void component_match_release(struct device *master,
+   struct component_match *match)
+{
+   unsigned int i;
+
+   for (i = 0; i < match->num; i++) {
+   struct component_match_array *mc = >compare[i];
+
+   if (mc->release)
+   mc->release(master, mc->data);
+   }
+}
+
+static void devm_component_match_release(struct device *dev, void *res)
 {
-   return offsetof(struct component_match, compare[num]);
+   component_match_release(dev, res);
 }

-static struct component_match *component_match_realloc(struct device *dev,
+static int component_match_realloc(struct device *dev,
struct component_match *match, size_t num)
 {
-   struct component_match *new;
+   struct component_match_array *new;

-   if (match && match->alloc == num)
-   return match;
+   if (match->alloc == num)
+   return 0;

-   new = devm_kmalloc(dev, component_match_size(num), GFP_KERNEL);
+   new = devm_kmalloc_array(dev, num, sizeof(*new), GFP_KERNEL);
if (!new)
-   return ERR_PTR(-ENOMEM);
+   return -ENOMEM;

-   if (match) {
-   memcpy(new, match, component_match_size(min(match->num, num)));
-   devm_kfree(dev, match);
-   } else {
-   new->num = 0;
+   if (match->compare) {
+   memcpy(new, match->compare, sizeof(*new) *
+   min(match->num, num));
+   devm_kfree(dev, match->compare);
}
+   match->compare = new;
+   match->alloc = num;

-   new->alloc = num;
-
-   return new;
+   return 0;
 }

 /*
- * Add a component to be matched.
+ * Add a component to be matched, with a release function.
  *
  * The match array is first created or extended if necessary.
  */
-void component_match_add(struct device *dev, struct component_match **matchptr,
+void component_match_add_release(struct device *master,
+   struct component_match **matchptr,
+   void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data)
 {
struct component_match *match = *matchptr;
@@ -234,23 +251,37 @@ void component_match_add(struct device *dev, struct 
component_match **matchptr,
if (IS_ERR(match))
return;

-   if (!match || match->num == match->alloc) {
-   size_t new_size = match ? match->alloc + 16 :