Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Martin Peres]

On 13/02/17 23:05, Eric Anholt wrote:

I was just trying to provide review to get the kernel unstuck.  The
kernel should not be blocked until the patch gets lands (this obviously
isn't the case with ioctls, which *don't* land in userspace until kernel
does), you just need userspace published and generally agreed that the
ABI works.



Yeah, I found it a bit odd too that we would get such requirement.

Anyway, thanks for taking the time, we will take this as an ACK from 
your side, which should be enough to merge the patch in the kernel.


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

[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics

[bugzilla-daemon]

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

Luya Tshimbalanga (l...@fedoraproject.org) changed:

   What|Removed |Added

 CC||l...@fedoraproject.org

--- Comment #6 from Luya Tshimbalanga (l...@fedoraproject.org) ---
Greetings,
I am the original reported on Freedesktop bug report. I have a similar hardware
in this case Kaveri and R5 M230 (Hainan or Jet Pro). 
The fix as mentioned on comment #5 is working fine.

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

RE: [PATCH] drm/ast: Fixed system hanged if disable P2A

[YC Chen]

Hi Ben,
This solution had been proved on x86 platform but I'm not sure if it works or 
not on POWER system . If we added a definition in SOC scratch register to info 
drm driver the P2A is disabled by BMC fw, then drm driver will no need to check 
it by reading 0xf00x. Is it acceptable?
Here are the flow:
If disable P2A in SOC scratch then ast->DisableP2A = true;
Else if the value of 0xf00x is not 0x_ then ast->DisableP2A = false;

Regards,

Y.C. Chen

-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@au1.ibm.com] 
Sent: Thursday, February 16, 2017 11:58 AM
To: YC Chen ; dri-devel@lists.freedesktop.org
Cc: airl...@redhat.com; e...@suse.com; Russell Currey 
Subject: Re: [PATCH] drm/ast: Fixed system hanged if disable P2A

On Thu, 2017-01-26 at 09:45 +0800, Y.C. Chen wrote:
> From: "Y.C. Chen" 
> 
> The original ast driver will access some BMC configuration through P2A 
> bridge that can be disabled since AST2300 and after.
> It will cause system hanged if P2A bridge is disabled.
> Here is the update to fix it.

Will this work for us on POWER ? The problem we observed is that if P2A is 
disabled, the read from f00x seems to not respond, ie, we get a PCIe target 
abort on the MMIO, not 0x_. That trips our HW error detection mechanism 
"EEH" which will take out the entire device.

Russell (CC) proposed a patch a while ago that seems to have gone nowhere that 
allows the driver to retrieve all the information it needs from the device-tree 
on platforms that support it.

That allows us to grab the necessary info from firmware before the bridge is 
closed (or via some specific BMC interface we have if we close the bridge) and 
pass it to Linux.

Any reason that patch hasn't been merged ? Dave ?

Cheers,
Ben.


> Signed-off-by: Y.C. Chen 
> ---
>  drivers/gpu/drm/ast/ast_drv.h  |   1 +
>  drivers/gpu/drm/ast/ast_main.c | 156 ++-
> --
>  drivers/gpu/drm/ast/ast_post.c |  18 +++--
>  3 files changed, 96 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.h 
> b/drivers/gpu/drm/ast/ast_drv.h index 908011d..7abda94 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -113,6 +113,7 @@ struct ast_private {
>   struct ttm_bo_kmap_obj cache_kmap;
>   int next_cursor;
>   bool support_wide_screen;
> + bool DisableP2A;
>  
>   enum ast_tx_chip tx_chip_type;
>   u8 dp501_maxclk;
> diff --git a/drivers/gpu/drm/ast/ast_main.c 
> b/drivers/gpu/drm/ast/ast_main.c index f75c642..c374685 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -124,6 +124,11 @@ static int ast_detect_chip(struct drm_device 
> *dev, bool *need_post)
>   } else
>   *need_post = false;
>  
> + /* Check P2A Access */
> + ast->DisableP2A = true;
> + data = ast_read32(ast, 0xf004);
> + if (data != 0x) ast->DisableP2A = false;
> +
>   /* Check if we support wide screen */
>   switch (ast->chip) {
>   case AST1180:
> @@ -140,15 +145,17 @@ static int ast_detect_chip(struct drm_device 
> *dev, bool *need_post)
>   ast->support_wide_screen = true;
>   else {
>   ast->support_wide_screen = false;
> - /* Read SCU7c (silicon revision register) */
> - ast_write32(ast, 0xf004, 0x1e6e);
> - ast_write32(ast, 0xf000, 0x1);
> - data = ast_read32(ast, 0x1207c);
> - data &= 0x300;
> - if (ast->chip == AST2300 && data == 0x0) /*
> ast1300 */
> - ast->support_wide_screen = true;
> - if (ast->chip == AST2400 && data == 0x100)
> /* ast1400 */
> - ast->support_wide_screen = true;
> + if (ast->DisableP2A == false) {
> + /* Read SCU7c (silicon revision
> register) */
> + ast_write32(ast, 0xf004,
> 0x1e6e);
> + ast_write32(ast, 0xf000, 0x1);
> + data = ast_read32(ast, 0x1207c);
> + data &= 0x300;
> + if (ast->chip == AST2300 && data ==
> 0x0) /* ast1300 */
> + ast->support_wide_screen =
> true;
> + if (ast->chip == AST2400 && data ==
> 0x100) /* ast1400 */
> + ast->support_wide_screen =
> true;
> + }
>   }
>   break;
>   }
> @@ -216,80 +223,81 @@ static int ast_get_dram_info(struct drm_device
> *dev)
>   uint32_t data, data2;
>   uint32_t denum, num, div, ref_pll;
>  
> - ast_write32(ast, 0xf004, 0x1e6e);
> - ast_write32(ast, 0xf000, 0x1);
> -
> -
> - 

Re: [PATCH] dma-buf/dma-fence: improve doc for dma_fence_add_callback()

[Sumit Semwal]

Hi Gustavo,


On 16 February 2017 at 02:27, Chris Wilson  wrote:
> On Wed, Feb 15, 2017 at 03:57:25PM -0200, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Document return values for this function.
>>
>> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Chris Wilson 
> -Chris
>
Thanks, pushed to drm-misc.

> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ast: Support AST2500

[Dave Airlie]

On 11 January 2017 at 12:57, Y.C. Chen  wrote:
> From: "Y.C. Chen" 

Please run checkpatch over this patch, it's got a lot of bad whitespace issues
(4 space and 2 space indents, indent the timing tables , remove start
of line whitespace.).

Dave.

>
> Signed-off-by: Y.C. Chen 
> ---
>  drivers/gpu/drm/ast/ast_drv.h|   2 +
>  drivers/gpu/drm/ast/ast_main.c   |  27 ++-
>  drivers/gpu/drm/ast/ast_mode.c   |  25 +-
>  drivers/gpu/drm/ast/ast_post.c   | 510 
> ++-
>  drivers/gpu/drm/ast/ast_tables.h |  57 -
>  5 files changed, 596 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 908011d..7e406ce 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -64,6 +64,7 @@ enum ast_chip {
> AST2150,
> AST2300,
> AST2400,
> +   AST2500,
> AST1180,
>  };
>
> @@ -80,6 +81,7 @@ enum ast_tx_chip {
>  #define AST_DRAM_1Gx32   3
>  #define AST_DRAM_2Gx16   6
>  #define AST_DRAM_4Gx16   7
> +#define AST_DRAM_8Gx16   8
>
>  struct ast_fbdev;
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index f75c642..40460ce 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -73,7 +73,10 @@ static int ast_detect_chip(struct drm_device *dev, bool 
> *need_post)
> ast->chip = AST1100;
> DRM_INFO("AST 1180 detected\n");
> } else {
> -   if (dev->pdev->revision >= 0x30) {
> +   if (dev->pdev->revision >= 0x40) {
> +   ast->chip = AST2500;
> +   DRM_INFO("AST 2500 detected\n");
> +   } else if (dev->pdev->revision >= 0x30) {
> ast->chip = AST2400;
> DRM_INFO("AST 2400 detected\n");
> } else if (dev->pdev->revision >= 0x20) {
> @@ -149,6 +152,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
> *need_post)
> ast->support_wide_screen = true;
> if (ast->chip == AST2400 && data == 0x100) /* ast1400 
> */
> ast->support_wide_screen = true;
> +   if (ast->chip == AST2500 && data == 0x100) /* ast2510 
> */
> +   ast->support_wide_screen = true;
> }
> break;
> }
> @@ -233,7 +238,24 @@ static int ast_get_dram_info(struct drm_device *dev)
> else
> ast->dram_bus_width = 32;
>
> -   if (ast->chip == AST2300 || ast->chip == AST2400) {
> +   if (ast->chip == AST2500) {
> +   switch (data & 0x03) {
> +   case 0:
> +   ast->dram_type = AST_DRAM_1Gx16;
> +   break;
> +   default:
> +   case 1:
> +   ast->dram_type = AST_DRAM_2Gx16;
> +   break;
> +   case 2:
> +   ast->dram_type = AST_DRAM_4Gx16;
> +   break;
> +   case 3:
> +   ast->dram_type = AST_DRAM_8Gx16;
> +   break;
> +   }
> +   }
> +   else if (ast->chip == AST2300 || ast->chip == AST2400) {
> switch (data & 0x03) {
> case 0:
> ast->dram_type = AST_DRAM_512Mx16;
> @@ -456,6 +478,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
> flags)
> ast->chip == AST2200 ||
> ast->chip == AST2300 ||
> ast->chip == AST2400 ||
> +   ast->chip == AST2500 ||
> ast->chip == AST1180) {
> dev->mode_config.max_width = 1920;
> dev->mode_config.max_height = 2048;
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index e26c98f..242ca7f 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -271,7 +271,10 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, 
> struct drm_display_mode *mod
>  {
> struct ast_private *ast = crtc->dev->dev_private;
> u8 jreg05 = 0, jreg07 = 0, jreg09 = 0, jregAC = 0, jregAD = 0, jregAE 
> = 0;
> -   u16 temp;
> +   u16 temp, precache = 0;
> +
> +if ((ast->chip == AST2500) && (vbios_mode->enh_table->flags & 
> AST2500PreCatchCRT))
> +   precache = 40;
>
> ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x11, 0x7f, 0x00);
>
> @@ -297,12 +300,12 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, 
> struct drm_display_mode *mod
> jregAD |= 0x01;  /* HBE D[5] */
> ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x03, 0xE0, (temp & 
> 0x1f));
>
> -   temp = (mode->crtc_hsync_start >> 3) - 1;
> +   temp = ((mode->crtc_hsync_start-precache) >> 3) - 1;
> 

Re: [PATCH v3 10/23] drm: hibmc: use vblank hooks in struct drm_crtc_funcs

[Xinliang Liu]

On 7 February 2017 at 17:16, Shawn Guo  wrote:
> From: Shawn Guo 
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by: Shawn Guo 
> Cc: Xinliang Liu 

Thanks Shawn for the rework patches,
For the hibmc,
Reviewed-by: Xinliang Liu 

Thanks,
-xinliang

> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 20 
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 22 --
>  2 files changed, 20 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> index c655883d3613..59542bddc980 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -423,6 +423,24 @@ static void hibmc_crtc_atomic_flush(struct drm_crtc 
> *crtc,
> spin_unlock_irqrestore(>dev->event_lock, flags);
>  }
>
> +static int hibmc_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> +   struct hibmc_drm_private *priv = crtc->dev->dev_private;
> +
> +   writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
> +  priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> +
> +   return 0;
> +}
> +
> +static void hibmc_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> +   struct hibmc_drm_private *priv = crtc->dev->dev_private;
> +
> +   writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
> +  priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> +}
> +
>  static const struct drm_crtc_funcs hibmc_crtc_funcs = {
> .page_flip = drm_atomic_helper_page_flip,
> .set_config = drm_atomic_helper_set_config,
> @@ -430,6 +448,8 @@ static void hibmc_crtc_atomic_flush(struct drm_crtc *crtc,
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state =  drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> +   .enable_vblank = hibmc_crtc_enable_vblank,
> +   .disable_vblank = hibmc_crtc_disable_vblank,
>  };
>
>  static const struct drm_crtc_helper_funcs hibmc_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 8cac70454b57..2ffdbf9801bd 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -37,26 +37,6 @@
> .llseek = no_llseek,
>  };
>
> -static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
> -{
> -   struct hibmc_drm_private *priv =
> -   (struct hibmc_drm_private *)dev->dev_private;
> -
> -   writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
> -  priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> -
> -   return 0;
> -}
> -
> -static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
> -{
> -   struct hibmc_drm_private *priv =
> -   (struct hibmc_drm_private *)dev->dev_private;
> -
> -   writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
> -  priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> -}
> -
>  irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>  {
> struct drm_device *dev = (struct drm_device *)arg;
> @@ -84,8 +64,6 @@ irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
> .desc   = "hibmc drm driver",
> .major  = 1,
> .minor  = 0,
> -   .enable_vblank  = hibmc_enable_vblank,
> -   .disable_vblank = hibmc_disable_vblank,
> .gem_free_object_unlocked = hibmc_gem_free_object,
> .dumb_create= hibmc_dumb_create,
> .dumb_map_offset= hibmc_dumb_mmap_offset,
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 11/23] drm: kirin: use vblank hooks in struct drm_crtc_funcs

[Xinliang Liu]

On 7 February 2017 at 17:16, Shawn Guo  wrote:
> From: Shawn Guo 
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by: Shawn Guo 
> Cc: Xinliang Liu 

Thanks Shawn for the rework patches,
For the kirin,
Reviewed-by: Xinliang Liu 

Thanks,
-xinliang

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 0624fab8046f..c96c228a9898 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -302,9 +302,8 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
>SOCKET_QOS_EN, SOCKET_QOS_EN);
>  }
>
> -static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
> +static int ade_crtc_enable_vblank(struct drm_crtc *crtc)
>  {
> -   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> struct ade_crtc *acrtc = to_ade_crtc(crtc);
> struct ade_hw_ctx *ctx = acrtc->ctx;
> void __iomem *base = ctx->base;
> @@ -318,9 +317,8 @@ static int ade_enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
> return 0;
>  }
>
> -static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
> +static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
>  {
> -   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> struct ade_crtc *acrtc = to_ade_crtc(crtc);
> struct ade_hw_ctx *ctx = acrtc->ctx;
> void __iomem *base = ctx->base;
> @@ -570,6 +568,8 @@ static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
> .set_property = drm_atomic_helper_crtc_set_property,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
> +   .enable_vblank  = ade_crtc_enable_vblank,
> +   .disable_vblank = ade_crtc_disable_vblank,
>  };
>
>  static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> @@ -1025,8 +1025,6 @@ static int ade_drm_init(struct platform_device *pdev)
>IRQF_SHARED, dev->driver->name, acrtc);
> if (ret)
> return ret;
> -   dev->driver->enable_vblank = ade_enable_vblank;
> -   dev->driver->disable_vblank = ade_disable_vblank;
>
> return 0;
>  }
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/7] dt-bindings: display: add STM32 LTDC driver

[Rob Herring]

On Fri, Feb 10, 2017 at 04:24:28PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre 
> ---
>  .../devicetree/bindings/display/st,stm32-ltdc.txt  | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
> b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> new file mode 100644
> index 000..b93e1c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> @@ -0,0 +1,37 @@
> +* STMicroelectronics STM32 lcd-tft display controller
> +
> +- ltdc: lcd-tft display controller host
> +  must be a sub-node of st-display-subsystem
> +  Required properties:
> +  - compatible: "st,stm32-ltdc"

Kind of generic. There's only one version for all stm32 parts?

> +  - reg: Physical base address of the IP registers and length of memory 
> mapped region.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ltdc it should contain:
> +  - "clk-lcd" for the clock feeding the output pixel clock & IP clock.
> +  - resets: reset to be used by the device (defined by use of RCC macro).
> +  Required nodes:
> +- Video port for RGB output.
> +
> +Example:
> +
> +/ {
> + ...
> + soc {
> + ...
> + ltdc: stm32-ltdc@40016800 {

display-controller@...

> + compatible = "st,stm32-ltdc";
> + reg = <0x40016800 0x200>;
> + interrupts = <88>, <89>;
> + resets = < STM32F4_APB2_RESET(LTDC)>;
> + clocks = < 1 CLK_LCD>;
> + clock-names = "lcd";
> + status = "disabled";

Don't need to show status in examples.

> +
> + port {
> + ltdc_out_rgb: endpoint {
> + };
> + };
> + };
> + };
> +};
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY

[Chris Zhong]

Hi Rob

On 02/16/2017 10:20 AM, Rob Herring wrote:

On Fri, Feb 10, 2017 at 03:44:11PM +0800, Chris Zhong wrote:

rockchip,uphy-dp-sel is the register of type-c phy enable DP function.

"dt-bindings: phy:" is the preferred subject prefix.

OK, I will change the header next version.
dt-bindings: phy: add uphy-dp-sel for Rockchip USB Type-C PHY.




Signed-off-by: Chris Zhong 
---

  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
  1 file changed, 5 insertions(+)

Otherwise,

Acked-by: Rob Herring 






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

[GIT PULL] drm/rockchip: convert to drm_mm

[Mark yao]

  
  
Hi Dave

After convert to drm_mm, rockchip arm64 platform can works with
iommu, like rk3399. it's import patches for rockchip arm64 platform

And these patches already have full reviewed, I hope these patches
can be landed.

  
Best regards

The following changes since commit
13f62f54d174d3417c3caaafedf5e22a0a03e442:

  Merge branch 'drm-next-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2017-02-10
10:13:30 +1000)

are available in the git repository at:


  https://github.com/markyzq/kernel-drm-rockchip.git
drm-rockchip-next-2017-02-16

for you to fetch changes up to
1aa5ca6e3ec63aa5815d78646748e88a7ceb1c8e:

  drm/rockchip: Use common IOMMU API to attach devices (2017-02-15
08:52:13 +0800)


Shunqian Zheng (1):
  drm/rockchip: Use common IOMMU API to attach devices

Tomasz Figa (1):
  drm/rockchip: Do not use DMA mapping API if attached to IOMMU
domain

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 101
-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 244
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 4 files changed, 298 insertions(+), 61 deletions(-)


-- Ｍark Yao
  


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

Re: [PATCH v3 22/24] drm/rockchip: dw-mipi-dsi: support non-burst modes

[Chris Zhong]

Hi John

On 02/01/2017 03:22 AM, Sean Paul wrote:

On Sun, Jan 29, 2017 at 01:24:42PM +, John Keeping wrote:

Reviewed-by: Sean Paul 


Signed-off-by: John Keeping 
Reviewed-by: Chris Zhong 
---
v3:
- Add Chris' Reviewed-by
Unchanged in v2

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +---
  1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 5bad92e2370e..58cb8ace2fe8 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -82,6 +82,7 @@
  #define FRAME_BTA_ACK BIT(14)
  #define ENABLE_LOW_POWER  (0x3f << 8)
  #define ENABLE_LOW_POWER_MASK (0x3f << 8)
+#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
  #define VID_MODE_TYPE_BURST_SYNC_PULSES   0x2

This field indicates the video mode transmission type as follows:
00: Non-burst with sync pulses
01: Non-burst with sync events
10 and 11: Burst mode

So, I think define the macro like this is better:

#define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
#define VID_MODE_TYPE_BURST0x2



  #define VID_MODE_TYPE_MASK0x3
  
@@ -286,6 +287,7 @@ struct dw_mipi_dsi {

u32 format;
u16 input_div;
u16 feedback_div;
+   unsigned long mode_flags;
  
  	const struct dw_mipi_dsi_plat_data *pdata;

  };
@@ -551,15 +553,10 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
*host,
return -EINVAL;
}
  
-	if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ||

-   !(device->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)) {
-   dev_err(dsi->dev, "device mode is unsupported\n");
-   return -EINVAL;
-   }
-
dsi->lanes = device->lanes;
dsi->channel = device->channel;
dsi->format = device->format;
+   dsi->mode_flags = device->mode_flags;
dsi->panel = of_drm_find_panel(device->dev.of_node);
if (dsi->panel)
return drm_panel_attach(dsi->panel, >connector);
@@ -716,7 +713,12 @@ static void dw_mipi_dsi_video_mode_config(struct 
dw_mipi_dsi *dsi)
  {
u32 val;
  
-	val = VID_MODE_TYPE_BURST_SYNC_PULSES | ENABLE_LOW_POWER;

+   val = ENABLE_LOW_POWER;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+   val |= VID_MODE_TYPE_BURST_SYNC_PULSES;
+   else if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
+   val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;


if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
val |= VID_MODE_TYPE_BURST;
else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
val |= VID_MODE_TYPE_NON_BURST_SYNC_PULSES;
else
val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;



  
  	dsi_write(dsi, DSI_VID_MODE_CFG, val);

  }
--
2.11.0.197.gb556de5.dirty

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



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

Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

[Rob Herring]

On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre 
> ---
>  .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>  
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> new file mode 100644
> index 000..f59e3c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> @@ -0,0 +1,7 @@
> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "ampire,am-480272h3tmqw-t01h"

No GPIO controls or power supply for this panel?

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

Re: [PATCH 1/4] Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY

[Rob Herring]

On Fri, Feb 10, 2017 at 03:44:11PM +0800, Chris Zhong wrote:
> rockchip,uphy-dp-sel is the register of type-c phy enable DP function.

"dt-bindings: phy:" is the preferred subject prefix.

> 
> Signed-off-by: Chris Zhong 
> ---
> 
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
>  1 file changed, 5 insertions(+)

Otherwise,

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

Re: [PATCH v3 23/24] drm/rockchip: dw-mipi-dsi: add reset control

[Chris Zhong]

Hi John

On 02/15/2017 08:39 PM, John Keeping wrote:

On Wed, 15 Feb 2017 11:38:45 +0800, Chris Zhong wrote:


On 01/29/2017 09:24 PM, John Keeping wrote:

In order to fully reset the state of the MIPI controller we must assert
this reset.

This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.

Signed-off-by: John Keeping 
Reviewed-by: Chris Zhong 
---
v3:
- Add Chris' Reviewed-by
Unchanged in v2

   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 30 ++
   1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 58cb8ace2fe8..cf3ca6b0cbdb 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -13,6 +13,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -1124,6 +1125,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
of_match_device(dw_mipi_dsi_dt_ids, dev);
const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
struct platform_device *pdev = to_platform_device(dev);
+   struct reset_control *apb_rst;
struct drm_device *drm = data;
struct dw_mipi_dsi *dsi;
struct resource *res;
@@ -1162,6 +1164,34 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
return ret;
}
   
+	/*

+* Note that the reset was not defined in the initial device tree, so
+* we have to be prepared for it not being found.
+*/
+   apb_rst = devm_reset_control_get(dev, "apb");
+   if (IS_ERR(apb_rst)) {
+   if (PTR_ERR(apb_rst) == -ENODEV) {

According to [0], I think it should be -ENOENT here.

Nice catch, I'll fix this.


[0]
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3d81216fde465e76c5eae98f61d3666163634395

commit 3d81216fde465e76c5eae98f61d3666163634395
Author: Alban Bedel 
Date:   Tue Sep 1 17:28:31 2015 +0200

  reset: Fix of_reset_control_get() for consistent return values

  When of_reset_control_get() is called without connection ID it returns
  -ENOENT when the 'resets' property doesn't exists or is an empty entry.
  However when a connection ID is given it returns -EINVAL when the
'resets'
  property doesn't exists or the requested name can't be found. This is
  because the error code returned by of_property_match_string() is just
  passed down as an index to of_parse_phandle_with_args(), which then
  returns -EINVAL.

  To get a consistent return value with both code paths we must return
  -ENOENT when of_property_match_string() fails.

  Signed-off-by: Alban Bedel 
  Signed-off-by: Philipp Zabel 



+   apb_rst = NULL;
+   } else {
+   dev_err(dev, "Unable to get reset control: %d\n", ret);

Also, we can not get error number from "ret" here.


+   return PTR_ERR(apb_rst);
+   }
+   }
+
+   if (apb_rst) {
+   ret = clk_prepare_enable(dsi->pclk);
+   if (ret) {
+   dev_err(dev, "%s: Failed to enable pclk\n", __func__);
+   return ret;
+   }
+
+   reset_control_assert(apb_rst);
+   usleep_range(10, 20);
+   reset_control_deassert(apb_rst);
+
+   clk_disable_unprepare(dsi->pclk);
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);








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

Re: [PATCH v2 3/3] drm/amdgpu: fix lock cleanup during buffer creation

[Michel Dänzer]

On 16/02/17 04:10 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> Open-code the initial ttm_bo_validate call, so that we can properly
> unlock the reservation lock when it fails. Also, properly destruct
> the reservation object when the first part of TTM BO initialization
> fails.
> 
> Actual deadlocks caused by the missing unlock should have been fixed
> by "drm/ttm: never add BO that failed to validate to the LRU list",
> superseding the flawed fix in commit 38fc4856ad98 ("drm/amdgpu: fix
> a potential deadlock in amdgpu_bo_create_restricted()").
> 
> This change fixes remaining recursive locking errors that can be seen
> with lock debugging enabled, and avoids the error of freeing a locked
> mutex.
> 
> v2: use ttm_bo_unref for error handling, and rebase on latest changes
> 
> Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED 
> handling (v2)")
> Signed-off-by: Nicolai Hähnle 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index c2e57f7..15944ea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -404,15 +404,31 @@ int amdgpu_bo_create_restricted(struct amdgpu_device 
> *adev,
>   }
>  
>   initial_bytes_moved = atomic64_read(>num_bytes_moved);
> - r = ttm_bo_init(>mman.bdev, >tbo, size, type,
> - >placement, page_align, !kernel, NULL,
> - acc_size, sg, resv ? resv : >tbo.ttm_resv,
> - _ttm_bo_destroy);
> + r = ttm_bo_init_top(>mman.bdev, >tbo, size, type,
> + page_align, NULL,
> + acc_size, sg, resv ? resv : >tbo.ttm_resv,
> + _ttm_bo_destroy);
> +
> + if (likely(r == 0))
> + r = ttm_bo_validate(>tbo, >placement, !kernel, false);
> +
> + if (unlikely(r != 0)) {
> + struct ttm_buffer_object *tbo = >tbo;
> +
> + if (!resv)
> + ww_mutex_unlock(>tbo.ttm_resv.lock);
> + ttm_bo_unref();
> + return r;
> + }

I think this would be clearer as

if (unlikely(r != 0)) {
struct ttm_buffer_object *tbo = >tbo;

if (!resv)
ww_mutex_unlock(>tbo.ttm_resv.lock);
ttm_bo_unref();
return r;
}

r = ttm_bo_validate(>tbo, >placement, !kernel, false);
[...]


>   amdgpu_cs_report_moved_bytes(adev,
>   atomic64_read(>num_bytes_moved) - initial_bytes_moved);
>  
> - if (unlikely(r != 0))
> - return r;
> + if (!(bo->tbo.mem.placement & TTM_PL_FLAG_NO_EVICT)) {
> + spin_lock(>tbo.glob->lru_lock);
> + ttm_bo_add_to_lru(>tbo);
> + spin_unlock(>tbo.glob->lru_lock);
> + }

It's a bit ugly to open-code this logic in driver code. Maybe add
another TTM helper which calls ttm_bo_validate and ttm_bo_add_to_lru?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

[Nicolai Hähnle]

On 15.02.2017 14:35, Nicolai Hähnle wrote:

On 14.02.2017 13:51, Christian König wrote:

Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:

On 14.02.2017 11:49, Christian König wrote:

Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.

Signed-off-by: Nicolai Hähnle 


Please squash that into your other patch. It fixes another bug, but I
don't think fixing one bug just to run into another is really a good
idea.


I don't understand. I'm not aware that this patch fixes anything, it
just enables the subsequent fix in amdgpu in patch #2. I don't think
squashing those together is a good idea (one is in ttm, the other in
amdgpu).


Ok, forget it I've messed up the different reference count.

With at least initializing bo->kref and bo->destroy before returning the
first error the patch is Reviewed-by: Christian König
.


Thanks. Does this apply to patches #2 and #3 as well?


Well, there's some minor necessary rebase fixes, so I'll probably just 
send out a new version once I got to test it.


Nicolai

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

[PULL] mxsfb fixes

[Marek Vasut]

Hi,

I collected the MXSFB fixes, based on top of airlied/drm-fixes:

The following changes since commit 697d3a21615672b2bf7724a65755799260325dda:

  Merge tag 'drm-intel-fixes-2017-02-09' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2017-02-10
10:14:24 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git
d7a280f2cc3860b0783fac9e8c5c223b8bdaea5c

for you to fetch changes up to d7a280f2cc3860b0783fac9e8c5c223b8bdaea5c:

  drm: mxsfb: Implement drm_panel handling (2017-02-14 05:35:56 +0100)


Fabio Estevam (2):
  drm: mxsfb_crtc: Fix the framebuffer misplacement
  drm: mxsfb: Implement drm_panel handling

Marek Vasut (1):
  drm: mxsfb: Fix crash when provided invalid DT bindings

Stefan Agner (2):
  drm: mxsfb: use bus_format to determine LCD bus width
  drm: mxsfb: fix pixel clock polarity

 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 49
+++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 
 drivers/gpu/drm/mxsfb/mxsfb_out.c  |  4 
 drivers/gpu/drm/mxsfb/mxsfb_regs.h |  1 +
 4 files changed, 52 insertions(+), 6 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

[Nicolai Hähnle]

On 15.02.2017 04:16, zhoucm1 wrote:



On 2017年02月14日 18:37, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.

Signed-off-by: Nicolai Hähnle 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 62
+---
  include/drm/ttm/ttm_bo_api.h | 45 
  2 files changed, 86 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 76bee42..ce4c0f5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1120,41 +1120,30 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
  }
  EXPORT_SYMBOL(ttm_bo_validate);
  -int ttm_bo_init(struct ttm_bo_device *bdev,
-struct ttm_buffer_object *bo,
-unsigned long size,
-enum ttm_bo_type type,
-struct ttm_placement *placement,
-uint32_t page_alignment,
-bool interruptible,
-struct file *persistent_swap_storage,
-size_t acc_size,
-struct sg_table *sg,
-struct reservation_object *resv,
-void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init_top(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+uint32_t page_alignment,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
  {
  int ret = 0;
  unsigned long num_pages;
  struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
-bool locked;
ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
  if (ret) {
  pr_err("Out of kernel memory\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  return -ENOMEM;
  }
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
  if (num_pages == 0) {
  pr_err("Illegal buffer object size\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  ttm_mem_global_free(mem_glob, acc_size);
  return -EINVAL;
  }
@@ -1204,6 +1193,37 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
  ret = drm_vma_offset_add(>vma_manager, >vma_node,
   bo->mem.num_pages);

if (ret && !resv), we should call
reservation_object_fini(>ttm_resv), right?


FWIW, you were right about this (and also mutex_destroy needs to be 
called for wu_mutex, etc.). But I'm following Christian's suggestion of 
having the caller use ttm_bo_unref for error cleanup, so all this error 
cleanup needn't be duplicated.


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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> Hi,
> 
> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> > bandwidth to drm_atomic_state would mean that a non-core object will be
> > modified by the core helper functions for swapping and clearing
> > it's state. So, lets add void * objects and helper functions that operate
> > on void * types to keep these objects and states private to the core.
> > Drivers can then implement specific functions to swap and clear states.
> > The other advantage having just void * for these objects in
> > drm_atomic_state is that objects of different types can be managed in the
> > same state array.
> >
> > v2: Added docs and new iterator to filter private objects (Daniel)
> >
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 68 +++
> >  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
> >  include/drm/drm_atomic.h| 91 
> > +
> >  3 files changed, 164 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index a567310..1a9ffe8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> > drm_atomic_state *state)
> > kfree(state->connectors);
> > kfree(state->crtcs);
> > kfree(state->planes);
> > +   kfree(state->private_objs);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >
> > @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> > drm_atomic_state *state)
> > state->planes[i].ptr = NULL;
> > state->planes[i].state = NULL;
> > }
> > +
> > +   for (i = 0; i < state->num_private_objs; i++) {
> > +   void *private_obj = state->private_objs[i].obj;
> > +   void *obj_state = state->private_objs[i].obj_state;
> > +
> > +   if (!private_obj)
> > +   continue;
> > +
> > +   state->private_objs[i].funcs->destroy_state(obj_state);
> > +   state->private_objs[i].obj = NULL;
> > +   state->private_objs[i].obj_state = NULL;
> > +   state->private_objs[i].funcs = NULL;
> > +   }
> > +
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >
> > @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> > drm_printer *p,
> >  }
> >
> >  /**
> > + * drm_atomic_get_private_obj_state - get private object state
> > + * @state: global atomic state
> > + * @obj: private object to get the state for
> > + * @funcs: pointer to the struct of function pointers that identify the 
> > object
> > + * type
> > + *
> > + * This function returns the private object state for the given private 
> > object,
> > + * allocating the state if needed. It does not grab any locks as the 
> > caller is
> > + * expected to care of any required locking.
> > + *
> > + * RETURNS:
> > + *
> > + * Either the allocated state or the error code encoded into a pointer.
> > + */
> > +void *
> > +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
> > + const struct drm_private_state_funcs *funcs)
> > +{
> > +   int index, num_objs, i;
> > +   size_t size;
> > +   struct __drm_private_objs_state *arr;
> > +
> > +   for (i = 0; i < state->num_private_objs; i++)
> > +   if (obj == state->private_objs[i].obj &&
> > +   state->private_objs[i].obj_state)
> > +   return state->private_objs[i].obj_state;
> 
> Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, 
> it
> doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. 
> I
> don't understand the locking stuff toowell, I just noticed this difference 
> when
> comparing this approach with what is done in the msm kms driver (where we
> have subclassed drm_atomic_state to msm_kms_state).
> 
> Thanks,
> Archit
> 


The caller is expected to take care of any required locking. The
driver-private objects are opaque from core's pov, so the core is not
aware of necessary locks for that object type.

-DK 

> > +
> > +   num_objs = state->num_private_objs + 1;
> > +   size = sizeof(*state->private_objs) * num_objs;
> > +   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> > +   if (!arr)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   state->private_objs = arr;
> > +   index = state->num_private_objs;
> > +   memset(>private_objs[index], 0, sizeof(*state->private_objs));
> > +
> > +   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
> > obj);
> > +   if (!state->private_objs[index].obj_state)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   state->private_objs[index].obj = 

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

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

--- Comment #43 from Micha  ---
Same for Warzone2100 (and others?) on latest Mint Mate with Oibaf ppa, too.
Still the same problems.

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

Re: [PATCH 6/8] dt-bindings: gpu: mali: Add optional OPPs

[Rob Herring]

On Thu, Feb 09, 2017 at 05:39:20PM +0100, Maxime Ripard wrote:
> The operating-points-v2 binding gives a way to provide the OPP of the GPU.
> Let's use it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 
>  1 file changed, 4 insertions(+), 0 deletions(-)

Bindings should not unnecessarily evolve. The h/w does not evolve in 
this way. This should have been part of the original binding given that 
it was just added.

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

[PATCH] drm: drm_printer: add __printf validation

[Joe Perches]

drm_printf does not currently use the compiler to verify
format and arguments.  Make it do so.

Miscellanea:

o Add appropriate #include files for __printf and struct va_format
o Convert dev_printk to dev_info

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/drm_print.c | 2 +-
 include/drm/drm_print.h | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 02a107d50706..74c466aca622 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -36,7 +36,7 @@ EXPORT_SYMBOL(__drm_printfn_seq_file);
 
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf)
 {
-   dev_printk(KERN_INFO, p->arg, "[" DRM_NAME "] %pV", vaf);
+   dev_info(p->arg, "[" DRM_NAME "] %pV", vaf);
 }
 EXPORT_SYMBOL(__drm_printfn_info);
 
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 7d98763c0444..ca4d7c6321f2 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -26,6 +26,8 @@
 #ifndef DRM_PRINT_H_
 #define DRM_PRINT_H_
 
+#include 
+#include 
 #include 
 #include 
 
@@ -75,6 +77,7 @@ void __drm_printfn_seq_file(struct drm_printer *p, struct 
va_format *vaf);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
 
+__printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
 
 
-- 
2.10.0.rc2.1.g053435c

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

Re: [PATCH 8/8] ARM: sun8i: a33: Add the Mali OPPs

[Rob Herring]

On Thu, Feb 09, 2017 at 05:39:22PM +0100, Maxime Ripard wrote:
> The Mali GPU in the A33 has various operating frequencies used in the
> Allwinner BSP.
> 
> Add them to our DT.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sun8i-a33.dtsi | 17 +
>  1 file changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi 
> b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 043b1b017276..e1b0abfee42f 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -101,6 +101,22 @@
>   status = "disabled";
>   };
>  
> + mali_opp_table: opp_table1 {

gpu-opp-table

> + compatible = "operating-points-v2";
> +
> + opp@14400 {
> + opp-hz = /bits/ 64 <14400>;
> + };
> +
> + opp@24000 {
> + opp-hz = /bits/ 64 <24000>;
> + };
> +
> + opp@38400 {
> + opp-hz = /bits/ 64 <38400>;
> + };
> + };
> +
>   memory {
>   reg = <0x4000 0x8000>;
>   };
> @@ -282,6 +298,7 @@
>  
>   {
>   memory-region = <_pool>;
> + operating-points-v2 = <_opp_table>;
>  };
>  
>   {
> -- 
> git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/8] dt-bindings: gpu: mali: Add optional memory-region

[Rob Herring]

On Thu, Feb 09, 2017 at 05:39:16PM +0100, Maxime Ripard wrote:
> The reserved memory bindings allow us to specify which memory areas our
> buffers can be allocated from.
> 
> Let's use it.

You didn't think of this when you just added Mali binding? 

> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 
>  1 file changed, 4 insertions(+), 0 deletions(-)

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

Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel

[Rob Herring]

On Thu, Feb 09, 2017 at 02:14:27PM +0100, Maxime Ripard wrote:
> The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
> can drive 18-bits 240x320 LCD displays.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 37 
> +
>  1 file changed, 37 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt

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

Re: [PATCH 1/3] dt-bindings: Document the dmas and dma-names properties for VC4 HDMI

[Rob Herring]

On Tue, Feb 07, 2017 at 01:07:01PM -0800, Eric Anholt wrote:
> From: Boris Brezillon 
> 
> These are optional, but necessary for HDMI audio support.
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Eric Anholt 
> ---
>  Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++
>  1 file changed, 3 insertions(+)

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

[PATCH 11/14] drm: qxl: Atomic phase 3: Use atomic handlers for planes

[Gabriel Krisman Bertazi]

Now that the state objects are wired up, we can move to the final atomic
handlers.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index d1c12ac222b7..52c4e643331a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -763,8 +763,8 @@ static const struct drm_plane_helper_funcs 
qxl_cursor_helper_funcs = {
 };
 
 static const struct drm_plane_funcs qxl_cursor_plane_funcs = {
-   .update_plane   = drm_plane_helper_update,
-   .disable_plane  = drm_plane_helper_disable,
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_primary_helper_destroy,
.reset  = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
@@ -785,8 +785,8 @@ static const struct drm_plane_helper_funcs 
primary_helper_funcs = {
 };
 
 static const struct drm_plane_funcs qxl_primary_plane_funcs = {
-   .update_plane   = drm_plane_helper_update,
-   .disable_plane  = drm_primary_helper_disable,
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_primary_helper_destroy,
.reset  = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
@@ -1161,6 +1161,8 @@ qxl_user_framebuffer_create(struct drm_device *dev,
 
 static const struct drm_mode_config_funcs qxl_mode_funcs = {
.fb_create = qxl_user_framebuffer_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 int qxl_create_monitors_object(struct qxl_device *qdev)
-- 
2.11.0

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

[PATCH 13/14] drm: qxl: Atomic phase 3: Wire up atomic page_flip helper

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 47 +--
 1 file changed, 1 insertion(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index f86e194ed797..2cd14bebc49c 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -278,55 +278,10 @@ static void qxl_crtc_destroy(struct drm_crtc *crtc)
kfree(qxl_crtc);
 }
 
-static int qxl_crtc_page_flip(struct drm_crtc *crtc,
-  struct drm_framebuffer *fb,
-  struct drm_pending_vblank_event *event,
-  uint32_t page_flip_flags)
-{
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_framebuffer *qfb_src = to_qxl_framebuffer(fb);
-   struct qxl_framebuffer *qfb_old = to_qxl_framebuffer(crtc->primary->fb);
-   struct qxl_bo *bo_old = gem_to_qxl_bo(qfb_old->obj);
-   struct qxl_bo *bo = gem_to_qxl_bo(qfb_src->obj);
-   unsigned long flags;
-   struct drm_clip_rect norect = {
-   .x1 = 0,
-   .y1 = 0,
-   .x2 = fb->width,
-   .y2 = fb->height
-   };
-   int inc = 1;
-   int one_clip_rect = 1;
-   int ret = 0;
-
-   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
-
-   bo_old->is_primary = false;
-   bo->is_primary = true;
-
-   ret = qxl_bo_pin(bo, bo->type, NULL);
-   if (ret)
-   return ret;
-
-   qxl_draw_dirty_fb(qdev, qfb_src, bo, 0, 0,
- , one_clip_rect, inc);
-
-   if (event) {
-   spin_lock_irqsave(>event_lock, flags);
-   drm_crtc_send_vblank_event(crtc, event);
-   spin_unlock_irqrestore(>event_lock, flags);
-   }
-
-   qxl_bo_unpin(bo);
-
-   return 0;
-}
-
 static const struct drm_crtc_funcs qxl_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = qxl_crtc_destroy,
-   .page_flip = qxl_crtc_page_flip,
+   .page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
-- 
2.11.0

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

[PATCH 14/14] drm: qxl: Enable atomic modesetting ioctl

[Gabriel Krisman Bertazi]

Now that atomic support is implemented, enable the atomic flag.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 67e94f4f3ce8..215ef001b718 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -259,7 +259,8 @@ static struct pci_driver qxl_pci_driver = {
 
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
-  DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
+  DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED |
+  DRIVER_ATOMIC,
 
.set_busid = drm_pci_set_busid,
 
-- 
2.11.0

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

[PATCH 12/14] drm: qxl: Atomic phase 3: Wire up atomic set_config helper

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 52c4e643331a..f86e194ed797 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -324,7 +324,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_funcs qxl_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.destroy = qxl_crtc_destroy,
.page_flip = qxl_crtc_page_flip,
.reset = drm_atomic_helper_crtc_reset,
@@ -467,13 +467,6 @@ static void qxl_monitors_config_set(struct qxl_device 
*qdev,
 
 }
 
-static void qxl_crtc_prepare(struct drm_crtc *crtc)
-{
-   DRM_DEBUG("current: %dx%d+%d+%d (%d).\n",
- crtc->mode.hdisplay, crtc->mode.vdisplay,
- crtc->x, crtc->y, crtc->enabled);
-}
-
 void qxl_mode_set_nofb(struct drm_crtc *crtc)
 {
struct qxl_device *qdev = crtc->dev->dev_private;
@@ -507,9 +500,7 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.dpms = qxl_crtc_dpms,
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
-   .mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = qxl_mode_set_nofb,
-   .prepare = qxl_crtc_prepare,
.commit = qxl_crtc_commit,
.atomic_flush = qxl_crtc_atomic_flush,
 };
-- 
2.11.0

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

[PATCH 06/14] drm: qxl: Atomic phase 1: Use drm_plane_helpers for primary plane

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 101 +-
 1 file changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index fef464730c9b..8ccf62ae0efd 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -252,6 +252,23 @@ static int qxl_add_common_modes(struct drm_connector 
*connector,
return i - 1;
 }
 
+static void qxl_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_crtc_state)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_pending_vblank_event *event;
+   unsigned long flags;
+
+   if (crtc->state && crtc->state->event) {
+   event = crtc->state->event;
+   crtc->state->event = NULL;
+
+   spin_lock_irqsave(>event_lock, flags);
+   drm_crtc_send_vblank_event(crtc, event);
+   spin_unlock_irqrestore(>event_lock, flags);
+   }
+}
+
 static void qxl_crtc_destroy(struct drm_crtc *crtc)
 {
struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc);
@@ -553,8 +570,81 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.mode_set = qxl_crtc_mode_set,
.prepare = qxl_crtc_prepare,
.commit = qxl_crtc_commit,
+   .atomic_flush = qxl_crtc_atomic_flush,
 };
 
+int qxl_primary_atomic_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct qxl_device *qdev = plane->dev->dev_private;
+   struct qxl_framebuffer *qfb;
+   struct qxl_bo *bo;
+
+   if (!state->crtc || !state->fb)
+   return 0;
+
+   qfb = to_qxl_framebuffer(state->fb);
+   bo = gem_to_qxl_bo(qfb->obj);
+
+   if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
+   DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void qxl_primary_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct qxl_device *qdev = plane->dev->dev_private;
+   struct qxl_framebuffer *qfb =
+   to_qxl_framebuffer(plane->state->fb);
+   struct qxl_framebuffer *qfb_old;
+   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
+   struct qxl_bo *bo_old;
+   struct drm_clip_rect norect = {
+   .x1 = 0,
+   .y1 = 0,
+   .x2 = qfb->base.width,
+   .y2 = qfb->base.height
+   };
+
+   if (!old_state->fb) {
+   qxl_io_log(qdev,
+  "create primary fb: %dx%d,%d,%d\n",
+  bo->surf.width, bo->surf.height,
+  bo->surf.stride, bo->surf.format);
+
+   qxl_io_create_primary(qdev, 0, bo);
+   bo->is_primary = true;
+   return;
+
+   } else {
+   qfb_old = to_qxl_framebuffer(old_state->fb);
+   bo_old = gem_to_qxl_bo(qfb_old->obj);
+   bo_old->is_primary = false;
+   }
+
+   bo->is_primary = true;
+   qxl_draw_dirty_fb(qdev, qfb, bo, 0, 0, , 1, 1);
+}
+
+static void qxl_primary_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
+{
+   struct qxl_device *qdev = plane->dev->dev_private;
+
+   if (old_state->fb)
+   {   struct qxl_framebuffer *qfb =
+   to_qxl_framebuffer(old_state->fb);
+   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
+
+   qxl_io_destroy_primary(qdev);
+   bo->is_primary = false;
+   }
+}
+
 int qxl_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
 {
@@ -742,8 +832,16 @@ static const uint32_t qxl_primary_plane_formats[] = {
DRM_FORMAT_ARGB,
 };
 
+static const struct drm_plane_helper_funcs primary_helper_funcs = {
+   .atomic_check = qxl_primary_atomic_check,
+   .atomic_update = qxl_primary_atomic_update,
+   .atomic_disable = qxl_primary_atomic_disable,
+   .prepare_fb = qxl_plane_prepare_fb,
+   .cleanup_fb = qxl_plane_cleanup_fb,
+};
+
 static const struct drm_plane_funcs qxl_primary_plane_funcs = {
-   .update_plane   = drm_primary_helper_update,
+   .update_plane   = drm_plane_helper_update,
.disable_plane  = drm_primary_helper_disable,
.destroy= drm_primary_helper_destroy,
 };
@@ -763,6 +861,7 @@ static struct drm_plane *qxl_create_plane(struct qxl_device 
*qdev,
funcs = _primary_plane_funcs;
formats = qxl_primary_plane_formats;
num_formats = ARRAY_SIZE(qxl_primary_plane_formats);
+   helper_funcs = _helper_funcs;
} else if (type == DRM_PLANE_TYPE_CURSOR) {
funcs = 

[PATCH 09/14] drm: qxl: Atomic phase 2: Wire up state object handlers

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 09c076f5a792..d5a00b6a07ea 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -325,6 +325,9 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = qxl_crtc_destroy,
.page_flip = qxl_crtc_page_flip,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
 void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
@@ -761,6 +764,9 @@ static const struct drm_plane_funcs qxl_cursor_plane_funcs 
= {
.update_plane   = drm_plane_helper_update,
.disable_plane  = drm_plane_helper_disable,
.destroy= drm_primary_helper_destroy,
+   .reset  = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };
 
 static const uint32_t qxl_primary_plane_formats[] = {
@@ -780,6 +786,9 @@ static const struct drm_plane_funcs qxl_primary_plane_funcs 
= {
.update_plane   = drm_plane_helper_update,
.disable_plane  = drm_primary_helper_disable,
.destroy= drm_primary_helper_destroy,
+   .reset  = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
 };
 
 static struct drm_plane *qxl_create_plane(struct qxl_device *qdev,
@@ -1057,6 +1066,9 @@ static const struct drm_connector_funcs 
qxl_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = qxl_conn_set_property,
.destroy = qxl_conn_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
 static void qxl_enc_destroy(struct drm_encoder *encoder)
@@ -1228,6 +1240,8 @@ int qxl_modeset_init(struct qxl_device *qdev)
 
qdev->mode_info.mode_config_initialized = true;
 
+   drm_mode_config_reset(>ddev);
+
/* primary surface must be created by this point, to allow
 * issuing command queue commands and having them read by
 * spice server. */
-- 
2.11.0

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

[PATCH 10/14] drm: qxl: Atomic phase 2: Use drm_atomic_set_fb_for_plane helper

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index d5a00b6a07ea..d1c12ac222b7 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -31,6 +31,7 @@
 #include "drm_crtc_helper.h"
 #include 
 #include 
+#include 
 
 static bool qxl_head_enabled(struct qxl_head *head)
 {
@@ -299,7 +300,8 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
int one_clip_rect = 1;
int ret = 0;
 
-   crtc->primary->fb = fb;
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
+
bo_old->is_primary = false;
bo->is_primary = true;
 
-- 
2.11.0

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

[PATCH 07/14] drm: qxl: Atomic phase 1: Implement mode_set_nofb

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 88 +++
 1 file changed, 16 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 8ccf62ae0efd..b23979fad1e2 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -462,77 +462,6 @@ static void qxl_monitors_config_set(struct qxl_device 
*qdev,
 
 }
 
-static int qxl_crtc_mode_set(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode,
-  int x, int y,
-  struct drm_framebuffer *old_fb)
-{
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_framebuffer *qfb;
-   struct qxl_bo *bo, *old_bo = NULL;
-   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   bool recreate_primary = false;
-   int ret;
-   int surf_id;
-   if (!crtc->primary->fb) {
-   DRM_DEBUG_KMS("No FB bound\n");
-   return 0;
-   }
-
-   if (old_fb) {
-   qfb = to_qxl_framebuffer(old_fb);
-   old_bo = gem_to_qxl_bo(qfb->obj);
-   }
-   qfb = to_qxl_framebuffer(crtc->primary->fb);
-   bo = gem_to_qxl_bo(qfb->obj);
-   DRM_DEBUG("+%d+%d (%d,%d) => (%d,%d)\n",
- x, y,
- mode->hdisplay, mode->vdisplay,
- adjusted_mode->hdisplay,
- adjusted_mode->vdisplay);
-
-   if (bo->is_primary == false)
-   recreate_primary = true;
-
-   if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
-   DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
-   return -EINVAL;
-}
-
-   ret = qxl_bo_pin(bo, bo->type, NULL);
-   if (ret != 0)
-   return -EINVAL;
-
-   if (recreate_primary) {
-   qxl_io_destroy_primary(qdev);
-   qxl_io_log(qdev,
-  "recreate primary: %dx%d,%d,%d\n",
-  bo->surf.width, bo->surf.height,
-  bo->surf.stride, bo->surf.format);
-   qxl_io_create_primary(qdev, 0, bo);
-   bo->is_primary = true;
-   }
-
-   if (bo->is_primary) {
-   DRM_DEBUG_KMS("setting surface_id to 0 for primary surface %d 
on crtc %d\n", bo->surface_id, qcrtc->index);
-   surf_id = 0;
-   } else {
-   surf_id = bo->surface_id;
-   }
-
-   if (old_bo && old_bo != bo) {
-   old_bo->is_primary = false;
-   qxl_bo_unpin(old_bo);
-   }
-
-   qxl_monitors_config_set(qdev, qcrtc->index, x, y,
-   mode->hdisplay,
-   mode->vdisplay, surf_id);
-   return 0;
-}
-
 static void qxl_crtc_prepare(struct drm_crtc *crtc)
 {
DRM_DEBUG("current: %dx%d+%d+%d (%d).\n",
@@ -540,6 +469,20 @@ static void qxl_crtc_prepare(struct drm_crtc *crtc)
  crtc->x, crtc->y, crtc->enabled);
 }
 
+void qxl_mode_set_nofb(struct drm_crtc *crtc)
+{
+   struct qxl_device *qdev = crtc->dev->dev_private;
+   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
+   struct drm_display_mode *mode = >mode;
+
+   DRM_DEBUG("Mode set (%d,%d)\n",
+ mode->hdisplay, mode->vdisplay);
+
+   qxl_monitors_config_set(qdev, qcrtc->index, 0, 0,
+   mode->hdisplay, mode->vdisplay, 0);
+
+}
+
 static void qxl_crtc_commit(struct drm_crtc *crtc)
 {
DRM_DEBUG("\n");
@@ -567,7 +510,8 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.dpms = qxl_crtc_dpms,
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
-   .mode_set = qxl_crtc_mode_set,
+   .mode_set = drm_helper_crtc_mode_set,
+   .mode_set_nofb = qxl_mode_set_nofb,
.prepare = qxl_crtc_prepare,
.commit = qxl_crtc_commit,
.atomic_flush = qxl_crtc_atomic_flush,
-- 
2.11.0

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

[PATCH 08/14] drm: qxl: Atomic phase 1: Don't unpin primary when disabling crtc

[Gabriel Krisman Bertazi]

In the qxl atomic model, the primary doesn't stay pinned all the time,
instead it is only pinned/unpinned between prepare_fb and cleanup_fb.
So, we no longer need a final unpin of the primary framebuffer when
disabling the crtc.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index b23979fad1e2..09c076f5a792 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -491,15 +491,7 @@ static void qxl_crtc_commit(struct drm_crtc *crtc)
 static void qxl_crtc_disable(struct drm_crtc *crtc)
 {
struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   if (crtc->primary->fb) {
-   struct qxl_framebuffer *qfb = 
to_qxl_framebuffer(crtc->primary->fb);
-   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
-
-   qxl_bo_unpin(bo);
-   crtc->primary->fb = NULL;
-   }
+   struct qxl_device *qdev = crtc->dev->dev_private;
 
qxl_monitors_config_set(qdev, qcrtc->index, 0, 0, 0, 0, 0);
 
-- 
2.11.0

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

[PATCH 05/14] drm: qxl: Atomic phase 1: convert cursor to universal plane

[Gabriel Krisman Bertazi]

In preparation for atomic conversion, let's use the transitional atomic
helpers drm_plane_helper_update/disable.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 442 +-
 drivers/gpu/drm/qxl/qxl_drv.h |   5 -
 2 files changed, 202 insertions(+), 245 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index a01036090b5c..fef464730c9b 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -30,6 +30,7 @@
 #include "qxl_object.h"
 #include "drm_crtc_helper.h"
 #include 
+#include 
 
 static bool qxl_head_enabled(struct qxl_head *head)
 {
@@ -256,7 +257,6 @@ static void qxl_crtc_destroy(struct drm_crtc *crtc)
struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc);
 
drm_crtc_cleanup(crtc);
-   qxl_bo_unref(_crtc->cursor_bo);
kfree(qxl_crtc);
 }
 
@@ -304,235 +304,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 }
 
-static int
-qxl_hide_cursor(struct qxl_device *qdev)
-{
-   struct qxl_release *release;
-   struct qxl_cursor_cmd *cmd;
-   int ret;
-
-   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd), 
QXL_RELEASE_CURSOR_CMD,
-, NULL);
-   if (ret)
-   return ret;
-
-   ret = qxl_release_reserve_list(release, true);
-   if (ret) {
-   qxl_release_free(qdev, release);
-   return ret;
-   }
-
-   cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
-   cmd->type = QXL_CURSOR_HIDE;
-   qxl_release_unmap(qdev, release, >release_info);
-
-   qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
-   qxl_release_fence_buffer_objects(release);
-   return 0;
-}
-
-static int qxl_crtc_apply_cursor(struct drm_crtc *crtc)
-{
-   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_cursor_cmd *cmd;
-   struct qxl_release *release;
-   int ret = 0;
-
-   if (!qcrtc->cursor_bo)
-   return 0;
-
-   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd),
-QXL_RELEASE_CURSOR_CMD,
-, NULL);
-   if (ret)
-   return ret;
-
-   ret = qxl_release_list_add(release, qcrtc->cursor_bo);
-   if (ret)
-   goto out_free_release;
-
-   ret = qxl_release_reserve_list(release, false);
-   if (ret)
-   goto out_free_release;
-
-   cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
-   cmd->type = QXL_CURSOR_SET;
-   cmd->u.set.position.x = qcrtc->cur_x + qcrtc->hot_spot_x;
-   cmd->u.set.position.y = qcrtc->cur_y + qcrtc->hot_spot_y;
-
-   cmd->u.set.shape = qxl_bo_physical_address(qdev, qcrtc->cursor_bo, 0);
-
-   cmd->u.set.visible = 1;
-   qxl_release_unmap(qdev, release, >release_info);
-
-   qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
-   qxl_release_fence_buffer_objects(release);
-
-   return ret;
-
-out_free_release:
-   qxl_release_free(qdev, release);
-   return ret;
-}
-
-static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
-   struct drm_file *file_priv,
-   uint32_t handle,
-   uint32_t width,
-   uint32_t height, int32_t hot_x, int32_t hot_y)
-{
-   struct drm_device *dev = crtc->dev;
-   struct qxl_device *qdev = dev->dev_private;
-   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
-   struct drm_gem_object *obj;
-   struct qxl_cursor *cursor;
-   struct qxl_cursor_cmd *cmd;
-   struct qxl_bo *cursor_bo, *user_bo;
-   struct qxl_release *release;
-   void *user_ptr;
-
-   int size = 64*64*4;
-   int ret = 0;
-   if (!handle)
-   return qxl_hide_cursor(qdev);
-
-   obj = drm_gem_object_lookup(file_priv, handle);
-   if (!obj) {
-   DRM_ERROR("cannot find cursor object\n");
-   return -ENOENT;
-   }
-
-   user_bo = gem_to_qxl_bo(obj);
-
-   ret = qxl_bo_pin(user_bo, QXL_GEM_DOMAIN_CPU, NULL);
-   if (ret)
-   goto out_unref;
-
-   ret = qxl_bo_kmap(user_bo, _ptr);
-   if (ret)
-   goto out_unpin;
-
-   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd),
-QXL_RELEASE_CURSOR_CMD,
-, NULL);
-   if (ret)
-   goto out_kunmap;
-
-   ret = qxl_alloc_bo_reserved(qdev, release, sizeof(struct qxl_cursor) + 
size,
-  _bo);
-   if (ret)
-   goto out_free_release;
-
-   ret = qxl_release_reserve_list(release, false);
-   if 

[PATCH 04/14] drm: qxl: Expose creation of universal primary plane

[Gabriel Krisman Bertazi]

Let's expose the primary plane initialization inside the qxl driver in
preparation for universal planes and atomic.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 71 ++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 2f53b48af56b..a01036090b5c 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -789,18 +789,87 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.commit = qxl_crtc_commit,
 };
 
+static const uint32_t qxl_primary_plane_formats[] = {
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+};
+
+static const struct drm_plane_funcs qxl_primary_plane_funcs = {
+   .update_plane   = drm_primary_helper_update,
+   .disable_plane  = drm_primary_helper_disable,
+   .destroy= drm_primary_helper_destroy,
+};
+
+static struct drm_plane *qxl_create_plane(struct qxl_device *qdev,
+ unsigned int possible_crtcs,
+ enum drm_plane_type type)
+{
+   const struct drm_plane_helper_funcs *helper_funcs = NULL;
+   struct drm_plane *plane;
+   const struct drm_plane_funcs *funcs;
+   const uint32_t *formats;
+   int num_formats;
+   int err;
+
+   if (type == DRM_PLANE_TYPE_PRIMARY) {
+   funcs = _primary_plane_funcs;
+   formats = qxl_primary_plane_formats;
+   num_formats = ARRAY_SIZE(qxl_primary_plane_formats);
+   } else {
+   return ERR_PTR(-EINVAL);
+   }
+
+   plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+   if (!plane)
+   return ERR_PTR(-ENOMEM);
+
+   err = drm_universal_plane_init(>ddev, plane, possible_crtcs,
+  funcs, formats, num_formats,
+  type, NULL);
+   if (err)
+   goto free_plane;
+
+   drm_plane_helper_add(plane, helper_funcs);
+
+   return plane;
+
+free_plane:
+   kfree(plane);
+   return ERR_PTR(-EINVAL);
+}
+
 static int qdev_crtc_init(struct drm_device *dev, int crtc_id)
 {
struct qxl_crtc *qxl_crtc;
+   struct drm_plane *primary;
+   struct qxl_device *qdev = dev->dev_private;
+   int r;
 
qxl_crtc = kzalloc(sizeof(struct qxl_crtc), GFP_KERNEL);
if (!qxl_crtc)
return -ENOMEM;
 
-   drm_crtc_init(dev, _crtc->base, _crtc_funcs);
+   primary = qxl_create_plane(qdev, 1 << crtc_id, DRM_PLANE_TYPE_PRIMARY);
+   if (IS_ERR(primary)) {
+   r = -ENOMEM;
+   goto free_mem;
+   }
+
+   r = drm_crtc_init_with_planes(dev, _crtc->base, primary, NULL,
+ _crtc_funcs, NULL);
+   if (r)
+   goto clean_primary;
+
qxl_crtc->index = crtc_id;
drm_crtc_helper_add(_crtc->base, _crtc_helper_funcs);
return 0;
+
+clean_primary:
+   drm_plane_cleanup(primary);
+   kfree(primary);
+free_mem:
+   kfree(qxl_crtc);
+   return r;
 }
 
 static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
-- 
2.11.0

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

[PATCH 00/14] qxl atomic modesetting

[Gabriel Krisman Bertazi]

Hi,

This series implements support for Atomic Modesetting in the QXL driver.
The first 4 patches in the series are some cleanups to prepare the
ground, while the rest implement Atomic in 3 phases, as suggested by
Daniel's blog post[1].

Testing was done with the X server, igt, libdrm testsuit and some
custom code that I can share if requested.  I hope this covers the main
use cases.

[1] 

Gabriel Krisman Bertazi (14):
  drm: qxl: Drop device flags attribute
  drm: qxl: Consolidate bo reservation when pinning
  drm: qxl: Don't initialize vblank support
  drm: qxl: Expose creation of universal primary plane
  drm: qxl: Atomic phase 1: convert cursor to universal plane
  drm: qxl: Atomic phase 1: Use drm_plane_helpers for primary plane
  drm: qxl: Atomic phase 1: Implement mode_set_nofb
  drm: qxl: Atomic phase 1: Don't unpin primary when disabling crtc
  drm: qxl: Atomic phase 2: Wire up state object handlers
  drm: qxl: Atomic phase 2: Use drm_atomic_set_fb_for_plane helper
  drm: qxl: Atomic phase 3: Use atomic handlers for planes
  drm: qxl: Atomic phase 3: Wire up atomic set_config helper
  drm: qxl: Atomic phase 3: Wire up atomic page_flip helper
  drm: qxl: Enable atomic modesetting ioctl

 drivers/gpu/drm/qxl/qxl_display.c | 773 +++---
 drivers/gpu/drm/qxl/qxl_drv.c |  31 +-
 drivers/gpu/drm/qxl/qxl_drv.h |   8 +-
 drivers/gpu/drm/qxl/qxl_fb.c  |  25 +-
 drivers/gpu/drm/qxl/qxl_kms.c |   5 +-
 drivers/gpu/drm/qxl/qxl_object.c  |  41 +-
 6 files changed, 434 insertions(+), 449 deletions(-)

-- 
2.11.0

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

[PATCH 01/14] drm: qxl: Drop device flags attribute

[Gabriel Krisman Bertazi]

There are no device specific flags that we need to keep track of here.
Let it vanish.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
 drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
 drivers/gpu/drm/qxl/qxl_kms.c | 5 +
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 8e17c241e63c..698e1a47def9 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -79,7 +79,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret)
goto free_dev;
 
-   ret = qxl_device_init(qdev, _driver, pdev, ent->driver_data);
+   ret = qxl_device_init(qdev, _driver, pdev);
if (ret)
goto disable_pci;
 
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 785c17b56f73..647f0926cb50 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -243,7 +243,6 @@ struct qxl_device;
 
 struct qxl_device {
struct drm_device ddev;
-   unsigned long flags;
 
resource_size_t vram_base, vram_size;
resource_size_t surfaceram_base, surfaceram_size;
@@ -335,7 +334,7 @@ extern const struct drm_ioctl_desc qxl_ioctls[];
 extern int qxl_max_ioctl;
 
 int qxl_device_init(struct qxl_device *qdev, struct drm_driver *drv,
-   struct pci_dev *pdev, unsigned long flags);
+   struct pci_dev *pdev);
 void qxl_device_fini(struct qxl_device *qdev);
 
 int qxl_modeset_init(struct qxl_device *qdev);
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 2dcd5c14cb56..2b1e1f3c825d 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -117,8 +117,7 @@ static void qxl_gc_work(struct work_struct *work)
 
 int qxl_device_init(struct qxl_device *qdev,
struct drm_driver *drv,
-   struct pci_dev *pdev,
-   unsigned long flags)
+   struct pci_dev *pdev)
 {
int r, sb;
 
@@ -130,8 +129,6 @@ int qxl_device_init(struct qxl_device *qdev,
pci_set_drvdata(pdev, >ddev);
qdev->ddev.dev_private = qdev;
 
-   qdev->flags = flags;
-
mutex_init(>gem.mutex);
mutex_init(>update_area_mutex);
mutex_init(>release_mutex);
-- 
2.11.0

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

[PATCH 03/14] drm: qxl: Don't initialize vblank support

[Gabriel Krisman Bertazi]

qxl don't have support for hardware vblanks so we can't initialize it
here, otherwise we risk getting stuck in drm_wait_one_vblank.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c |  3 ---
 drivers/gpu/drm/qxl/qxl_drv.c | 26 +-
 2 files changed, 1 insertion(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 84d35ba2384a..2f53b48af56b 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -293,14 +293,11 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
qxl_draw_dirty_fb(qdev, qfb_src, bo, 0, 0,
  , one_clip_rect, inc);
 
-   drm_crtc_vblank_get(crtc);
-
if (event) {
spin_lock_irqsave(>event_lock, flags);
drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(>event_lock, flags);
}
-   drm_crtc_vblank_put(crtc);
 
qxl_bo_unpin(bo);
 
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 698e1a47def9..67e94f4f3ce8 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -83,13 +83,9 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (ret)
goto disable_pci;
 
-   ret = drm_vblank_init(>ddev, 1);
-   if (ret)
-   goto unload;
-
ret = qxl_modeset_init(qdev);
if (ret)
-   goto vblank_cleanup;
+   goto unload;
 
drm_kms_helper_poll_init(>ddev);
 
@@ -102,8 +98,6 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
 modeset_cleanup:
qxl_modeset_fini(qdev);
-vblank_cleanup:
-   drm_vblank_cleanup(>ddev);
 unload:
qxl_device_fini(qdev);
 disable_pci:
@@ -247,21 +241,6 @@ static int qxl_pm_restore(struct device *dev)
return qxl_drm_resume(drm_dev, false);
 }
 
-static u32 qxl_noop_get_vblank_counter(struct drm_device *dev,
-  unsigned int pipe)
-{
-   return 0;
-}
-
-static int qxl_noop_enable_vblank(struct drm_device *dev, unsigned int pipe)
-{
-   return 0;
-}
-
-static void qxl_noop_disable_vblank(struct drm_device *dev, unsigned int pipe)
-{
-}
-
 static const struct dev_pm_ops qxl_pm_ops = {
.suspend = qxl_pm_suspend,
.resume = qxl_pm_resume,
@@ -281,9 +260,6 @@ static struct pci_driver qxl_pci_driver = {
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
-   .get_vblank_counter = qxl_noop_get_vblank_counter,
-   .enable_vblank = qxl_noop_enable_vblank,
-   .disable_vblank = qxl_noop_disable_vblank,
 
.set_busid = drm_pci_set_busid,
 
-- 
2.11.0

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

[PATCH 02/14] drm: qxl: Consolidate bo reservation when pinning

[Gabriel Krisman Bertazi]

Every attempt to pin/unpin objects in memory requires
qxl_bo_reserve/unreserve calls around the pinning operation to protect
the object from concurrent access, which causes that call sequence to be
reproduced every place where pinning is needed.  In some cases, that
sequence was not executed correctly, resulting in potential unprotected
pinning operations.

This commit encapsulates the reservation inside a new wrapper to make
sure it is always handled properly.  In cases where reservation must be
done beforehand, for some reason, one can use the unprotected version
__qxl_bo_pin/unpin.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_display.c | 52 ++-
 drivers/gpu/drm/qxl/qxl_fb.c  | 25 ++-
 drivers/gpu/drm/qxl/qxl_object.c  | 41 --
 3 files changed, 54 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 1094cd33eb06..84d35ba2384a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -286,11 +286,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
bo_old->is_primary = false;
bo->is_primary = true;
 
-   ret = qxl_bo_reserve(bo, false);
-   if (ret)
-   return ret;
ret = qxl_bo_pin(bo, bo->type, NULL);
-   qxl_bo_unreserve(bo);
if (ret)
return ret;
 
@@ -306,11 +302,7 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
}
drm_crtc_vblank_put(crtc);
 
-   ret = qxl_bo_reserve(bo, false);
-   if (!ret) {
-   qxl_bo_unpin(bo);
-   qxl_bo_unreserve(bo);
-   }
+   qxl_bo_unpin(bo);
 
return 0;
 }
@@ -417,12 +409,7 @@ static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
 
user_bo = gem_to_qxl_bo(obj);
 
-   ret = qxl_bo_reserve(user_bo, false);
-   if (ret)
-   goto out_unref;
-
ret = qxl_bo_pin(user_bo, QXL_GEM_DOMAIN_CPU, NULL);
-   qxl_bo_unreserve(user_bo);
if (ret)
goto out_unref;
 
@@ -485,11 +472,8 @@ static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
qxl_release_fence_buffer_objects(release);
 
/* finish with the userspace bo */
-   ret = qxl_bo_reserve(user_bo, false);
-   if (!ret) {
-   qxl_bo_unpin(user_bo);
-   qxl_bo_unreserve(user_bo);
-   }
+   qxl_bo_unpin(user_bo);
+
drm_gem_object_unreference_unlocked(obj);
 
qxl_bo_unref (>cursor_bo);
@@ -731,15 +715,10 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
return -EINVAL;
 }
 
-   ret = qxl_bo_reserve(bo, false);
-   if (ret != 0)
-   return ret;
ret = qxl_bo_pin(bo, bo->type, NULL);
-   if (ret != 0) {
-   qxl_bo_unreserve(bo);
+   if (ret != 0)
return -EINVAL;
-   }
-   qxl_bo_unreserve(bo);
+
if (recreate_primary) {
qxl_io_destroy_primary(qdev);
qxl_io_log(qdev,
@@ -765,9 +744,7 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
 
if (old_bo && old_bo != bo) {
old_bo->is_primary = false;
-   ret = qxl_bo_reserve(old_bo, false);
qxl_bo_unpin(old_bo);
-   qxl_bo_unreserve(old_bo);
}
 
qxl_monitors_config_set(qdev, qcrtc->index, x, y,
@@ -796,10 +773,8 @@ static void qxl_crtc_disable(struct drm_crtc *crtc)
if (crtc->primary->fb) {
struct qxl_framebuffer *qfb = 
to_qxl_framebuffer(crtc->primary->fb);
struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
-   int ret;
-   ret = qxl_bo_reserve(bo, false);
+
qxl_bo_unpin(bo);
-   qxl_bo_unreserve(bo);
crtc->primary->fb = NULL;
}
 
@@ -1128,17 +1103,9 @@ int qxl_create_monitors_object(struct qxl_device *qdev)
}
qdev->monitors_config_bo = gem_to_qxl_bo(gobj);
 
-   ret = qxl_bo_reserve(qdev->monitors_config_bo, false);
-   if (ret)
-   return ret;
-
ret = qxl_bo_pin(qdev->monitors_config_bo, QXL_GEM_DOMAIN_VRAM, NULL);
-   if (ret) {
-   qxl_bo_unreserve(qdev->monitors_config_bo);
+   if (ret)
return ret;
-   }
-
-   qxl_bo_unreserve(qdev->monitors_config_bo);
 
qxl_bo_kmap(qdev->monitors_config_bo, NULL);
 
@@ -1159,13 +1126,10 @@ int qxl_destroy_monitors_object(struct qxl_device *qdev)
qdev->ram_header->monitors_config = 0;
 
qxl_bo_kunmap(qdev->monitors_config_bo);
-   ret = qxl_bo_reserve(qdev->monitors_config_bo, false);
+   ret = qxl_bo_unpin(qdev->monitors_config_bo);
if (ret)
return ret;
 
-   qxl_bo_unpin(qdev->monitors_config_bo);
-   qxl_bo_unreserve(qdev->monitors_config_bo);
-

[Bug 89785] GPU Fault 147 and Ring Stalls and Tests Fail in Pillars of Eternity

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #15 from Samuel Pitoiset  ---
At least, three people said: "the issue is fixed" and I can confirm that
"Pillars of Eternity" works like a charm on my end. I think it's enough for
closing this very old issue (almost 2 years ago).

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

[Bug 93247] Bound by Flame game crashes GPU

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #3 from Samuel Pitoiset  ---
Thanks for the confirmation. Closing.

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

[Bug 93247] Bound by Flame game crashes GPU

[bugzilla-daemon]

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

--- Comment #2 from l.gambe...@alice.it ---
(In reply to Samuel Pitoiset from comment #1)
> I have just played the game few minutes, looks good with my config (RX480
> with mesa/LLVM from Git and amd-stagin-4.9 kernel). Your config is different
> but as the bug is quite old, can you try again? Hopefully it should work
> now. Thanks.

Yes, this bug is resolved, using this updated configuration:

System:Host: accipigna Kernel: 4.9.6-1-MANJARO x86_64 (64 bit) Desktop: KDE
Plasma 5.8.5
   Distro: Manjaro Linux
Machine:   Device: desktop Mobo: ASRock model: FM2A88X Extreme4+ UEFI [Legacy]:
American Megatrends v: P3.30 date: 05/13/2016
CPU:   Quad core AMD A10-7850K Radeon R7 12 Compute Cores 4C+8G (-MCP-)
cache: 8192 KB 
   clock speeds: max: 3700 MHz 1: 3700 MHz 2: 1700 MHz 3: 1700 MHz 4:
1700 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Pitcairn PRO [Radeon HD 7850
/ R7 265 / R9 270 1024SP]
   Display Server: X.Org 1.19.1 driver: radeon Resolution:
1920x1080@60.00hz
   GLX Renderer: Gallium 0.4 on AMD PITCAIRN (DRM 2.48.0 /
4.9.6-1-MANJARO, LLVM 3.9.1)
   GLX Version: 3.0 Mesa 13.0.3


It remains slower (less FPS) than the Windows version, but playable.

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

[Bug 92012] new account account

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #4 from Samuel Pitoiset  ---
According to git logs, Samuel Li has been able to push commits. I guess the
account has been created since September, 2015. Closing.

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

[Bug 93080] War Thunder launcher no longer loads

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #6 from Samuel Pitoiset  ---
War Thunder has been updated many times since December, 2015. The issue is
fixed now, it requests a 4.1 core profile, not a compat one. Closing.

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

Re: [PATCH] dma-buf/dma-fence: improve doc for dma_fence_add_callback()

[Chris Wilson]

On Wed, Feb 15, 2017 at 03:57:25PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Document return values for this function.
> 
> Signed-off-by: Gustavo Padovan 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Drop debug print at boot with DPI enabled.

[Eric Anholt]

Daniel Vetter  writes:

> On Wed, Feb 08, 2017 at 12:47:01PM -0800, Eric Anholt wrote:
>> Unlike the other encoders in the driver, I've also dropped the debug
>> dump function.  There's only really one register to this device, and
>> we have the debugfs reg entry still.
>> 
>> Signed-off-by: Eric Anholt 
>
> Yeah, dmesg spew by default isn't cool. Btw if you ever want to have fancy
> debug printers, there's drm_printer, which allows you to spam both dmesg
> and debugfs with the same code. Rob did that, I recently converted drm_mm,
> it's pretty cool.
>
> Acked-by: Daniel Vetter 

Merged to -next, thanks.

The drm printer stuff looks really promising!  I'm also interested,
though, in the debugfs_regset32 stuff that lets you just name your regs
in a struct and pass it and your regs base address to the helper for
creating the debugfs entry.  I bet we can mash those two ideas together
into something really nice.


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

[Bug 93247] Bound by Flame game crashes GPU

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
I have just played the game few minutes, looks good with my config (RX480 with
mesa/LLVM from Git and amd-stagin-4.9 kernel). Your config is different but as
the bug is quite old, can you try again? Hopefully it should work now. Thanks.

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

[PATCH v2 2/3] drm/ttm: fix the documentation of ttm_bo_init

[Nicolai Hähnle]

From: Nicolai Hähnle 

As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.

Signed-off-by: Nicolai Hähnle 
---
 include/drm/ttm/ttm_bo_api.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 6e8eaee..5add713 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -520,7 +520,11 @@ extern int ttm_bo_init_top(struct ttm_bo_device *bdev,
  * As this object may be part of a larger structure, this function,
  * together with the @destroy function,
  * enables driver-specific objects derived from a ttm_buffer_object.
- * On successful return, the object kref and list_kref are set to 1.
+ *
+ * On successful return, the caller owns an object kref to @bo. The kref and
+ * list_kref are usually set to 1, but note that in some situations, other
+ * tasks may already be holding references to @bo as well.
+ *
  * If a failure occurs, the function will call the @destroy function, or
  * kfree() if @destroy is NULL. Thus, after a failure, dereferencing @bo is
  * illegal and will likely cause memory corruption.
-- 
2.9.3

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

[PATCH v2 1/3] drm/ttm: split BO structure initialization into a separate function

[Nicolai Hähnle]

From: Nicolai Hähnle 

Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.

v2: callers of ttm_bo_init_top should use ttm_bo_unref for error
handling

Signed-off-by: Nicolai Hähnle 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 89 
 include/drm/ttm/ttm_bo_api.h | 44 ++
 2 files changed, 100 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c438b04..390b763 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1119,44 +1119,23 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_validate);
 
-int ttm_bo_init(struct ttm_bo_device *bdev,
-   struct ttm_buffer_object *bo,
-   unsigned long size,
-   enum ttm_bo_type type,
-   struct ttm_placement *placement,
-   uint32_t page_alignment,
-   bool interruptible,
-   struct file *persistent_swap_storage,
-   size_t acc_size,
-   struct sg_table *sg,
-   struct reservation_object *resv,
-   void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init_top(struct ttm_bo_device *bdev,
+   struct ttm_buffer_object *bo,
+   unsigned long size,
+   enum ttm_bo_type type,
+   uint32_t page_alignment,
+   struct file *persistent_swap_storage,
+   size_t acc_size,
+   struct sg_table *sg,
+   struct reservation_object *resv,
+   void (*destroy) (struct ttm_buffer_object *))
 {
int ret = 0;
unsigned long num_pages;
struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
-   bool locked;
-
-   ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
-   if (ret) {
-   pr_err("Out of kernel memory\n");
-   if (destroy)
-   (*destroy)(bo);
-   else
-   kfree(bo);
-   return -ENOMEM;
-   }
 
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
-   if (num_pages == 0) {
-   pr_err("Illegal buffer object size\n");
-   if (destroy)
-   (*destroy)(bo);
-   else
-   kfree(bo);
-   ttm_mem_global_free(mem_glob, acc_size);
-   return -EINVAL;
-   }
+
bo->destroy = destroy;
 
kref_init(>kref);
@@ -1181,7 +1160,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->moving = NULL;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
bo->persistent_swap_storage = persistent_swap_storage;
-   bo->acc_size = acc_size;
+   bo->acc_size = 0;
bo->sg = sg;
if (resv) {
bo->resv = resv;
@@ -1195,6 +1174,22 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->priority = 0;
 
/*
+* Error checking comes after initialization, so that the regular
+* buffer object cleanup code can be used safely by the caller.
+*/
+   if (num_pages == 0) {
+   pr_err("Illegal buffer object size\n");
+   return -EINVAL;
+   }
+
+   ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
+   if (ret) {
+   pr_err("Out of kernel memory\n");
+   return -ENOMEM;
+   }
+   bo->acc_size = acc_size;
+
+   /*
 * For ttm_bo_type_device buffers, allocate
 * address space from the device.
 */
@@ -1203,6 +1198,34 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
ret = drm_vma_offset_add(>vma_manager, >vma_node,
 bo->mem.num_pages);
 
+   return ret;
+}
+EXPORT_SYMBOL(ttm_bo_init_top);
+
+int ttm_bo_init(struct ttm_bo_device *bdev,
+   struct ttm_buffer_object *bo,
+   unsigned long size,
+   enum ttm_bo_type type,
+   struct ttm_placement *placement,
+   uint32_t page_alignment,
+   bool interruptible,
+   struct file *persistent_swap_storage,
+   size_t acc_size,
+   struct sg_table *sg,
+   struct reservation_object *resv,
+   void (*destroy) (struct ttm_buffer_object *))
+{
+   bool locked;
+   int ret;
+
+   ret = ttm_bo_init_top(bdev, bo, size, type, page_alignment,
+ persistent_swap_storage, acc_size, sg, resv,
+ destroy);
+   if (ret) {
+   ttm_bo_unref();
+   return ret;
+   }
+
/* passed reservation objects 

[PATCH v2 3/3] drm/amdgpu: fix lock cleanup during buffer creation

[Nicolai Hähnle]

From: Nicolai Hähnle 

Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM BO initialization
fails.

Actual deadlocks caused by the missing unlock should have been fixed
by "drm/ttm: never add BO that failed to validate to the LRU list",
superseding the flawed fix in commit 38fc4856ad98 ("drm/amdgpu: fix
a potential deadlock in amdgpu_bo_create_restricted()").

This change fixes remaining recursive locking errors that can be seen
with lock debugging enabled, and avoids the error of freeing a locked
mutex.

v2: use ttm_bo_unref for error handling, and rebase on latest changes

Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED 
handling (v2)")
Signed-off-by: Nicolai Hähnle 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c2e57f7..15944ea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -404,15 +404,31 @@ int amdgpu_bo_create_restricted(struct amdgpu_device 
*adev,
}
 
initial_bytes_moved = atomic64_read(>num_bytes_moved);
-   r = ttm_bo_init(>mman.bdev, >tbo, size, type,
-   >placement, page_align, !kernel, NULL,
-   acc_size, sg, resv ? resv : >tbo.ttm_resv,
-   _ttm_bo_destroy);
+   r = ttm_bo_init_top(>mman.bdev, >tbo, size, type,
+   page_align, NULL,
+   acc_size, sg, resv ? resv : >tbo.ttm_resv,
+   _ttm_bo_destroy);
+
+   if (likely(r == 0))
+   r = ttm_bo_validate(>tbo, >placement, !kernel, false);
+
+   if (unlikely(r != 0)) {
+   struct ttm_buffer_object *tbo = >tbo;
+
+   if (!resv)
+   ww_mutex_unlock(>tbo.ttm_resv.lock);
+   ttm_bo_unref();
+   return r;
+   }
+
amdgpu_cs_report_moved_bytes(adev,
atomic64_read(>num_bytes_moved) - initial_bytes_moved);
 
-   if (unlikely(r != 0))
-   return r;
+   if (!(bo->tbo.mem.placement & TTM_PL_FLAG_NO_EVICT)) {
+   spin_lock(>tbo.glob->lru_lock);
+   ttm_bo_add_to_lru(>tbo);
+   spin_unlock(>tbo.glob->lru_lock);
+   }
 
bo->tbo.priority = ilog2(bo->tbo.num_pages);
if (kernel)
-- 
2.9.3

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

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

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

Thierry Leconte  changed:

   What|Removed |Added

 CC||thierry.leco...@laposte.net

--- Comment #42 from Thierry Leconte  ---
Confirm that this bug is still present on up to date fedora25 :
kernel 4.9.8-201.fc25 
mesa 13.0.4

with X11 or wayland (no differences).
Only gnome-shell is affected. All others apps are ok.

same GPU as others :

Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org R300 Project (0x1002)
Device: ATI RS600 (0x7941)
Version: 13.0.4
Accelerated: yes
Video memory: 256MB
Unified memory: no
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RS600
OpenGL version string: 2.1 Mesa 13.0.4
OpenGL shading language version string: 1.20

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

[PATCH] drm/virtio: call drm_plane_cleanup() at destroy phase

[Gustavo Padovan]

From: Gustavo Padovan 

virtio was missing this call to clean up core plane usage.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 11288ff..1ff9c64 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -44,6 +44,7 @@ static const uint32_t virtio_gpu_cursor_formats[] = {
 
 static void virtio_gpu_plane_destroy(struct drm_plane *plane)
 {
+   drm_plane_cleanup(plane);
kfree(plane);
 }
 
-- 
2.9.3

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

[PATCH] dma-buf/dma-fence: improve doc for dma_fence_add_callback()

[Gustavo Padovan]

From: Gustavo Padovan 

Document return values for this function.

Signed-off-by: Gustavo Padovan 
---
 drivers/dma-buf/dma-fence.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index d1f1f45..809b397 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -239,6 +239,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
  * after it signals with dma_fence_signal. The callback itself can be called
  * from irq context.
  *
+ * Returns 0 in case of success, -ENOENT if the fence is already signaled
+ * and -EINVAL in case of error.
  */
 int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
   dma_fence_func_t func)
-- 
2.9.3

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

[PATCH] drm: Add DPCD definitions for DP 1.4 DSC feature

[Manasi Navare]

Display stream compression is supported on DP 1.4 DP
devices. This patch adds the corersponding DPCD
register definitions for DSC.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Paulo Zanoni 
Cc: dri-devel@lists.freedesktop.org
---
 include/drm/drm_dp_helper.h | 102 
 1 file changed, 102 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ba89295..4c1fc26 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -179,6 +179,108 @@
 
 #define DP_GUID0x030   /* 1.2 */
 
+#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
+# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
+
+#define DP_DSC_REV  0x061
+# define DP_DSC_MAJOR_MASK  (15 << 0)
+# define DP_DSC_MINOR_MASK  (15 << 4)
+# define DP_DSC_MINOR_SHIFT 4
+
+#define DP_DSC_RC_BUF_BLK_SIZE  0x062
+# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
+# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
+# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
+# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
+
+#define DP_DSC_RC_BUF_SIZE  0x063
+
+#define DP_DSC_SLICE_CAP_1  0x064
+# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
+# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
+# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
+# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
+# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
+# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
+# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
+
+#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
+# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0)
+# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
+# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
+# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
+# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
+# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
+# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
+# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
+# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
+# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
+
+#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
+# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
+
+#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
+
+#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
+
+#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
+# define DP_DSC_RGB (1 << 0)
+# define DP_DSC_YCbCr444(1 << 1)
+# define DP_DSC_YCbCr422_Simple (1 << 2)
+# define DP_DSC_YCbCr422_Native (1 << 3)
+# define DP_DSC_YCbCr420_Native (1 << 4)
+
+#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
+# define DP_DSC_8_BPC   (1 << 1)
+# define DP_DSC_10_BPC  (1 << 2)
+# define DP_DSC_12_BPC  (1 >> 3)
+
+#define DP_DSC_PEAK_THROUGHPUT  0x06B
+# define DP_DSC_THROUGHPUT_MODE_0_340   0x1
+# define DP_DSC_THROUGHPUT_MODE_0_400   0x2
+# define DP_DSC_THROUGHPUT_MODE_0_450   0x3
+# define DP_DSC_THROUGHPUT_MODE_0_500   0x4
+# define DP_DSC_THROUGHPUT_MODE_0_550   0x5
+# define DP_DSC_THROUGHPUT_MODE_0_600   0x6
+# define DP_DSC_THROUGHPUT_MODE_0_650   0x7
+# define DP_DSC_THROUGHPUT_MODE_0_700   0x8
+# define DP_DSC_THROUGHPUT_MODE_0_750   0x9
+# define DP_DSC_THROUGHPUT_MODE_0_800   0xA
+# define DP_DSC_THROUGHPUT_MODE_0_850   0xB
+# define DP_DSC_THROUGHPUT_MODE_0_900   0xC
+# define DP_DSC_THROUGHPUT_MODE_0_950   0xD
+# define DP_DSC_THROUGHPUT_MODE_0_1000  0xE
+# define DP_DSC_THROUGHPUT_MODE_1_MASK  (15 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
+# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_600   (6 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_650   (7 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_700   (8 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_750   (9 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_800   (10 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_850   (11 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_900   (12 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_950   (13 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_1000  (14 << 4)
+
+#define DP_DSC_MAX_SLICE_WIDTH  0x06C
+
+#define DP_DSC_SLICE_CAP_2  0x06D
+# define DP_DSC_16_PER_DP_DSC_SINK  (1 << 0)
+# define DP_DSC_20_PER_DP_DSC_SINK  (1 << 1)
+# define DP_DSC_24_PER_DP_DSC_SINK  (1 << 2)
+
+#define 

Re: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to drm_crtc_helper_funcs

[Maxime Ripard]

Hi Daniel,

On Tue, Feb 14, 2017 at 10:42:53PM +0100, Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 01:03:27PM -0800, John Stultz wrote:
> > On Tue, Feb 14, 2017 at 12:22 PM, Daniel Vetter  wrote:
> > > On Tue, Feb 14, 2017 at 11:45:54AM -0800, John Stultz wrote:
> > >>
> > >> Not following here. What do you mean by "put it into drivers"?  Where?
> > >
> > > In your driver callback for ->mode_valid, call into a shared function to
> > > validate CRTC limits. Which you also call from the crtc's ->mode_fixup
> > > function.
> > 
> > So bascially have the adv7511 driver's mode_valid() have a special
> > callback to the kirin (and freedreno, and whatever other) drm driver
> > to check the modes? Or I guess the drm driver that uses that bridge
> > should register something w/ the adv7511 code?
> > 
> > Part of my confusion here is that the main issue is that its not just
> > one driver I'm dealing with, and they're all really just tied together
> > via device tree, so I'm not sure how to special case it in just one of
> > the drivers.
> 
> This sounds you want to fix this for bridges, but your patch only adds a
> crtc callback?

I've had kind of the same issue on sun4i actually. The issue is that a
bridge (through EDID) might report that some modes are supported, and
the bridge has a chance to say whether or not it can support such
resolutions and filter out the ones it cannot.

However, components higher in the pipeline cannot do so. In my case,
we had an RGB to HDMI that was definitely able to support up to
1080p60. However, our RGB encoder can only generate a pixel clock for
up to ~720p60, and this is not really the bridge's fault, so it
shouldn't be in the bridge driver. The same bridge attached to a
different RGB encoder (even a different SoC from the same family in
our case) will run just fine at 1080p.

We currently end up letting the user choose a resolution we knew very
well had not a chance to work. I came up with a similar solution than
John's, but for the encoders (since our clocks are per-encoder), but
unfortunately had no time to push it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [Intel-gfx] [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3

[Sinclair Yeh]

On Wed, Feb 15, 2017 at 03:56:09PM +0200, Jani Nikula wrote:
> On Wed, 25 Jan 2017, Maarten Lankhorst  
> wrote:
> > This was somehow lost between v3 and the merged version in Maarten's
> > patch merged as:
> >
> > commit f2d580b9a8149735cbc4b59c4a8df60173658140
> > Author: Maarten Lankhorst 
> > Date:   Wed May 4 14:38:26 2016 +0200
> >
> > drm/core: Do not preserve framebuffer on rmfb, v4.
> >
> > This introduces a slight behavioral change to rmfb. Instead of
> > disabling a crtc when the primary plane is disabled, we try to
> > preserve it.
> >
> > Apart from old versions of the vmwgfx xorg driver, there is
> > nothing depending on rmfb disabling a crtc. Since vmwgfx is
> > a legacy driver we can safely only disable the plane with atomic.
> >
> > If this commit is rejected by the driver then we will still fall
> > back to the old behavior and turn off the crtc.
> >
> > v2:
> > - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
> > - Add WARN_ON when atomic_remove_fb fails.
> > - Always call drm_atomic_state_put.
> > v3:
> > - Use drm_drv_uses_atomic_modeset
> > - Handle the case where the first plane-disable-only commit fails
> >   with -EINVAL. Some drivers do not support this, fall back to
> >   disabling all crtc's in this case.
> >
> > Signed-off-by: Daniel Vetter 
> > Signed-off-by: Daniel Vetter 
> > Signed-off-by: Maarten Lankhorst 
> 
> Pushed to drm-misc-next-fixes, and sent the pull request to Dave. Thanks
> for the patch.

I verified yesterday that this patch will cause a regression for vmwgfx
multi-mon.  Can we hold off on this?



> 
> BR,
> Jani.
> 
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 106 
> > 
> >  drivers/gpu/drm/drm_crtc_internal.h |   1 +
> >  drivers/gpu/drm/drm_framebuffer.c   |   7 +++
> >  3 files changed, 114 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 723392fc98c8..c79ab8048435 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -2058,6 +2058,112 @@ static void complete_crtc_signaling(struct 
> > drm_device *dev,
> > kfree(fence_state);
> >  }
> >  
> > +int drm_atomic_remove_fb(struct drm_framebuffer *fb)
> > +{
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   struct drm_device *dev = fb->dev;
> > +   struct drm_atomic_state *state;
> > +   struct drm_plane *plane;
> > +   struct drm_connector *conn;
> > +   struct drm_connector_state *conn_state;
> > +   int i, ret = 0;
> > +   unsigned plane_mask, disable_crtcs = false;
> > +
> > +   state = drm_atomic_state_alloc(dev);
> > +   if (!state)
> > +   return -ENOMEM;
> > +
> > +   drm_modeset_acquire_init(, 0);
> > +   state->acquire_ctx = 
> > +
> > +retry:
> > +   plane_mask = 0;
> > +   ret = drm_modeset_lock_all_ctx(dev, );
> > +   if (ret)
> > +   goto unlock;
> > +
> > +   drm_for_each_plane(plane, dev) {
> > +   struct drm_plane_state *plane_state;
> > +
> > +   if (plane->state->fb != fb)
> > +   continue;
> > +
> > +   plane_state = drm_atomic_get_plane_state(state, plane);
> > +   if (IS_ERR(plane_state)) {
> > +   ret = PTR_ERR(plane_state);
> > +   goto unlock;
> > +   }
> > +
> > +   /*
> > +* Some drivers do not support keeping crtc active with the
> > +* primary plane disabled. If we fail to commit with -EINVAL
> > +* then we will try to perform the same commit but with all
> > +* crtc's disabled for primary planes as well.
> > +*/
> > +   if (disable_crtcs && plane_state->crtc->primary == plane) {
> > +   struct drm_crtc_state *crtc_state;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> > plane_state->crtc);
> > +
> > +   ret = drm_atomic_add_affected_connectors(state, 
> > plane_state->crtc);
> > +   if (ret)
> > +   goto unlock;
> > +
> > +   crtc_state->active = false;
> > +   ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
> > +   if (ret)
> > +   goto unlock;
> > +   }
> > +
> > +   drm_atomic_set_fb_for_plane(plane_state, NULL);
> > +   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> > +   if (ret)
> > +   goto unlock;
> > +
> > +   plane_mask |= BIT(drm_plane_index(plane));
> > +
> > +   plane->old_fb = plane->fb;
> > +   }
> > +
> > +   /* This list is only not empty when disable_crtcs is set. */
> > +   for_each_connector_in_state(state, conn, conn_state, i) {
> > +   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
> > +
> > 

[Bug 98931] radeonsi: Very low shader performance

[bugzilla-daemon]

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

Cris  changed:

   What|Removed |Added

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

--- Comment #1 from Cris  ---
No idea what fixed it, but it's working just fine now.

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

[PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

[Maxime Ripard]

From: Xinliang Liu 

This patch add a config to support to create multi buffer for cma fbdev.
Such as double buffer and triple buffer.

Cma fbdev is convient to add a legency fbdev. And still many Android
devices use fbdev now and at least double buffer is needed for these
Android devices, so that a buffer flip can be operated. It will need
some time for Android device vendors to abondon legency fbdev. So multi
buffer for fbdev is needed.

Signed-off-by: Xinliang Liu 
[s.chr...@phytec.de: Picking patch from
 https://lkml.org/lkml/2015/9/14/188]
Signed-off-by: Stefan Christ 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/Kconfig |  9 +
 drivers/gpu/drm/drm_fb_helper.c | 10 ++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ebfe8404c25f..700c8b8e57a9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -84,6 +84,15 @@ config DRM_FBDEV_EMULATION
 
  If in doubt, say "Y".
 
+config DRM_FBDEV_OVERALLOC
+   int "Overallocation of the fbdev buffer"
+   depends on DRM_FBDEV_EMULATION
+   default 100
+   help
+ Defines the fbdev buffer overallocation in percent. Default
+ is 100. Typical values for double buffering will be 200,
+ triple buffering 300.
+
 config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e934b541feea..c6de87abaca8 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -48,6 +48,12 @@ module_param_named(fbdev_emulation, drm_fbdev_emulation, 
bool, 0600);
 MODULE_PARM_DESC(fbdev_emulation,
 "Enable legacy fbdev emulation [default=true]");
 
+static int drm_fbdev_overalloc = CONFIG_DRM_FBDEV_OVERALLOC;
+module_param(drm_fbdev_overalloc, int, 0444);
+MODULE_PARM_DESC(drm_fbdev_overalloc,
+"Overallocation of the fbdev buffer (%) [default="
+__MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
+
 static LIST_HEAD(kernel_fb_helper_list);
 static DEFINE_MUTEX(kernel_fb_helper_lock);
 
@@ -1573,6 +1579,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
sizes.fb_height = sizes.surface_height = 768;
}
 
+   /* Handle our overallocation */
+   sizes.surface_height *= drm_fbdev_overalloc;
+   sizes.surface_height /= 100;
+
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
if (ret < 0)
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Maxime Ripard]

From: Stefan Christ 

Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.

Code is based on

https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196

Signed-off-by: Stefan Christ 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_fb_helper.c | 63 ++-
 include/drm/drm_fb_helper.h | 12 +-
 2 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c6de87abaca8..15ee9641c725 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1240,6 +1240,69 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
fb_info *info)
 EXPORT_SYMBOL(drm_fb_helper_setcmap);
 
 /**
+ * drm_fb_helper_ioctl - legacy ioctl implementation
+ * @info: fbdev registered by the helper
+ * @cmd: ioctl command
+ * @arg: ioctl argument
+ *
+ * A helper to implement the standard fbdev ioctl. Only
+ * FBIO_WAITFORVSYNC is implemented for now.
+ */
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
+   unsigned long arg)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct drm_device *dev = fb_helper->dev;
+   struct drm_mode_set *mode_set;
+   struct drm_crtc *crtc;
+   u32 karg;
+   int ret = 0;
+
+   mutex_lock(>mode_config.mutex);
+   if (!drm_fb_helper_is_bound(fb_helper)) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
+   switch (cmd) {
+   case FBIO_WAITFORVSYNC:
+   if (get_user(karg, (__u32 __user *)arg)) {
+   ret = -EFAULT;
+   goto unlock;
+   }
+
+   if (karg >= fb_helper->crtc_count) {
+   ret = -EINVAL;
+   goto unlock;
+   }
+
+   mode_set = _helper->crtc_info[karg].mode_set;
+   crtc = mode_set->crtc;
+
+   /*
+* Only wait for a vblank event if the CRTC is
+* enabled, otherwise just don't do anythintg,
+* not even report an error.
+*/
+   ret = drm_crtc_vblank_get(crtc);
+   if (!ret) {
+   drm_crtc_wait_one_vblank(crtc);
+   drm_crtc_vblank_put(crtc);
+   }
+
+   ret = 0;
+   goto unlock;
+   default:
+   ret = -ENOTTY;
+   }
+
+unlock:
+   mutex_unlock(>mode_config.mutex);
+   return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_ioctl);
+
+/**
  * drm_fb_helper_check_var - implementation for ->fb_check_var
  * @var: screeninfo to check
  * @info: fbdev registered by the helper
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 975deedd593e..2891888c6e41 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -230,7 +230,8 @@ struct drm_fb_helper {
.fb_blank   = drm_fb_helper_blank, \
.fb_pan_display = drm_fb_helper_pan_display, \
.fb_debug_enter = drm_fb_helper_debug_enter, \
-   .fb_debug_leave = drm_fb_helper_debug_leave
+   .fb_debug_leave = drm_fb_helper_debug_leave, \
+   .fb_ioctl   = drm_fb_helper_ioctl
 
 #ifdef CONFIG_DRM_FBDEV_EMULATION
 void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
*helper,
@@ -286,6 +287,9 @@ void drm_fb_helper_set_suspend_unlocked(struct 
drm_fb_helper *fb_helper,
 
 int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
 
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
+   unsigned long arg);
+
 int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
 int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
 int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
@@ -377,6 +381,12 @@ static inline int drm_fb_helper_setcmap(struct fb_cmap 
*cmap,
return 0;
 }
 
+static inline int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+   return 0;
+}
+
 static inline void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper)
 {
 }
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/2] drm: Support framebuffer panning

[Maxime Ripard]

Hi,

This is a respin of the previous serie called "Support fast framebuffer
panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been
removed, and the comments that were made at that time fixed (hopefully).

Let me know what you think,
Maxime

Changes from v2:
  - Renamed the CONFIG_DRM_CMA_FBDEV_BUFFER_NUM to
CONFIG_DRM_FBDEV_OVERALLOC, and changed it for a percentage
  - Moved the overallocation code into the core fbdev helpers to not rely
on CMA anymore
  - Changed the locks taken by drm_fb_helper_ioctl to the mode_config mutex
intead of calling drm_modeset_lock_all
  - Don't test against drm_crtc's enabled anymore, but rely on the error
code of drm_crtc_vblank_get instead
  - Defined drm_fb_helper_ioctl when DRM_FBDEV_EMULATION is not set in
order to fix a compilation error
  - Don't wait for all CRTC's vblank but only the one given in the ioctl
argument

Changes from v1:
  - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS
  - Expanded a bit the kerneldoc for drm_fb_helper_ioctl
  - Added some locking to drm_fb_helper_ioctl
  - Checked that the framebuffer is indeed attached before allowing ioctl
  - Added a module parameter to specify the number of framebuffers to
allocate

Initial cover letter: Support fast framebuffer panning for i.MX6

im currently working on supporting double/tripple buffering for the
framebuffer emulation on the i.MX6.  While working on it I noticed that the
mainline kernel does not support some features in the generic drm
framebuffer emulation for framebuffer panning and vsync synchronisation.
They are needed for simple framebuffer applications and some OpenGL
libraries using double buffering with FBIOPUT_VSCREENINFO,
FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.

Stefan Christ (1):
  drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

Xinliang Liu (1):
  drm/fb-helper: Add multi buffer support for cma fbdev

 drivers/gpu/drm/Kconfig |  9 -
 drivers/gpu/drm/drm_fb_helper.c | 73 ++-
 include/drm/drm_fb_helper.h | 12 +-
 3 files changed, 93 insertions(+), 1 deletion(-)

base-commit: 0879b944c95d65f7523d178d3addaebe84e510ec
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #10 from Matias N. Goldberg  ---
I've built LLVM 5.0 from latest SVN.
I've applied the patch from https://reviews.llvm.org/D26348

The issue still persists. I don't know if anything else was needed (e.g.
changes to radeonsi to make use of the patch?).

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

i915: Dealing with 90° rotated display ?

[Hans de Goede]

Hi Jani,

As discussed here:

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

I've a mini-laptop which uses a phone-screen,
so the native orientation of the screen is portrait,
where as for a clam-shell device one wants it to
be landscape. Ideally there would be a flag somewhere
to tell the i915 driver that the panel is mounted
90° rotated in its bezel and have the i915 driver
apply that rotation on top of whatever rotation
userspace requests.

So question is there already a place (variable) in
the i915 driver where one can set such a rotation
offset to apply on top of what userspace requests ?

If not do you have any idea how feasible adding one
would be and can you give me a few pointers / hints
where to start with such a thing ?

Regards,

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

Re: i915: Dealing with 90° rotated display ?

[Ville Syrjälä]

On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
> Hi Jani,
> 
> As discussed here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=94894
> 
> I've a mini-laptop which uses a phone-screen,
> so the native orientation of the screen is portrait,
> where as for a clam-shell device one wants it to
> be landscape. Ideally there would be a flag somewhere
> to tell the i915 driver that the panel is mounted
> 90° rotated in its bezel and have the i915 driver
> apply that rotation on top of whatever rotation
> userspace requests.
> 
> So question is there already a place (variable) in
> the i915 driver where one can set such a rotation
> offset to apply on top of what userspace requests ?
> 
> If not do you have any idea how feasible adding one
> would be and can you give me a few pointers / hints
> where to start with such a thing ?

You could have a look at my branch (which I pointed out in the bug).

But note that 90/270 degree rotation is a little busted currently.
You'll need at least
https://patchwork.freedesktop.org/patch/120208/

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-next-queued 3/23] drivers/gpu/drm/i915/i915_gem_gtt.c:964: warning: 'iter.sg' is used uninitialized in this function

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   75c7b0b8620ce5a672da02e721a775acb7863c64
commit: 894ccebee2b0e606ba9638d20dd87b33568482d7 [3/23] drm/i915: 
Micro-optimise gen8_ppgtt_insert_entries()
config: x86_64-randconfig-v0-02151136 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 894ccebee2b0e606ba9638d20dd87b33568482d7
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_4lvl':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:964: warning: 'iter.sg' is used 
>> uninitialized in this function
>> drivers/gpu/drm/i915/i915_gem_gtt.c:965: warning: 'iter.dma' is used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_3lvl':
   drivers/gpu/drm/i915/i915_gem_gtt.c:947: warning: 'iter.sg' is used 
uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c:948: warning: 'iter.dma' is used 
uninitialized in this function

vim +964 drivers/gpu/drm/i915/i915_gem_gtt.c

   958 enum i915_cache_level cache_level,
   959 u32 unused)
   960  {
   961  struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
   962  struct sgt_dma iter = {
   963  .sg = pages->sgl,
 > 964  .dma = sg_dma_address(iter.sg),
 > 965  .max = iter.dma + iter.sg->length,
   966  };
   967  struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
   968  unsigned int pml4e = gen8_pml4e_index(start);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave, I'm flushing out the GVT fixes for the v4.11 merge window. I'll
probably have more pure i915 fixes still.

Heads up, for some reason your merge of drm-rockchip-next-2017-02-07
shows up in the stats below. I'm not quite sure what's going on
here. Let me know if you want me to do something about it.


BR,
Jani.

The following changes since commit 26d7f34cae7aad9600cd40ce07ec3fbe8606a567:

  Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into 
drm-next (2017-02-07 11:05:42 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/drm-intel-next-fixes-2017-02-15

for you to fetch changes up to d4c432364e7e469468b8438939486257dd10de25:

  Merge tag 'gvt-next-2017-02-15' of https://github.com/01org/gvt-linux into 
drm-intel-next-fixes (2017-02-15 11:50:15 +0200)


GVT fixes for the v4.11 merge window.


Changbin Du (5):
  drm/i915/gvt: remove a noisy unimportant log in sched_policy
  drm/i915/gvt: remove a redundant end of line in debug log
  drm/i915/gvt: reduce the line of interrupt logs and log friendly
  drm/i915/gvt: fix crash at function release_shadow_wa_ctx
  drm/i915/gvt: add missing display part reset for vGPU reset

Chuanxiao Dong (6):
  drm/i915/gvt: add more resolutions in virtual edid
  drm/i915/gvt: Map shadow page before using it in shadow page table
  drm/i915/gvt: map pfn for PTE entry in kvm
  drm/i915/gvt: enable IOMMU for gvt
  drm/i915/gvt: optimize the inhibit context mmio load
  drm/i915/gvt: return error code if dma map iova failed

Dan Carpenter (1):
  drm/i915/gvt/kvmgt: remove some dead code

Dave Airlie (1):
  Merge branch 'drm-rockchip-next-2017-02-07' of 
https://github.com/markyzq/kernel-drm-rockchip into drm-next

Jani Nikula (2):
  Merge tag 'gvt-next-2017-02-07' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes
  Merge tag 'gvt-next-2017-02-15' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes

Xu Han (1):
  drm/i915/gvt: add sprite plane flip done support.

Zhenyu Wang (7):
  drm/i915: make intel_gvt_init() later instead of too early
  drm/i915/gvt: move intel iommu detection to intel_gvt_init()
  drm/i915/gvt: remove detect_host() MPT hook
  drm/i915/gvt: use normal mmio read function for firmware exposure
  drm/i915/gvt: fix vgpu type size init
  drm/i915/gvt: Fix alignment for GTT allocation
  drm/i915/gvt: Fix shadow context descriptor

 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  15 ++---
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  20 +-
 drivers/gpu/drm/i915/gvt/display.c  |  31 ++---
 drivers/gpu/drm/i915/gvt/display.h  |   1 +
 drivers/gpu/drm/i915/gvt/execlist.c |   2 +-
 drivers/gpu/drm/i915/gvt/firmware.c |  47 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  70 +++--
 drivers/gpu/drm/i915/gvt/gvt.c  |   7 ---
 drivers/gpu/drm/i915/gvt/hypercall.h|   1 -
 drivers/gpu/drm/i915/gvt/interrupt.c|  57 +
 drivers/gpu/drm/i915/gvt/kvmgt.c| 108 +++-
 drivers/gpu/drm/i915/gvt/mpt.h  |  12 
 drivers/gpu/drm/i915/gvt/render.c   |  17 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |   1 -
 drivers/gpu/drm/i915/gvt/scheduler.c|   5 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |  14 +++--
 drivers/gpu/drm/i915/i915_drv.c |  14 ++---
 drivers/gpu/drm/i915/intel_gvt.c|   5 ++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |   2 +-
 19 files changed, 215 insertions(+), 214 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Maxime Ripard]

Hi,

On Mon, Feb 13, 2017 at 04:45:33PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 13, 2017 at 11:35:18AM +0100, Maxime Ripard wrote:
> > Hi Ville,
> > 
> > On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> > > > From: Stefan Christ 
> > > > 
> > > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> > > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> > > > based OpenGL(ES)/EGL implementations may require the ioctl to
> > > > synchronize drawing or buffer flip for double buffering. It is tested on
> > > > the i.MX6.
> > > > 
> > > > Code is based on
> > > > 
> > > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> > > > 
> > > > Signed-off-by: Stefan Christ 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >  drivers/gpu/drm/drm_fb_helper.c | 55 
> > > > ++-
> > > >  include/drm/drm_fb_helper.h |  5 ++-
> > > >  2 files changed, 59 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > index e934b541feea..39a3532e311c 100644
> > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> > > > struct fb_info *info)
> > > >  EXPORT_SYMBOL(drm_fb_helper_setcmap);
> > > >  
> > > >  /**
> > > > + * drm_fb_helper_ioctl - legacy ioctl implementation
> > > > + * @info: fbdev registered by the helper
> > > > + * @cmd: ioctl command
> > > > + * @arg: ioctl argument
> > > > + *
> > > > + * A helper to implement the standard fbdev ioctl. Only
> > > > + * FBIO_WAITFORVSYNC is implemented for now.
> > > > + */
> > > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, 
> > > > unsigned long arg)
> > > > +{
> > > > +   struct drm_fb_helper *fb_helper = info->par;
> > > > +   struct drm_device *dev = fb_helper->dev;
> > > > +   unsigned int i;
> > > > +   int ret = 0;
> > > > +
> > > > +   drm_modeset_lock_all(dev);
> > > > +   if (!drm_fb_helper_is_bound(fb_helper)) {
> > > > +   drm_modeset_unlock_all(dev);
> > > > +   return -EBUSY;
> > > > +   }
> > > > +
> > > > +   switch (cmd) {
> > > > +   case FBIO_WAITFORVSYNC:
> > > > +   for (i = 0; i < fb_helper->crtc_count; i++) {
> > > 
> > > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
> > > to do this for all the crtcs. Though what that crtc means for fb is
> > > rather poorly defined.
> > 
> > I guess I could just use that index to retrieve only the right CRTC in
> > fb_helper->crtc_info.
> > 
> > > 
> > > > +   struct drm_mode_set *mode_set;
> > > > +   struct drm_crtc *crtc;
> > > > +
> > > > +   mode_set = _helper->crtc_info[i].mode_set;
> > > > +   crtc = mode_set->crtc;
> > > > +
> > > > +   /*
> > > > +* Only call drm_crtc_wait_one_vblank for crtcs 
> > > > that
> > > > +* are currently enabled.
> > > > +*/
> > > > +   if (!crtc->enabled)
> > > > +   continue;
> > > > +
> > > > +   ret = drm_crtc_vblank_get(crtc);
> > > > +   if (!ret) {
> > > > +   drm_crtc_wait_one_vblank(crtc);
> > > > +   drm_crtc_vblank_put(crtc);
> > > > +   }
> > > 
> > > This looks quite sub-optimal. It should rather do something along the
> > > lines of what drm_atomic_helper_wait_for_vblanks() does.
> > 
> > How is that suboptimal?
> 
> You're serializing the waits rather than doing them in parallel.
> 
> Let's look at a simple three crtc example (|=vblank):
> 
> time -->
> CRTC 1: | | | |
> CRTC 2:   | | | |
> CRTC 3: | | | |
> 
> Your code waits until here:
> |   |   |
> 1   2   3
> ^
> 
> Optimal code would wait until here:
> |
> ^

Ah, right. But then, this would happen only if we loop over all the
CRTCs, which shouldn't happen in the v2 as you suggested.

Out of curiosity, how could we fix this if we were to loop over all
the framebuffers? By waiting on any vblank count to change?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [Intel-gfx] [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3

[Jani Nikula]

On Wed, 25 Jan 2017, Maarten Lankhorst  
wrote:
> This was somehow lost between v3 and the merged version in Maarten's
> patch merged as:
>
> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> Author: Maarten Lankhorst 
> Date:   Wed May 4 14:38:26 2016 +0200
>
> drm/core: Do not preserve framebuffer on rmfb, v4.
>
> This introduces a slight behavioral change to rmfb. Instead of
> disabling a crtc when the primary plane is disabled, we try to
> preserve it.
>
> Apart from old versions of the vmwgfx xorg driver, there is
> nothing depending on rmfb disabling a crtc. Since vmwgfx is
> a legacy driver we can safely only disable the plane with atomic.
>
> If this commit is rejected by the driver then we will still fall
> back to the old behavior and turn off the crtc.
>
> v2:
> - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
> - Add WARN_ON when atomic_remove_fb fails.
> - Always call drm_atomic_state_put.
> v3:
> - Use drm_drv_uses_atomic_modeset
> - Handle the case where the first plane-disable-only commit fails
>   with -EINVAL. Some drivers do not support this, fall back to
>   disabling all crtc's in this case.
>
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Maarten Lankhorst 

Pushed to drm-misc-next-fixes, and sent the pull request to Dave. Thanks
for the patch.

BR,
Jani.


> ---
>  drivers/gpu/drm/drm_atomic.c| 106 
> 
>  drivers/gpu/drm/drm_crtc_internal.h |   1 +
>  drivers/gpu/drm/drm_framebuffer.c   |   7 +++
>  3 files changed, 114 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 723392fc98c8..c79ab8048435 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2058,6 +2058,112 @@ static void complete_crtc_signaling(struct drm_device 
> *dev,
>   kfree(fence_state);
>  }
>  
> +int drm_atomic_remove_fb(struct drm_framebuffer *fb)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_device *dev = fb->dev;
> + struct drm_atomic_state *state;
> + struct drm_plane *plane;
> + struct drm_connector *conn;
> + struct drm_connector_state *conn_state;
> + int i, ret = 0;
> + unsigned plane_mask, disable_crtcs = false;
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state)
> + return -ENOMEM;
> +
> + drm_modeset_acquire_init(, 0);
> + state->acquire_ctx = 
> +
> +retry:
> + plane_mask = 0;
> + ret = drm_modeset_lock_all_ctx(dev, );
> + if (ret)
> + goto unlock;
> +
> + drm_for_each_plane(plane, dev) {
> + struct drm_plane_state *plane_state;
> +
> + if (plane->state->fb != fb)
> + continue;
> +
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state)) {
> + ret = PTR_ERR(plane_state);
> + goto unlock;
> + }
> +
> + /*
> +  * Some drivers do not support keeping crtc active with the
> +  * primary plane disabled. If we fail to commit with -EINVAL
> +  * then we will try to perform the same commit but with all
> +  * crtc's disabled for primary planes as well.
> +  */
> + if (disable_crtcs && plane_state->crtc->primary == plane) {
> + struct drm_crtc_state *crtc_state;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state, 
> plane_state->crtc);
> +
> + ret = drm_atomic_add_affected_connectors(state, 
> plane_state->crtc);
> + if (ret)
> + goto unlock;
> +
> + crtc_state->active = false;
> + ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
> + if (ret)
> + goto unlock;
> + }
> +
> + drm_atomic_set_fb_for_plane(plane_state, NULL);
> + ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> + if (ret)
> + goto unlock;
> +
> + plane_mask |= BIT(drm_plane_index(plane));
> +
> + plane->old_fb = plane->fb;
> + }
> +
> + /* This list is only not empty when disable_crtcs is set. */
> + for_each_connector_in_state(state, conn, conn_state, i) {
> + ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
> +
> + if (ret)
> + goto unlock;
> + }
> +
> + if (plane_mask)
> + ret = drm_atomic_commit(state);
> +
> +unlock:
> + if (plane_mask)
> + drm_atomic_clean_old_fb(dev, plane_mask, ret);
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> +   

[PULL] drm-misc-next-fixes

[Jani Nikula]

Hi Dave, a couple of drm core fixes for the v4.11 merge window.

BR,
Jani.

The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:

  Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-02-10 10:13:30 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-02-15

for you to fetch changes up to 1592364de3912dad264262f4bcc61552984c9523:

  drm: Resurrect atomic rmfb code, v3 (2017-02-15 15:40:57 +0200)


Fixes for the v4.11 merge window.


Denys Dmytriyenko (1):
  uapi: add missing install of dma-buf.h

Maarten Lankhorst (1):
  drm: Resurrect atomic rmfb code, v3

 drivers/gpu/drm/drm_atomic.c| 106 
 drivers/gpu/drm/drm_crtc_internal.h |   1 +
 drivers/gpu/drm/drm_framebuffer.c   |   7 +++
 include/uapi/linux/Kbuild   |   1 +
 4 files changed, 115 insertions(+)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes for v4.10

[Jani Nikula]

Hi Dave, one dp/mst oops fix for v4.10. If it doesn't make it to v4.10,
then please get this in during the merge window.

BR,
Jani.

The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc:

  Linux 4.10-rc8 (2017-02-12 13:03:20 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-02-15

for you to fetch changes up to bb08c04dc867b5f392caec635c097d5d5fcd8c9f:

  drm/dp/mst: fix kernel oops when turning off secondary monitor (2017-02-15 
11:41:19 +0200)


dp/mst oops fix for v4.10


Pierre-Louis Bossart (1):
  drm/dp/mst: fix kernel oops when turning off secondary monitor

 drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

[Nicolai Hähnle]

On 14.02.2017 13:51, Christian König wrote:

Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:

On 14.02.2017 11:49, Christian König wrote:

Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.

Signed-off-by: Nicolai Hähnle 


Please squash that into your other patch. It fixes another bug, but I
don't think fixing one bug just to run into another is really a good
idea.


I don't understand. I'm not aware that this patch fixes anything, it
just enables the subsequent fix in amdgpu in patch #2. I don't think
squashing those together is a good idea (one is in ttm, the other in
amdgpu).


Ok, forget it I've messed up the different reference count.

With at least initializing bo->kref and bo->destroy before returning the
first error the patch is Reviewed-by: Christian König
.


Thanks. Does this apply to patches #2 and #3 as well?

Cheers,
Nicolai




Regards,
Christian.





Additional to that one comment below.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 62
+---
  include/drm/ttm/ttm_bo_api.h | 45 
  2 files changed, 86 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 76bee42..ce4c0f5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1120,41 +1120,30 @@ int ttm_bo_validate(struct ttm_buffer_object
*bo,
  }
  EXPORT_SYMBOL(ttm_bo_validate);
  -int ttm_bo_init(struct ttm_bo_device *bdev,
-struct ttm_buffer_object *bo,
-unsigned long size,
-enum ttm_bo_type type,
-struct ttm_placement *placement,
-uint32_t page_alignment,
-bool interruptible,
-struct file *persistent_swap_storage,
-size_t acc_size,
-struct sg_table *sg,
-struct reservation_object *resv,
-void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init_top(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+uint32_t page_alignment,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
  {
  int ret = 0;
  unsigned long num_pages;
  struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
-bool locked;
ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
  if (ret) {
  pr_err("Out of kernel memory\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  return -ENOMEM;
  }
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
  if (num_pages == 0) {
  pr_err("Illegal buffer object size\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  ttm_mem_global_free(mem_glob, acc_size);
  return -EINVAL;
  }


I would move those checks after all the field initializations. This way
the structure has at least a valid content and we can safely use
ttm_bo_unref on it.


That feels odd to me, since the return value indicates that the buffer
wasn't properly initialized, but I don't feel strongly about it.

Cheers,
Nicolai




Regards,
Christian.


@@ -1204,6 +1193,37 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
  ret = drm_vma_offset_add(>vma_manager, >vma_node,
   bo->mem.num_pages);
  +return ret;
+}
+EXPORT_SYMBOL(ttm_bo_init_top);
+
+int ttm_bo_init(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+struct ttm_placement *placement,
+uint32_t page_alignment,
+bool interruptible,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
+{
+bool locked;
+int ret;
+
+ret = ttm_bo_init_top(bdev, bo, size, type, page_alignment,
+  persistent_swap_storage, acc_size, sg, resv,
+  destroy);
+if (ret) {
+if (destroy)
+(*destroy)(bo);
+else
+kfree(bo);
+return ret;
+}
+
  /* passed reservation objects should already be locked,
   * since otherwise lockdep will be angered in radeon.
   */
diff --git a/include/drm/ttm/ttm_bo_api.h
b/include/drm/ttm/ttm_bo_api.h
index f195899..d44b8e4 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -453,6 +453,51 @@ size_t 

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Maxime Ripard]

Hi,

On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote:
> > On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> > > On 13 February 2017 at 10:54, Maxime Ripard wrote:
> > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> > >>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> >  This patch add a config to support to create multi buffer for cma
> >  fbdev. Such as double buffer and triple buffer.
> >  
> >  Cma fbdev is convient to add a legency fbdev. And still many Android
> >  devices use fbdev now and at least double buffer is needed for these
> >  Android devices, so that a buffer flip can be operated. It will need
> >  some time for Android device vendors to abondon legency fbdev. So
> >  multi buffer for fbdev is needed.
> > >>> 
> > >>> How exactly do we expect Android to move away from fbdev if we add
> > >>> features to the fbdev compat layer ? I'd much rather make it clear to
> > >>> them that fbdev is a thing from the past and that they'd better
> > >>> migrate now.
> > >> 
> > >> If your point is that merging this patch will slow down the Android
> > >> move away from fbdev, I disagree with that (obviously).
> > >> 
> > >> I don't care at all about Android on my platform of choice, but don't
> > >> see how that merging this patch will change anything.
> > >> 
> > >> Let's be honest, Android trees typically have thousands of patches on
> > >> top of mainline. Do you think a simple, 15 LoC, patch will make any
> > >> difference to vendors? If they want to stay on fbdev and have that
> > >> feature, they'll just merge this patch, done.
> > > 
> > > So, in that case, why not just let them do that? They'd already have
> > > to add patches to use this, surely; we don't have anything in mainline
> > > kernels which allows people to actually use this larger allocation.
> > > Apart from software mmap() and using panning to do flips, but I'm
> > > taking it as a given that people shipping Android on their devices
> > > aren't using software rendering.
> > 
> > I think we need to make a distinction between fbdev the subsystem in the
> > kernel, and fbdev the uabi:
> > 
> > - fbdev the subsystem is completely dead in upstream. I think we have full
> >   agreement on that.
> > - fbdev the uabi isn't, and if we can get more users from fbdev based
> >   drivers to kms/atomic drivers by adding fairly simple stuff like this,
> >   I'm all for it.
>
> The real question, in my opinion, is how to get more users for the DRM/KMS 
> userspace API, to help killing the fbdev API. What's the incentive for 
> userspace to migrate if we tell them that we're going to support the fbdev 
> API 
> forever, and will even go through the trouble of extending the supported 
> feature set ? I have a customer who wouldn't have migrated their userspace to 
> DRM/KMS if these two patches had been merged a few years ago.

If those patches are not in, then I can see three ways to support old
/ deficient userspaces:
  1) Carry those patches out of tree
  2) Write an fbdev driver for the display engine
  3) Rewrite the userspace components

While 3. would arguably be the best option, this isn't always one,
unfortunately.

And as a community, I think 1 and 2 are not very good for us. 1. will
drive away vendors from our community, undermining the effort we've
been doing for a few years. And 2 will result in a driver we really
don't want to merge (so useless), and even if it would out of tree,
that would make it one less system / board / SoC *with* DRM/KMS APIs,
reducing the interest of switching for application developpers.

If we really want to make people switch to DRM / KMS, we have to make
it ubiquitous. And if we want to make it ubiquitous, we really want to
have a transition period where people will have both APIs, supported
in a decent enough way.

And then, that's a win for everyone, because in the process you get
fbdev (booo!) and KMS (yay!), allowing for people to switch over, and
eventually kill the emulation entirely. But it's far too early for
that. I mean, we don't even have an fbv replacement yet...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v3 23/24] drm/rockchip: dw-mipi-dsi: add reset control

[John Keeping]

On Wed, 15 Feb 2017 11:38:45 +0800, Chris Zhong wrote:

> On 01/29/2017 09:24 PM, John Keeping wrote:
> > In order to fully reset the state of the MIPI controller we must assert
> > this reset.
> >
> > This is slightly more complicated than it could be in order to maintain
> > compatibility with device trees that do not specify the reset property.
> >
> > Signed-off-by: John Keeping 
> > Reviewed-by: Chris Zhong 
> > ---
> > v3:
> > - Add Chris' Reviewed-by
> > Unchanged in v2
> >
> >   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 30 ++
> >   1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index 58cb8ace2fe8..cf3ca6b0cbdb 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -13,6 +13,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -1124,6 +1125,7 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> > struct device *master,
> > of_match_device(dw_mipi_dsi_dt_ids, dev);
> > const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
> > struct platform_device *pdev = to_platform_device(dev);
> > +   struct reset_control *apb_rst;
> > struct drm_device *drm = data;
> > struct dw_mipi_dsi *dsi;
> > struct resource *res;
> > @@ -1162,6 +1164,34 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> > struct device *master,
> > return ret;
> > }
> >   
> > +   /*
> > +* Note that the reset was not defined in the initial device tree, so
> > +* we have to be prepared for it not being found.
> > +*/
> > +   apb_rst = devm_reset_control_get(dev, "apb");
> > +   if (IS_ERR(apb_rst)) {
> > +   if (PTR_ERR(apb_rst) == -ENODEV) {  
> According to [0], I think it should be -ENOENT here.

Nice catch, I'll fix this.

> [0]
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3d81216fde465e76c5eae98f61d3666163634395
> 
> commit 3d81216fde465e76c5eae98f61d3666163634395
> Author: Alban Bedel 
> Date:   Tue Sep 1 17:28:31 2015 +0200
> 
>  reset: Fix of_reset_control_get() for consistent return values
> 
>  When of_reset_control_get() is called without connection ID it returns
>  -ENOENT when the 'resets' property doesn't exists or is an empty entry.
>  However when a connection ID is given it returns -EINVAL when the 
> 'resets'
>  property doesn't exists or the requested name can't be found. This is
>  because the error code returned by of_property_match_string() is just
>  passed down as an index to of_parse_phandle_with_args(), which then
>  returns -EINVAL.
> 
>  To get a consistent return value with both code paths we must return
>  -ENOENT when of_property_match_string() fails.
> 
>  Signed-off-by: Alban Bedel 
>  Signed-off-by: Philipp Zabel 
> 
> 
> > +   apb_rst = NULL;
> > +   } else {
> > +   dev_err(dev, "Unable to get reset control: %d\n", ret);
> > +   return PTR_ERR(apb_rst);
> > +   }
> > +   }
> > +
> > +   if (apb_rst) {
> > +   ret = clk_prepare_enable(dsi->pclk);
> > +   if (ret) {
> > +   dev_err(dev, "%s: Failed to enable pclk\n", __func__);
> > +   return ret;
> > +   }
> > +
> > +   reset_control_assert(apb_rst);
> > +   usleep_range(10, 20);
> > +   reset_control_deassert(apb_rst);
> > +
> > +   clk_disable_unprepare(dsi->pclk);
> > +   }
> > +
> > ret = clk_prepare_enable(dsi->pllref_clk);
> > if (ret) {
> > dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);  
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Maxime Ripard]

Hi,

On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> Hi Maxime,
> 
> On 13 February 2017 at 10:54, Maxime Ripard
>  wrote:
> > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> >> > This patch add a config to support to create multi buffer for cma fbdev.
> >> > Such as double buffer and triple buffer.
> >> >
> >> > Cma fbdev is convient to add a legency fbdev. And still many Android
> >> > devices use fbdev now and at least double buffer is needed for these
> >> > Android devices, so that a buffer flip can be operated. It will need
> >> > some time for Android device vendors to abondon legency fbdev. So multi
> >> > buffer for fbdev is needed.
> >>
> >> How exactly do we expect Android to move away from fbdev if we add 
> >> features to
> >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev 
> >> is a
> >> thing from the past and that they'd better migrate now.
> >
> > If your point is that merging this patch will slow down the Android
> > move away from fbdev, I disagree with that (obviously).
> >
> > I don't care at all about Android on my platform of choice, but don't
> > see how that merging this patch will change anything.
> >
> > Let's be honest, Android trees typically have thousands of patches on
> > top of mainline. Do you think a simple, 15 LoC, patch will make any
> > difference to vendors? If they want to stay on fbdev and have that
> > feature, they'll just merge this patch, done.
> 
> So, in that case, why not just let them do that? They'd already have
> to add patches to use this, surely; we don't have anything in mainline
> kernels which allows people to actually use this larger allocation.
> Apart from software mmap() and using panning to do flips, but I'm
> taking it as a given that people shipping Android on their devices
> aren't using software rendering.

My point was that you're not doing it more difficult for people not
willing to contribute upstream, you're just making it more difficult
for people who want to contribute.

The whole argument to engage vendors upstream is that we sell them
that eventually they will be able to just use whatever kernel release
is on kernel.org or in their distro of choice.

If those people depend on a feature that is entirely rejected
upstream, then they'll have to carry that patch in their tree,
creating a BSP in the process. And that reduces greatly the strength
of the "you should contribute" argument, making them less involved.

> > However, what I do see is that three different people/organisations
> > have now expressed interest in that feature, on three different
> > SoCs. If that patch needed a significant rework of the fbdev layer,
> > then yes, I might agree that it's not worth it. But in this case, it's
> > pretty trivial.
> >
> > The only people you're "punishing" here with that kind of concern are
> > the people who actually play fair and want not to have any patches and
> > everything upstream.
> 
> I would hazard a guess that most users of this have out-of-tree GPU
> drivers.

Out of tree GPU drivers, that can be distributed separately from the
kernel, just like any out of tree module can. This doesn't require any
kernel patches at all.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Mark Brown]

On Tue, Feb 14, 2017 at 09:59:55PM +0200, Laurent Pinchart wrote:
> On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:

> > ADF was probably the best example in this. KMS also took a while until all
> > the fbdev wheels have been properly reinvented (some are still the same old
> > squeaky onces as fbdev had, e.g. fbcon).

> > And I don't think destaging ION is going to be hard, just a bit of
> > work (could be a nice gsoc or whatever).

> Oh, technically speaking, it would be pretty simple. The main issue is to 
> decide whether we want to commit to the existing ION API. I don't :-)

Right, we need to figure out what people should be doing and let them
work on it.  At the minute anyone who wants to use this stuff in
mainline is kind of stuck as attempts to add ION drivers get pushback

   https://lkml.org/lkml/2016/11/7/806

but so do attempts to do something different (there was a statement in
that thread that new ION drivers could be added if we could ever figure
out bindings but I'm not sure there's any prospect of that).  There's no
clear direction for people to follow if they want to make progress.


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

Re: [PATCH v2] drm/color: Document CTM eqations

[Daniel Stone]

Hi,

On 15 February 2017 at 11:39, Ville Syrjälä
 wrote:
> On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
>>  wrote:
>> > Hmm. Two's complement is what I was thinking it is. Which shows that
>> > I never managed to read the code in any detail. Definitely needs to
>> > be documented properly.
>>
>> That sounds supremely backwards. I guess we can't fix this anymore?
>
> I have no idea. Anyone else?

I don't know of any implementation using this; maybe closed Intel
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.

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

Re: [PATCH v2] drm/color: Document CTM eqations

[Ville Syrjälä]

On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
> On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
>  wrote:
> >> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >> >> index ce7efe2e8a5e..3401637caf8e 100644
> >> >> --- a/include/uapi/drm/drm_mode.h
> >> >> +++ b/include/uapi/drm/drm_mode.h
> >> >> @@ -525,7 +525,13 @@ struct drm_mode_crtc_lut {
> >> >>  };
> >> >>
> >> >>  struct drm_color_ctm {
> >> >> -  /* Conversion matrix in S31.32 format. */
> >> >> +  /*
> >> >> +   * Conversion matrix in S31.32 format, in row-major form:
> >> >
> >> >s32.32 is how I'd state that (to match the regular s32 and whatnot
> >> >types).
> >> >
> >>
> >> Can you explain a bit more what exactly you mean by s32.32? e.g. what
> >> would be the bitfield representing the most negative number?
> >>
> >> I understand the S31.32 here as a sign + magnitude format (which makes
> >> it rather odd to store it in a signed variable, but never mind). This
> >> also appears to be what igt does in set_ctm() in kms_pipe_color.c:
> >>
> >>   for (i = 0; i < ARRAY_SIZE(ctm.matrix); i++) {
> >>   if (coefficients[i] < 0) {
> >>   ctm.matrix[i] =
> >>   (int64_t) (-coefficients[i] * ((int64_t) 1L 
> >> << 32));
> >>   ctm.matrix[i] |= 1ULL << 63;
> >>   } else
> >>   ctm.matrix[i] =
> >>   (int64_t) (coefficients[i] * ((int64_t) 1L 
> >> << 32));
> >>   }
> >>
> >> If that's what you meant as well, then I don't think s32.32 is a good
> >> way to describe it, because the integer part has only 31 bits
> >> available.
> >>
> >> If you meant a regular two's-complement fixed-point number, where the
> >> most negative number would be 0x1000., then yeah that's
> >> what I thought it meant too originally. Clarifying the docs here
> >> sounds like a great plan.
> >>
> >> I guess the igt implementation means that it's a sign + magnitude
> >> number, and the fact that it's stored in an s64 is a bizarre quirk
> >> that we just live with.
> >
> > Hmm. Two's complement is what I was thinking it is. Which shows that
> > I never managed to read the code in any detail. Definitely needs to
> > be documented properly.
> 
> That sounds supremely backwards. I guess we can't fix this anymore?

I have no idea. Anyone else?

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Archit Taneja]

Hi,

On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }

 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;


Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).

Thanks,
Archit


+
+   num_objs = state->num_private_objs + 1;
+   size = sizeof(*state->private_objs) * num_objs;
+   arr = krealloc(state->private_objs, size, GFP_KERNEL);
+   if (!arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs = arr;
+   index = state->num_private_objs;
+   memset(>private_objs[index], 0, sizeof(*state->private_objs));
+
+   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
obj);
+   if (!state->private_objs[index].obj_state)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs[index].obj = obj;
+   state->private_objs[index].funcs = funcs;
+   state->num_private_objs = num_objs;
+
+   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
+state->private_objs[index].obj_state, state);
+
+   return state->private_objs[index].obj_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+
+/**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
  * @connector: connector to get state object for
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

[zhoucm1]

On 2017年02月15日 18:43, Nicolai Hähnle wrote:

On 15.02.2017 04:16, zhoucm1 wrote:

On 2017年02月14日 18:37, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.

Signed-off-by: Nicolai Hähnle 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 62
+---
  include/drm/ttm/ttm_bo_api.h | 45 
  2 files changed, 86 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
b/drivers/gpu/drm/ttm/ttm_bo.c

index 76bee42..ce4c0f5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1120,41 +1120,30 @@ int ttm_bo_validate(struct ttm_buffer_object 
*bo,

  }
  EXPORT_SYMBOL(ttm_bo_validate);
  -int ttm_bo_init(struct ttm_bo_device *bdev,
-struct ttm_buffer_object *bo,
-unsigned long size,
-enum ttm_bo_type type,
-struct ttm_placement *placement,
-uint32_t page_alignment,
-bool interruptible,
-struct file *persistent_swap_storage,
-size_t acc_size,
-struct sg_table *sg,
-struct reservation_object *resv,
-void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init_top(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+uint32_t page_alignment,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
  {
  int ret = 0;
  unsigned long num_pages;
  struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
-bool locked;
ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
  if (ret) {
  pr_err("Out of kernel memory\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  return -ENOMEM;
  }
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
  if (num_pages == 0) {
  pr_err("Illegal buffer object size\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  ttm_mem_global_free(mem_glob, acc_size);
  return -EINVAL;
  }
@@ -1204,6 +1193,37 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
  ret = drm_vma_offset_add(>vma_manager, >vma_node,
   bo->mem.num_pages);

if (ret && !resv), we should call
reservation_object_fini(>ttm_resv), right?


Good point, though actually, ret can never be != 0 here, so this can 
be simplified a bit.




  +return ret;
+}
+EXPORT_SYMBOL(ttm_bo_init_top);
+
+int ttm_bo_init(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+struct ttm_placement *placement,
+uint32_t page_alignment,
+bool interruptible,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
+{
+bool locked;
+int ret;
+

Can we lock resv anyway before ttm_bo_init_top like what you did in
patch #3? if yes, seems we don't need patch#3 any more, right?


if (!resv) {
bool locked;

reservation_object_init(>tbo.ttm_resv);
locked = ww_mutex_trylock(>tbo.ttm_resv.lock);
WARN_ON(!locked);
}
r = ttm_bo_init_top(>mman.bdev, >tbo, size, type,
page_align, NULL,
acc_size, sg, resv ? resv : 
>tbo.ttm_resv,

_ttm_bo_destroy);


No, because there's still different behavior when it comes to 
unlocking. There are three different behaviors that are needed:


1. resv == NULL, and leaving ttm_bo_init with the BO unreserved.

2. resv != NULL, and not changing the reserved status during 
initialization.


3. resv != NULL, and leaving initialization with the BO reserved, but 
unlocking when the BO is destroyed.


1+2 can be expressed well with the ttm_bo_init interface, but 3 cannot.

I think a possible alternative would be to change ttm_bo_init so that 
it always returns on success with the BO reserved, but that would 
require changing all the drivers, and I don't really see the advantage 
over just being more explicit in each driver.

OK, make sense, then wait Alex to submit to staging branch and verify it.

Thanks,
David Zhou


Cheers,
Nicolai



Regards,
David Zhou

+ret = ttm_bo_init_top(bdev, bo, size, type, page_alignment,
+  persistent_swap_storage, acc_size, sg, resv,
+  destroy);
+if (ret) {
+if 

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

[Nicolai Hähnle]

On 15.02.2017 04:16, zhoucm1 wrote:

On 2017年02月14日 18:37, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.

Signed-off-by: Nicolai Hähnle 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 62
+---
  include/drm/ttm/ttm_bo_api.h | 45 
  2 files changed, 86 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 76bee42..ce4c0f5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1120,41 +1120,30 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
  }
  EXPORT_SYMBOL(ttm_bo_validate);
  -int ttm_bo_init(struct ttm_bo_device *bdev,
-struct ttm_buffer_object *bo,
-unsigned long size,
-enum ttm_bo_type type,
-struct ttm_placement *placement,
-uint32_t page_alignment,
-bool interruptible,
-struct file *persistent_swap_storage,
-size_t acc_size,
-struct sg_table *sg,
-struct reservation_object *resv,
-void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init_top(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+uint32_t page_alignment,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
  {
  int ret = 0;
  unsigned long num_pages;
  struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
-bool locked;
ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
  if (ret) {
  pr_err("Out of kernel memory\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  return -ENOMEM;
  }
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
  if (num_pages == 0) {
  pr_err("Illegal buffer object size\n");
-if (destroy)
-(*destroy)(bo);
-else
-kfree(bo);
  ttm_mem_global_free(mem_glob, acc_size);
  return -EINVAL;
  }
@@ -1204,6 +1193,37 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
  ret = drm_vma_offset_add(>vma_manager, >vma_node,
   bo->mem.num_pages);

if (ret && !resv), we should call
reservation_object_fini(>ttm_resv), right?


Good point, though actually, ret can never be != 0 here, so this can be 
simplified a bit.




  +return ret;
+}
+EXPORT_SYMBOL(ttm_bo_init_top);
+
+int ttm_bo_init(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+struct ttm_placement *placement,
+uint32_t page_alignment,
+bool interruptible,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
+{
+bool locked;
+int ret;
+

Can we lock resv anyway before ttm_bo_init_top like what you did in
patch #3? if yes, seems we don't need patch#3 any more, right?


if (!resv) {
bool locked;

reservation_object_init(>tbo.ttm_resv);
locked = ww_mutex_trylock(>tbo.ttm_resv.lock);
WARN_ON(!locked);
}
r = ttm_bo_init_top(>mman.bdev, >tbo, size, type,
page_align, NULL,
acc_size, sg, resv ? resv : >tbo.ttm_resv,
_ttm_bo_destroy);


No, because there's still different behavior when it comes to unlocking. 
There are three different behaviors that are needed:


1. resv == NULL, and leaving ttm_bo_init with the BO unreserved.

2. resv != NULL, and not changing the reserved status during initialization.

3. resv != NULL, and leaving initialization with the BO reserved, but 
unlocking when the BO is destroyed.


1+2 can be expressed well with the ttm_bo_init interface, but 3 cannot.

I think a possible alternative would be to change ttm_bo_init so that it 
always returns on success with the BO reserved, but that would require 
changing all the drivers, and I don't really see the advantage over just 
being more explicit in each driver.


Cheers,
Nicolai



Regards,
David Zhou

+ret = ttm_bo_init_top(bdev, bo, size, type, page_alignment,
+  persistent_swap_storage, acc_size, sg, resv,
+  destroy);
+if (ret) {
+if (destroy)
+(*destroy)(bo);
+else
+kfree(bo);
+return ret;
+}
+
  /* passed reservation 

Re: [Intel-gfx] [PATCH RESEND] drm/dp/mst: fix kernel oops when turning off secondary monitor

[Jani Nikula]

On Wed, 15 Feb 2017, Jani Nikula  wrote:
> On Tue, 14 Feb 2017, Daniel Vetter  wrote:
>> On Tue, Feb 14, 2017 at 02:49:21PM +0200, Jani Nikula wrote:
>>> From: Pierre-Louis Bossart 
>>> 
>>> 100% reproducible issue found on SKL SkullCanyon NUC with two external
>>> DP daisy-chained monitors in DP/MST mode. When turning off or changing
>>> the input of the second monitor the machine stops with a kernel
>>> oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.
>>> 
>>> This issue is traced to an inconsistent control flow in
>>> drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
>>> same time as 'req_payload.num_slots' is set to zero, but the pointer is
>>> dereferenced even when req_payload.num_slot is zero.
>>> 
>>> The problematic dereference was introduced in commit dfda0df34
>>> ("drm/mst: rework payload table allocation to conform better") and may
>>> impact all versions since v3.18
>>> 
>>> The fix suggested by Chris Wilson removes the kernel oops and was found to
>>> work well after 10mn of monkey-testing with the second monitor power and
>>> input buttons
>>> 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
>>> Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform 
>>> better.")
>>> Cc: Dave Airlie 
>>> Cc: Chris Wilson 
>>> Cc: Nathan D Ciobanu 
>>> Cc: Dhinakaran Pandiyan 
>>> Cc: Sean Paul 
>>> Cc:  # v3.18+
>>> Tested-by: Nathan D Ciobanu 
>>> Reviewed-by: Dhinakaran Pandiyan 
>>> Signed-off-by: Pierre-Louis Bossart 
>>> Signed-off-by: Jani Nikula 
>>
>> You haz drm-misc commit rights, pls use them :-)
>
> Sure, I just wanted to have a fresh CI run on this.
>
>> Since it doesn't have deps, probably simplest to smash into drm-misc-fixes
>> and then send a pull req to Dave right away. If you want, you can roll
>> -fixes forward to -rc8 while at it.
>
> Will do.

And pushed to drm-misc-fixes, thanks for the patch, review and testing.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98784] Talos Principle rendering flickering garbage on start instead of its logo and loading squares

[bugzilla-daemon]

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

--- Comment #17 from Germano Massullo  ---
(In reply to Torbjörn Andersson from comment #16)
> I can't reproduce the glitch any more. Perhaps today's update of the game
> fixed it?

I still experience the problem even after the update

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

[Bug 99542] vdpau logging errors since gallium/radeon: adjust the rule for using the LINEAR_ALIGNED layout

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Benjamin Gaignard]

2017-02-14 20:59 GMT+01:00 Laurent Pinchart :
> Hi Daniel,
>
> On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
>> On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart wrote:
>> > On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
>> >> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
>> >>> This is the core of simple allocator module.
>> >>> It aim to offert one common ioctl to allocate specific memory.
>> >>>
>> >>> version 2:
>> >>> - rebased on 4.10-rc7
>> >>>
>> >>> Signed-off-by: Benjamin Gaignard 
>> >>
>> >> Why not ION? It's a bit a broken record question, but if there is a
>> >> clear answer it should be in the patch ...
>> >
>> > There's a bit of love & hate relationship between Linux developers and
>> > ION. The API has shortcomings, and attempts to fix the issues went
>> > nowhere. As Laura explained, starting from a blank slate (obviously
>> > keeping in mind the lessons learnt so far with ION and other similar APIs)
>> > and then adding a wrapper to expose ION on Android systems (at least as an
>> > interim measure) was thought to be a better option. I still believe it is,
>> > but we seem to lack traction. The problem has been around for so long that
>> > I feel everybody has lost hope.
>> >
>> > I don't think this is unsolvable, but we need to regain motivation. In my
>> > opinion the first step would be to define the precise extent of the
>> > problem we want to solve.
>>
>> I'm not sure anyone really tried hard enough (in the same way no one
>> tried hard enough to destage android syncpts, until last year). And
>> anything new should at least very clearly explain why ION (even with
>> the various todo items we collected at a few conferences) won't work,
>> and how exactly the new allocator is different from ION. I don't think
>> we need a full design doc (like you say, buffer allocation is hard,
>> we'll get it wrong anyway), but at least a proper comparison with the
>> existing thing. Plus explanation why we can't reuse the uabi.
>
> I've explained several of my concerns (including open questions that need
> answers) in another reply to this patch, let's discuss them there to avoid
> splitting the discussion.
>
>> Because ime when you rewrite something, you generally get one thing
>> right (the one thing that pissed you off about the old solution), plus
>> lots and lots of things that the old solution got right, wrong
>> (because it's all lost in the history).
>
> History, repeating mistakes, all that. History never repeats itself though. We
> might make similar or identical mistakes, but there's no fatality, unless we
> decide not to try before even starting :-)
>
>> ADF was probably the best example in this. KMS also took a while until all
>> the fbdev wheels have been properly reinvented (some are still the same old
>> squeaky onces as fbdev had, e.g. fbcon).
>>
>> And I don't think destaging ION is going to be hard, just a bit of
>> work (could be a nice gsoc or whatever).
>
> Oh, technically speaking, it would be pretty simple. The main issue is to
> decide whether we want to commit to the existing ION API. I don't :-)

I think that Laura have give her felling about ION when commenting the previous
version of this patchset:
https://lkml.org/lkml/2017/1/25/76

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

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Benjamin Gaignard]

2017-02-14 20:30 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch. I've CC'ed the linux-api mailing list.
>
> On Monday 13 Feb 2017 15:45:05 Benjamin Gaignard wrote:
>> This is the core of simple allocator module.
>> It aim to offert one common ioctl to allocate specific memory.
>>
>> version 2:
>> - rebased on 4.10-rc7
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  Documentation/simple-allocator.txt  |  81 +++
>>  drivers/Kconfig |   2 +
>>  drivers/Makefile|   1 +
>>  drivers/simpleallocator/Kconfig |  10 ++
>>  drivers/simpleallocator/Makefile|   1 +
>>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>>  drivers/simpleallocator/simple-allocator.c  | 180 +
>>  include/uapi/linux/simple-allocator.h   |  35 +
>>  8 files changed, 343 insertions(+)
>>  create mode 100644 Documentation/simple-allocator.txt
>>  create mode 100644 drivers/simpleallocator/Kconfig
>>  create mode 100644 drivers/simpleallocator/Makefile
>>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>>  create mode 100644 include/uapi/linux/simple-allocator.h
>>
>> diff --git a/Documentation/simple-allocator.txt
>> b/Documentation/simple-allocator.txt new file mode 100644
>> index 000..89ba883
>> --- /dev/null
>> +++ b/Documentation/simple-allocator.txt
>> @@ -0,0 +1,81 @@
>> +Simple Allocator Framework
>
> There's nothing simple in buffer allocation, otherwise we would have solved
> the problem a long time ago. Let's not use a misleading name.

Simple was not about the problem, it was about the using only one ioctl.
Anyway a better name is needed: "Limited allocation API", "Basic
allocator framework" ?
suggestions are welcomes

>
>> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
>> +on dedicated memory regions and export them as a dmabuf file descriptor.
>> +Using dmabuf file descriptor allow to share this memory between processes
>> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
>> +When userland wants to free the memory only a call to close() in needed
>> +so it could done even without knowing that buffer has been allocated by
>> +simple allocator ioctl.
>> +
>> +Each memory regions will be seen as a filein /dev/.
>> +For example CMA regions will exposed has /dev/cmaX.
>
> Why do you need multiple devices ? Furthermore, given how central this API
> will become, I believe it needs very strict review, and would be a candidate
> for a syscall.

I believe that having a device per memory regions is simple than have having,
like ION, heaps which request to add masks (or heap ids) to select them.
My goal here is not to have a a central device /dev/simple_allocator
where allcoations
are dispatched over heaps but only a common ioctl to make userland life easier.
Maybe I should regroup all the device under the same directory: /dev/simple/ ?

>
> Without diving into details yet, there are a few particular points I'm
> concerned about.
>
> - What is the scope of this API ? What problems do you want to solve, plan to
> solve in the future, and consider as out of scope ?

My problem is to be able to allocate a buffer in contiguous memory
(CMA) when using
a software decoder and Weston. This will save the copy between decoder
and display
because display only accepted contiguous memory.
Wayland dmabuf protocol can't allocate buffers so I need an other way
to get access to CMA.
I also other use cases where I need to allocate memory in special
memory region for secure
purpose.

For those both cases I need an API to allocate memory from userland so
I decided to
propose a common ioctl which may be used for even more memory regions.

>
> - How should we handle permissions and resource limits ? Is file-based
> permission on a device node a good model ? How do we prevent or at least
> mitigate memory-related DoS ?

Since each memory region will be represented by a device we could set per
device permissions for example with SELinux policy.

>
> - How should such a central allocator API interact with containers and
> virtualization in general ?

I'm not expert enough in container and virtualization but I know they could have
access to some files/directories to store data so I guess it will
possible for them
to call (for example) /dev/cma0  to allocate memory

> - What model do we want to expose to applications to select a memory type ?
> You still haven't convinced me that we should expose memory pools explicitly
> to application (à la ION), and I believe a usage/constraint model would be
> better.

Memory type selection should be solved by something more smarter than my code.
My goal here is only to provided a common way to perform allocations.
If  "Unix Device Memory 

Re: [Intel-gfx] [PATCH RESEND] drm/dp/mst: fix kernel oops when turning off secondary monitor

[Jani Nikula]

On Tue, 14 Feb 2017, Daniel Vetter  wrote:
> On Tue, Feb 14, 2017 at 02:49:21PM +0200, Jani Nikula wrote:
>> From: Pierre-Louis Bossart 
>> 
>> 100% reproducible issue found on SKL SkullCanyon NUC with two external
>> DP daisy-chained monitors in DP/MST mode. When turning off or changing
>> the input of the second monitor the machine stops with a kernel
>> oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.
>> 
>> This issue is traced to an inconsistent control flow in
>> drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
>> same time as 'req_payload.num_slots' is set to zero, but the pointer is
>> dereferenced even when req_payload.num_slot is zero.
>> 
>> The problematic dereference was introduced in commit dfda0df34
>> ("drm/mst: rework payload table allocation to conform better") and may
>> impact all versions since v3.18
>> 
>> The fix suggested by Chris Wilson removes the kernel oops and was found to
>> work well after 10mn of monkey-testing with the second monitor power and
>> input buttons
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
>> Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform 
>> better.")
>> Cc: Dave Airlie 
>> Cc: Chris Wilson 
>> Cc: Nathan D Ciobanu 
>> Cc: Dhinakaran Pandiyan 
>> Cc: Sean Paul 
>> Cc:  # v3.18+
>> Tested-by: Nathan D Ciobanu 
>> Reviewed-by: Dhinakaran Pandiyan 
>> Signed-off-by: Pierre-Louis Bossart 
>> Signed-off-by: Jani Nikula 
>
> You haz drm-misc commit rights, pls use them :-)

Sure, I just wanted to have a fresh CI run on this.

> Since it doesn't have deps, probably simplest to smash into drm-misc-fixes
> and then send a pull req to Dave right away. If you want, you can roll
> -fixes forward to -rc8 while at it.

Will do.

BR,
Jani.

> -Daniel
>
>> ---
>>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 122a1b04bebc..f2cc375907d0 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1817,7 +1817,7 @@ int drm_dp_update_payload_part1(struct 
>> drm_dp_mst_topology_mgr *mgr)
>>  mgr->payloads[i].vcpi = req_payload.vcpi;
>>  } else if (mgr->payloads[i].num_slots) {
>>  mgr->payloads[i].num_slots = 0;
>> -drm_dp_destroy_payload_step1(mgr, port, 
>> port->vcpi.vcpi, >payloads[i]);
>> +drm_dp_destroy_payload_step1(mgr, port, 
>> mgr->payloads[i].vcpi, >payloads[i]);
>>  req_payload.payload_state = 
>> mgr->payloads[i].payload_state;
>>  mgr->payloads[i].start_slot = 0;
>>  }
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel