RE: [PATCH] drm/ttm: add updated_glob_count in dma_page

[He, Roger]

-Original Message-
From: Koenig, Christian 
Sent: Wednesday, January 17, 2018 3:37 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: Grodzovsky, Andrey 
Subject: Re: [PATCH] drm/ttm: add updated_glob_count in dma_page

Am 17.01.2018 um 06:54 schrieb Roger He:
> add this for correctly updating global mem count in ttm_mem_zone.
> before that when ttm_mem_global_alloc_page fails, we would update all 
> dma_page's global mem count in ttm_dma->pages_list. but actually here 
> we should not update for the last dma_page.
>
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 57 
> +---
>   1 file changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index c7f01a4..3e78ea4 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -121,6 +121,8 @@ struct dma_pool {
>* @vaddr: The virtual address of the page and a flag if the page belongs 
> to a
>* huge pool
>* @dma: The bus address of the page. If the page is not allocated
> + * @updated_glob_count: to indicate whether we already updated global
> + * memory count in ttm_mem_zone
>*   via the DMA API, it will be -1.
>*/
>   struct dma_page {
> @@ -128,6 +130,7 @@ struct dma_page {
>   unsigned long vaddr;
>   struct page *p;
>   dma_addr_t dma;
> + bool updated_glob_count;

That is not a good idea at all because it massively increases how much 
memory we will use.

Please put that in the vaddr instead. The lower bits should always be 
zero, so we already put the VADDR_FLAG_HUGE_POOL flag in there.

Good idea, I will try.

Thanks
Roger(Hongbo.He)
>   };
>   
>   /*
> @@ -874,18 +877,18 @@ static int ttm_dma_page_pool_fill_locked(struct 
> dma_pool *pool,
>   }
>   
>   /*
> - * @return count of pages still required to fulfill the request.
>* The populate list is actually a stack (not that is matters as TTM
>* allocates one page at a time.
> + * return dma_page pointer if success, otherwise NULL.
>*/
> -static int ttm_dma_pool_get_pages(struct dma_pool *pool,
> +static struct dma_page *ttm_dma_pool_get_pages(struct dma_pool *pool,
> struct ttm_dma_tt *ttm_dma,
> unsigned index)
>   {
> - struct dma_page *d_page;
> + struct dma_page *d_page = NULL;
>   struct ttm_tt *ttm = _dma->ttm;
>   unsigned long irq_flags;
> - int count, r = -ENOMEM;
> + int count;
>   
>   spin_lock_irqsave(>lock, irq_flags);
>   count = ttm_dma_page_pool_fill_locked(pool, _flags); @@ -894,12 
> +897,11 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
>   ttm->pages[index] = d_page->p;
>   ttm_dma->dma_address[index] = d_page->dma;
>   list_move_tail(_page->page_list, _dma->pages_list);
> - r = 0;
>   pool->npages_in_use += 1;
>   pool->npages_free -= 1;
>   }
>   spin_unlock_irqrestore(>lock, irq_flags);
> - return r;
> + return d_page;
>   }
>   
>   static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool 
> huge) @@ -934,6 +936,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, 
> struct device *dev,
>   struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
>   unsigned long num_pages = ttm->num_pages;
>   struct dma_pool *pool;
> + struct dma_page *d_page;
>   enum pool_type type;
>   unsigned i;
>   int ret;
> @@ -962,8 +965,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev,
>   while (num_pages >= HPAGE_PMD_NR) {
>   unsigned j;
>   
> - ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
> - if (ret != 0)
> + d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
> + if (!d_page)
>   break;
>   
>   ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i], @@ 
> -973,6 
> +976,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev,
>   return -ENOMEM;
>   }
>   
> + d_page->updated_glob_count = true;
>   for (j = i + 1; j < (i + HPAGE_PMD_NR); ++j) {
>   ttm->pages[j] = ttm->pages[j - 1] + 1;
>   ttm_dma->dma_address[j] = ttm_dma->dma_address[j - 1] + 
> @@ -996,8 
> +1000,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device 
> *dev,
>   }
>   
>   while (num_pages) {
> - ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
> - if (ret != 0) {
> + d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
> + if (!d_page) {
>   ttm_dma_unpopulate(ttm_dma, dev);
>   return -ENOMEM;
> 

Re: [PATCH] drm/ttm: add updated_glob_count in dma_page

[Christian König]

Am 17.01.2018 um 06:54 schrieb Roger He:

add this for correctly updating global mem count in ttm_mem_zone.
before that when ttm_mem_global_alloc_page fails, we would update all
dma_page's global mem count in ttm_dma->pages_list. but actually here
we should not update for the last dma_page.

Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 57 +---
  1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..3e78ea4 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -121,6 +121,8 @@ struct dma_pool {
   * @vaddr: The virtual address of the page and a flag if the page belongs to a
   * huge pool
   * @dma: The bus address of the page. If the page is not allocated
+ * @updated_glob_count: to indicate whether we already updated global
+ * memory count in ttm_mem_zone
   *   via the DMA API, it will be -1.
   */
  struct dma_page {
@@ -128,6 +130,7 @@ struct dma_page {
unsigned long vaddr;
struct page *p;
dma_addr_t dma;
+   bool updated_glob_count;


That is not a good idea at all because it massively increases how much 
memory we will use.


Please put that in the vaddr instead. The lower bits should always be 
zero, so we already put the VADDR_FLAG_HUGE_POOL flag in there.


Apart from that it looks good to me.

Regards,
Christian.


  };
  
  /*

@@ -874,18 +877,18 @@ static int ttm_dma_page_pool_fill_locked(struct dma_pool 
*pool,
  }
  
  /*

- * @return count of pages still required to fulfill the request.
   * The populate list is actually a stack (not that is matters as TTM
   * allocates one page at a time.
+ * return dma_page pointer if success, otherwise NULL.
   */
-static int ttm_dma_pool_get_pages(struct dma_pool *pool,
+static struct dma_page *ttm_dma_pool_get_pages(struct dma_pool *pool,
  struct ttm_dma_tt *ttm_dma,
  unsigned index)
  {
-   struct dma_page *d_page;
+   struct dma_page *d_page = NULL;
struct ttm_tt *ttm = _dma->ttm;
unsigned long irq_flags;
-   int count, r = -ENOMEM;
+   int count;
  
  	spin_lock_irqsave(>lock, irq_flags);

count = ttm_dma_page_pool_fill_locked(pool, _flags);
@@ -894,12 +897,11 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
ttm->pages[index] = d_page->p;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(_page->page_list, _dma->pages_list);
-   r = 0;
pool->npages_in_use += 1;
pool->npages_free -= 1;
}
spin_unlock_irqrestore(>lock, irq_flags);
-   return r;
+   return d_page;
  }
  
  static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool huge)

@@ -934,6 +936,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
+   struct dma_page *d_page;
enum pool_type type;
unsigned i;
int ret;
@@ -962,8 +965,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
while (num_pages >= HPAGE_PMD_NR) {
unsigned j;
  
-		ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);

-   if (ret != 0)
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page)
break;
  
  		ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],

@@ -973,6 +976,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
  
+		d_page->updated_glob_count = true;

for (j = i + 1; j < (i + HPAGE_PMD_NR); ++j) {
ttm->pages[j] = ttm->pages[j - 1] + 1;
ttm_dma->dma_address[j] = ttm_dma->dma_address[j - 1] +
@@ -996,8 +1000,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
}
  
  	while (num_pages) {

-   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
-   if (ret != 0) {
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
}
@@ -1009,6 +1013,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
  
+		d_page->updated_glob_count = true;

++i;
--num_pages;
}
@@ -1049,8 +1054,11 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
continue;
  
  			count++;

-   

drm: fix vmwgfx boot warning WAS Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps

[Thomas Hellstrom]

Hi, Woody,

On 01/16/2018 10:39 PM, Woody Suwalski wrote:

Thomas, the same way my DRM patch has disappeared:
Date

Tue, 19 Dec 2017 11:50:57 -0800
From Sinclair Yeh <>
Subject Re: [PATCH v.2] 4.15 vmgfx boot warning




This looks okay to me.


Since this is a core DRM patch I think Sinclair was expecting it to be 
pulled in using the drm-misc tree. Did you get a comment from Daniel on 
this patch?


Thanks,
Thomas

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

[PATCH 0/4] drm/msm/dsi: Add DSI 10nm PLL/PHY drivers

[Archit Taneja]

Add the 10nm DSI PHY/PLL drivers. This will be used on the SDM845 SoC.
Most of the code is based on the corresponding downstream PLL [1] and
PHY [2] drivers.

The PHY driver has a few TODOs which would be resolved in future
patches.

[1] 
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/clk/qcom/mdss/mdss-dsi-pll-10nm.c?h=msm-4.9
[2] 
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v3_0.c?h=msm-4.9

Archit Taneja (4):
  drm/msm/dsi: Update generated headers for 10nm PLL/PHY
  drm/msm/dsi: Add skeleton 10nm PHY/PLL code
  drm/msm/dsi: Populate PLL 10nm clock ops
  drm/msm/dsi: Populate the 10nm PHY funcs

 drivers/gpu/drm/msm/Kconfig|   7 +
 drivers/gpu/drm/msm/Makefile   |   2 +
 drivers/gpu/drm/msm/dsi/dsi.h  |   1 +
 drivers/gpu/drm/msm/dsi/dsi.xml.h  | 187 ++-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  |   4 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 251 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c  |   3 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h  |   9 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 822 +
 10 files changed, 1274 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
 create mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c

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

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

[PATCH 3/4] drm/msm/dsi: Populate PLL 10nm clock ops

[Archit Taneja]

Populate PLL clock ops from downstream. This contains the VCO PLL
ops and the registration of standard clk_divider and clk_mux clocks.
Unlike 14nm PLL, the postdividers/mux of the slave PLL doesn't need
to be set to the same values of the postdivs/mux of the master PLL.
Hence, we don't need special postdivider clock ops like we did with
the 14nm PLL driver.

Like the previous PLL drivers, the implementation is slightly different
from downstream. We don't use shadow clocks, but have the ability to
reparent the RCGs to a different source.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 662 -
 1 file changed, 654 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 34c24442d34b..c4c37a7df637 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -10,6 +10,78 @@
 #include "dsi_pll.h"
 #include "dsi.xml.h"
 
+/*
+ * DSI PLL 10nm - clock diagram (eg: DSI0):
+ *
+ *   dsi0_pll_out_div_clk  dsi0_pll_bit_clk
+ *  ||
+ *  ||
+ * +-+  |  +--+  |  ++
+ *  dsi0vco_clk ---| out_div |--o--| divl_3_0 |--o--| /8 |-- dsi0pllbyte
+ * +-+  |  +--+  |  ++
+ *  ||
+ *  || 
dsi0_pll_by_2_bit_clk
+ *  ||  |
+ *  ||  ++  |  |\  
dsi0_pclk_mux
+ *  ||--| /2 |--o--| \   |
+ *  ||  ++ |  \  |  
+-+
+ *  |--|  |--o--| 
div_7_4 |-- dsi0pll
+ *  |--|  / 
+-+
+ *  |  +-+ | /
+ *  ---| /4? |--o--|/
+ * +-+  |   |
+ *  |   |dsiclk_sel
+ *  |
+ *  dsi0_pll_post_out_div_clk
+ */
+
+#define DSI_BYTE_PLL_CLK   0
+#define DSI_PIXEL_PLL_CLK  1
+#define NUM_PROVIDED_CLKS  2
+
+struct dsi_pll_regs {
+   u32 pll_prop_gain_rate;
+   u32 pll_lockdet_rate;
+   u32 decimal_div_start;
+   u32 frac_div_start_low;
+   u32 frac_div_start_mid;
+   u32 frac_div_start_high;
+   u32 pll_clock_inverters;
+   u32 ssc_stepsize_low;
+   u32 ssc_stepsize_high;
+   u32 ssc_div_per_low;
+   u32 ssc_div_per_high;
+   u32 ssc_adjper_low;
+   u32 ssc_adjper_high;
+   u32 ssc_control;
+};
+
+struct dsi_pll_config {
+   u32 ref_freq;
+   bool div_override;
+   u32 output_div;
+   bool ignore_frac;
+   bool disable_prescaler;
+   bool enable_ssc;
+   bool ssc_center;
+   u32 dec_bits;
+   u32 frac_bits;
+   u32 lock_timer;
+   u32 ssc_freq;
+   u32 ssc_offset;
+   u32 ssc_adj_per;
+   u32 thresh_cycles;
+   u32 refclk_cycles;
+};
+
+struct pll_10nm_cached_state {
+   unsigned long vco_rate;
+   u8 bit_clk_div;
+   u8 pix_clk_div;
+   u8 pll_out_div;
+   u8 pll_mux;
+};
+
 struct dsi_pll_10nm {
struct msm_dsi_pll base;
 
@@ -19,7 +91,24 @@ struct dsi_pll_10nm {
void __iomem *phy_cmn_mmio;
void __iomem *mmio;
 
+   u64 vco_ref_clk_rate;
+   u64 vco_current_rate;
+
+   /* protects REG_DSI_10nm_PHY_CMN_CLK_CFG0 register */
+   spinlock_t postdiv_lock;
+
int vco_delay;
+   struct dsi_pll_config pll_configuration;
+   struct dsi_pll_regs reg_setup;
+
+   /* private clocks: */
+   struct clk_hw *hws[NUM_DSI_CLOCKS_MAX];
+   u32 num_hws;
+
+   /* clock-provider: */
+   struct clk_hw_onecell_data *hw_data;
+
+   struct pll_10nm_cached_state cached_state;
 
enum msm_dsi_phy_usecase uc;
struct dsi_pll_10nm *slave;
@@ -33,6 +122,190 @@ struct dsi_pll_10nm {
  */
 static struct dsi_pll_10nm *pll_10nm_list[DSI_MAX];
 
+static void dsi_pll_setup_config(struct dsi_pll_10nm *pll)
+{
+   struct dsi_pll_config *config = >pll_configuration;
+
+   config->ref_freq = pll->vco_ref_clk_rate;
+   config->output_div = 1;
+   config->dec_bits = 8;
+   config->frac_bits = 18;
+   config->lock_timer = 64;
+   config->ssc_freq = 31500;
+   config->ssc_offset = 5000;
+   config->ssc_adj_per = 2;
+   config->thresh_cycles = 32;
+   config->refclk_cycles = 256;
+
+   config->div_override = false;
+   

[PATCH 4/4] drm/msm/dsi: Populate the 10nm PHY funcs

[Archit Taneja]

Populate the PHY ops with the downstream driver as reference.

There are a couple of TODOs which need to be resolved:
- The PHY timings are all hardcoded for now. This needs to be replaced
  with automatic calculations once we get/understand them.
- There are some lane configuration registers which use a new
  representation between physical and logical lane mappings. For now,
  we've hardcoced them to follow the default mapping (i.e
  logical 0 -> phy 0, logical 1 -> phy 1 etc).

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 199 +
 1 file changed, 199 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index b7545fb63bf5..0af951aaeea1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -8,9 +8,208 @@
 #include "dsi_phy.h"
 #include "dsi.xml.h"
 
+static int dsi_phy_hw_v3_0_is_pll_on(struct msm_dsi_phy *phy)
+{
+   void __iomem *base = phy->base;
+   u32 data = 0;
+
+   data = dsi_phy_read(base + REG_DSI_10nm_PHY_CMN_PLL_CNTRL);
+   mb(); /* make sure read happened */
+
+   return (data & BIT(0));
+}
+
+static void dsi_phy_hw_v3_0_config_lpcdrx(struct msm_dsi_phy *phy, bool enable)
+{
+   void __iomem *lane_base = phy->lane_base;
+   int phy_lane_0 = 0; /* TODO: Support all lane swap configs */
+
+   /*
+* LPRX and CDRX need to enabled only for physical data lane
+* corresponding to the logical data lane 0
+*/
+   if (enable)
+   dsi_phy_write(lane_base +
+ REG_DSI_10nm_PHY_LN_LPRX_CTRL(phy_lane_0), 0x3);
+   else
+   dsi_phy_write(lane_base +
+ REG_DSI_10nm_PHY_LN_LPRX_CTRL(phy_lane_0), 0);
+}
+
+static void dsi_phy_hw_v3_0_lane_settings(struct msm_dsi_phy *phy)
+{
+   int i;
+   u8 tx_dctrl[] = { 0x00, 0x00, 0x00, 0x04, 0x01 };
+   void __iomem *lane_base = phy->lane_base;
+
+   /* Strength ctrl settings */
+   for (i = 0; i < 5; i++) {
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_LPTX_STR_CTRL(i),
+ 0x55);
+   /*
+* Disable LPRX and CDRX for all lanes. And later on, it will
+* be only enabled for the physical data lane corresponding
+* to the logical data lane 0
+*/
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_LPRX_CTRL(i), 0);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_PIN_SWAP(i), 0x0);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_HSTX_STR_CTRL(i),
+ 0x88);
+   }
+
+   dsi_phy_hw_v3_0_config_lpcdrx(phy, true);
+
+   /* other settings */
+   for (i = 0; i < 5; i++) {
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG0(i), 0x0);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG1(i), 0x0);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG2(i), 0x0);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG3(i),
+ i == 4 ? 0x80 : 0x0);
+   dsi_phy_write(lane_base +
+ REG_DSI_10nm_PHY_LN_OFFSET_TOP_CTRL(i), 0x0);
+   dsi_phy_write(lane_base +
+ REG_DSI_10nm_PHY_LN_OFFSET_BOT_CTRL(i), 0x0);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(i),
+ tx_dctrl[i]);
+   }
+
+   /* Toggle BIT 0 to release freeze I/0 */
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 0x05);
+   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 0x04);
+}
+
+static int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing *timing,
+  struct msm_dsi_phy_clk_request *clk_req)
+{
+   /*
+* TODO: These params need to be computed, they're currently hardcoded
+* for a 1440x2560@60Hz panel with a byteclk of 100.618 Mhz, and a
+* default escape clock of 19.2 Mhz.
+*/
+
+   timing->hs_halfbyte_en = 0;
+   timing->clk_zero = 0x1c;
+   timing->clk_prepare = 0x07;
+   timing->clk_trail = 0x07;
+   timing->hs_exit = 0x23;
+   timing->hs_zero = 0x21;
+   timing->hs_prepare = 0x07;
+   timing->hs_trail = 0x07;
+   timing->hs_rqst = 0x05;
+   timing->ta_sure = 0x00;
+   timing->ta_go = 0x03;
+   timing->ta_get = 0x04;
+
+   timing->shared_timings.clk_pre = 0x2d;
+   timing->shared_timings.clk_post = 0x0d;
+
+   return 0;
+}
+
 static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy, int src_pll_id,
   struct msm_dsi_phy_clk_request *clk_req)
 {
+   int ret;
+   u32 status;
+   u32 const delay_us = 5;
+   u32 const timeout_us = 1000;
+   struct 

[PATCH 2/4] drm/msm/dsi: Add skeleton 10nm PHY/PLL code

[Archit Taneja]

Add new 10nm DSI PLL/PHY files that will be used on SDM845.

Just populate empty pll/phy funcs for now. These will be filled up
later.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/Kconfig|   7 ++
 drivers/gpu/drm/msm/Makefile   |   2 +
 drivers/gpu/drm/msm/dsi/dsi.h  |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  |   4 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  52 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c  |   3 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h  |   9 ++
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 176 +
 9 files changed, 255 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
 create mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 99d39b2aefa6..9ebaa7391113 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -81,3 +81,10 @@ config DRM_MSM_DSI_14NM_PHY
default y
help
  Choose this option if DSI PHY on 8996 is used on the platform.
+
+config DRM_MSM_DSI_10NM_PHY
+   bool "Enable DSI 10nm PHY driver in MSM DRM (used by SDM845)"
+   depends on DRM_MSM_DSI
+   default y
+   help
+ Choose this option if DSI PHY on SDM845 is used on the platform.
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 92b3844202d2..14edd244df87 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -81,12 +81,14 @@ msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/phy/dsi_phy_28nm.o
 msm-$(CONFIG_DRM_MSM_DSI_20NM_PHY) += dsi/phy/dsi_phy_20nm.o
 msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += dsi/phy/dsi_phy_28nm_8960.o
 msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/phy/dsi_phy_14nm.o
+msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/phy/dsi_phy_10nm.o
 
 ifeq ($(CONFIG_DRM_MSM_DSI_PLL),y)
 msm-y += dsi/pll/dsi_pll.o
 msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/pll/dsi_pll_28nm.o
 msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += dsi/pll/dsi_pll_28nm_8960.o
 msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/pll/dsi_pll_14nm.o
+msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
 endif
 
 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index eafd714a5b84..024e7a3af9f1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -36,6 +36,7 @@ enum msm_dsi_phy_type {
MSM_DSI_PHY_20NM,
MSM_DSI_PHY_28NM_8960,
MSM_DSI_PHY_14NM,
+   MSM_DSI_PHY_10NM,
MSM_DSI_PHY_MAX
 };
 
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 790ca280cbfd..f8056d1df9a0 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -394,6 +394,10 @@ static const struct of_device_id dsi_phy_dt_match[] = {
 #ifdef CONFIG_DRM_MSM_DSI_14NM_PHY
{ .compatible = "qcom,dsi-phy-14nm",
  .data = _phy_14nm_cfgs },
+#endif
+#ifdef CONFIG_DRM_MSM_DSI_10NM_PHY
+   { .compatible = "qcom,dsi-phy-10nm",
+ .data = _phy_10nm_cfgs },
 #endif
{}
 };
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 1733f6608a09..c56268cbdb3d 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -48,6 +48,7 @@ extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs;
 
 struct msm_dsi_dphy_timing {
u32 clk_pre;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
new file mode 100644
index ..b7545fb63bf5
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -0,0 +1,52 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ * Copyright (c) 2018, The Linux Foundation
+ */
+
+#include 
+
+#include "dsi_phy.h"
+#include "dsi.xml.h"
+
+static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy, int src_pll_id,
+  struct msm_dsi_phy_clk_request *clk_req)
+{
+   return 0;
+}
+
+static void dsi_10nm_phy_disable(struct msm_dsi_phy *phy)
+{
+}
+
+static int dsi_10nm_phy_init(struct msm_dsi_phy *phy)
+{
+   struct platform_device *pdev = phy->pdev;
+
+   phy->lane_base = msm_ioremap(pdev, "dsi_phy_lane",
+"DSI_PHY_LANE");
+   if (IS_ERR(phy->lane_base)) {
+   dev_err(>dev, "%s: failed to map phy lane base\n",
+   __func__);
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs = {
+   .type = MSM_DSI_PHY_10NM,
+   .src_pll_truthtable = 

[PATCH 1/4] drm/msm/dsi: Update generated headers for 10nm PLL/PHY

[Archit Taneja]

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 187 +++---
 1 file changed, 174 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 479086ccf180..f6a9471b70c8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -8,19 +8,10 @@ This file was generated by the rules-ng-ng headergen tool in 
this git repository
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1572 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2849 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
37411 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
33004 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
602 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2017-05-17 13:21:27)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
41799 bytes, from 2017-06-16 12:32:42)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (  
10416 bytes, from 2017-05-17 13:21:27)
-
-Copyright (C) 2013-2017 by the following authors:
+- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/dsi/dsi.xml(  
37239 bytes, from 2018-01-12 09:09:22)
+- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml (  
 1572 bytes, from 2016-05-09 06:32:54)
+
+Copyright (C) 2013-2018 by the following authors:
 - Rob Clark  (robclark)
 - Ilia Mirkin  (imirkin)
 
@@ -1556,5 +1547,175 @@ static inline uint32_t 
REG_DSI_14nm_PHY_LN_VREG_CNTRL(uint32_t i0) { return 0x00
 
 #define REG_DSI_14nm_PHY_PLL_PLL_BANDGAP   0x0108
 
+#define REG_DSI_10nm_PHY_CMN_REVISION_ID0  0x
+
+#define REG_DSI_10nm_PHY_CMN_REVISION_ID1  0x0004
+
+#define REG_DSI_10nm_PHY_CMN_REVISION_ID2  0x0008
+
+#define REG_DSI_10nm_PHY_CMN_REVISION_ID3  0x000c
+
+#define REG_DSI_10nm_PHY_CMN_CLK_CFG0  0x0010
+
+#define REG_DSI_10nm_PHY_CMN_CLK_CFG1  0x0014
+
+#define REG_DSI_10nm_PHY_CMN_GLBL_CTRL 0x0018
+
+#define REG_DSI_10nm_PHY_CMN_RBUF_CTRL 0x001c
+
+#define REG_DSI_10nm_PHY_CMN_VREG_CTRL 0x0020
+
+#define REG_DSI_10nm_PHY_CMN_CTRL_00x0024
+
+#define REG_DSI_10nm_PHY_CMN_CTRL_10x0028
+
+#define REG_DSI_10nm_PHY_CMN_CTRL_20x002c
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CFG0 0x0030
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CFG1 0x0034
+
+#define REG_DSI_10nm_PHY_CMN_PLL_CNTRL 0x0038
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CTRL0
0x0098
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CTRL1
0x009c
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CTRL2
0x00a0
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CTRL3
0x00a4
+
+#define REG_DSI_10nm_PHY_CMN_LANE_CTRL4
0x00a8
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_0 0x00ac
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_1 0x00b0
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_2 0x00b4
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_3 0x00b8
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_4 0x00bc
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_5 0x00c0
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_6 0x00c4
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_7 0x00c8
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_8 0x00cc
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_9 0x00d0
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_100x00d4
+
+#define REG_DSI_10nm_PHY_CMN_TIMING_CTRL_11  

[PATCH] rnndb: dsi: Add DSI 10nm PLL/PHY registers

[Archit Taneja]

Signed-off-by: Archit Taneja 
---
 rnndb/dsi/dsi.xml | 95 +++
 1 file changed, 95 insertions(+)

diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml
index c7052378..fdcc2d3e 100644
--- a/rnndb/dsi/dsi.xml
+++ b/rnndb/dsi/dsi.xml
@@ -814,4 +814,99 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

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

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

[PATCH] drm/ttm: add updated_glob_count in dma_page

[Roger He]

add this for correctly updating global mem count in ttm_mem_zone.
before that when ttm_mem_global_alloc_page fails, we would update all
dma_page's global mem count in ttm_dma->pages_list. but actually here
we should not update for the last dma_page.

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 57 +---
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..3e78ea4 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -121,6 +121,8 @@ struct dma_pool {
  * @vaddr: The virtual address of the page and a flag if the page belongs to a
  * huge pool
  * @dma: The bus address of the page. If the page is not allocated
+ * @updated_glob_count: to indicate whether we already updated global
+ * memory count in ttm_mem_zone
  *   via the DMA API, it will be -1.
  */
 struct dma_page {
@@ -128,6 +130,7 @@ struct dma_page {
unsigned long vaddr;
struct page *p;
dma_addr_t dma;
+   bool updated_glob_count;
 };
 
 /*
@@ -874,18 +877,18 @@ static int ttm_dma_page_pool_fill_locked(struct dma_pool 
*pool,
 }
 
 /*
- * @return count of pages still required to fulfill the request.
  * The populate list is actually a stack (not that is matters as TTM
  * allocates one page at a time.
+ * return dma_page pointer if success, otherwise NULL.
  */
-static int ttm_dma_pool_get_pages(struct dma_pool *pool,
+static struct dma_page *ttm_dma_pool_get_pages(struct dma_pool *pool,
  struct ttm_dma_tt *ttm_dma,
  unsigned index)
 {
-   struct dma_page *d_page;
+   struct dma_page *d_page = NULL;
struct ttm_tt *ttm = _dma->ttm;
unsigned long irq_flags;
-   int count, r = -ENOMEM;
+   int count;
 
spin_lock_irqsave(>lock, irq_flags);
count = ttm_dma_page_pool_fill_locked(pool, _flags);
@@ -894,12 +897,11 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
ttm->pages[index] = d_page->p;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(_page->page_list, _dma->pages_list);
-   r = 0;
pool->npages_in_use += 1;
pool->npages_free -= 1;
}
spin_unlock_irqrestore(>lock, irq_flags);
-   return r;
+   return d_page;
 }
 
 static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool huge)
@@ -934,6 +936,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
+   struct dma_page *d_page;
enum pool_type type;
unsigned i;
int ret;
@@ -962,8 +965,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
while (num_pages >= HPAGE_PMD_NR) {
unsigned j;
 
-   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
-   if (ret != 0)
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page)
break;
 
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
@@ -973,6 +976,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
 
+   d_page->updated_glob_count = true;
for (j = i + 1; j < (i + HPAGE_PMD_NR); ++j) {
ttm->pages[j] = ttm->pages[j - 1] + 1;
ttm_dma->dma_address[j] = ttm_dma->dma_address[j - 1] +
@@ -996,8 +1000,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
}
 
while (num_pages) {
-   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
-   if (ret != 0) {
+   d_page = ttm_dma_pool_get_pages(pool, ttm_dma, i);
+   if (!d_page) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
}
@@ -1009,6 +1013,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
return -ENOMEM;
}
 
+   d_page->updated_glob_count = true;
++i;
--num_pages;
}
@@ -1049,8 +1054,11 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
continue;
 
count++;
-   ttm_mem_global_free_page(ttm->glob->mem_glob,
-d_page->p, pool->size);
+   if (d_page->updated_glob_count) {
+   ttm_mem_global_free_page(ttm->glob->mem_glob,
+ 

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #9 from Fredrik Höglund  ---
The broken window preview is actually a bug in plasma.

The thumbnail code doesn't look at the sizes of the color channels; it only
checks that the GLX_BUFFER_SIZE matches the depth of the window.

-- 
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: [PATCHv<8> 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

[kbuild test robot]

Hi Ong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15-rc8 next-20180116]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hean-Loong-Ong/Intel-FPGA-Video-and-Image-Processing-Suite/20180117-103626
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/cdev.h:8:0,
from include/drm/drmP.h:36,
from drivers/gpu/drm/ivip/intel_vip_core.c:24:
   drivers/gpu/drm/ivip/intel_vip_core.c: In function 'intelvipfb_enable':
>> drivers/gpu/drm/ivip/intel_vip_core.c:57:33: warning: format '%x' expects 
>> argument of type 'unsigned int', but argument 3 has type 'dma_addr_t {aka 
>> long long unsigned int}' [-Wformat=]
 dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
^
   include/linux/device.h:1355:51: note: in definition of macro 'dev_info'
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
  ^~~
   drivers/gpu/drm/ivip/intel_vip_core.c: At top level:
>> drivers/gpu/drm/ivip/intel_vip_core.c:76:15: error: 'drm_fb_cma_create' 
>> undeclared here (not in a function); did you mean 'drm_gem_cma_create'?
 .fb_create = drm_fb_cma_create,
  ^
  drm_gem_cma_create
   drivers/gpu/drm/ivip/intel_vip_core.c: In function 
'intelvipfb_pipe_prepare_fb':
>> drivers/gpu/drm/ivip/intel_vip_core.c:90:9: error: implicit declaration of 
>> function 'drm_fb_cma_prepare_fb'; did you mean 'drm_fb_cma_get_gem_obj'? 
>> [-Werror=implicit-function-declaration]
 return drm_fb_cma_prepare_fb(>plane, plane_state);
^
drm_fb_cma_get_gem_obj
   cc1: some warnings being treated as errors

vim +76 drivers/gpu/drm/ivip/intel_vip_core.c

  > 24  #include 
25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  
34  #include 
35  #include 
36  #include 
37  
38  #include "intel_vip_drv.h"
39  
40  static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
41 struct drm_crtc_state *crtc_state)
42  {
43  /*
44   * The frameinfo variable has to correspond to the size of the 
VIP Suite
45   * Frame Reader register 7 which will determine the maximum 
size used
46   * in this frameinfo
47   */
48  
49  u32 frameinfo;
50  struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
51  void __iomem *base = priv->base;
52  struct drm_plane_state *state = pipe->plane.state;
53  dma_addr_t addr;
54  
55  addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
56  
  > 57  dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
58  
59  frameinfo =
60  readl(base + INTELVIPFB_FRAME_READER) & 0x00ff;
61  writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
62  writel(addr, base + INTELVIPFB_FRAME_START);
63  /* Finally set the control register to 1 to start streaming */
64  writel(1, base + INTELVIPFB_CONTROL);
65  }
66  
67  static void intelvipfb_disable(struct drm_simple_display_pipe *pipe)
68  {
69  struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
70  void __iomem *base = priv->base;
71  /* set the control register to 0 to stop streaming */
72  writel(0, base + INTELVIPFB_CONTROL);
73  }
74  
75  static const struct drm_mode_config_funcs intelvipfb_mode_config_funcs 
= {
  > 76  .fb_create = drm_fb_cma_create,
77  .atomic_check = drm_atomic_helper_check,
78  .atomic_commit = drm_atomic_helper_commit,
79  };
80  
81  static void intelvipfb_setup_mode_config(struct drm_device *drm)
82  {
83  drm_mode_config_init(drm);
84  drm->mode_config.funcs = _mode_config_funcs;
85  }
86  
87  static int intelvipfb_pipe_prepare_fb(struct drm_simple_display_pipe 
*pipe,
88  struct drm_plane_state 
*plane_s

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #8 from Mario Kleiner  ---
compton didn't cause problems for me under default 24 bit color-depth on
X-Server 1.19.3.

But Christoph's setup is running the new server 1.19.6, and the glxinfo shows
various new 32 bit visuals, not only rgba 8 8 8 8 but also rgba 10 10 10 2.

1.19.6 contains the patch "glx: Duplicate relevant fbconfigs for compositing
visuals" backported from master, adding lots new 32 bpp compositing visuals, so
that might trigger the 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] drm: Make PANEL_ORIENTATION_QUIRKS depend on DRM

[kbuild test robot]

Hi Chris,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180116]
[cannot apply to v4.15-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-Make-PANEL_ORIENTATION_QUIRKS-depend-on-DRM/20180117-091428
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-kexec (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

warning: (FB_EFI) selects DRM_PANEL_ORIENTATION_QUIRKS which has unmet direct 
dependencies (HAS_IOMEM && DRM)

---
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

[Bug 104540] Corrupted colors in OBS-Studio window capture

[bugzilla-daemon]

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

--- Comment #2 from Mario Kleiner  ---
Just to add a bit to this: Testing this also on Kubuntu 16.04.3 LTS in X
default color depth 24 bit and running apitrace on obs showed nothing
suspicious to me wrt. selection of fbconfigs and visuals, creation of
framebuffers etc. Just regular 8 bpc fbconfigs. The color corruption did happen
with the x-composite input plugin, but not with the xshm input plugin.

So the corruption seems to stem from the x-composite based grabbing/input side,
not from the output/rendering/display side.

-- 
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

[radeon-alex:amd-staging-drm-next 1493/1561] sound/soc/amd/raven/acp3x-pcm-dma.c:246:10: error: implicit declaration of function 'page_to_phys'; did you mean 'page_to_pfn'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   39bfc5b3764e987ae64388e7169bc63589c93a79
commit: 4ab7d004f9ff2e877caa267887360e1804b4edcf [1493/1561] ASoC: AMD: enable 
ACP3x drivers build
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4ab7d004f9ff2e877caa267887360e1804b4edcf
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
   sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 
'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
   sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'config_acp3x_dma':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:246:10: error: implicit declaration of 
>> function 'page_to_phys'; did you mean 'page_to_pfn'? 
>> [-Werror=implicit-function-declaration]
  addr = page_to_phys(pg);
 ^~~~
 page_to_pfn
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
function 'devm_ioremap'; did you mean 'devm_kmemdup'? 
[-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
 ^~~~
 devm_kmemdup
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +246 sound/soc/amd/raven/acp3x-pcm-dma.c

090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  222  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  223  static void 
config_acp3x_dma(struct i2s_stream_instance *rtd, int direction)
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  224  {
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  225   u16 page_idx;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  226   u64 addr;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  227   u32 low, high, val, 
acp_fifo_addr;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  228   struct page *pg = 
rtd->pg;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  229  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  230   /* 8 scratch registers 
used to map one 64 bit address.
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  231* For 2 pages (4096 * 
2 bytes), it will be 16 registers.
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  232*/
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  233   if (direction == 
SNDRV_PCM_STREAM_PLAYBACK)
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  234   val = 0;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  235   else
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  236   val = 16;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  237  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  238   /* Group Enable */
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  239   
rv_writel(ACP_SRAM_PTE_OFFSET | BIT(31), rtd->acp3x_base +
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  240   
mmACPAXI2AXI_ATU_BASE_ADDR_GRP_1);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  241   
rv_writel(PAGE_SIZE_4K_ENABLE, rtd->acp3x_base +
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  242   
mmACPAXI2AXI_ATU_PAGE_SIZE_GRP_1);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  243  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  244   for (page_idx = 0; 
page_idx < rtd->num_pages; page_idx++) {
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  245   /* Load the low 
address of page int ACP SRAM through SRBM */
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29 @246   addr = 
page_to_phys(pg);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  247   low = 
lower_32_bits(addr);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  248   high = 
upper_32_bits(addr);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  249  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  250   rv_writel(low, 
rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  251   high |= BIT(31);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  

RE: [PATCH v2 1/2] drm/ttm: Allow page allocations w/o triggering OOM..

[He, Roger]

Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Andrey Grodzovsky
Sent: Tuesday, January 16, 2018 11:18 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig, 
Christian 
Cc: He, Roger 
Subject: [PATCH v2 1/2] drm/ttm: Allow page allocations w/o triggering OOM..

This to allow drivers to choose to avoid OOM invocation and handle page 
allocation failures instead.

v2:
Remove extra new lines.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/ttm/ttm_bo.c |  3 +++
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 ++
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +++
 drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--
 include/drm/ttm/ttm_bo_driver.h  |  4 
 5 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
2eb71ff..f32aab1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -234,6 +234,9 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
 
+   if (bdev->no_retry)
+   page_flags |= TTM_PAGE_FLAG_NO_RETRY;
+
switch (bo->type) {
case ttm_bo_type_device:
if (zero_alloc)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0eab24e..f34c843 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -741,6 +741,9 @@ static int ttm_page_pool_get_pages(struct ttm_page_pool 
*pool,
if (ttm_flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
 
+   if (ttm_flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
/* ttm_alloc_new_pages doesn't reference pool so we can run
 * multiple requests in parallel.
 **/
@@ -893,6 +896,9 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
if (flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
 
+   if (flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
if (flags & TTM_PAGE_FLAG_DMA32)
gfp_flags |= GFP_DMA32;
else
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..6949ef7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -920,6 +920,9 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt 
*ttm_dma, bool huge)
gfp_flags &= ~__GFP_COMP;
}
 
+   if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
return gfp_flags;
 }
 
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 
5a046a3..9e4d43d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -301,7 +301,11 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
swap_space = swap_storage->f_mapping;
 
for (i = 0; i < ttm->num_pages; ++i) {
-   from_page = shmem_read_mapping_page(swap_space, i);
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+   from_page = shmem_read_mapping_page_gfp(swap_space, i, 
gfp_mask);
+
if (IS_ERR(from_page)) {
ret = PTR_ERR(from_page);
goto out_err;
@@ -350,10 +354,15 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
swap_space = swap_storage->f_mapping;
 
for (i = 0; i < ttm->num_pages; ++i) {
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
+__GFP_RETRY_MAYFAIL : 0);
+
from_page = ttm->pages[i];
if (unlikely(from_page == NULL))
continue;
-   to_page = shmem_read_mapping_page(swap_space, i);
+
+   to_page = shmem_read_mapping_page_gfp(swap_space, i, gfp_mask);
if (IS_ERR(to_page)) {
ret = PTR_ERR(to_page);
goto out_err;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h 
index 94064b1..9b417eb 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -86,6 +86,7 @@ struct ttm_backend_func {
 #define TTM_PAGE_FLAG_ZERO_ALLOC  (1 << 6)
 #define TTM_PAGE_FLAG_DMA32   (1 << 7)
 #define TTM_PAGE_FLAG_SG   

[radeon-alex:amd-staging-drm-next 1493/1561] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   39bfc5b3764e987ae64388e7169bc63589c93a79
commit: 4ab7d004f9ff2e877caa267887360e1804b4edcf [1493/1561] ASoC: AMD: enable 
ACP3x drivers build
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4ab7d004f9ff2e877caa267887360e1804b4edcf
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   sound/soc/amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
>> sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of 
>> function 'pci_enable_msi' [-Werror=implicit-function-declaration]
 ret = pci_enable_msi(pci);
   ^~
>> sound/soc/amd/raven/pci-acp3x.c:122:2: error: implicit declaration of 
>> function 'pci_disable_msi' [-Werror=implicit-function-declaration]
 pci_disable_msi(pci);
 ^~~
   sound/soc/amd/raven/pci-acp3x.c: At top level:
   sound/soc/amd/raven/pci-acp3x.c:159:1: warning: data definition has no type 
or storage class
module_pci_driver(acp3x_driver);
^
   sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in 
declaration of 'module_pci_driver' [-Werror=implicit-int]
   sound/soc/amd/raven/pci-acp3x.c:159:1: warning: parameter names (without 
types) in function declaration
   sound/soc/amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but 
not used [-Wunused-variable]
static struct pci_driver acp3x_driver  = {
 ^~~~
   cc1: some warnings being treated as errors

vim +/pci_enable_msi +58 sound/soc/amd/raven/pci-acp3x.c

565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   29  
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   30  static int 
snd_acp3x_probe(struct pci_dev *pci,
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   31  
   const struct pci_device_id *pci_id)
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   32  {
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   33  int ret;
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   34  u32 addr, val;
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   35  struct 
acp3x_dev_data *adata;
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   36  struct 
platform_device_info pdevinfo;
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   37  unsigned int 
irqflags;
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   38  
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   39  if 
(pci_enable_device(pci)) {
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   40  
dev_err(>dev, "pci_enable_device failed\n");
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   41  return 
-ENODEV;
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   42  }
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   43  
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   44  ret = 
pci_request_regions(pci, "AMD ACP3x audio");
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   45  if (ret < 0) {
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   46  
dev_err(>dev, "pci_request_regions failed\n");
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   47  goto 
disable_pci;
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   48  }
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   49  
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   50  adata = 
devm_kzalloc(>dev, sizeof(struct acp3x_dev_data),
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   51  
GFP_KERNEL);
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   52  if (adata == 
NULL) {
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   53  ret = 
-ENOMEM;
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   54  goto 
release_regions;
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   55  }
565217284 Maruthi Srinivas Bayyavarapu 2017-03-27   56  
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   57  /* check for 
msi interrupt support */
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29  @58  ret = 
pci_enable_msi(pci);
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   59  if (ret)
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   60  /* msi 
is not enabled */
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   61  
irqflags = IRQF_SHARED;
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   62  else
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   63  /* msi 
is enabled */
0d43cf402 Maruthi Srinivas Bayyavarapu 2017-03-29   64  

RE: [PATCH 2/2] drm/amdgpu: Use new TTM flag to avoid OOM triggering.

[He, Roger]

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Tuesday, January 16, 2018 8:46 PM
To: Grodzovsky, Andrey ; Koenig, Christian 
; He, Roger ; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amdgpu: Use new TTM flag to avoid OOM triggering.

Am 16.01.2018 um 13:43 schrieb Andrey Grodzovsky:
>
>
> On 01/16/2018 03:54 AM, Christian König wrote:
>> Am 16.01.2018 um 07:18 schrieb He, Roger:
>>> -Original Message-
>>> From: Andrey Grodzovsky [mailto:andrey.grodzov...@amd.com]
>>> Sent: Saturday, January 13, 2018 6:29 AM
>>> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
>>> Cc: Koenig, Christian ; He, Roger 
>>> ; Grodzovsky, Andrey 
>>> Subject: [PATCH 2/2] drm/amdgpu: Use new TTM flag to avoid OOM 
>>> triggering.
>>>
>>> This to have a load time option to avoid OOM on RAM allocations.
>>>
>>> Signed-off-by: Andrey Grodzovsky 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h    | 1 +
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c    | 4 
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 
>>>   3 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index b7c181e..1387239 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -127,6 +127,7 @@ extern int amdgpu_job_hang_limit;  extern int 
>>> amdgpu_lbpw;  extern int amdgpu_compute_multipipe;  extern int 
>>> amdgpu_gpu_recovery;
>>> +extern int amdgpu_alloc_no_oom;
>>>     #ifdef CONFIG_DRM_AMDGPU_SI
>>>   extern int amdgpu_si_support;
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> index d96f9ac..6e98189 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> @@ -130,6 +130,7 @@ int amdgpu_job_hang_limit = 0;  int amdgpu_lbpw 
>>> = -1;  int amdgpu_compute_multipipe = -1;  int amdgpu_gpu_recovery = 
>>> -1; /* auto */
>>> +int amdgpu_alloc_no_oom = -1; /* auto */
>>>
>>> How about turn it on as default?
>>
>> I think we can even go a step further, drop the module parameter and 
>> just turn it always on for amdgpu.
>>
>> Christian.
>
> Will fix, just a reminder that Roger's patches - [PATCH 1/2] drm/ttm: 
> don't update global memory count for some special cases [PATCH 2/2] 
> drm/ttm: only free pages rather than update global memory count 
> together
>
> Needs to be merged before my patches since the fix a TTM bug on 
> allocation failure.

The second is merged, but I had some comments on the first and Roger 
hasn't replied yet.

Roger what's the status on that one?

Already fixed locally, but not tested yet.  Try to send out today.

Thanks
Roger(Hongbo.He)

>
> Thanks,
> Andrey
>
>>
>>>
>>> Thanks
>>> Roger(Hongbo.He)
>>>
>>> MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in 
>>> megabytes");  module_param_named(vramlimit, amdgpu_vram_limit, int, 
>>> 0600); @@ -285,6 +286,9 @@ module_param_named(compute_multipipe,
>>> amdgpu_compute_multipipe, int, 0444); MODULE_PARM_DESC(gpu_recovery, 
>>> "Enable GPU recovery mechanism, (1 = enable, 0 = disable, -1 = 
>>> auto"); module_param_named(gpu_recovery, amdgpu_gpu_recovery, int, 
>>> 0444);
>>>   +MODULE_PARM_DESC(alloc_no_oom, "Allocate RAM without triggering 
>>> OOM
>>> +killer, (1 = enable, 0 = disable, -1 = auto"); 
>>> +module_param_named(alloc_no_oom, amdgpu_alloc_no_oom, int, 0444);
>>> +
>>>   #ifdef CONFIG_DRM_AMDGPU_SI
>>>     #if defined(CONFIG_DRM_RADEON) ||
>>> defined(CONFIG_DRM_RADEON_MODULE) diff --git 
>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> index 5c4c3e0..fc27164 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> @@ -420,6 +420,10 @@ static int amdgpu_bo_do_create(struct 
>>> amdgpu_device *adev,  #endif
>>>     bo->tbo.bdev = >mman.bdev;
>>> +
>>> +    if (amdgpu_alloc_no_oom == 1)
>>> +    bo->tbo.bdev->no_retry = true;
>>> +
>>>   amdgpu_ttm_placement_from_domain(bo, domain);
>>>     r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, 
>>> type,
>>> --
>>> 2.7.4
>>>
>>> ___
>>> 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

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

[PATCH 4/4] drm/vgem: flush page during page fault

[Gurchetan Singh]

This is required to use buffers allocated by vgem on AMD and ARM devices.
We're experiencing a case where eviction of the cache races with userspace
writes. To fix this, flush the cache after retrieving a page.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 35bfdfb746a7..fb263969f02d 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf)
break;
}
 
+   drm_flush_pages(obj->base.dev->dev, , 1);
}
return ret;
 }
-- 
2.13.5

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

[PATCH 2/4] drm: add additional parameter in drm_flush_pages() and drm_flush_sg()

[Gurchetan Singh]

We've found the DMA API is effective for flushing the cache on ARM
devices, and it requires a struct device *.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/drm_cache.c | 5 +++--
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 drivers/gpu/drm/i915/i915_gem_clflush.c | 2 +-
 drivers/gpu/drm/ttm/ttm_tt.c| 2 +-
 drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
 include/drm/drm_cache.h | 5 +++--
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 89cdd32fe1f3..3d2bb9d71a60 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -78,7 +78,8 @@ static void drm_cache_flush_clflush(struct page *pages[],
  * to a page in the array.
  */
 void
-drm_flush_pages(struct page *pages[], unsigned long num_pages)
+drm_flush_pages(struct device *dev, struct page *pages[],
+   unsigned long num_pages)
 {
 
 #if defined(CONFIG_X86)
@@ -119,7 +120,7 @@ EXPORT_SYMBOL(drm_flush_pages);
  * sg.
  */
 void
-drm_flush_sg(struct sg_table *st)
+drm_flush_sg(struct device *dev, struct sg_table *st)
 {
 #if defined(CONFIG_X86)
if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe191d0e84e1..045866f2b5dd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -259,7 +259,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
if (needs_clflush &&
(obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0 &&
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
-   drm_flush_sg(pages);
+   drm_flush_sg(obj->base.dev->dev, pages);
 
__start_cpu_write(obj);
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index f413c5e5735d..b5938f14141f 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -71,7 +71,7 @@ static const struct dma_fence_ops i915_clflush_ops = {
 static void __i915_do_clflush(struct drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
-   drm_flush_sg(obj->mm.pages);
+   drm_flush_sg(obj->base.dev->dev, obj->mm.pages);
intel_fb_obj_flush(obj, ORIGIN_CPU);
 }
 
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 59e272a58752..fb2382d01bba 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -122,7 +122,7 @@ static int ttm_tt_set_caching(struct ttm_tt *ttm,
}
 
if (ttm->caching_state == tt_cached)
-   drm_flush_pages(ttm->pages, ttm->num_pages);
+   drm_flush_pages(NULL, ttm->pages, ttm->num_pages);
 
for (i = 0; i < ttm->num_pages; ++i) {
cur_page = ttm->pages[i];
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 802a97e1a4bf..35bfdfb746a7 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -325,7 +325,7 @@ static int vgem_prime_pin(struct drm_gem_object *obj)
/* Flush the object from the CPU cache so that importers can rely
 * on coherent indirect access via the exported dma-address.
 */
-   drm_flush_pages(pages, n_pages);
+   drm_flush_pages(obj->dev->dev, pages, n_pages);
 
return 0;
 }
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 25c029470315..cb77315dd8dd 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -35,8 +35,9 @@
 
 #include 
 
-void drm_flush_pages(struct page *pages[], unsigned long num_pages);
-void drm_flush_sg(struct sg_table *st);
+void drm_flush_pages(struct device *dev, struct page *pages[],
+unsigned long num_pages);
+void drm_flush_sg(struct device *dev, struct sg_table *st);
 void drm_clflush_virt_range(void *addr, unsigned long length);
 
 static inline bool drm_arch_can_wc_memory(void)
-- 
2.13.5

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

[PATCH 1/4] drm: rename {drm_clflush_sg, drm_clflush_pages}

[Gurchetan Singh]

Since clfush is an x86-only instruction, these function names won't
make much sense if we start adding cases for other architectures.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/drm_cache.c | 12 ++--
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_clflush.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  2 +-
 drivers/gpu/drm/ttm/ttm_tt.c|  2 +-
 drivers/gpu/drm/vgem/vgem_drv.c |  2 +-
 include/drm/drm_cache.h |  4 ++--
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 3bd76e918b5d..89cdd32fe1f3 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -70,7 +70,7 @@ static void drm_cache_flush_clflush(struct page *pages[],
 #endif
 
 /**
- * drm_clflush_pages - Flush dcache lines of a set of pages.
+ * drm_flush_pages - Flush dcache lines of a set of pages.
  * @pages: List of pages to be flushed.
  * @num_pages: Number of pages in the array.
  *
@@ -78,7 +78,7 @@ static void drm_cache_flush_clflush(struct page *pages[],
  * to a page in the array.
  */
 void
-drm_clflush_pages(struct page *pages[], unsigned long num_pages)
+drm_flush_pages(struct page *pages[], unsigned long num_pages)
 {
 
 #if defined(CONFIG_X86)
@@ -109,17 +109,17 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
WARN_ON_ONCE(1);
 #endif
 }
-EXPORT_SYMBOL(drm_clflush_pages);
+EXPORT_SYMBOL(drm_flush_pages);
 
 /**
- * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
+ * drm_flush_sg - Flush dcache lines pointing to a scather-gather.
  * @st: struct sg_table.
  *
  * Flush every data cache line entry that points to an address in the
  * sg.
  */
 void
-drm_clflush_sg(struct sg_table *st)
+drm_flush_sg(struct sg_table *st)
 {
 #if defined(CONFIG_X86)
if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -140,7 +140,7 @@ drm_clflush_sg(struct sg_table *st)
WARN_ON_ONCE(1);
 #endif
 }
-EXPORT_SYMBOL(drm_clflush_sg);
+EXPORT_SYMBOL(drm_flush_sg);
 
 /**
  * drm_clflush_virt_range - Flush dcache lines of a region
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 61ba321e9970..fe191d0e84e1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -259,7 +259,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
if (needs_clflush &&
(obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0 &&
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
-   drm_clflush_sg(pages);
+   drm_flush_sg(pages);
 
__start_cpu_write(obj);
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index f663cd919795..f413c5e5735d 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -71,7 +71,7 @@ static const struct dma_fence_ops i915_clflush_ops = {
 static void __i915_do_clflush(struct drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
-   drm_clflush_sg(obj->mm.pages);
+   drm_flush_sg(obj->mm.pages);
intel_fb_obj_flush(obj, ORIGIN_CPU);
 }
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1d9655576b6e..8ac7eb25e46d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -100,7 +100,7 @@ static int rockchip_gem_get_pages(struct 
rockchip_gem_object *rk_obj)
 * Fake up the SG table so that dma_sync_sg_for_device() can be used
 * to flush the pages associated with it.
 *
-* TODO: Replace this by drm_clflush_sg() once it can be implemented
+* TODO: Replace this by drm_flush_sg() once it can be implemented
 * without relying on symbols that are not exported.
 */
for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 8ebc8d3560c3..59e272a58752 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -122,7 +122,7 @@ static int ttm_tt_set_caching(struct ttm_tt *ttm,
}
 
if (ttm->caching_state == tt_cached)
-   drm_clflush_pages(ttm->pages, ttm->num_pages);
+   drm_flush_pages(ttm->pages, ttm->num_pages);
 
for (i = 0; i < ttm->num_pages; ++i) {
cur_page = ttm->pages[i];
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 2524ff116f00..802a97e1a4bf 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -325,7 +325,7 @@ static int vgem_prime_pin(struct drm_gem_object *obj)
/* Flush the object from the CPU cache so that importers can rely
 * on coherent indirect access 

[PATCH 3/4] drm: add ARM flush implementations

[Gurchetan Singh]

The DMA API can be used to flush scatter gather tables and physical
pages on ARM devices.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/drm_cache.c | 17 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  7 ++-
 drivers/gpu/drm/tegra/gem.c |  6 +-
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 3d2bb9d71a60..98d6ebb40e96 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -105,6 +105,18 @@ drm_flush_pages(struct device *dev, struct page *pages[],
   (unsigned long)page_virtual + PAGE_SIZE);
kunmap_atomic(page_virtual);
}
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   unsigned long i;
+   dma_addr_t dma_handle;
+
+   if (!dev)
+   return;
+
+   for (i = 0; i < num_pages; i++) {
+   dma_handle = phys_to_dma(drm->dev, page_to_phys(pages[i]));
+   dma_sync_single_for_device(dev, dma_handle, PAGE_SIZE,
+  DMA_TO_DEVICE);
+   }
 #else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
@@ -136,6 +148,11 @@ drm_flush_sg(struct device *dev, struct sg_table *st)
 
if (wbinvd_on_all_cpus())
pr_err("Timed out waiting for cache flush\n");
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   if (!dev)
+   return;
+
+   dma_sync_sg_for_device(dev, st->sgl, st->nents, DMA_TO_DEVICE);
 #else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 8ac7eb25e46d..0157f90b5d10 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -99,15 +100,11 @@ static int rockchip_gem_get_pages(struct 
rockchip_gem_object *rk_obj)
/*
 * Fake up the SG table so that dma_sync_sg_for_device() can be used
 * to flush the pages associated with it.
-*
-* TODO: Replace this by drm_flush_sg() once it can be implemented
-* without relying on symbols that are not exported.
 */
for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
sg_dma_address(s) = sg_phys(s);
 
-   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
-  DMA_TO_DEVICE);
+   drm_flush_sg(drm->dev, rk_obj->sgt);
 
return 0;
 
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index ab1e53d434e8..9945fd2f6bd6 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -230,15 +230,11 @@ static int tegra_bo_get_pages(struct drm_device *drm, 
struct tegra_bo *bo)
/*
 * Fake up the SG table so that dma_sync_sg_for_device() can be used
 * to flush the pages associated with it.
-*
-* TODO: Replace this by drm_clflash_sg() once it can be implemented
-* without relying on symbols that are not exported.
 */
for_each_sg(bo->sgt->sgl, s, bo->sgt->nents, i)
sg_dma_address(s) = sg_phys(s);
 
-   dma_sync_sg_for_device(drm->dev, bo->sgt->sgl, bo->sgt->nents,
-  DMA_TO_DEVICE);
+   drm_flush_sg(drm->dev, bo->sgt);
 
return 0;
 
-- 
2.13.5

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

Re: [PATCH] drm/fb-helper: Fix of-by-one in setcmap_pseudo_palette

[Sean Paul]

On Tue, Jan 16, 2018 at 11:27:28PM +0100, Daniel Vetter wrote:
> On Tue, Jan 16, 2018 at 11:00 PM, Sean Paul  wrote:
> > On Fri, Jan 12, 2018 at 10:08:49PM +0100, Daniel Vetter wrote:
> >> On Fri, Jan 12, 2018 at 3:08 PM, Sean Paul  wrote:
> >> > On Fri, Jan 12, 2018 at 4:48 AM, Daniel Vetter  
> >> > wrote:
> >> >> [Fair warning: This is pure conjecture right now.]
> >> >>
> >> >> In
> >> >>
> >> >> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
> >> >> Author: Peter Rosin 
> >> >> Date:   Tue Jul 4 12:36:57 2017 +0200
> >> >>
> >> >> drm/fb-helper: factor out pseudo-palette
> >> >>
> >> >> Peter extracted the pseudo palette computation, but seems to have done
> >> >> an off-by-one. I spotted that +1, but then noticed that we've passed
> >> >> start++ to (now gone) setcolreg function, so it seemed to all match
> >> >> up. Except post vs. pre-increment ftw.
> >> >>
> >> >> Result is that the palette is off-by-one, and the forground color
> >> >> (slot 0) ends up black, rendering a fairly unreadable console.
> >> >>
> >> >> What baffles me is that on some systems it still seems to work
> >> >> somehow, which lead us all down a wild goose chase trying to add
> >> >> load_lut calls back in in various places (which was also intentionally
> >> >> removed, but really doesn't seem to be the real root cause).
> >> >>
> >> >> Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
> >> >> Cc: Peter Rosin 
> >> >> Cc: Daniel Vetter 
> >> >> Cc: Daniel Vetter 
> >> >> Cc: Gustavo Padovan 
> >> >> Cc: Sean Paul 
> >> >> Cc: David Airlie 
> >> >> Cc: dri-devel@lists.freedesktop.org
> >> >> Cc:  # v4.14+
> >> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
> >> >> Reported-by: Deposite Pirate 
> >> >> Reported-by: Bill Fraser 
> >> >> Cc: Deposite Pirate 
> >> >> Cc: Bill Fraser 
> >> >> Cc: Michel Dänzer 
> >> >> Signed-off-by: Daniel Vetter 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >> >> b/drivers/gpu/drm/drm_fb_helper.c
> >> >> index 035784ddd133..1c3a200c4a10 100644
> >> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> >> @@ -1295,7 +1295,7 @@ static int setcmap_pseudo_palette(struct fb_cmap 
> >> >> *cmap, struct fb_info *info)
> >> >> mask <<= info->var.transp.offset;
> >> >> value |= mask;
> >> >> }
> >> >> -   palette[cmap->start + i] = value;
> >> >> +   palette[cmap->start] = value;
> >> >
> >> > I don't think this is equivalent to what was there before. Before
> >> > there we set palette[cmap->start]->palette[cmap->start + cmap->len -
> >> > 1], now we're only setting palette[cmap->start].
> >> >
> >> > In the previous version (before Peter's change), we wrote
> >> > palette[cmap->start] twice. So while there is an off-by-one bug, I
> >> > don't think this fixes the issue.
> >>
> >> Well this patch is complete nonsense, no idea what I was thinking ...
> >
> > [Sending this out since it's in my tree and I'll forget soon]
> >
> > Equivalent behavior would be:
> 
> Are you sure? 

Definitely not, I was just driving by, enjoying the scenery.

> On 2nd look I think there isn't actually any off-by-one

Yeah, I have convinced myself of the same thing. So I'll just file this under
¯\_(ツ)_/¯.

Sean

> going on in the referenced patch. The only thing I can see is that the
> old code filled out the first entries of an oversized table (more than
> 16 entries), and only returned -EINVAL when getting to entry 17. The
> new one doesn't do that. But more testing in the bug report hints at
> this not being the real bug (and I didn't find any callers in the
> fbcon code that would indicate there is such a bug).
> -Daniel
> 
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 035784ddd133..df6709768723 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1295,7 +1295,8 @@ static int setcmap_pseudo_palette(struct fb_cmap 
> > *cmap, struct fb_info *info)
> > mask <<= info->var.transp.offset;
> > value |= mask;
> > }
> > -   palette[cmap->start + i] = value;
> > +   if (i > 0)
> > +   palette[cmap->start + i - 1] = value;
> > }
> >
> > return 0;
> >
> >
> >> -Daniel
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> +41 (0) 

Re: [PATCH] drm/fb-helper: Fix of-by-one in setcmap_pseudo_palette

[Daniel Vetter]

On Tue, Jan 16, 2018 at 11:00 PM, Sean Paul  wrote:
> On Fri, Jan 12, 2018 at 10:08:49PM +0100, Daniel Vetter wrote:
>> On Fri, Jan 12, 2018 at 3:08 PM, Sean Paul  wrote:
>> > On Fri, Jan 12, 2018 at 4:48 AM, Daniel Vetter  
>> > wrote:
>> >> [Fair warning: This is pure conjecture right now.]
>> >>
>> >> In
>> >>
>> >> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
>> >> Author: Peter Rosin 
>> >> Date:   Tue Jul 4 12:36:57 2017 +0200
>> >>
>> >> drm/fb-helper: factor out pseudo-palette
>> >>
>> >> Peter extracted the pseudo palette computation, but seems to have done
>> >> an off-by-one. I spotted that +1, but then noticed that we've passed
>> >> start++ to (now gone) setcolreg function, so it seemed to all match
>> >> up. Except post vs. pre-increment ftw.
>> >>
>> >> Result is that the palette is off-by-one, and the forground color
>> >> (slot 0) ends up black, rendering a fairly unreadable console.
>> >>
>> >> What baffles me is that on some systems it still seems to work
>> >> somehow, which lead us all down a wild goose chase trying to add
>> >> load_lut calls back in in various places (which was also intentionally
>> >> removed, but really doesn't seem to be the real root cause).
>> >>
>> >> Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
>> >> Cc: Peter Rosin 
>> >> Cc: Daniel Vetter 
>> >> Cc: Daniel Vetter 
>> >> Cc: Gustavo Padovan 
>> >> Cc: Sean Paul 
>> >> Cc: David Airlie 
>> >> Cc: dri-devel@lists.freedesktop.org
>> >> Cc:  # v4.14+
>> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
>> >> Reported-by: Deposite Pirate 
>> >> Reported-by: Bill Fraser 
>> >> Cc: Deposite Pirate 
>> >> Cc: Bill Fraser 
>> >> Cc: Michel Dänzer 
>> >> Signed-off-by: Daniel Vetter 
>> >> ---
>> >>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> >> b/drivers/gpu/drm/drm_fb_helper.c
>> >> index 035784ddd133..1c3a200c4a10 100644
>> >> --- a/drivers/gpu/drm/drm_fb_helper.c
>> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> >> @@ -1295,7 +1295,7 @@ static int setcmap_pseudo_palette(struct fb_cmap 
>> >> *cmap, struct fb_info *info)
>> >> mask <<= info->var.transp.offset;
>> >> value |= mask;
>> >> }
>> >> -   palette[cmap->start + i] = value;
>> >> +   palette[cmap->start] = value;
>> >
>> > I don't think this is equivalent to what was there before. Before
>> > there we set palette[cmap->start]->palette[cmap->start + cmap->len -
>> > 1], now we're only setting palette[cmap->start].
>> >
>> > In the previous version (before Peter's change), we wrote
>> > palette[cmap->start] twice. So while there is an off-by-one bug, I
>> > don't think this fixes the issue.
>>
>> Well this patch is complete nonsense, no idea what I was thinking ...
>
> [Sending this out since it's in my tree and I'll forget soon]
>
> Equivalent behavior would be:

Are you sure? On 2nd look I think there isn't actually any off-by-one
going on in the referenced patch. The only thing I can see is that the
old code filled out the first entries of an oversized table (more than
16 entries), and only returned -EINVAL when getting to entry 17. The
new one doesn't do that. But more testing in the bug report hints at
this not being the real bug (and I didn't find any callers in the
fbcon code that would indicate there is such a bug).
-Daniel

>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd133..df6709768723 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1295,7 +1295,8 @@ static int setcmap_pseudo_palette(struct fb_cmap *cmap, 
> struct fb_info *info)
> mask <<= info->var.transp.offset;
> value |= mask;
> }
> -   palette[cmap->start + i] = value;
> +   if (i > 0)
> +   palette[cmap->start + i - 1] = value;
> }
>
> return 0;
>
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dsi: Fix improper use of mipi_dsi_device_transfer() return value

[Sean Paul]

On Mon, Jan 15, 2018 at 10:12:24AM +0100, Andrzej Hajda wrote:
> On 12.01.2018 15:48, Philippe Cornu wrote:
> > The function mipi_dsi_device_transfer() returns the number of transmitted
> > or received bytes on success or a negative error code on failure.
> >
> > The functions mipi_dsi_shutdown_peripheral(), mipi_dsi_turn_on_peripheral() 
> > &
> > mipi_dsi_set_maximum_return_packet_size() use improperly this returned
> > value in case of success: 0 should be returned instead of the number of
> > transmitted bytes.
> >
> > Signed-off-by: Philippe Cornu 
> 
> I guess, the best would be to create and use some helper similar to
> PTR_ERR_OR_ZERO,
> but this is also OK.
> 
> Reviewed-by: Andrzej Hajda 

Applied to drm-misc-next. Thanks for the patch and review

Sean

> 
>  --
> Regards
> Andrzej
> 
> > ---
> >  drivers/gpu/drm/drm_mipi_dsi.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> > index 4b47226b90d4..bc73b7f5b9fc 100644
> > --- a/drivers/gpu/drm/drm_mipi_dsi.c
> > +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> > @@ -498,8 +498,9 @@ int mipi_dsi_shutdown_peripheral(struct mipi_dsi_device 
> > *dsi)
> > .tx_buf = (u8 [2]) { 0, 0 },
> > .tx_len = 2,
> > };
> > +   int ret = mipi_dsi_device_transfer(dsi, );
> >  
> > -   return mipi_dsi_device_transfer(dsi, );
> > +   return (ret < 0) ? ret : 0;
> >  }
> >  EXPORT_SYMBOL(mipi_dsi_shutdown_peripheral);
> >  
> > @@ -517,8 +518,9 @@ int mipi_dsi_turn_on_peripheral(struct mipi_dsi_device 
> > *dsi)
> > .tx_buf = (u8 [2]) { 0, 0 },
> > .tx_len = 2,
> > };
> > +   int ret = mipi_dsi_device_transfer(dsi, );
> >  
> > -   return mipi_dsi_device_transfer(dsi, );
> > +   return (ret < 0) ? ret : 0;
> >  }
> >  EXPORT_SYMBOL(mipi_dsi_turn_on_peripheral);
> >  
> > @@ -541,8 +543,9 @@ int mipi_dsi_set_maximum_return_packet_size(struct 
> > mipi_dsi_device *dsi,
> > .tx_len = sizeof(tx),
> > .tx_buf = tx,
> > };
> > +   int ret = mipi_dsi_device_transfer(dsi, );
> >  
> > -   return mipi_dsi_device_transfer(dsi, );
> > +   return (ret < 0) ? ret : 0;
> >  }
> >  EXPORT_SYMBOL(mipi_dsi_set_maximum_return_packet_size);
> >  
> 
> 

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

[PATCH] drm/panel: panasonic-vvx10f034n00: Fix wuxga_nt_panel_disable() return value

[Sean Paul]

Return value for mipi_dsi_shutdown_peripheral() is unchecked.
Check it and return any errors if they come up. Even if
mipi_dsi_shutdown_peripheral() fails, continue attempting to
disable.

Cc: Philippe Cornu 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 7f915f706fa6..91dc5a6b14f9 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -72,11 +72,12 @@ static int wuxga_nt_panel_on(struct wuxga_nt_panel 
*wuxga_nt)
 static int wuxga_nt_panel_disable(struct drm_panel *panel)
 {
struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
+   int ret;
 
if (!wuxga_nt->enabled)
return 0;
 
-   mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
+   ret = mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
 
if (wuxga_nt->backlight) {
wuxga_nt->backlight->props.power = FB_BLANK_POWERDOWN;
@@ -86,7 +87,7 @@ static int wuxga_nt_panel_disable(struct drm_panel *panel)
 
wuxga_nt->enabled = false;
 
-   return 0;
+   return ret;
 }
 
 static int wuxga_nt_panel_unprepare(struct drm_panel *panel)
-- 
2.16.0.rc1.238.g530d649a79-goog

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

Re: [PATCH v2 2/2] drm: rcar-du: lvds: Fix LVDS startup on R-Car gen2

[Laurent Pinchart]

Hi Sergei,

On Tuesday, 16 January 2018 22:17:31 EET Sergei Shtylyov wrote:
> On 01/16/2018 06:46 PM, Laurent Pinchart wrote:
> >>> From: Sergei Shtylyov 
> >>> 
> >>> According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS
> >>> must be enabled and the bias crcuit enabled after the LVDS I/O pins are
> 
> Oops, this needs fixing (note the typo!). Could you please change this
> passage to:
> 
> and the bias circuit must be enabled after the LVDS I/O pins are
> 
> ?

Sure I'll fix that.

> >>> enabled, not before. Fix the gen2 LVDS startup sequence accordingly.
> >>> 
> >>> While at it, also fix the comment preceding the first LVDCR0 write that
> >>> still talks about hardcoding the LVDS mode 0.
> >> 
> >> Please do this in a separate commit then...
> > 
> > The reason I added it here is that I think we don't need patch 1/2 from
> > this series, and I found a bit overkill to split a comment fix to a
> > separate patch when we have a patch that touches the code around the
> > comment.
> 
> OK, you're the maintainer of this driver, you know better. :-)
> 
> >>> Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
> >> 
> >> You forgot to specify the other commit this one fixes -- I mean the
> >> comment fix.
> > 
> > Do we need to for a comment update ? It doesn't affect fix the behaviour
> > of the driver or device, and I'd thus prefer to avoid giving the wrong
> > impression that this patch fixes an bug introduced in a previous commit,
> > otherwise it might end up being backported unnecessarily.
> 
> OK, no dire need to backport indeed...
> 
> >>> Signed-off-by: Sergei Shtylyov 
> >>> Reviewed-by: Laurent Pinchart
> >>> 
> >>> [Set the mode and input at the same time as the BEN and LVEN bits]
> >>> Tested-by: Laurent Pinchart 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> ---
> >>> 
> >>>drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 14 +++---
> >>>1 file changed, 7 insertions(+), 7 deletions(-)
> >>> 
> >>> Hi Sergei,
> >>> 
> >>> For your convenience (and if you agree with bundling mode setup with the
> >>> first write as explained in my review of patch 1/2), here's the updated
> >>> version of patch 2/2 that I have taken in my development branch. If
> >>> you're fine with it I'll keep it, otherwise we can continue the review
> >>> discussion.
> >> 
> >> As I said, I don't know how to interpret the note 3 in either manual.
> 
> Moreover, it seems to me that the notes don't match the start-up procedure
> anymore...

How so ?

> > As explained in my latest reply to patch 1/2, my understanding is that the
> > parameters can be programmed at any time before step 6. The fact that the
> > current code works seems to confirm that interpretation. We could ask
> > Renesas for a confirmation if you want.
> 
> Would be good to ask, indeed.

I'll ask.

-- 
Regards,

Laurent Pinchart

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

[Bug 104508] Unable to set "Content Type" bit for HDMI and DisplayPort

[bugzilla-daemon]

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

--- Comment #3 from N. W.  ---
Any update on this one?

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

Re: [PATCH] drm/fb-helper: Fix of-by-one in setcmap_pseudo_palette

[Sean Paul]

On Fri, Jan 12, 2018 at 10:08:49PM +0100, Daniel Vetter wrote:
> On Fri, Jan 12, 2018 at 3:08 PM, Sean Paul  wrote:
> > On Fri, Jan 12, 2018 at 4:48 AM, Daniel Vetter  
> > wrote:
> >> [Fair warning: This is pure conjecture right now.]
> >>
> >> In
> >>
> >> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
> >> Author: Peter Rosin 
> >> Date:   Tue Jul 4 12:36:57 2017 +0200
> >>
> >> drm/fb-helper: factor out pseudo-palette
> >>
> >> Peter extracted the pseudo palette computation, but seems to have done
> >> an off-by-one. I spotted that +1, but then noticed that we've passed
> >> start++ to (now gone) setcolreg function, so it seemed to all match
> >> up. Except post vs. pre-increment ftw.
> >>
> >> Result is that the palette is off-by-one, and the forground color
> >> (slot 0) ends up black, rendering a fairly unreadable console.
> >>
> >> What baffles me is that on some systems it still seems to work
> >> somehow, which lead us all down a wild goose chase trying to add
> >> load_lut calls back in in various places (which was also intentionally
> >> removed, but really doesn't seem to be the real root cause).
> >>
> >> Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
> >> Cc: Peter Rosin 
> >> Cc: Daniel Vetter 
> >> Cc: Daniel Vetter 
> >> Cc: Gustavo Padovan 
> >> Cc: Sean Paul 
> >> Cc: David Airlie 
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc:  # v4.14+
> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
> >> Reported-by: Deposite Pirate 
> >> Reported-by: Bill Fraser 
> >> Cc: Deposite Pirate 
> >> Cc: Bill Fraser 
> >> Cc: Michel Dänzer 
> >> Signed-off-by: Daniel Vetter 
> >> ---
> >>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >> b/drivers/gpu/drm/drm_fb_helper.c
> >> index 035784ddd133..1c3a200c4a10 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -1295,7 +1295,7 @@ static int setcmap_pseudo_palette(struct fb_cmap 
> >> *cmap, struct fb_info *info)
> >> mask <<= info->var.transp.offset;
> >> value |= mask;
> >> }
> >> -   palette[cmap->start + i] = value;
> >> +   palette[cmap->start] = value;
> >
> > I don't think this is equivalent to what was there before. Before
> > there we set palette[cmap->start]->palette[cmap->start + cmap->len -
> > 1], now we're only setting palette[cmap->start].
> >
> > In the previous version (before Peter's change), we wrote
> > palette[cmap->start] twice. So while there is an off-by-one bug, I
> > don't think this fixes the issue.
> 
> Well this patch is complete nonsense, no idea what I was thinking ...

[Sending this out since it's in my tree and I'll forget soon]

Equivalent behavior would be: 

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd133..df6709768723 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1295,7 +1295,8 @@ static int setcmap_pseudo_palette(struct fb_cmap *cmap, 
struct fb_info *info)
mask <<= info->var.transp.offset;
value |= mask;
}
-   palette[cmap->start + i] = value;
+   if (i > 0)
+   palette[cmap->start + i - 1] = value;
}
 
return 0;


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

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

[Bug 104507] Unable to set "Content Type" bit for HDMI and DisplayPort

[bugzilla-daemon]

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

--- Comment #3 from N. W.  ---
Any update on this one?

-- 
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 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

--- Comment #2 from roman...@amd.com ---
I cannot reproduce it on v4.15-rc7 (git#1545dec46db3)
Vedran, can you  provide more info on your setup:
- display and connector types
- window manager
- dmesg with amdgpu.dc_log=1

-- 
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] [RESEND] vmwgfx: use monotonic event timestamps

[Arnd Bergmann]

On Tue, Jan 16, 2018 at 6:28 PM, Thomas Hellstrom  wrote:
> Hi, Arnd,
>
> Sinclair's on paternal leave and I thought this patch was already in
> drm-next. My bad.

No worries.

> Dave, is it too late to pull this in for the next merge window?

The patch isn't urgent, it's fine to wait until after the merge window, I just
want to avoid having to send it once more as I make my way through
the remaining 'timeval' and 'timespec' users.

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

Re: [PATCH v16 00/10] Add backlight helper functions

[Sean Paul]

On Tue, Jan 16, 2018 at 10:31:07AM +, Meghana Madhyastha wrote:
> Move drm helper functions from tinydrm-helpers to linux/backlight for
> ease of use by callers in other drivers.
> 
> Changes in v16:
> -Add a comment about setting brightness = max_brightness in of_find_backlight
> -Add dri-devel and linux-kernel mailing lists

I just took a pass through the set. Agreed on all of Noralf's review feedback
(which seems minor). Once that's resolved, feel free to add my R-b to the whole
thing. Thanks for sticking with this, almost there :-)

Sean

> 
> Meghana Madhyastha (10):
>   video: backlight: Add helpers to enable and disable backlight
>   drm/tinydrm: Convert tinydrm_enable/disable_backlight to
> backlight_enable/disable
>   video: backlight: Add of_find_backlight helper in backlight.c
>   drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight
>   video: backlight: Add devres versions of of_find_backlight
>   drm/tinydrm: Call devres version of of_find_backlight
>   drm/panel: Use backlight_enable/disable helpers
>   drm/omapdrm: Use backlight_enable/disable helpers
>   drm/panel: Use of_find_backlight helper
>   drm/omapdrm: Use of_find_backlight helper
> 
>  drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 22 ++
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c   | 16 ++---
>  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c  |  6 +-
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 22 ++
>  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 22 ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c  | 95 
> -
>  drivers/gpu/drm/tinydrm/mi0283qt.c  |  3 +-
>  drivers/gpu/drm/tinydrm/mipi-dbi.c  |  4 +-
>  drivers/video/backlight/backlight.c | 69 ++
>  include/drm/tinydrm/tinydrm-helpers.h   |  4 --
>  include/linux/backlight.h   | 56 +++
>  11 files changed, 157 insertions(+), 162 deletions(-)
> 
> -- 
> 2.11.0
> 

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

[PATCH v2 2/3] drm/msm/dsi: correct DSI id bounds check during registration

[Lloyd Atkinson]

Check DSI instance id argument against the proper boundary size
to protect against invalid configuration of the DSI id.

Signed-off-by: Lloyd Atkinson 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 1a54fd6..4cb1cb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -862,7 +862,7 @@ int msm_dsi_manager_register(struct msm_dsi *msm_dsi)
int id = msm_dsi->id;
int ret;
 
-   if (id > DSI_MAX) {
+   if (id >= DSI_MAX) {
pr_err("%s: invalid id %d\n", __func__, id);
return -EINVAL;
}
-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

[Pandiyan, Dhinakaran]

On Mon, 2018-01-15 at 10:38 +0100, Daniel Vetter wrote:
> On Fri, Jan 12, 2018 at 01:57:03PM -0800, Dhinakaran Pandiyan wrote:
> > drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> > space requested vblank sequence using this clipped 32-bit count(when the
> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > value and gets queued like that. However, the code that checks if the
> > requested sequence has passed compares this against the 64-bit vblank
> > count.
> > 
> > Cc: Keith Packard 
> > Cc: Michel Dänzer 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> Sounds like the 64bit widening wasn't all that well tested ... do we have
> an igt for this? Iirc the base igt was merged already.

I don't see anything that would particularly trigger this condition
i.e., vblank->count > 2^32 in the IGTs. We'll need to implement
something to force set a very large vblank->count and then request a
vblank sequence.




> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_vblank.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 32d9bcf5be7f..768a8e44d99b 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, unsigned int pipe,
> > store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> >  }
> >  
> > -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> >  {
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> >  
> > -- 
> > 2.11.0
> > 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] drm/msm/dsi: check for failure on retrieving pll in dsi manager

[Lloyd Atkinson]

Make msm_dsi_pll_init consistently return an error code instead
of NULL when pll initialization fails so that later pll
retrieval can check against an error code. Add checks for these
failures after retrieval of src_pll to avoid invalid pointer
dereferences later in msm_dsi_pll_get_clk_provider.

Signed-off-by: Lloyd Atkinson 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 +++---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c | 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 8552481..1a54fd6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -88,6 +88,8 @@ static int dsi_mgr_setup_components(int id)
 
msm_dsi_phy_set_usecase(msm_dsi->phy, MSM_DSI_PHY_STANDALONE);
src_pll = msm_dsi_phy_get_pll(msm_dsi->phy);
+   if (IS_ERR(src_pll))
+   return PTR_ERR(src_pll);
ret = msm_dsi_host_set_src_pll(msm_dsi->host, src_pll);
} else if (!other_dsi) {
ret = 0;
@@ -116,6 +118,8 @@ static int dsi_mgr_setup_components(int id)
msm_dsi_phy_set_usecase(clk_slave_dsi->phy,
MSM_DSI_PHY_SLAVE);
src_pll = msm_dsi_phy_get_pll(clk_master_dsi->phy);
+   if (IS_ERR(src_pll))
+   return PTR_ERR(src_pll);
ret = msm_dsi_host_set_src_pll(msm_dsi->host, src_pll);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 790ca28..c8bfaa7 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -503,10 +503,10 @@ static int dsi_phy_driver_probe(struct platform_device 
*pdev)
goto fail;
 
phy->pll = msm_dsi_pll_init(pdev, phy->cfg->type, phy->id);
-   if (!phy->pll)
+   if (IS_ERR_OR_NULL(phy->pll))
dev_info(dev,
-   "%s: pll init failed, need separate pll clk driver\n",
-   __func__);
+   "%s: pll init failed: %ld, need separate pll clk 
driver\n",
+   __func__, PTR_ERR(phy->pll));
 
dsi_phy_disable_resource(phy);
 
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
index bc289f5..491f08d 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
@@ -173,7 +173,7 @@ struct msm_dsi_pll *msm_dsi_pll_init(struct platform_device 
*pdev,
 
if (IS_ERR(pll)) {
dev_err(dev, "%s: failed to init DSI PLL\n", __func__);
-   return NULL;
+   return pll;
}
 
pll->type = type;
-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH v2 3/3] drm/msm/dsi: check msm_dsi and dsi pointers before use

[Lloyd Atkinson]

Move null checks of pointer arguments to the beginning of the
modeset init function since they are referenced immediately
instead of after they have already been used.

Signed-off-by: Lloyd Atkinson 
---
 drivers/gpu/drm/msm/dsi/dsi.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 98742d7..ee7e090 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -196,7 +196,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
struct drm_bridge *ext_bridge;
int ret;
 
-   if (WARN_ON(!encoder))
+   if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
return -EINVAL;
 
msm_dsi->dev = dev;
@@ -245,19 +245,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
 
return 0;
 fail:
-   if (msm_dsi) {
-   /* bridge/connector are normally destroyed by drm: */
-   if (msm_dsi->bridge) {
-   msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
-   msm_dsi->bridge = NULL;
-   }
+   /* bridge/connector are normally destroyed by drm: */
+   if (msm_dsi->bridge) {
+   msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
+   msm_dsi->bridge = NULL;
+   }
 
-   /* don't destroy connector if we didn't make it */
-   if (msm_dsi->connector && !msm_dsi->external_bridge)
-   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
+   /* don't destroy connector if we didn't make it */
+   if (msm_dsi->connector && !msm_dsi->external_bridge)
+   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
 
-   msm_dsi->connector = NULL;
-   }
+   msm_dsi->connector = NULL;
 
return ret;
 }
-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH v2 0/3] drm/msm/dsi: improve pointer validation checks

[Lloyd Atkinson]

This series improves a few pointer validation checks around the
drm/msm/dsi driver.

v2 incoporates feedback on patch 1/3 and patch 3/3.

Lloyd Atkinson (3):
  drm/msm/dsi: check for failure on retrieving pll in dsi manager
  drm/msm/dsi: correct DSI id bounds check during registration
  drm/msm/dsi: check msm_dsi and dsi pointers before use

 drivers/gpu/drm/msm/dsi/dsi.c | 22 ++
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  6 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  6 +++---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c |  2 +-
 4 files changed, 19 insertions(+), 17 deletions(-)

-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

[bugzilla-daemon]

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

--- Comment #5 from Vedran Miletić  ---
4.15-rc8 on Kaveri after modprobe -r:

[  215.855452] [drm] radeon: finishing device.
[  215.895091] [TTM] Finalizing pool allocator
[  215.895254] [TTM] Finalizing DMA pool allocator
[  215.895302] [TTM] Zone  kernel: Used memory at exit: 2080 kiB
[  215.895305] [drm] radeon: ttm finalized

I'll close this bug after I get a chance to try it on RV635. 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

Re: [PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Rob,

On Tuesday, 16 January 2018 18:54:00 EET Rob Herring wrote:
> On Tue, Jan 16, 2018 at 10:32 AM, Laurent Pinchart wrote:
> > On Tuesday, 16 January 2018 16:35:26 EET Rob Herring wrote:
> >> On Mon, Jan 15, 2018 at 5:46 PM, Frank Rowand wrote:
> >>> On 01/15/18 12:29, Laurent Pinchart wrote:
>  On Monday, 15 January 2018 22:12:33 EET Frank Rowand wrote:
> > On 01/15/18 11:22, Laurent Pinchart wrote:
> >> On Monday, 15 January 2018 21:12:44 EET Frank Rowand wrote:
> >>> On 01/15/18 09:09, Rob Herring wrote:
>  On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
> > The internal LVDS encoders now have their own DT bindings. Before
> > switching the driver infrastructure to those new bindings,
> > implement backward-compatibility through live DT patching.
> 
> [...]
> 
>  How would you like to proceed ? I can try the manual approach again
>  but need information about how I could cleanly implement phandle
>  allocation. I will likely then run into other issues for which I might
>  need help.
> >>> 
> >>> Here are my first thoughts, based on 4.15-rc7:
> >>> 
> >>> Question to Rob and Frank: should of_attach_node() be called directly,
> >>> or should it be called indirectly by creating a change set that adds the
> >>> node?
> >>> 
> >>> Frank's off the cuff answer (but would like to think more about it):
> >>> since the driver is modifying its own devicetree data, and thus no other
> >>> entity needs to be notified about the changes, there is no need to add
> >>> the complexity of using a change set.
> >> 
> >> There's exactly 2 users outside of the DT core. That's generally a
> >> sign of an API I'd like to make private.
> >> 
> >>> The following is how of_attach_node() could be modified to dynamically
> >>> create a phandle on request.
> >> 
> >> How would this work for all the phandle references that need to be fixed
> >> up?
> > 
> > As I know which properties contain a phandle that needs to be fixed up, my
> > plan is to update those properties manually with the value of the newly
> > allocated phandle.
> 
> That sounds like more low level, internal detail mucking with than
> this current patch.

While I think the current patch is a bit of a hack I still like to to some 
extend, so I'm not requesting APIs to muck with OF internals instead of using 
the overlay API. It's entirely up to you and Frank (and other OF core 
developers). I'm fine with either way, all I know is that I need a solution 
:-)

> > What I need here is the ability to insert the following structure in the
> > device tree:
> > 
> > lvds@feb9 {
> > 
> >compatible = "renesas,r8a7796-lvds"; (*)
> >reg = <0 0xfeb9 0 0x14>; (*)
> >clocks = < CPG_MOD 727>; (*)
> 
> I'm still of the opinion that all of this should be in a per SoC overlay.
> 
> >ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > port@0 {
> > reg = <0>;
> > lvds0_in: endpoint {
> > remote-endpoint = <_out_lvds0>;
> > (*)
> > };
> > };
> > port@1 {
> > reg = <1>;
> > lvds0_out: endpoint {
> > remote-endpoint = <_in>; (*)
> 
> Then do the fixup of just the remote-endpoint properties. While it
> would be nice to say overlays are completely static, I'm guessing
> that's not going to be the case. After all, we pretty much have
> overlays because DT being static has limitations.

Do you mean fixing them up in the parsed overlay before applying it, or 
manually in the live device tree after applying the overlay ?

> > };
> > };
> > };
> > };
> > 
> > with the node unit address and all properties marked with a (*) computed
> > at runtime based on information extract from the device tree. Additionally
> > I need phandles for the lvds0_in and lvds0_out nodes, and set the value of
> > two properties in the tree with those phandles.
> > 
> > I've used overlays as that was the only way I found to allocate phandles,
> > but any other API will work for me as well.
> 
> I don't think drivers mucking with phandles directly to avoid another
> overlay user is an improvement.

Again I'm fine either way.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

[Maxime Ripard]

Hi Ayan,

On Mon, Jan 15, 2018 at 03:47:44PM +, Ayan Halder wrote:
> On Tue, Jan 09, 2018 at 02:28:33PM +0100, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote:
> > > On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> > > > There's a bunch of drivers that duplicate the same function to know if a
> > > > particular format embeds an alpha component or not.
> > > >
> > > > Let's create a helper to avoid duplicating that logic.
> > > >
> > > > Cc: Boris Brezillon 
> > > > Cc: Eric Anholt 
> > > > Cc: Inki Dae 
> > > > Cc: Joonyoung Shim 
> > > > Cc: Kyungmin Park 
> > > > Cc: Laurent Pinchart 
> > > > Cc: Mark Yao 
> > > > Cc: Seung-Woo Kim 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >  drivers/gpu/drm/drm_fourcc.c | 43 
> > > > +-
> > > >  include/drm/drm_fourcc.h |  1 +-
> > > >  2 files changed, 44 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > > > index 9c0152df45ad..6e6227d6a46b 100644
> > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > @@ -348,3 +348,46 @@ int drm_format_plane_height(int height, uint32_t
> > > > format, int plane) return height / info->vsub;
> > > >  }
> > > >  EXPORT_SYMBOL(drm_format_plane_height);
> > > > +
> > > > +/**
> > > > + * drm_format_has_alpha - get whether the format embeds an alpha 
> > > > component
> > > > + * @format: pixel format (DRM_FORMAT_*)
> > > > + *
> > > > + * Returns:
> > > > + * true if the format embeds an alpha component, false otherwise.
> > > > + */
> > > > +bool drm_format_has_alpha(uint32_t format)
> > > > +{
> > > > + switch (format) {
> > > > + case DRM_FORMAT_ARGB:
> > > > + case DRM_FORMAT_ABGR:
> > > > + case DRM_FORMAT_RGBA:
> > > > + case DRM_FORMAT_BGRA:
> > > > + case DRM_FORMAT_ARGB1555:
> > > > + case DRM_FORMAT_ABGR1555:
> > > > + case DRM_FORMAT_RGBA5551:
> > > > + case DRM_FORMAT_BGRA5551:
> > > > + case DRM_FORMAT_ARGB:
> > > > + case DRM_FORMAT_ABGR:
> > > > + case DRM_FORMAT_RGBA:
> > > > + case DRM_FORMAT_BGRA:
> > > > + case DRM_FORMAT_ARGB2101010:
> > > > + case DRM_FORMAT_ABGR2101010:
> > > > + case DRM_FORMAT_RGBA1010102:
> > > > + case DRM_FORMAT_BGRA1010102:
> > > > + case DRM_FORMAT_AYUV:
> > > > + case DRM_FORMAT_XRGB_A8:
> > > > + case DRM_FORMAT_XBGR_A8:
> > > > + case DRM_FORMAT_RGBX_A8:
> > > > + case DRM_FORMAT_BGRX_A8:
> > > > + case DRM_FORMAT_RGB888_A8:
> > > > + case DRM_FORMAT_BGR888_A8:
> > > > + case DRM_FORMAT_RGB565_A8:
> > > > + case DRM_FORMAT_BGR565_A8:
> > > > + return true;
> > > > +
> > > > + default:
> > > > + return false;
> > > > + }
> > > > +}
> > > > +EXPORT_SYMBOL(drm_format_has_alpha);
> > >
> > > How about adding the information to struct drm_format_info instead ?
> > > drm_format_has_alpha() could then be implemented as
> > >
> > > bool drm_format_has_alpha(uint32_t format)
> > > {
> > > const struct drm_format_info *info;
> > >
> > > info = drm_format_info(format);
> > > return info ? info->has_alpha : false;
> > > }
> >
> > I considered it, and wasn't too sure about if adding more fields to
> > drm_format_info was ok. I can definitely do it that way.
>
> Are you going to send an updated patch with the change mentioned here.
> Or should I update my patch (https://patchwork.kernel.org/patch/10161023/)
> and change the type of '.alpha' to boolean to denote if the color
> format has an alpha channel or not.

Yes, I already had those patches ready. I'm just waiting for the
discussion on the alpha property to settle before sending a v2.

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 v2 2/2] drm: rcar-du: lvds: Fix LVDS startup on R-Car gen2

[Sergei Shtylyov]

On 01/16/2018 06:46 PM, Laurent Pinchart wrote:


From: Sergei Shtylyov 

According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS
must be enabled and the bias crcuit enabled after the LVDS I/O pins are


   Oops, this needs fixing (note the typo!). Could you please change this 
passage to:


and the bias circuit must be enabled after the LVDS I/O pins are

?


enabled, not before. Fix the gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.


Please do this in a separate commit then...


The reason I added it here is that I think we don't need patch 1/2 from this
series, and I found a bit overkill to split a comment fix to a separate patch
when we have a patch that touches the code around the comment.


   OK, you're the maintainer of this driver, you know better. :-)


Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")


You forgot to specify the other commit this one fixes -- I mean the comment
fix.


Do we need to for a comment update ? It doesn't affect fix the behaviour of
the driver or device, and I'd thus prefer to avoid giving the wrong impression
that this patch fixes an bug introduced in a previous commit, otherwise it
might end up being backported unnecessarily.


   OK, no dire need to backport indeed...


Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
[Set the mode and input at the same time as the BEN and LVEN bits]
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart

---

   drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 14 +++---
   1 file changed, 7 insertions(+), 7 deletions(-)

Hi Sergei,

For your convenience (and if you agree with bundling mode setup with the
first write as explained in my review of patch 1/2), here's the updated
version of patch 2/2 that I have taken in my development branch. If
you're fine with it I'll keep it, otherwise we can continue the review
discussion.


As I said, I don't know how to interpret the note 3 in either manual.


   Moreover, it seems to me that the notes don't match the start-up procedure 
anymore...



As explained in my latest reply to patch 1/2, my understanding is that the
parameters can be programmed at any time before step 6. The fact that the
current code works seems to confirm that interpretation. We could ask Renesas
for a confirmation if you want.


   Would be good to ask, indeed.

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

[PATCH v3] drm/amdgpu: Use new TTM flag to avoid OOM triggering.

[Andrey Grodzovsky]

Avoid OOM on syatem pages allocations.

v2:
Remove modeprobe parameter, make this behaviour the only option.

v3:
Move setting no_retry flag into amdgpu_ttm_init.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 290cdf0..d32f482 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1387,6 +1387,10 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
return r;
}
adev->mman.initialized = true;
+
+   /* We opt to avoid OOM on system pages allocations */
+   adev->mman.bdev.no_retry = true;
+
r = ttm_bo_init_mm(>mman.bdev, TTM_PL_VRAM,
adev->gmc.real_vram_size >> PAGE_SHIFT);
if (r) {
-- 
2.7.4

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

[Bug 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

--- Comment #5 from Andy Furniss  ---
Thanks, stupid monitor rather than some rounding then :-)

-- 
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 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

--- Comment #4 from Alex Deucher  ---
(In reply to Andy Furniss from comment #3)
> Thanks, that works.
> 
> This is the same with non dc, but is there a reason they are a bit low?
> 
>   1920x1080 (0x5b) 285.500MHz +HSync -VSync
> h: width  1920 start 1968 end 2000 total 2080 skew0 clock
> 137.26KHz
> v: height 1080 start 1083 end 1088 total 1144   clock
> 119.98Hz
> 
>  1920x1080 (0x5c) 260.250MHz +HSync -VSync
> h: width  1920 start 1968 end 2000 total 2080 skew0 clock
> 125.12KHz
> v: height 1080 start 1083 end 1088 total 1138   clock
> 109.95Hz
> 
>  1920x1080 (0x5d) 235.500MHz +HSync -VSync
> h: width  1920 start 1968 end 2000 total 2080 skew0 clock
> 113.22KHz
> v: height 1080 start 1083 end 1088 total 1133   clock 
> 99.93Hz
> 
> I was hoping DC would differ from the old driver in giving exact Hz for
> these.

Those are the modes from the EDID from your monitor:

CEA extension block
Extension version: 1
0 8-byte timing descriptors
Detailed mode: Clock 235.500 MHz, 521 mm x 293 mm
   1920 1968 2000 2080 hborder 0
   1080 1083 1088 1133 vborder 0
   +hsync -vsync 
Detailed mode: Clock 260.250 MHz, 521 mm x 293 mm
   1920 1968 2000 2080 hborder 0
   1080 1083 1088 1138 vborder 0
   +hsync -vsync 
Detailed mode: Clock 285.500 MHz, 521 mm x 293 mm
   1920 1968 2000 2080 hborder 0
   1080 1083 1088 1144 vborder 0
   +hsync -vsync

-- 
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 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

--- Comment #3 from Andy Furniss  ---
Thanks, that works.

This is the same with non dc, but is there a reason they are a bit low?

  1920x1080 (0x5b) 285.500MHz +HSync -VSync
h: width  1920 start 1968 end 2000 total 2080 skew0 clock 137.26KHz
v: height 1080 start 1083 end 1088 total 1144   clock 119.98Hz

 1920x1080 (0x5c) 260.250MHz +HSync -VSync
h: width  1920 start 1968 end 2000 total 2080 skew0 clock 125.12KHz
v: height 1080 start 1083 end 1088 total 1138   clock 109.95Hz

 1920x1080 (0x5d) 235.500MHz +HSync -VSync
h: width  1920 start 1968 end 2000 total 2080 skew0 clock 113.22KHz
v: height 1080 start 1083 end 1088 total 1133   clock  99.93Hz

I was hoping DC would differ from the old driver in giving exact Hz for these.

-- 
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 v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

[Brian Norris]

Hi all,

I believe Philippe's comments about return values have been addressed
separately, and this patch was applied to drm-misc-next. But I have one
additional thought below.

On Tue, Jan 09, 2018 at 12:32:47PM -0800, Brian Norris wrote:
> This takes care of 2 TODOs in this driver, by using the common DSI
> packet-marshalling code instead of our custom short/long write code.
> This both saves us some duplicated code and gets us free support for
> command types that weren't already part of our switch block (e.g.,
> MIPI_DSI_GENERIC_LONG_WRITE).
> 
> The code logic stays mostly intact, except that it becomes unnecessary
> to split the short/long write functions, and we have to copy data a bit
> more.
> 
> Along the way, I noticed that loop bounds were a little odd:
> 
>   while (DIV_ROUND_UP(len, pld_data_bytes))
> 
> This really was just supposed to be 'len != 0', so I made that more
> clear.
> 
> Tested on RK3399 with some pending refactoring patches by Nickey Yang,
> to make the Rockchip DSI driver wrap this common driver.
> 
> Signed-off-by: Brian Norris 
> Reviewed-by: Philippe Cornu 
> Tested-by: Philippe Cornu 

...

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4fd66ec..ed91e32ee43a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c

...

> @@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct 
> dw_mipi_dsi *dsi,
>   }
>   }
>  
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
> + remainder = 0;
> + memcpy(, packet->header, sizeof(packet->header));
> + return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
>  }
>  
>  static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
>const struct mipi_dsi_msg *msg)
>  {
>   struct dw_mipi_dsi *dsi = host_to_dsi(host);
> + struct mipi_dsi_packet packet;
>   int ret;
>  
> - /*
> -  * TODO dw drv improvements
> -  * use mipi_dsi_create_packet() instead of all following
> -  * functions and code (no switch cases, no
> -  * dw_mipi_dsi_dcs_short_write(), only the loop in long_write...)
> -  * and use packet.header...
> -  */
> - dw_mipi_message_config(dsi, msg);
> -
> - switch (msg->type) {
> - case MIPI_DSI_DCS_SHORT_WRITE:
> - case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
> - case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
> - ret = dw_mipi_dsi_dcs_short_write(dsi, msg);
> - break;
> - case MIPI_DSI_DCS_LONG_WRITE:
> - ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
> - break;
> - default:
> - dev_err(dsi->dev, "unsupported message type 0x%02x\n",
> - msg->type);
> - ret = -EINVAL;

By removing this default case, I'm hiding the fact that this driver
doesn't currently implement RX support at all -- only TX. (Previously,
if presented with, e.g., a MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM, the
driver would reject it. Now it will silently fail to return it.)

I believe some Rockchip folks have preliminary RX support implemented
somewhere, so we might consider merging that, or else re-introducing a
failure case to catch the unimplemented RX support.

Brian

> + ret = mipi_dsi_create_packet(, msg);
> + if (ret) {
> + dev_err(dsi->dev, "failed to create packet: %d\n", ret);
> + return ret;
>   }
>  
> - return ret;
> + dw_mipi_message_config(dsi, msg);
> +
> + return dw_mipi_dsi_write(dsi, );
>  }
>  
>  static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()

[Brian Norris]

On Tue, Jan 16, 2018 at 12:22:52PM +0530, Archit Taneja wrote:
> On 01/10/2018 08:03 PM, Andrzej Hajda wrote:
> >On 09.01.2018 21:32, Brian Norris wrote:
> >>@@ -386,9 +386,9 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> >>}
> >>}
> >>-   remainder = 0;
> >>-   memcpy(, packet->header, sizeof(packet->header));
> >>-   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
> >>+   word = 0;
> >>+   memcpy(, packet->header, sizeof(packet->header));
> >>+   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
> >
> >You could create and use appropriate helper, lets say:
> >
> >u32 le_to_cpup(const u8 *p, int count)
> >{
> >     __le32 r = 0;
> >
> >     memcpy(, p, count);
> >     return le32_to_cpu(r);
> >}

I suppose that could be a small improvement, for future consideration,
if this gets too out of hand.

> >With or without this change:
> >Reviewed-by: Andrzej Hajda 

Thanks!

> Queued to drm-misc-next as is.

Thanks!

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

[Bug 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

--- Comment #2 from Harry Wentland  ---
Created attachment 136782
  --> https://bugs.freedesktop.org/attachment.cgi?id=136782=edit
Fix for dual-link DVI modes

The error is unrelated. This patch should fix your dual-link DVI modes. It's
hitting the mailing list soon, just took a bit longer than the rest of the DVI
patches. Note that we also see issues with non-native modes on one display with
this patch, but that's likely a monitor-specific issue.

-- 
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 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

--- Comment #1 from Andy Furniss  ---
Created attachment 136780
  --> https://bugs.freedesktop.org/attachment.cgi?id=136780=edit
xrandr with missing > 60Hz modes

-- 
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 104660] DC R9 285 dual link DVI modes not shown.

[bugzilla-daemon]

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

Bug ID: 104660
   Summary: DC R9 285 dual link DVI modes not shown.
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: adf.li...@gmail.com

Created attachment 136779
  --> https://bugs.freedesktop.org/attachment.cgi?id=136779=edit
dmesg with error

R9 285 Tonga, I see in agd5f 4.17-wip there are commits to do with DVI dual
link. 

I was hoping "Don't block dual-link DVI modes" would enable 120Hz my monitor
supports, which has always worked with without dc.

There is an error in dmesg - don't know if it's related. dmesg and xrandr
attached.

[drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't have set_dce_clock
for v0

-- 
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] [RESEND] vmwgfx: use monotonic event timestamps

[Thomas Hellstrom]

Hi, Arnd,

Sinclair's on paternal leave and I thought this patch was already in 
drm-next. My bad.

Dave, is it too late to pull this in for the next merge window?

/Thomas


On 01/16/2018 06:18 PM, Arnd Bergmann wrote:

DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.

As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic times for drm_event_vblank,
but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
the y2038/y2106 overflow as well as time jumps.

For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
which solves those problems and avoids the deprecated do_gettimeofday()
function.

This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().

Link: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_10076599_=DwIBAg=uilaK90D4TOVoH58JNXRgQ=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ=8M6vawBo0zDsjbqhzV0xpOwAzX7Zm-uyGlIDnQ7-Gms=sHGuz0aoE9aLjVp5GALo8mYrN1bwOHW6mGpJIZmhwAc=
Signed-off-by: Arnd Bergmann 
---
Originally sent on Nov 27. Sinclair Yeh said he'd pick it up
for the next pull request, but it's not in linux-next yet.

Resending the unchanged patch, please pick it up when you have time,
or feel free to ignore this email in case it's already in some tree
that just isn't part of linux-next but will be sent during the
next merge window.
---
  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 6c5c75cf5e6c..9ed544f8958f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -901,11 +901,12 @@ static void vmw_event_fence_action_seq_passed(struct 
vmw_fence_action *action)
spin_lock_irq(>event_lock);
  
  	if (likely(eaction->tv_sec != NULL)) {

-   struct timeval tv;
+   struct timespec64 ts;
  
-		do_gettimeofday();

-   *eaction->tv_sec = tv.tv_sec;
-   *eaction->tv_usec = tv.tv_usec;
+   ktime_get_ts64();
+   /* monotonic time, so no y2038 overflow */
+   *eaction->tv_sec = ts.tv_sec;
+   *eaction->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
}
  
  	drm_send_event_locked(dev, eaction->event);



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

[PATCH] [RESEND] vmwgfx: use monotonic event timestamps

[Arnd Bergmann]

DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.

As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic times for drm_event_vblank,
but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
the y2038/y2106 overflow as well as time jumps.

For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
which solves those problems and avoids the deprecated do_gettimeofday()
function.

This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().

Link: https://patchwork.kernel.org/patch/10076599/
Signed-off-by: Arnd Bergmann 
---
Originally sent on Nov 27. Sinclair Yeh said he'd pick it up
for the next pull request, but it's not in linux-next yet.

Resending the unchanged patch, please pick it up when you have time,
or feel free to ignore this email in case it's already in some tree
that just isn't part of linux-next but will be sent during the
next merge window.
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 6c5c75cf5e6c..9ed544f8958f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -901,11 +901,12 @@ static void vmw_event_fence_action_seq_passed(struct 
vmw_fence_action *action)
spin_lock_irq(>event_lock);
 
if (likely(eaction->tv_sec != NULL)) {
-   struct timeval tv;
+   struct timespec64 ts;
 
-   do_gettimeofday();
-   *eaction->tv_sec = tv.tv_sec;
-   *eaction->tv_usec = tv.tv_usec;
+   ktime_get_ts64();
+   /* monotonic time, so no y2038 overflow */
+   *eaction->tv_sec = ts.tv_sec;
+   *eaction->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
}
 
drm_send_event_locked(dev, eaction->event);
-- 
2.9.0

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

Re: [PATCH v16 07/10] drm/panel: Use backlight_enable/disable helpers

[Noralf Trønnes]

Den 16.01.2018 11.35, skrev Meghana Madhyastha:

Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.

Signed-off-by: Meghana Madhyastha 
---
  drivers/gpu/drm/panel/panel-innolux-p079zca.c   |  6 ++
  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c  |  6 ++
  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 12 
  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 12 
  4 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba93449f..4c1b29eec 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -45,8 +45,7 @@ static int innolux_panel_disable(struct drm_panel *panel)
if (!innolux->enabled)
return 0;
  
-	innolux->backlight->props.power = FB_BLANK_POWERDOWN;

-   backlight_update_status(innolux->backlight);
+   backlight_disable(innolux->backlight);
  
  	err = mipi_dsi_dcs_set_display_off(innolux->link);

if (err < 0)
@@ -151,8 +150,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
if (innolux->enabled)
return 0;
  
-	innolux->backlight->props.power = FB_BLANK_UNBLANK;

-   ret = backlight_update_status(innolux->backlight);
+   ret = backlight_enable(innolux->backlight);
if (ret) {
DRM_DEV_ERROR(panel->drm->dev,
  "Failed to enable backlight %d\n", ret);
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340ef7..0a94ab79a 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -192,8 +192,7 @@ static int jdi_panel_disable(struct drm_panel *panel)
if (!jdi->enabled)
return 0;
  
-	jdi->backlight->props.power = FB_BLANK_POWERDOWN;

-   backlight_update_status(jdi->backlight);
+   backlight_disable(jdi->backlight);
  
  	jdi->enabled = false;
  
@@ -289,8 +288,7 @@ static int jdi_panel_enable(struct drm_panel *panel)

if (jdi->enabled)
return 0;
  
-	jdi->backlight->props.power = FB_BLANK_UNBLANK;

-   backlight_update_status(jdi->backlight);
+   backlight_enable(jdi->backlight);
  
  	jdi->enabled = true;
  
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c

index 3cce3ca19..1512ec4f3 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -96,10 +96,8 @@ static int sharp_panel_disable(struct drm_panel *panel)
if (!sharp->enabled)
return 0;
  
-	if (sharp->backlight) {

-   sharp->backlight->props.power = FB_BLANK_POWERDOWN;
-   backlight_update_status(sharp->backlight);
-   }
+   if (sharp->backlight)


No need for a NULL check, backlight_enable/disable() already does that.
The same goes for the rest of the patch.

Noralf.


+   backlight_disable(sharp->backlight);
  
  	sharp->enabled = false;
  
@@ -263,10 +261,8 @@ static int sharp_panel_enable(struct drm_panel *panel)

if (sharp->enabled)
return 0;
  
-	if (sharp->backlight) {

-   sharp->backlight->props.power = FB_BLANK_UNBLANK;
-   backlight_update_status(sharp->backlight);
-   }
+   if (sharp->backlight)
+   backlight_enable(sharp->backlight);
  
  	sharp->enabled = true;
  
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c

index 3aeb0bda4..a6af3257f 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -117,10 +117,8 @@ static int sharp_nt_panel_disable(struct drm_panel *panel)
if (!sharp_nt->enabled)
return 0;
  
-	if (sharp_nt->backlight) {

-   sharp_nt->backlight->props.power = FB_BLANK_POWERDOWN;
-   backlight_update_status(sharp_nt->backlight);
-   }
+   if (sharp_nt->backlight)
+   backlight_disable(sharp_nt->backlight);
  
  	sharp_nt->enabled = false;
  
@@ -203,10 +201,8 @@ static int sharp_nt_panel_enable(struct drm_panel *panel)

if (sharp_nt->enabled)
return 0;
  
-	if (sharp_nt->backlight) {

-   sharp_nt->backlight->props.power = FB_BLANK_UNBLANK;
-   backlight_update_status(sharp_nt->backlight);
-   }
+   if (sharp_nt->backlight)
+   backlight_enable(sharp_nt->backlight);
  
  	sharp_nt->enabled = true;
  


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

Re: [PATCH v16 09/10] drm/panel: Use of_find_backlight helper

[Noralf Trønnes]

Den 16.01.2018 11.36, skrev Meghana Madhyastha:

Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.

Signed-off-by: Meghana Madhyastha 
---
  drivers/gpu/drm/panel/panel-innolux-p079zca.c   | 10 +++---
  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 10 +++---
  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 10 +++---
  3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 4c1b29eec..a69b0530f 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -230,14 +230,10 @@ static int innolux_panel_add(struct innolux_panel 
*innolux)
innolux->enable_gpio = NULL;
}
  
-	np = of_parse_phandle(dev->of_node, "backlight", 0);

-   if (np) {
-   innolux->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   innolux->backlight = devm_of_find_backlight(np);


This driver isn't broken like tinydrm was, so it does put the backlight
device on cleanup like it should. So when you're using the devm_ version,
the result is a double put. Just remove the put_device() in
innolux_panel_add/del() and you're good.

I haven't checked the other drivers.

Noralf.

PS:
Give people a few days (one week?) to respond before respinning a new
version, so we avoid a fragmented discussion.

  
-		if (!innolux->backlight)

-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(innolux->backlight))
+   return PTR_ERR(innolux->backlight);
  
  	drm_panel_init(>base);

innolux->base.funcs = _panel_funcs;
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 1512ec4f3..d5450c9d9 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -329,14 +329,10 @@ static int sharp_panel_add(struct sharp_panel *sharp)
if (IS_ERR(sharp->supply))
return PTR_ERR(sharp->supply);
  
-	np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);

-   if (np) {
-   sharp->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   sharp->backlight = devm_of_find_backlight(np);
  
-		if (!sharp->backlight)

-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(sharp->backlight))
+   return PTR_ERR(sharp->backlight);
  
  	drm_panel_init(>base);

sharp->base.funcs = _panel_funcs;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index a6af3257f..db31d8268 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -273,14 +273,10 @@ static int sharp_nt_panel_add(struct sharp_nt_panel 
*sharp_nt)
gpiod_set_value(sharp_nt->reset_gpio, 0);
}
  
-	np = of_parse_phandle(dev->of_node, "backlight", 0);

-   if (np) {
-   sharp_nt->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   sharp_nt->backlight = devm_of_find_backlight(np);
  
-		if (!sharp_nt->backlight)

-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(sharp_nt->backlight))
+   return PTR_ERR(sharp_nt->backlight);
  
  	drm_panel_init(_nt->base);

sharp_nt->base.funcs = _nt_panel_funcs;


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

Re: [PATCH v16 06/10] drm/tinydrm: Call devres version of of_find_backlight

[Noralf Trønnes]

Den 16.01.2018 11.34, skrev Meghana Madhyastha:

Call devm_of_find_backlight (the devres version) instead of
of_find_backlight.

Signed-off-by: Meghana Madhyastha 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 3f9065fb5..4d8650bdc 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -191,7 +191,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
  
-	mipi->backlight = of_find_backlight(dev);

+   mipi->backlight = devm_of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
  


You've missed st7735r.

With that fixed:
Reviewed-by: Noralf Trønnes 

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

Re: [PATCH v16 05/10] video: backlight: Add devres versions of of_find_backlight

[Noralf Trønnes]

Den 16.01.2018 11.34, skrev Meghana Madhyastha:

Add devm_of_find_backlight and the corresponding release
function because some drivers use devres versions of functions
for acquiring device resources.

Signed-off-by: Meghana Madhyastha 


checkpatch complains:
-:26: WARNING: Block comments should align the * on each line
This one is text so might as well fix it:
-:29: WARNING: line over 80 characters

With that fixed:
Reviewed-by: Noralf Trønnes 


---
  drivers/video/backlight/backlight.c | 29 +
  include/linux/backlight.h   |  7 +++
  2 files changed, 36 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 7e4a5d77d..b3f76945f 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -620,6 +620,35 @@ struct backlight_device *of_find_backlight(struct device 
*dev)
  }
  EXPORT_SYMBOL(of_find_backlight);
  
+static void devm_backlight_put(void *data)

+{
+   backlight_put(data);
+}
+
+/**
+  * devm_of_find_backlight - Resource-managed of_find_backlight()
+  * @dev: Device
+  *
+  * Device managed version of of_find_backlight(). The reference on the 
backlight
+  * device is automatically dropped on driver detach.
+  */
+struct backlight_device *devm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *bd;
+   int ret;
+
+   bd = of_find_backlight(dev);
+   if (IS_ERR_OR_NULL(bd))
+   return bd;
+   ret = devm_add_action(dev, devm_backlight_put, bd);
+   if (ret) {
+   backlight_put(bd);
+   return ERR_PTR(ret);
+   }
+   return bd;
+}
+EXPORT_SYMBOL(devm_of_find_backlight);
+
  static void __exit backlight_class_exit(void)
  {
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 32ea510da..1d373f5a6 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -215,11 +215,18 @@ of_find_backlight_by_node(struct device_node *node)
  
  #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

  struct backlight_device *of_find_backlight(struct device *dev);
+struct backlight_device *devm_of_find_backlight(struct device *dev);
  #else
  static inline struct backlight_device *of_find_backlight(struct device *dev)
  {
return NULL;
  }
+
+static inline struct backlight_device *
+devm_of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
  #endif
  
  #endif


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

Re: [PATCH v16 04/10] drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight

[Noralf Trønnes]

Den 16.01.2018 11.34, skrev Meghana Madhyastha:

Remove tinydrm_of_find_backlight from tinydrm-helpers.c. We now have
a generic of_find_backlight defined in backlight.c. Let the callers
of tinydrm_of_find_backlight call of_find_backlight.

Signed-off-by: Meghana Madhyastha 


This patch needs rebasing, changes to mi0283qt.
You've missed st7735r.

I'd appreciate if you could also remove these from tinydrm/Kconfig:

    select BACKLIGHT_LCD_SUPPORT
    select BACKLIGHT_CLASS_DEVICE

It's an ugly hack that we don't need anymore thanks to your work!

With that fixed:
Reviewed-by: Noralf Trønnes 


---
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 --
  drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
  include/drm/tinydrm/tinydrm-helpers.h  |  2 --
  3 files changed, 2 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index 7326e1758..d1c3ce9ab 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -236,46 +236,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
  }
  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
  
-/**

- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
-   struct backlight_device *backlight;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (!np)
-   return NULL;
-
-   backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!backlight)
-   return ERR_PTR(-EPROBE_DEFER);
-
-   if (!backlight->props.brightness) {
-   backlight->props.brightness = backlight->props.max_brightness;
-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
-   }
-
-   return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
  #if IS_ENABLED(CONFIG_SPI)
  
  /**

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 674d40764..3f9065fb5 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -190,7 +191,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
  
-	mipi->backlight = tinydrm_of_find_backlight(dev);

+   mipi->backlight = of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
  
diff --git a/include/drm/tinydrm/tinydrm-helpers.h b/include/drm/tinydrm/tinydrm-helpers.h

index f54fae03e..0a4ddbc04 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -46,8 +46,6 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
  void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer 
*fb,
   struct drm_clip_rect *clip);
  
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev);

-
  size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len);
  bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);
  int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,


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

Re: [PATCH v16 03/10] video: backlight: Add of_find_backlight helper in backlight.c

[Noralf Trønnes]

Den 16.01.2018 11.33, skrev Meghana Madhyastha:

Add of_find_backlight, a helper function which is a generic version
of tinydrm_of_find_backlight that can be used by other drivers to avoid
repetition of code and simplify things.

Signed-off-by: Meghana Madhyastha 
---
Changes in v16:
-Add comment about brightness in of_find_backlight

  drivers/video/backlight/backlight.c | 40 +
  include/linux/backlight.h   | 19 ++
  2 files changed, 59 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 8049e7656..7e4a5d77d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -580,6 +580,46 @@ struct backlight_device *of_find_backlight_by_node(struct 
device_node *node)
  EXPORT_SYMBOL(of_find_backlight_by_node);
  #endif
  
+/**

+  * of_find_backlight - Get backlight device
+  * @dev: Device
+  *
+  * This function looks for a property named 'backlight' on the DT node
+  * connected to @dev and looks up the backlight device.
+  *
+  * Call backlight_put() to drop the reference on the backlight device.
+  * gpio_backlight uses brightness as power state during probe.


I was thinking the gpio_backlight issue to be a comment with the code, 
not the docs.

Isn't this sentence a bit confusing as part of the docs?

checkpatch complains:
-:21: WARNING: Block comments should align the * on each line
-:72: WARNING: Block comments should align the * on each line

Noralf.


+  *
+  * Returns:
+  * A pointer to the backlight device if found.
+  * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
+  * device is found.
+  * NULL if there's no backlight property.
+  */
+struct backlight_device *of_find_backlight(struct device *dev)
+{
+   struct backlight_device *bd = NULL;
+   struct device_node *np;
+
+   if (!dev)
+   return NULL;
+
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (np) {
+   bd = of_find_backlight_by_node(np);
+   of_node_put(np);
+   if (!bd)
+   return ERR_PTR(-EPROBE_DEFER);
+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;
+   }
+   }
+
+   return bd;
+}
+EXPORT_SYMBOL(of_find_backlight);
+
  static void __exit backlight_class_exit(void)
  {
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 7b6a9a2a3..32ea510da 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -160,6 +160,16 @@ static inline int backlight_disable(struct 
backlight_device *bd)
return backlight_update_status(bd);
  }
  
+/**

+  * backlight_put - Drop backlight reference
+  * @bd: the backlight device to put
+  */
+static inline void backlight_put(struct backlight_device *bd)
+{
+   if (bd)
+   put_device(>dev);
+}
+
  extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
@@ -203,4 +213,13 @@ of_find_backlight_by_node(struct device_node *node)
  }
  #endif
  
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

+struct backlight_device *of_find_backlight(struct device *dev);
+#else
+static inline struct backlight_device *of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
  #endif


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

Re: [PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Rob Herring]

On Tue, Jan 16, 2018 at 10:32 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Tuesday, 16 January 2018 16:35:26 EET Rob Herring wrote:
>> On Mon, Jan 15, 2018 at 5:46 PM, Frank Rowand wrote:
>> > On 01/15/18 12:29, Laurent Pinchart wrote:
>> >> On Monday, 15 January 2018 22:12:33 EET Frank Rowand wrote:
>> >>> On 01/15/18 11:22, Laurent Pinchart wrote:
>>  On Monday, 15 January 2018 21:12:44 EET Frank Rowand wrote:
>> > On 01/15/18 09:09, Rob Herring wrote:
>> >> On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
>> >>> The internal LVDS encoders now have their own DT bindings. Before
>> >>> switching the driver infrastructure to those new bindings, implement
>> >>> backward-compatibility through live DT patching.

[...]

>> >> How would you like to proceed ? I can try the manual approach again but
>> >> need information about how I could cleanly implement phandle allocation.
>> >> I will likely then run into other issues for which I might need help.
>> >
>> > Here are my first thoughts, based on 4.15-rc7:
>> >
>> > Question to Rob and Frank: should of_attach_node() be called directly, or
>> > should it be called indirectly by creating a change set that adds the
>> > node?
>> >
>> > Frank's off the cuff answer (but would like to think more about it): since
>> > the driver is modifying its own devicetree data, and thus no other entity
>> > needs to be notified about the changes, there is no need to add the
>> > complexity of using a change set.
>>
>> There's exactly 2 users outside of the DT core. That's generally a
>> sign of an API I'd like to make private.
>>
>> > The following is how of_attach_node() could be modified to dynamically
>> > create a phandle on request.
>>
>> How would this work for all the phandle references that need to be fixed up?
>
> As I know which properties contain a phandle that needs to be fixed up, my
> plan is to update those properties manually with the value of the newly
> allocated phandle.

That sounds like more low level, internal detail mucking with than
this current patch.

> What I need here is the ability to insert the following structure in the
> device tree:
>
> lvds@feb9 {
>compatible = "renesas,r8a7796-lvds"; (*)
>reg = <0 0xfeb9 0 0x14>; (*)
>clocks = < CPG_MOD 727>; (*)

I'm still of the opinion that all of this should be in a per SoC overlay.

>
>ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> lvds0_in: endpoint {
> remote-endpoint = <_out_lvds0>; (*)
> };
> };
> port@1 {
> reg = <1>;
> lvds0_out: endpoint {
> remote-endpoint = <_in>; (*)

Then do the fixup of just the remote-endpoint properties. While it
would be nice to say overlays are completely static, I'm guessing
that's not going to be the case. After all, we pretty much have
overlays because DT being static has limitations.

> };
> };
> };
> };
>
> with the node unit address and all properties marked with a (*) computed at
> runtime based on information extract from the device tree. Additionally I need
> phandles for the lvds0_in and lvds0_out nodes, and set the value of two
> properties in the tree with those phandles.
>
> I've used overlays as that was the only way I found to allocate phandles, but
> any other API will work for me as well.

I don't think drivers mucking with phandles directly to avoid another
overlay user is an improvement.

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #18 from Bill Fraser (bill.fra...@gmail.com) ---
Assuming that patch is meant to be applied directly to b8e2b019 without any
other patches, yep, that works for me.

I tried rebasing onto 4.15-rc8, and it did so without any merge conflicts, so
I'm going to try testing that as well next, and get back to you.

Thanks for looking at this, by the way!

-- 
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 v16 02/10] drm/tinydrm: Convert tinydrm_enable/disable_backlight to backlight_enable/disable

[Noralf Trønnes]

Den 16.01.2018 11.32, skrev Meghana Madhyastha:

Remove tinydrm_enable/disable_backlight and let the callers call the
more generic backlight_enable/disable helpers

Signed-off-by: Meghana Madhyastha 


This patch needs to be rebased on some recent changes to mipi-dbi.

Reviewed-by: Noralf Trønnes 


---
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 55 --
  drivers/gpu/drm/tinydrm/mipi-dbi.c |  4 +-
  include/drm/tinydrm/tinydrm-helpers.h  |  2 -
  3 files changed, 2 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bf96072d1..7326e1758 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -276,61 +276,6 @@ struct backlight_device *tinydrm_of_find_backlight(struct 
device *dev)
  }
  EXPORT_SYMBOL(tinydrm_of_find_backlight);
  
-/**

- * tinydrm_enable_backlight - Enable backlight helper
- * @backlight: Backlight device
- *
- * Returns:
- * Zero on success, negative error code on failure.
- */
-int tinydrm_enable_backlight(struct backlight_device *backlight)
-{
-   unsigned int old_state;
-   int ret;
-
-   if (!backlight)
-   return 0;
-
-   old_state = backlight->props.state;
-   backlight->props.state &= ~BL_CORE_FBBLANK;
-   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
- backlight->props.state);
-
-   ret = backlight_update_status(backlight);
-   if (ret)
-   DRM_ERROR("Failed to enable backlight %d\n", ret);
-
-   return ret;
-}
-EXPORT_SYMBOL(tinydrm_enable_backlight);
-
-/**
- * tinydrm_disable_backlight - Disable backlight helper
- * @backlight: Backlight device
- *
- * Returns:
- * Zero on success, negative error code on failure.
- */
-int tinydrm_disable_backlight(struct backlight_device *backlight)
-{
-   unsigned int old_state;
-   int ret;
-
-   if (!backlight)
-   return 0;
-
-   old_state = backlight->props.state;
-   backlight->props.state |= BL_CORE_FBBLANK;
-   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
- backlight->props.state);
-   ret = backlight_update_status(backlight);
-   if (ret)
-   DRM_ERROR("Failed to disable backlight %d\n", ret);
-
-   return ret;
-}
-EXPORT_SYMBOL(tinydrm_disable_backlight);
-
  #if IS_ENABLED(CONFIG_SPI)
  
  /**

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index aa6b6ce56..8c2cb1cf2 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -291,7 +291,7 @@ void mipi_dbi_pipe_enable(struct drm_simple_display_pipe 
*pipe,
if (fb)
fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
  
-	tinydrm_enable_backlight(mipi->backlight);

+   backlight_enable(mipi->backlight);
  }
  EXPORT_SYMBOL(mipi_dbi_pipe_enable);
  
@@ -330,7 +330,7 @@ void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe)

mipi->enabled = false;
  
  	if (mipi->backlight)

-   tinydrm_disable_backlight(mipi->backlight);
+   backlight_disable(mipi->backlight);
else
mipi_dbi_blank(mipi);
  }
diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
b/include/drm/tinydrm/tinydrm-helpers.h
index d554ded60..f54fae03e 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -47,8 +47,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct 
drm_framebuffer *fb,
   struct drm_clip_rect *clip);
  
  struct backlight_device *tinydrm_of_find_backlight(struct device *dev);

-int tinydrm_enable_backlight(struct backlight_device *backlight);
-int tinydrm_disable_backlight(struct backlight_device *backlight);
  
  size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len);

  bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);


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

Re: [PATCH v16 01/10] video: backlight: Add helpers to enable and disable backlight

[Noralf Trønnes]

Den 16.01.2018 11.31, skrev Meghana Madhyastha:

Add helper functions backlight_enable and backlight_disable to
enable/disable a backlight device. These helper functions can
then be used by different drm and tinydrm drivers to avoid
repetition of code and also to enforce a uniform and consistent
way to enable/disable a backlight device.

Signed-off-by: Meghana Madhyastha 


checkpatch complains:
-:23: WARNING: Block comments should align the * on each line
-:45: ERROR: trailing whitespace

With that fixed:
Reviewed-by: Noralf Trønnes 


---
  include/linux/backlight.h | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index af7003548..7b6a9a2a3 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -130,6 +130,36 @@ static inline int backlight_update_status(struct 
backlight_device *bd)
return ret;
  }
  
+/**

+  * backlight_enable - Enable backlight
+  * @bd: the backlight device to enable
+  */
+static inline int backlight_enable(struct backlight_device *bd)
+{
+   if (!bd)
+   return 0;
+
+   bd->props.power = FB_BLANK_UNBLANK;
+   bd->props.state &= ~BL_CORE_FBBLANK;
+
+   return backlight_update_status(bd);
+}
+
+/**
+  * backlight_disable - Disable backlight
+  * @bd: the backlight device to disable
+  */
+static inline int backlight_disable(struct backlight_device *bd)
+{
+   if (!bd)
+   return 0;
+   
+   bd->props.power = FB_BLANK_POWERDOWN;
+   bd->props.state |= BL_CORE_FBBLANK;
+
+   return backlight_update_status(bd);
+}
+
  extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);


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

Re: [PATCH] [v2] drm/i915: use static const array for PICK macro

[Arnd Bergmann]

On Mon, Dec 11, 2017 at 7:40 PM, Chris Wilson  wrote:
> Quoting Chris Wilson (2017-12-11 12:51:42)
>> Quoting Arnd Bergmann (2017-12-11 12:46:22)
>> > v2: rebased after a1986f4174a4 ("drm/i915: Remove unnecessary PORT3 
>> > definition.")
>> > ---
>> >  drivers/gpu/drm/i915/i915_reg.h | 18 +-
>> >  1 file changed, 9 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 09bf043c1c2e..36f4408503e1 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -139,7 +139,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>> > return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
>> >  }
>> >
>> > -#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>> > +#define _PICK(__index, ...) ({static const u32 __arr[] = { __VA_ARGS__ }; 
>> > __arr[__index];})
>>
>> Is gcc smart enough for
>> if (__builtin_context_p(__index)) {
>> ((const u32 []){ __VA_ARGS__ })[__index];
>> } else {
>> static const u32 __arr[] = { __VA_ARGS__ };
>> __arr[__index];
>> }
>> ?
>
> Not really, we don't have enough constants for it to make a substantial
> difference:
>
> add/remove: 1/0 grow/shrink: 3/5 up/down: 617/-604 (13)
> Function old new   delta
> cnl_ddi_vswing_program.isra- 574+574
> bxt_ddi_phy_is_enabled   220 241 +21
> bxt_ddi_phy_set_signal_level 537 556 +19
> i9xx_get_pipe_config14741477  +3
> bxt_ddi_phy_verify_state 411 408  -3
> _bxt_ddi_phy_init956 950  -6
> vlv_display_power_well_init  470 461  -9
> bxt_ddi_pll_get_hw_state 774 762 -12
> cnl_ddi_vswing_sequence 1166 592-574
> Total: Before=13461532, After=13461545, chg +0.00%
>
> Of particular note the size of __arr[] is not reduced, so gcc is already
> eliminating the static[] for constant index, or not eliminating the
> redundant branch here.

I noticed we never concluded here. Did you see anything wrong with my
workaround in the end or could we just apply it to avoid the stack
size regression?

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

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

[bugzilla-daemon]

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

--- Comment #4 from Vedran Miletić  ---
Actually, this seems to affect the Kaveri system from bug 99353 as well. I'll
test 4.15-rc ASAP.

-- 
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 v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Rob,

On Tuesday, 16 January 2018 16:35:26 EET Rob Herring wrote:
> On Mon, Jan 15, 2018 at 5:46 PM, Frank Rowand wrote:
> > On 01/15/18 12:29, Laurent Pinchart wrote:
> >> On Monday, 15 January 2018 22:12:33 EET Frank Rowand wrote:
> >>> On 01/15/18 11:22, Laurent Pinchart wrote:
>  On Monday, 15 January 2018 21:12:44 EET Frank Rowand wrote:
> > On 01/15/18 09:09, Rob Herring wrote:
> >> On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
> >>> The internal LVDS encoders now have their own DT bindings. Before
> >>> switching the driver infrastructure to those new bindings, implement
> >>> backward-compatibility through live DT patching.
> >> 
> >> Uhh, we just got rid of TI's patching and now adding this one. I
> >> guess
> >>> 
> >>> Let me first answer the question that you ask later.  You ask "Can we
> >>> work on this together to find a solution that would suit us both ?"
> >>> 
> >>> My answer to that is emphatically YES.  I will definitely work with you
> >>> to try to find a good solution.
> >> 
> >> \o/
> >> 
> > Please no.  What we just got rid of was making it difficult for me to
> > make changes to the overlay infrastructure.  There are issues with
> > overlays that need to be fixed before overlays become really usable.
> > I am about to propose the next change, which involves removing a
> > chunk of code that I will not be able to remove if this patch is
> > accepted (the proposal is awaiting me collecting some data about
> > the impact of the change, which I expect to complete this week).
> >>> 
> >>> I should have thought just a little bit more before I hit send.  The
> >>> situation is even worse than I wrote.  One of the next steps (in
> >>> addition to what I wrote about above) is to change the overlay apply
> >>> function to accept a flattened device tree (FDT), not an expanded
> >>> device tree.  In this changed model, the unflattened overlay is
> >>> not available to be modified before it is applied.
> >> 
> >> That makes sense if we consider overlays to be immutable objects that we
> >> apply without offering a way to modify them. I won't challenge that API
> >> decision, as my use of an overlay here is a bit of a hack indeed.
> >> 
> >>> It is important for the devicetree infrastructure to have ownership
> >>> of the FDT that is used to create the unflattened tree.  (Notice
> >>> that in the proposed patch, rcar_du_of_get_overlay() follows the
> >>> TI example of doing a kmemdup of the blob (FDT), then uses the
> >>> copy for the unflatten.  The kmemdup() in this case is to create
> >>> a persistent copy of the FDT.)  The driver having ownership of
> >>> this copy, and having the ability to free it is one of the many
> >>> problems with the current overlay implementation.
> >> 
> >> Yes, that's something I've identified as well. Lots of work has been done
> >> to clean up the OF core and we're clearly not done yet. I'm happy to see
> >> all the improvements you're working on.
> >> 
> > Can you please handle both the old and new bindings through driver
> > code instead?
>  
>  I could, but it would be pointless. The point here is to allow cleanups
>  in the driver. The LVDS encoder handling code is very intrusive in its
>  current form and I need to get rid of it. There would be zero point in
>  moving to the new infrastructure, as the main point is to get rid of
>  the old code which prevents moving forward. As a consequence that would
>  block new boards from receiving proper upstream support. An easy option
>  is to break backward compatibility. I'm personally fine with that, but
>  I assume other people would complain :-)
>  
>  I can, on the other hand, work with you to see how live DT patching
>  could be implemented in this driver without blocking your code. When
>  developing this patch series I start by patching the device tree
>  manually without relying on overlays at all, but got blocked by the
>  fact that I need to allocate phandles for new nodes I create. If there
>  was an API to allocate an unused phandle I could avoid using the
>  overlay infrastructure at all. Or there could be other
> >>> 
> >>> It seems reasonable to provide a way to autogenerate a phandle (if
> >>> requested) by the devicetree code that creates a new node.  Were you
> >>> using a function from drivers/of/dynamic.c to create the node?
> >> 
> >> Not to allocate the node, no. I allocated the device_node structure
> >> manually with kzalloc(), and inserted it in the device tree with
> >> of_attach_node(). Is that the right approach ? I haven't been able to
> >> test the code as I stopped when I realized I couldn't allocate phandles.
> >> 
>  options I'm not thinking of as I don't know what the changes you're
>  working on are. Can we work on this together to find a solution that
>  would suit us both ?
> >>> 
> >>> Again, yes, I would be 

Re: [PATCH v2 2/2] drm: rcar-du: lvds: Fix LVDS startup on R-Car gen2

[Laurent Pinchart]

Hi Sergei,

On Saturday, 13 January 2018 11:33:55 EET Sergei Shtylyov wrote:
> On 1/13/2018 2:10 AM, Laurent Pinchart wrote:
> > From: Sergei Shtylyov 
> > 
> > According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS
> > must be enabled and the bias crcuit enabled after the LVDS I/O pins are
> > enabled, not before. Fix the gen2 LVDS startup sequence accordingly.
> > 
> > While at it, also fix the comment preceding the first LVDCR0 write that
> > still talks about hardcoding the LVDS mode 0.
> 
> Please do this in a separate commit then...

The reason I added it here is that I think we don't need patch 1/2 from this 
series, and I found a bit overkill to split a comment fix to a separate patch 
when we have a patch that touches the code around the comment.

> > Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
> 
> You forgot to specify the other commit this one fixes -- I mean the comment
> fix.

Do we need to for a comment update ? It doesn't affect fix the behaviour of 
the driver or device, and I'd thus prefer to avoid giving the wrong impression 
that this patch fixes an bug introduced in a previous commit, otherwise it 
might end up being backported unnecessarily.

> > Signed-off-by: Sergei Shtylyov 
> > Reviewed-by: Laurent Pinchart 
> > [Set the mode and input at the same time as the BEN and LVEN bits]
> > Tested-by: Laurent Pinchart 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >   drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 14 +++---
> >   1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > Hi Sergei,
> > 
> > For your convenience (and if you agree with bundling mode setup with the
> > first write as explained in my review of patch 1/2), here's the updated
> > version of patch 2/2 that I have taken in my development branch. If
> > you're fine with it I'll keep it, otherwise we can continue the review
> > discussion.
> 
> As I said, I don't know how to interpret the note 3 in either manual.

As explained in my latest reply to patch 1/2, my understanding is that the 
parameters can be programmed at any time before step 6. The fact that the 
current code works seems to confirm that interpretation. We could ask Renesas 
for a confirmation if you want.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Laurent Pinchart]

Hi Sergei,

On Saturday, 13 January 2018 11:25:31 EET Sergei Shtylyov wrote:
> On 1/13/2018 1:15 AM, Laurent Pinchart wrote:
> >>> According to the latest revisions of the R-Car gen3 manual, the LVDS
> >>> mode must be set before the LVDS I/O pins are enabled, not after --  fix 
> >>> the gen3 LVDS startup sequence accordingly...
> >>> 
> >>> While  at it,  also fix the comment  preceding the first LVDCR0 write in
> >>> the R-Car gen2 startup code that still talks about hardcoding the LVDS
> >>> mode 0...
> >> 
> >> How about fixing that in patch 2/2 that touches the Gen2 initialization
> >> sequence ? I think I'd even go as far as squashing both patches, I don't
> >> think there's a need to split them.
> >> 
> >>> Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode
> >>> selection")
> >>> Signed-off-by: Sergei Shtylyov 
> >> 
> >> Is this really needed ? Does it fix a problem you've experienced, or is
> >> it theoretical only ? The mode shouldn't matter before the LVDS internal
> >> logic is turned on. Unless there's a real issue I'm not sure we should
> >> make the code more complex.
> > 
> > Furthermore the datasheet states
> > 
> > "3. This refers to settings other than those that are concerned with
> > LVDS-IF startup. These items may be set while waiting for the conditions
> > of step 6 to be met."
> 
> Ah, I hadn't paid much attention to this note. Howeve, it seems quite
> vague to me... and there's no condition in step 6. ;-)

Lots of bits and pieces are lost in translation yes :-)

> > Doesn't this mean that the mode and input selector don't have to be set as
> > the very first step, but can be programmed at any point before starting
> > the LVDS encoder through the PWD bit (on Gen3) or the PLLON bit (on Gen2)
> > ?
> 
> Frankly speaking, I don't know how to interpret that note...

My understanding is that the parameters can be programmed at any time before 
step 6. The fact that the current code works seems to confirm that 
interpretation. We could ask Renesas for a confirmation if you want.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Geert Uytterhoeven]

Hi Rob,

On Tue, Jan 16, 2018 at 4:08 PM, Rob Herring  wrote:
> On Tue, Jan 16, 2018 at 2:56 AM, Geert Uytterhoeven
>  wrote:
>> On Mon, Jan 15, 2018 at 7:01 PM, Laurent Pinchart
>>  wrote:
>>> On Monday, 15 January 2018 19:09:53 EET Rob Herring wrote:
 On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
 > The internal LVDS encoders now have their own DT bindings. Before
 > switching the driver infrastructure to those new bindings, implement
 > backward-compatibility through live DT patching.

 Uhh, we just got rid of TI's patching and now adding this one. I guess
 it's necessary, but I'd like to know how long we need to keep this?
>>>
>>> That's a good question. How long are we supposed to keep DT backward
>>> compatibility for ? I don't think there's a one-size-fits-them-all answer to
>>> this question. Geert, any opinion ? How long do you plan to keep the CPG
>>> (clocks) DT backward compatibility for instance ?
>>
>> Good question indeed...
>>
>> It's not just CPG/MSSR. Over the years we also added or changed APMU (SMP),
>> SYSC (power domains), RST (mode pins), CMT (timers), ..., all of which have
>> some sort of compatibility support in the kernel.
>>
>> Hence to avoid having to remember the kernel versions that dropped backwards
>> compatibility for each of the above components, I was thinking about an
>> R-Car Gen2 DT Flag Day.
>
> There's probably also DT changes that enable new features folks would
> want/need? Or maybe carrying for some number of LTS releases is
> enough.

Sure. If you want new features, you have to upgrade the DTB anyway.
Backwards compatibility is about keeping features without updating DTB.

>> However, that was before I learned about your plans for LVDS (it seems every
>> kernel release we learn about something new, postponing the flag day ;-).
>> And now I'm quite sure we'll have another change in the future (DU per
>> channel device nodes)...
>>
>> About using DT fixups to implement backwards compatibility: I did my share
>> of thinking and experimenting with DT fixups (see e.g. "[PATCH/RFC 0/1]
>> soc: renesas: Add DT fixup code for backwards compatibility"
>> (https://www.spinics.net/lists/linux-renesas-soc/msg04305.html).
>> DT fixups are hard to implement right, and not everything can be done
>> that way.  Hence in the end, none of this was ever used upstream, and
>> everything was handled in C...
>
> In an ideal world, we would have some tool:
>
> dt-diff-to-overlay old.dts new.dts > my-fixup-overlay.dts
>
> And then in the kernel have infrastructure such you just declare match
> tables with overlays to apply:
>
> struct of_device_id dt_match[] = {
>   {
> .compatible = "vendor,board",
>   },
>   {},
> };
> DT_FIXUP(dt_match, my-fixup-overlay.dtbo);
>
> But maybe I'm dreaming...

Really?

We might as well include the latest DTB in the kernel, and use that if
machine_is_compatible("vendor,board")? ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/ttm: Allow page allocations w/o triggering OOM..

[Christian König]

Am 16.01.2018 um 16:18 schrieb Andrey Grodzovsky:

This to allow drivers to choose to avoid OOM invocation and handle
page allocation failures instead.

v2:
Remove extra new lines.

Signed-off-by: Andrey Grodzovsky 


Reviewed-by: Christian König  for the series.


---
  drivers/gpu/drm/ttm/ttm_bo.c |  3 +++
  drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 ++
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +++
  drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--
  include/drm/ttm/ttm_bo_driver.h  |  4 
  5 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2eb71ff..f32aab1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -234,6 +234,9 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
  
+	if (bdev->no_retry)

+   page_flags |= TTM_PAGE_FLAG_NO_RETRY;
+
switch (bo->type) {
case ttm_bo_type_device:
if (zero_alloc)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0eab24e..f34c843 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -741,6 +741,9 @@ static int ttm_page_pool_get_pages(struct ttm_page_pool 
*pool,
if (ttm_flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
  
+		if (ttm_flags & TTM_PAGE_FLAG_NO_RETRY)

+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
/* ttm_alloc_new_pages doesn't reference pool so we can run
 * multiple requests in parallel.
 **/
@@ -893,6 +896,9 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
if (flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
  
+		if (flags & TTM_PAGE_FLAG_NO_RETRY)

+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
if (flags & TTM_PAGE_FLAG_DMA32)
gfp_flags |= GFP_DMA32;
else
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..6949ef7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -920,6 +920,9 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt 
*ttm_dma, bool huge)
gfp_flags &= ~__GFP_COMP;
}
  
+	if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)

+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
return gfp_flags;
  }
  
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c

index 5a046a3..9e4d43d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -301,7 +301,11 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
swap_space = swap_storage->f_mapping;
  
  	for (i = 0; i < ttm->num_pages; ++i) {

-   from_page = shmem_read_mapping_page(swap_space, i);
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+   from_page = shmem_read_mapping_page_gfp(swap_space, i, 
gfp_mask);
+
if (IS_ERR(from_page)) {
ret = PTR_ERR(from_page);
goto out_err;
@@ -350,10 +354,15 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
swap_space = swap_storage->f_mapping;
  
  	for (i = 0; i < ttm->num_pages; ++i) {

+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+
from_page = ttm->pages[i];
if (unlikely(from_page == NULL))
continue;
-   to_page = shmem_read_mapping_page(swap_space, i);
+
+   to_page = shmem_read_mapping_page_gfp(swap_space, i, gfp_mask);
if (IS_ERR(to_page)) {
ret = PTR_ERR(to_page);
goto out_err;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 94064b1..9b417eb 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -86,6 +86,7 @@ struct ttm_backend_func {
  #define TTM_PAGE_FLAG_ZERO_ALLOC  (1 << 6)
  #define TTM_PAGE_FLAG_DMA32   (1 << 7)
  #define TTM_PAGE_FLAG_SG  (1 << 8)
+#define TTM_PAGE_FLAG_NO_RETRY(1 << 9)
  
  enum ttm_caching_state {

tt_uncached,
@@ -556,6 +557,7 @@ struct ttm_bo_global {
   * @dev_mapping: A pointer to the struct address_space representing the
   * device address space.
   * @wq: Work queue structure for the delayed delete workqueue.
+ * @no_retry: Don't retry 

[PATCH v2 1/2] drm/ttm: Allow page allocations w/o triggering OOM..

[Andrey Grodzovsky]

This to allow drivers to choose to avoid OOM invocation and handle
page allocation failures instead.

v2:
Remove extra new lines.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/ttm/ttm_bo.c |  3 +++
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 ++
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +++
 drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--
 include/drm/ttm/ttm_bo_driver.h  |  4 
 5 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2eb71ff..f32aab1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -234,6 +234,9 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
 
+   if (bdev->no_retry)
+   page_flags |= TTM_PAGE_FLAG_NO_RETRY;
+
switch (bo->type) {
case ttm_bo_type_device:
if (zero_alloc)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0eab24e..f34c843 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -741,6 +741,9 @@ static int ttm_page_pool_get_pages(struct ttm_page_pool 
*pool,
if (ttm_flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
 
+   if (ttm_flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
/* ttm_alloc_new_pages doesn't reference pool so we can run
 * multiple requests in parallel.
 **/
@@ -893,6 +896,9 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
if (flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
 
+   if (flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
if (flags & TTM_PAGE_FLAG_DMA32)
gfp_flags |= GFP_DMA32;
else
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..6949ef7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -920,6 +920,9 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt 
*ttm_dma, bool huge)
gfp_flags &= ~__GFP_COMP;
}
 
+   if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
return gfp_flags;
 }
 
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5a046a3..9e4d43d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -301,7 +301,11 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
swap_space = swap_storage->f_mapping;
 
for (i = 0; i < ttm->num_pages; ++i) {
-   from_page = shmem_read_mapping_page(swap_space, i);
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+   from_page = shmem_read_mapping_page_gfp(swap_space, i, 
gfp_mask);
+
if (IS_ERR(from_page)) {
ret = PTR_ERR(from_page);
goto out_err;
@@ -350,10 +354,15 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
swap_space = swap_storage->f_mapping;
 
for (i = 0; i < ttm->num_pages; ++i) {
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+
from_page = ttm->pages[i];
if (unlikely(from_page == NULL))
continue;
-   to_page = shmem_read_mapping_page(swap_space, i);
+
+   to_page = shmem_read_mapping_page_gfp(swap_space, i, gfp_mask);
if (IS_ERR(to_page)) {
ret = PTR_ERR(to_page);
goto out_err;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 94064b1..9b417eb 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -86,6 +86,7 @@ struct ttm_backend_func {
 #define TTM_PAGE_FLAG_ZERO_ALLOC  (1 << 6)
 #define TTM_PAGE_FLAG_DMA32   (1 << 7)
 #define TTM_PAGE_FLAG_SG  (1 << 8)
+#define TTM_PAGE_FLAG_NO_RETRY(1 << 9)
 
 enum ttm_caching_state {
tt_uncached,
@@ -556,6 +557,7 @@ struct ttm_bo_global {
  * @dev_mapping: A pointer to the struct address_space representing the
  * device address space.
  * @wq: Work queue structure for the delayed delete workqueue.
+ * @no_retry: Don't retry allocation if it fails
  *
  */
 
@@ -592,6 +594,8 @@ struct ttm_bo_device {
struct delayed_work wq;
 
   

[PATCH v2 2/2] drm/amdgpu: Use new TTM flag to avoid OOM triggering.

[Andrey Grodzovsky]

Avoid OOM on syatem pages allocations.

v2:
Remove modeprobe parameter, making this behaviour the only option.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 5c4c3e0..b4dc3bd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -420,6 +420,10 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
 #endif
 
bo->tbo.bdev = >mman.bdev;
+
+   /* We opt to avoid OOM on system pages allocations */
+   bo->tbo.bdev->no_retry = true;
+
amdgpu_ttm_placement_from_domain(bo, domain);
 
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
-- 
2.7.4

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #18 from Bong Cosca  ---
The only saving grace with all this display corruption is that there's a mouse
cursor when I use amdgpu with 2D acceleration disabled.

-- 
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 v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Rob Herring]

On Tue, Jan 16, 2018 at 2:56 AM, Geert Uytterhoeven
 wrote:
> Hi Laurent,
>
> On Mon, Jan 15, 2018 at 7:01 PM, Laurent Pinchart
>  wrote:
>> On Monday, 15 January 2018 19:09:53 EET Rob Herring wrote:
>>> On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
>>> > The internal LVDS encoders now have their own DT bindings. Before
>>> > switching the driver infrastructure to those new bindings, implement
>>> > backward-compatibility through live DT patching.
>>>
>>> Uhh, we just got rid of TI's patching and now adding this one. I guess
>>> it's necessary, but I'd like to know how long we need to keep this?
>>
>> That's a good question. How long are we supposed to keep DT backward
>> compatibility for ? I don't think there's a one-size-fits-them-all answer to
>> this question. Geert, any opinion ? How long do you plan to keep the CPG
>> (clocks) DT backward compatibility for instance ?
>
> Good question indeed...
>
> It's not just CPG/MSSR. Over the years we also added or changed APMU (SMP),
> SYSC (power domains), RST (mode pins), CMT (timers), ..., all of which have
> some sort of compatibility support in the kernel.
>
> Hence to avoid having to remember the kernel versions that dropped backwards
> compatibility for each of the above components, I was thinking about an
> R-Car Gen2 DT Flag Day.

There's probably also DT changes that enable new features folks would
want/need? Or maybe carrying for some number of LTS releases is
enough.

> However, that was before I learned about your plans for LVDS (it seems every
> kernel release we learn about something new, postponing the flag day ;-).
> And now I'm quite sure we'll have another change in the future (DU per
> channel device nodes)...
>
> About using DT fixups to implement backwards compatibility: I did my share
> of thinking and experimenting with DT fixups (see e.g. "[PATCH/RFC 0/1]
> soc: renesas: Add DT fixup code for backwards compatibility"
> (https://www.spinics.net/lists/linux-renesas-soc/msg04305.html).
> DT fixups are hard to implement right, and not everything can be done
> that way.  Hence in the end, none of this was ever used upstream, and
> everything was handled in C...

In an ideal world, we would have some tool:

dt-diff-to-overlay old.dts new.dts > my-fixup-overlay.dts

And then in the kernel have infrastructure such you just declare match
tables with overlays to apply:

struct of_device_id dt_match[] = {
  {
.compatible = "vendor,board",
  },
  {},
};
DT_FIXUP(dt_match, my-fixup-overlay.dtbo);

But maybe I'm dreaming...

> So I'm wondering if it would be easier if you would implement backwards
> compatibility in C, using different compatible values for the new bindings?
> I.e. switch from "renesas,du-r8a77*" to "renesas,r8a77*-du" +
> "renesas,r8a77*-lvds"?
> That way it also becomes very clear that there are old and new bindings,
> and that there is backwards compatibility code for the old binding.
>
> I know you're aware (the rest of the audience may not be) that the LVDS
> part is not the only separate hardware block current unified in the single
> DU node: each DU channel has its own hardware block.  Perhaps you can also
> bite the bullet and have a single device node per DT channel, allowing
> Runtime PM for DU channels?
> Of course you have to tie channels together using a "companion" (cfr. USB)
> or "renesas,bonding" (cfr. DRIF) property (unfortunately I learned about
> the former only after the latter was already established).
>
> Finally, implementing backwards compatibility support by DT fixup using
> overlays may complicate backporting to LTSI kernels, due to the dependency
> on DT overlays, which were reworked lately.
>
>>> > --- a/drivers/gpu/drm/rcar-du/Kconfig
>>> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
>>> > @@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
>>> > bool "R-Car DU LVDS Encoder Support"
>>> > depends on DRM_RCAR_DU
>>> > select DRM_PANEL
>>> > +   select OF_FLATTREE
>>> > +   select OF_OVERLAY
>>>
>>> OF_OVERLAY should probably select OF_FLATTREE. I guess in theory, we
>>> could have an overlay from a non-FDT source...
>
> Currently the select is needed for of_fdt_unflatten_tree() only, which is
> not used by the core OF_OVERLAY code. So you could build an overlay in
> memory yourself, and pass that, without using of_fdt_unflatten_tree().
> But that is going to change if I read Frank's reponse well?

Yes, it's currently a 4 or so step process that we plan to make a single call.

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

Re: [PATCH] [RESEND] gpu: ipu-v3: prg: avoid possible array underflow

[Philipp Zabel]

Hi Arnd,

On Tue, 2018-01-16 at 15:31 +0100, Arnd Bergmann wrote:
> gcc-8 reports that we access an array with a negative index
> in an error case:
> 
> drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
> drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below 
> array bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]
> 
> This moves the range check in front of the dereference.
> 
> Signed-off-by: Arnd Bergmann 
> 
> Originally sent on Dec 4, 2017. No reply, so resending unchanged.

Thank you, applied to imx-drm/fixes.

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

[PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures

[Arnd Bergmann]

The two functions pass a partially initialized structure back to the
caller after a memset() on the destination.

This is not entirely well-defined, most compilers are sensible enough
to either keep the zero-initialization for the uninitialized members,
but gcc-4.4 does not, and it warns about this:

drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_sdvo_find_best_pll':
drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_lvds_find_best_pll':
drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used 
uninitialized in this function
drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used 
uninitialized in this function

This adds an initialization at declaration time to avoid the warning
and make it well-defined on all compiler versions.

Signed-off-by: Arnd Bergmann 
---
Originally submitted on Sep 15, 2017, but got no reply. Resending unchanged.
---
 drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index 0fff269d3fe6..b49fe79c3f44 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -134,7 +134,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
gma_limit_t *limit,
struct drm_crtc *crtc, int target,
int refclk, struct gma_clock_t *best_clock)
 {
-   struct gma_clock_t clock;
+   struct gma_clock_t clock = {};
u32 target_vco, actual_freq;
s32 freq_error, min_error = 10;
 
@@ -191,7 +191,7 @@ static bool mrst_lvds_find_best_pll(const struct 
gma_limit_t *limit,
struct drm_crtc *crtc, int target,
int refclk, struct gma_clock_t *best_clock)
 {
-   struct gma_clock_t clock;
+   struct gma_clock_t clock = {};
int err = target;
 
memset(best_clock, 0, sizeof(*best_clock));
-- 
2.9.0

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

Re: [PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

[Arnd Bergmann]

On Tue, Dec 5, 2017 at 6:01 PM, Harry Wentland  wrote:
>>
>
> Thanks, Arnd. This is what I was missing. I'll take another look.
>
> It would still work without KCOV, although I agree that's not ideal by any 
> means.

Any update on this? I see building DCN1.0 with KCOV using gcc-8 is still broken.

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

Re: [PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Rob Herring]

On Mon, Jan 15, 2018 at 5:46 PM, Frank Rowand  wrote:
> On 01/15/18 12:29, Laurent Pinchart wrote:
>> Hi Frank,
>>
>> On Monday, 15 January 2018 22:12:33 EET Frank Rowand wrote:
>>> On 01/15/18 11:22, Laurent Pinchart wrote:
 On Monday, 15 January 2018 21:12:44 EET Frank Rowand wrote:
> On 01/15/18 09:09, Rob Herring wrote:
>> +Frank
>>
>> On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
>>> The internal LVDS encoders now have their own DT bindings. Before
>>> switching the driver infrastructure to those new bindings, implement
>>> backward-compatibility through live DT patching.
>>
>> Uhh, we just got rid of TI's patching and now adding this one. I guess
>>>
>>> Let me first answer the question that you ask later.  You ask "Can we work
>>> on this together to find a solution that would suit us both ?"
>>>
>>> My answer to that is emphatically YES.  I will definitely work with you to
>>> try to find a good solution.
>>
>> \o/
>>
> Please no.  What we just got rid of was making it difficult for me to
> make changes to the overlay infrastructure.  There are issues with
> overlays that need to be fixed before overlays become really usable.
> I am about to propose the next change, which involves removing a
> chunk of code that I will not be able to remove if this patch is
> accepted (the proposal is awaiting me collecting some data about
> the impact of the change, which I expect to complete this week).
>>>
>>> I should have thought just a little bit more before I hit send.  The
>>> situation is even worse than I wrote.  One of the next steps (in
>>> addition to what I wrote about above) is to change the overlay apply
>>> function to accept a flattened device tree (FDT), not an expanded
>>> device tree.  In this changed model, the unflattened overlay is
>>> not available to be modified before it is applied.
>>
>> That makes sense if we consider overlays to be immutable objects that we 
>> apply
>> without offering a way to modify them. I won't challenge that API decision, 
>> as
>> my use of an overlay here is a bit of a hack indeed.
>>
>>> It is important for the devicetree infrastructure to have ownership
>>> of the FDT that is used to create the unflattened tree.  (Notice
>>> that in the proposed patch, rcar_du_of_get_overlay() follows the
>>> TI example of doing a kmemdup of the blob (FDT), then uses the
>>> copy for the unflatten.  The kmemdup() in this case is to create
>>> a persistent copy of the FDT.)  The driver having ownership of
>>> this copy, and having the ability to free it is one of the many
>>> problems with the current overlay implementation.
>>
>> Yes, that's something I've identified as well. Lots of work has been done to
>> clean up the OF core and we're clearly not done yet. I'm happy to see all the
>> improvements you're working on.
>>
> Can you please handle both the old and new bindings through driver
> code instead?

 I could, but it would be pointless. The point here is to allow cleanups in
 the driver. The LVDS encoder handling code is very intrusive in its
 current form and I need to get rid of it. There would be zero point in
 moving to the new infrastructure, as the main point is to get rid of the
 old code which prevents moving forward. As a consequence that would block
 new boards from receiving proper upstream support. An easy option is to
 break backward compatibility. I'm personally fine with that, but I assume
 other people would complain :-)

 I can, on the other hand, work with you to see how live DT patching could
 be implemented in this driver without blocking your code. When developing
 this patch series I start by patching the device tree manually without
 relying on overlays at all, but got blocked by the fact that I need to
 allocate phandles for new nodes I create. If there was an API to allocate
 an unused phandle I could avoid using the overlay infrastructure at all.
 Or there could be other
>>>
>>> It seems reasonable to provide a way to autogenerate a phandle (if
>>> requested) by the devicetree code that creates a new node.  Were you using
>>> a function from drivers/of/dynamic.c to create the node?
>>
>> Not to allocate the node, no. I allocated the device_node structure manually
>> with kzalloc(), and inserted it in the device tree with of_attach_node(). Is
>> that the right approach ? I haven't been able to test the code as I stopped
>> when I realized I couldn't allocate phandles.
>>
 options I'm not thinking of as I don't know what the changes you're
 working on are. Can we work on this together to find a solution that
 would suit us both ?
>>>
>>> Again, yes, I would be glad to work with you on this.
>>
>> How would you like to proceed ? I can try the manual approach again but need
>> information about how I could cleanly implement phandle allocation. I will
>> likely 

[PATCH] [RESEND] gpu: ipu-v3: prg: avoid possible array underflow

[Arnd Bergmann]

gcc-8 reports that we access an array with a negative index
in an error case:

drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below array 
bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]

This moves the range check in front of the dereference.

Signed-off-by: Arnd Bergmann 

Originally sent on Dec 4, 2017. No reply, so resending unchanged.
---
 drivers/gpu/ipu-v3/ipu-prg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 067365c733c6..0bcb935e525c 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -250,7 +250,7 @@ void ipu_prg_channel_disable(struct ipuv3_channel *ipu_chan)
struct ipu_prg_channel *chan = >chan[prg_chan];
u32 val;
 
-   if (!chan->enabled || prg_chan < 0)
+   if (prg_chan < 0 || !chan->enabled)
return;
 
pm_runtime_get_sync(prg->dev);
-- 
2.9.0

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

Re: [PATCH 05/10] ARM: dts: porter: Fix HDMI output routing

[Simon Horman]

On Mon, Jan 15, 2018 at 10:25:34AM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Monday, 15 January 2018 09:56:03 EET Simon Horman wrote:
> > On Fri, Jan 12, 2018 at 02:58:53AM +0200, Laurent Pinchart wrote:
> > > The HDMI encoder is connected to the RGB output of the DU, which is
> > > port@0, not port@1. Fix the incorrect DT description.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > 
> > Should this have the following tag?
> > 
> > Fixes: c5af8a4248d3 ("ARM: dts: porter: add DU DT support")
> 
> That would make sense, yes.
> 
> > If so, is it a fix to apply for v4.15 or a more regular patch
> > to apply for v4.16?
> 
> I believe we can wait for v4.16. HDMI output works on Porter at the
> moment due to a separate bug in the DU driver that clones outputs by
> default when it shouldn't. There's however no harm in backporting the
> patch to stable series if desired, but it's not required.

Thanks, I've applied this for v4.16 with the fixes tag above.
Possibly the fixes tag will result in some automated backporting occurring.
If so we can let that run its course, if not we can leave things be with
the option to backport later if we decide its necessary.

I have not applied the other dts patches in this series at this point.

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

Re: [PATCH 2/5] drm/ttm: Export the ttm_k[un]map_atomic_prot API.

[Christian König]

Am 16.01.2018 um 14:56 schrieb Thomas Hellstrom:

It will be used by vmwgfx cpu blit.

Cc: Christian König 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 31 ++-
  include/drm/ttm/ttm_bo_api.h  |  4 
  2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6d6d939..9d4c7f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -263,24 +263,45 @@ static int ttm_copy_io_page(void *dst, void *src, 
unsigned long page)
  #define __ttm_kunmap_atomic(__addr) vunmap(__addr)
  #endif
  
-static void *ttm_kmap_atomic_prot(struct page *page,

- pgprot_t prot)
+
+/**
+ * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
+ * specified page protection.
+ *
+ * @page: The page to map.
+ * @prot: The page protection.
+ *
+ * This function maps a TTM page using the kmap_atomic api if available,
+ * otherwise falls back to vmap. The user must make sure that the
+ * specified page does not have an aliased mapping with a different caching
+ * policy unless the architecture explicitly allows it. Also mapping and
+ * unmapping using this api must be correctly nested. Unmapping should
+ * occur in the reverse order of mapping.
+ */
+void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
  {
if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
return kmap_atomic(page);
else
return __ttm_kmap_atomic_prot(page, prot);
  }
+EXPORT_SYMBOL(ttm_kmap_atomic_prot);
  
-

-static void ttm_kunmap_atomic_prot(void *addr,
-  pgprot_t prot)
+/**
+ * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
+ * ttm_kmap_atomic_prot.
+ *
+ * @addr: The virtual address from the map.
+ * @prot: The page protection.
+ */
+void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
  {
if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
kunmap_atomic(addr);
else
__ttm_kunmap_atomic(addr);
  }
+EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
  
  static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,

unsigned long page,
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index f1c74c2..936e5d5 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -728,6 +728,10 @@ unsigned long ttm_bo_default_io_mem_pfn(struct 
ttm_buffer_object *bo,
  int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
struct ttm_bo_device *bdev);
  
+void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot);

+
+void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot);
+
  /**
   * ttm_bo_io
   *


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

Re: [PATCH 1/5] drm/ttm: Clean up kmap_atomic_prot selection code

[Christian König]

Am 16.01.2018 um 14:56 schrieb Thomas Hellstrom:

Use helpers to perform the kmap_atomic_prot() functionality to
a) Avoid in-function ifdefs that violate the kernel coding policy,
b) Facilitate exporting the functionality.

This commit should not change any functionality.

Cc: Christian König 
Signed-off-by: Thomas Hellstrom 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 64 +++
  1 file changed, 31 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 153de1b..6d6d939 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -255,6 +255,33 @@ static int ttm_copy_io_page(void *dst, void *src, unsigned 
long page)
return 0;
  }
  
+#ifdef CONFIG_X86

+#define __ttm_kmap_atomic_prot(__page, __prot) kmap_atomic_prot(__page, __prot)
+#define __ttm_kunmap_atomic(__addr) kunmap_atomic(__addr)
+#else
+#define __ttm_kmap_atomic_prot(__page, __prot) vmap(&__page, 1, 0,  __prot)
+#define __ttm_kunmap_atomic(__addr) vunmap(__addr)
+#endif
+
+static void *ttm_kmap_atomic_prot(struct page *page,
+ pgprot_t prot)
+{
+   if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
+   return kmap_atomic(page);
+   else
+   return __ttm_kmap_atomic_prot(page, prot);
+}
+
+
+static void ttm_kunmap_atomic_prot(void *addr,
+  pgprot_t prot)
+{
+   if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
+   kunmap_atomic(addr);
+   else
+   __ttm_kunmap_atomic(addr);
+}
+
  static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
unsigned long page,
pgprot_t prot)
@@ -266,28 +293,13 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void 
*src,
return -ENOMEM;
  
  	src = (void *)((unsigned long)src + (page << PAGE_SHIFT));

-
-#ifdef CONFIG_X86
-   dst = kmap_atomic_prot(d, prot);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   dst = vmap(, 1, 0, prot);
-   else
-   dst = kmap(d);
-#endif
+   dst = ttm_kmap_atomic_prot(d, prot);
if (!dst)
return -ENOMEM;
  
  	memcpy_fromio(dst, src, PAGE_SIZE);
  
-#ifdef CONFIG_X86

-   kunmap_atomic(dst);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   vunmap(dst);
-   else
-   kunmap(d);
-#endif
+   ttm_kunmap_atomic_prot(dst, prot);
  
  	return 0;

  }
@@ -303,27 +315,13 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void 
*dst,
return -ENOMEM;
  
  	dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));

-#ifdef CONFIG_X86
-   src = kmap_atomic_prot(s, prot);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   src = vmap(, 1, 0, prot);
-   else
-   src = kmap(s);
-#endif
+   src = ttm_kmap_atomic_prot(s, prot);
if (!src)
return -ENOMEM;
  
  	memcpy_toio(dst, src, PAGE_SIZE);
  
-#ifdef CONFIG_X86

-   kunmap_atomic(src);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   vunmap(src);
-   else
-   kunmap(s);
-#endif
+   ttm_kunmap_atomic_prot(src, prot);
  
  	return 0;

  }


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

Re: [PATCH libdrm] drm: fix return value

[Zhou, David(ChunMing)]

Can your guys help me push it and last vamgr patches to upstream?
My new count request for libdrm still is under pending.

Thanks,
David Zhou


发自坚果 Pro

Christian K鰊ig  于 2018年1月16日 下午4:56写道：

Apart from that a good catch and Reviewed-by: Christian König
.

Regards,
Christian.

Am 16.01.2018 um 09:49 schrieb Michel Dänzer:
> Moving from the amd-gfx list to dri-devel, since this isn't amdgpu specific.
>
>
> On 2018-01-16 03:54 AM, Chunming Zhou wrote:
>> otherwise -ETIME is missed.
>>
>> Change-Id: Ic5580a74d8027cc468c6135f8cf2f81817993423
>> Signed-off-by: Chunming Zhou 
>> ---
>>   xf86drm.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xf86drm.c b/xf86drm.c
>> index 8a327170..3881bd9f 100644
>> --- a/xf86drm.c
>> +++ b/xf86drm.c
>> @@ -4241,7 +4241,7 @@ int drmSyncobjWait(int fd, uint32_t *handles, unsigned 
>> num_handles,
>>
>>   ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
>>   if (ret < 0)
>> -return ret;
>> +return -errno;
>>
>>   if (first_signaled)
>>   *first_signaled = args.first_signaled;
>>
>

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

[PATCH 0/5] drm/ttm, drm/vmwgfx: Use kmap_atomic() for cpu blit

[Thomas Hellstrom]

The purpose of this series is to remove the often full-screen vmwgfx sequence
vmap()
blit()
vunmap()
and replace it with kmap_atomic() style per-page maps.

Although somewhat rare nowadays, 32-bit VMs restrict the vmap space so that
huge vmaps may sometimes fail. Also, large vmaps lead to frequent global
TLB flushes.

On the contrary, using kmap_atomic() makes the blit code a lot more complex,
but hopefully we shouldn't need to revisit that code. On 64-bit architectures,
kmap_atomic() is essentially free as long as the mapping is cached, since then
the linear kernel map is reused. On 32-bit architectures the same holds for
lowmem pages, and on highmem pages the TLB flushes are local and per-page.
Preliminary findings on 32-bit vms show that while the blit itself consumes
more CPU with the new approach, the system idle time is about the same or
slightly increased.

The cpu blit was originally written as a TTM utility, for use also with CPU
buffer object moves, but until that code is written and tested we're keeping
it in vmwgfx.

In addition we've added a possibility to compute the diff bounding box
between the source and the destinations. The overhead of computing that
bounding-box is not that big when integrated with a CPU blit that still has to
be performed. And it comes in very handy for remoting of 2D-only VMs where
the damage rects are broken (Ubuntu / compiz) or for page-flipping
(gnome-shell).

Note that a slightly modified version of patch 3/5 is already upstream in 4.15.
This series is against drm-next and it's included for completeness.


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

[PATCH 4/5] drm/vmwgfx: Add a cpu blit utility that can be used for page-backed bos

[Thomas Hellstrom]

The utility uses kmap_atomic() instead of vmapping the whole buffer
object. As a result there will be more book-keeping but on some
architectures this will help avoid exhausting vmalloc space and also
avoid expensive TLB flushes.

The blit utility also adds a provision to compute a bounding box of
changed content, which is very useful to optimize presentation speed
of ill-behaved applications that don't supply proper damage regions, and
for page-flips. The cost of computing the bounding box is not that
expensive when done in a cpu-blit utility like this.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/vmwgfx/Makefile  |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 506 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  48 
 3 files changed, 555 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index ad80211..794cc9d 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -7,6 +7,6 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o 
vmwgfx_drv.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
vmwgfx_cmdbuf_res.o vmwgfx_cmdbuf.o vmwgfx_stdu.o \
vmwgfx_cotable.o vmwgfx_so.o vmwgfx_binding.o vmwgfx_msg.o \
-   vmwgfx_simple_resource.o vmwgfx_va.o
+   vmwgfx_simple_resource.o vmwgfx_va.o vmwgfx_blit.o
 
 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
new file mode 100644
index 000..2730403
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -0,0 +1,506 @@
+/**
+ *
+ * Copyright © 2017 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include "vmwgfx_drv.h"
+
+/*
+ * Template that implements find_first_diff() for a generic
+ * unsigned integer type. @size and return value are in bytes.
+ */
+#define VMW_FIND_FIRST_DIFF(_type)  \
+static size_t vmw_find_first_diff_ ## _type \
+   (const _type * dst, const _type * src, size_t size)\
+{   \
+   size_t i;\
+\
+   for (i = 0; i < size; i += sizeof(_type)) {  \
+   if (*dst++ != *src++)\
+   break;   \
+   }\
+\
+   return i;\
+}
+
+
+/*
+ * Template that implements find_last_diff() for a generic
+ * unsigned integer type. Pointers point to the item following the
+ * *end* of the area to be examined. @size and return value are in
+ * bytes.
+ */
+#define VMW_FIND_LAST_DIFF(_type)  \
+static ssize_t vmw_find_last_diff_ ## _type(   \
+   const _type * dst, const _type * src, size_t size)  \
+{  \
+   while (size) {  \
+   if (*--dst != *--src)   \
+   break;  \
+   \
+   size -= sizeof(_type);  \
+   }

[PATCH 3/5] drm/vmwgfx: Don't cache framebuffer maps

[Thomas Hellstrom]

Buffer objects need to be either pinned or reserved while a map is active,
that's not the case here, so avoid caching the framebuffer map.
This will cause increasing mapping activity mainly when we don't do
page flipping.

This fixes occasional garbage filled screens when the framebuffer has been
evicted after the map.

Since in-kernel mapping of whole buffer objects is error-prone on 32-bit
architectures and also quite inefficient, we will revisit this later.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  6 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 40 +++-
 3 files changed, 13 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 34ee856..96737d5 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -694,7 +694,6 @@ vmw_du_plane_duplicate_state(struct drm_plane *plane)
vps->pinned = 0;
 
/* Mapping is managed by prepare_fb/cleanup_fb */
-   memset(>guest_map, 0, sizeof(vps->guest_map));
memset(>host_map, 0, sizeof(vps->host_map));
vps->cpp = 0;
 
@@ -757,11 +756,6 @@ vmw_du_plane_destroy_state(struct drm_plane *plane,
 
 
/* Should have been freed by cleanup_fb */
-   if (vps->guest_map.virtual) {
-   DRM_ERROR("Guest mapping not freed\n");
-   ttm_bo_kunmap(>guest_map);
-   }
-
if (vps->host_map.virtual) {
DRM_ERROR("Host mapping not freed\n");
ttm_bo_kunmap(>host_map);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 70a7be2..42b0f15 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -177,7 +177,7 @@ struct vmw_plane_state {
int pinned;
 
/* For CPU Blit */
-   struct ttm_bo_kmap_obj host_map, guest_map;
+   struct ttm_bo_kmap_obj host_map;
unsigned int cpp;
 };
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 0e771d6..6de2874 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -114,7 +114,7 @@ struct vmw_screen_target_display_unit {
bool defined;
 
/* For CPU Blit */
-   struct ttm_bo_kmap_obj host_map, guest_map;
+   struct ttm_bo_kmap_obj host_map;
unsigned int cpp;
 };
 
@@ -641,7 +641,8 @@ static void vmw_stdu_dmabuf_cpu_commit(struct vmw_kms_dirty 
*dirty)
s32 src_pitch, dst_pitch;
u8 *src, *dst;
bool not_used;
-
+   struct ttm_bo_kmap_obj guest_map;
+   int ret;
 
if (!dirty->num_hits)
return;
@@ -652,6 +653,13 @@ static void vmw_stdu_dmabuf_cpu_commit(struct 
vmw_kms_dirty *dirty)
if (width == 0 || height == 0)
return;
 
+   ret = ttm_bo_kmap(>buf->base, 0, ddirty->buf->base.num_pages,
+ _map);
+   if (ret) {
+   DRM_ERROR("Failed mapping framebuffer for blit: %d\n",
+ ret);
+   goto out_cleanup;
+   }
 
/* Assume we are blitting from Host (display_srf) to Guest (dmabuf) */
src_pitch = stdu->display_srf->base_size.width * stdu->cpp;
@@ -659,7 +667,7 @@ static void vmw_stdu_dmabuf_cpu_commit(struct vmw_kms_dirty 
*dirty)
src += ddirty->top * src_pitch + ddirty->left * stdu->cpp;
 
dst_pitch = ddirty->pitch;
-   dst = ttm_kmap_obj_virtual(>guest_map, _used);
+   dst = ttm_kmap_obj_virtual(_map, _used);
dst += ddirty->fb_top * dst_pitch + ddirty->fb_left * stdu->cpp;
 
 
@@ -718,6 +726,7 @@ static void vmw_stdu_dmabuf_cpu_commit(struct vmw_kms_dirty 
*dirty)
vmw_fifo_commit(dev_priv, sizeof(*cmd));
}
 
+   ttm_bo_kunmap(_map);
 out_cleanup:
ddirty->left = ddirty->top = ddirty->fb_left = ddirty->fb_top = S32_MAX;
ddirty->right = ddirty->bottom = S32_MIN;
@@ -1062,9 +1071,6 @@ vmw_stdu_primary_plane_cleanup_fb(struct drm_plane *plane,
 {
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
 
-   if (vps->guest_map.virtual)
-   ttm_bo_kunmap(>guest_map);
-
if (vps->host_map.virtual)
ttm_bo_kunmap(>host_map);
 
@@ -1230,33 +1236,11 @@ vmw_stdu_primary_plane_prepare_fb(struct drm_plane 
*plane,
 */
if (vps->content_fb_type == SEPARATE_DMA &&
!(dev_priv->capabilities & SVGA_CAP_3D)) {
-
-   struct vmw_framebuffer_dmabuf *new_vfbd;
-
-   new_vfbd = vmw_framebuffer_to_vfbd(new_fb);
-
-   ret = ttm_bo_reserve(_vfbd->buffer->base, false, false,
-NULL);
-   if (ret)
-   goto out_srf_unpin;
-
-   ret = 

[PATCH 5/5] drm/vmwgfx: Use the cpu blit utility for framebuffer to screen target blits

[Thomas Hellstrom]

This blit was previously performed using two large vmaps, one of which
was teared down and remapped on each blit. Use the more resource-
conserving TTM cpu blit instead.

The blit is used in boundary-box computing mode which makes it possible
to minimize the bounding box used in host operations.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |  23 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|   1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  50 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h|   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |   5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   | 105 +++--
 6 files changed, 97 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 22231bc..2fe099a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -185,6 +185,22 @@ static const struct ttm_place evictable_placement_flags[] 
= {
}
 };
 
+static const struct ttm_place nonfixed_placement_flags[] = {
+   {
+   .fpfn = 0,
+   .lpfn = 0,
+   .flags = TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED
+   }, {
+   .fpfn = 0,
+   .lpfn = 0,
+   .flags = VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED
+   }, {
+   .fpfn = 0,
+   .lpfn = 0,
+   .flags = VMW_PL_FLAG_MOB | TTM_PL_FLAG_CACHED
+   }
+};
+
 struct ttm_placement vmw_evictable_placement = {
.num_placement = 4,
.placement = evictable_placement_flags,
@@ -213,6 +229,13 @@ struct ttm_placement vmw_mob_ne_placement = {
.busy_placement = _ne_placement_flags
 };
 
+struct ttm_placement vmw_nonfixed_placement = {
+   .num_placement = 3,
+   .placement = nonfixed_placement_flags,
+   .num_busy_placement = 1,
+   .busy_placement = _placement_flags
+};
+
 struct vmw_ttm_tt {
struct ttm_dma_tt dma_ttm;
struct vmw_private *dev_priv;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 99e7e426..62e567a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -767,6 +767,7 @@ extern struct ttm_placement vmw_evictable_placement;
 extern struct ttm_placement vmw_srf_placement;
 extern struct ttm_placement vmw_mob_placement;
 extern struct ttm_placement vmw_mob_ne_placement;
+extern struct ttm_placement vmw_nonfixed_placement;
 extern struct ttm_bo_driver vmw_bo_driver;
 extern int vmw_dma_quiescent(struct drm_device *dev);
 extern int vmw_bo_map_dma(struct ttm_buffer_object *bo);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 96737d5..a62d0f8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -692,9 +692,6 @@ vmw_du_plane_duplicate_state(struct drm_plane *plane)
return NULL;
 
vps->pinned = 0;
-
-   /* Mapping is managed by prepare_fb/cleanup_fb */
-   memset(>host_map, 0, sizeof(vps->host_map));
vps->cpp = 0;
 
/* Each ref counted resource needs to be acquired again */
@@ -756,11 +753,6 @@ vmw_du_plane_destroy_state(struct drm_plane *plane,
 
 
/* Should have been freed by cleanup_fb */
-   if (vps->host_map.virtual) {
-   DRM_ERROR("Host mapping not freed\n");
-   ttm_bo_kunmap(>host_map);
-   }
-
if (vps->surf)
vmw_surface_unreference(>surf);
 
@@ -1139,12 +1131,14 @@ static const struct drm_framebuffer_funcs 
vmw_framebuffer_dmabuf_funcs = {
 };
 
 /**
- * Pin the dmabuffer to the start of vram.
+ * Pin the dmabuffer in a location suitable for access by the
+ * display system.
  */
 static int vmw_framebuffer_pin(struct vmw_framebuffer *vfb)
 {
struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
struct vmw_dma_buffer *buf;
+   struct ttm_placement *placement;
int ret;
 
buf = vfb->dmabuf ?  vmw_framebuffer_to_vfbd(>base)->buffer :
@@ -1161,12 +1155,24 @@ static int vmw_framebuffer_pin(struct vmw_framebuffer 
*vfb)
break;
case vmw_du_screen_object:
case vmw_du_screen_target:
-   if (vfb->dmabuf)
-   return vmw_dmabuf_pin_in_vram_or_gmr(dev_priv, buf,
-false);
+   if (vfb->dmabuf) {
+   if (dev_priv->capabilities & SVGA_CAP_3D) {
+   /*
+* Use surface DMA to get content to
+* sreen target surface.
+*/
+   placement = _vram_gmr_placement;
+   } else {
+   /* Use CPU blit. */
+

[PATCH 2/5] drm/ttm: Export the ttm_k[un]map_atomic_prot API.

[Thomas Hellstrom]

It will be used by vmwgfx cpu blit.

Cc: Christian König 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 31 ++-
 include/drm/ttm/ttm_bo_api.h  |  4 
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6d6d939..9d4c7f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -263,24 +263,45 @@ static int ttm_copy_io_page(void *dst, void *src, 
unsigned long page)
 #define __ttm_kunmap_atomic(__addr) vunmap(__addr)
 #endif
 
-static void *ttm_kmap_atomic_prot(struct page *page,
- pgprot_t prot)
+
+/**
+ * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
+ * specified page protection.
+ *
+ * @page: The page to map.
+ * @prot: The page protection.
+ *
+ * This function maps a TTM page using the kmap_atomic api if available,
+ * otherwise falls back to vmap. The user must make sure that the
+ * specified page does not have an aliased mapping with a different caching
+ * policy unless the architecture explicitly allows it. Also mapping and
+ * unmapping using this api must be correctly nested. Unmapping should
+ * occur in the reverse order of mapping.
+ */
+void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
 {
if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
return kmap_atomic(page);
else
return __ttm_kmap_atomic_prot(page, prot);
 }
+EXPORT_SYMBOL(ttm_kmap_atomic_prot);
 
-
-static void ttm_kunmap_atomic_prot(void *addr,
-  pgprot_t prot)
+/**
+ * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
+ * ttm_kmap_atomic_prot.
+ *
+ * @addr: The virtual address from the map.
+ * @prot: The page protection.
+ */
+void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
 {
if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
kunmap_atomic(addr);
else
__ttm_kunmap_atomic(addr);
 }
+EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
 
 static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
unsigned long page,
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index f1c74c2..936e5d5 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -728,6 +728,10 @@ unsigned long ttm_bo_default_io_mem_pfn(struct 
ttm_buffer_object *bo,
 int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
struct ttm_bo_device *bdev);
 
+void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot);
+
+void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot);
+
 /**
  * ttm_bo_io
  *
-- 
2.7.4

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

[PATCH 1/5] drm/ttm: Clean up kmap_atomic_prot selection code

[Thomas Hellstrom]

Use helpers to perform the kmap_atomic_prot() functionality to
a) Avoid in-function ifdefs that violate the kernel coding policy,
b) Facilitate exporting the functionality.

This commit should not change any functionality.

Cc: Christian König 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 64 +++
 1 file changed, 31 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 153de1b..6d6d939 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -255,6 +255,33 @@ static int ttm_copy_io_page(void *dst, void *src, unsigned 
long page)
return 0;
 }
 
+#ifdef CONFIG_X86
+#define __ttm_kmap_atomic_prot(__page, __prot) kmap_atomic_prot(__page, __prot)
+#define __ttm_kunmap_atomic(__addr) kunmap_atomic(__addr)
+#else
+#define __ttm_kmap_atomic_prot(__page, __prot) vmap(&__page, 1, 0,  __prot)
+#define __ttm_kunmap_atomic(__addr) vunmap(__addr)
+#endif
+
+static void *ttm_kmap_atomic_prot(struct page *page,
+ pgprot_t prot)
+{
+   if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
+   return kmap_atomic(page);
+   else
+   return __ttm_kmap_atomic_prot(page, prot);
+}
+
+
+static void ttm_kunmap_atomic_prot(void *addr,
+  pgprot_t prot)
+{
+   if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
+   kunmap_atomic(addr);
+   else
+   __ttm_kunmap_atomic(addr);
+}
+
 static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
unsigned long page,
pgprot_t prot)
@@ -266,28 +293,13 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void 
*src,
return -ENOMEM;
 
src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
-
-#ifdef CONFIG_X86
-   dst = kmap_atomic_prot(d, prot);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   dst = vmap(, 1, 0, prot);
-   else
-   dst = kmap(d);
-#endif
+   dst = ttm_kmap_atomic_prot(d, prot);
if (!dst)
return -ENOMEM;
 
memcpy_fromio(dst, src, PAGE_SIZE);
 
-#ifdef CONFIG_X86
-   kunmap_atomic(dst);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   vunmap(dst);
-   else
-   kunmap(d);
-#endif
+   ttm_kunmap_atomic_prot(dst, prot);
 
return 0;
 }
@@ -303,27 +315,13 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void 
*dst,
return -ENOMEM;
 
dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
-#ifdef CONFIG_X86
-   src = kmap_atomic_prot(s, prot);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   src = vmap(, 1, 0, prot);
-   else
-   src = kmap(s);
-#endif
+   src = ttm_kmap_atomic_prot(s, prot);
if (!src)
return -ENOMEM;
 
memcpy_toio(dst, src, PAGE_SIZE);
 
-#ifdef CONFIG_X86
-   kunmap_atomic(src);
-#else
-   if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL))
-   vunmap(src);
-   else
-   kunmap(s);
-#endif
+   ttm_kunmap_atomic_prot(src, prot);
 
return 0;
 }
-- 
2.7.4

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

[PATCH] [RESEND v2] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

[Arnd Bergmann]

gcc thinks that interpreting a multiplication result as a bool
is confusing:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean 
context, suggest '&&' instead [-Werror=int-in-bool-context]

Adding a temporary variable to contain the divisor helps make
it clear what is going on and avoids that warning.

Fixes: 7632b30e4b8b ("drm/nouveau/clk: namespace + nvidia gpu names (no binary 
change)")
Signed-off-by: Arnd Bergmann 
---
Originally submitted on July 14, but no reply. Resent on Sep 6, got
one comment and sent an updated version, which again got no other
replies.

This is the v2 version again.

The warning is currently disabled in mainline, but I think we can turn
it back on in the future, and this change here seems harmless.

v2: use a temporary variable as suggested by Karol Herbst.
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
index 96e0941c8edd..f0a26881d9b9 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
@@ -110,6 +110,7 @@ read_pll(struct gt215_clk *clk, int idx, u32 pll)
struct nvkm_device *device = clk->base.subdev.device;
u32 ctrl = nvkm_rd32(device, pll + 0);
u32 sclk = 0, P = 1, N = 1, M = 1;
+   u32 MP;
 
if (!(ctrl & 0x0008)) {
if (ctrl & 0x0001) {
@@ -130,10 +131,12 @@ read_pll(struct gt215_clk *clk, int idx, u32 pll)
sclk = read_clk(clk, 0x10 + idx, false);
}
 
-   if (M * P)
-   return sclk * N / (M * P);
+   MP = M * P;
 
-   return 0;
+   if (!MP)
+   return 0;
+
+   return sclk * N / MP;
 }
 
 static int
-- 
2.9.0

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

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

[bugzilla-daemon]

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

--- Comment #3 from Vedran Miletić  ---
(In reply to Michel Dänzer from comment #2)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=e97f12f359775de4fabfb507f836ebffa20f4986 should help for this.

Thanks. imirkin warned me on IRC (wrt similar bug 104609 in nouveau) not to
expect machine to reboot cleanly, so I'll be able to test it in a few weeks,
which is when 4.15.x is expected to come to Fedora 27 anyway.

-- 
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 4/7] drm/vmwgfx: Move screen object page flip to atomic function

[Thomas Hellstrom]

From: Deepak Rawat 

The dmabuf_dirty/surface_dirty in case of screen object is moved to
plane atomic update, so that page flip in atomic ioctl also works.

vmwgfx does not support DRM_MODE_PAGE_FLIP_ASYNC, so this flag is never
expected.

Signed-off-by: Deepak Rawat 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 114 ---
 1 file changed, 64 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 21f4019..7164724 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -316,69 +316,21 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
  struct drm_modeset_acquire_ctx *ctx)
 {
struct vmw_private *dev_priv = vmw_priv(crtc->dev);
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
-   struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(new_fb);
-   struct vmw_fence_obj *fence = NULL;
-   struct drm_vmw_rect vclips;
int ret;
 
if (!vmw_kms_crtc_flippable(dev_priv, crtc))
return -EINVAL;
 
-   flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
-   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
+   ret = drm_atomic_helper_page_flip(crtc, new_fb, event, flags, ctx);
if (ret) {
DRM_ERROR("Page flip error %d.\n", ret);
return ret;
}
 
-   /* do a full screen dirty update */
-   vclips.x = crtc->x;
-   vclips.y = crtc->y;
-   vclips.w = crtc->mode.hdisplay;
-   vclips.h = crtc->mode.vdisplay;
-
-   if (vfb->dmabuf)
-   ret = vmw_kms_sou_do_dmabuf_dirty(dev_priv, vfb,
- NULL, , 1, 1,
- true, , crtc);
-   else
-   ret = vmw_kms_sou_do_surface_dirty(dev_priv, vfb,
-  NULL, , NULL,
-  0, 0, 1, 1, , crtc);
-
-
-   if (ret != 0)
-   goto out_no_fence;
-   if (!fence) {
-   ret = -EINVAL;
-   goto out_no_fence;
-   }
-
-   if (event) {
-   struct drm_file *file_priv = event->base.file_priv;
-
-   ret = vmw_event_fence_action_queue(file_priv, fence,
-  >base,
-  >event.vbl.tv_sec,
-  >event.vbl.tv_usec,
-  true);
-   }
-
-   /*
-* No need to hold on to this now. The only cleanup
-* we need to do if we fail is unref the fence.
-*/
-   vmw_fence_obj_unreference();
-
if (vmw_crtc_to_du(crtc)->is_implicit)
vmw_kms_update_implicit_fb(dev_priv, crtc);
 
return ret;
-
-out_no_fence:
-   drm_atomic_set_fb_for_plane(crtc->primary->state, old_fb);
-   return ret;
 }
 
 static const struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
@@ -530,9 +482,71 @@ vmw_sou_primary_plane_atomic_update(struct drm_plane 
*plane,
struct drm_plane_state *old_state)
 {
struct drm_crtc *crtc = plane->state->crtc;
+   struct drm_pending_vblank_event *event = NULL;
+   struct vmw_fence_obj *fence = NULL;
+   int ret;
+
+   if (crtc && plane->state->fb) {
+   struct vmw_private *dev_priv = vmw_priv(crtc->dev);
+   struct vmw_framebuffer *vfb =
+   vmw_framebuffer_to_vfb(plane->state->fb);
+   struct drm_vmw_rect vclips;
+
+   vclips.x = crtc->x;
+   vclips.y = crtc->y;
+   vclips.w = crtc->mode.hdisplay;
+   vclips.h = crtc->mode.vdisplay;
+
+   if (vfb->dmabuf)
+   ret = vmw_kms_sou_do_dmabuf_dirty(dev_priv, vfb, NULL,
+ , 1, 1, true,
+ , crtc);
+   else
+   ret = vmw_kms_sou_do_surface_dirty(dev_priv, vfb, NULL,
+  , NULL, 0, 0,
+  1, 1, , crtc);
+
+   /*
+* We cannot really fail this function, so if we do, then output
+* an error and maintain consistent atomic state.
+*/
+   if (ret != 0)
+   DRM_ERROR("Failed to update screen.\n");
 
-   if (crtc)
crtc->primary->fb = plane->state->fb;
+   } else {
+   /*
+* When disabling a plane, CRTC and FB should 

[PATCH 6/7] drm/vmwgfx: Send the correct nonblock option for atomic_commit

[Thomas Hellstrom]

From: Deepak Rawat 

Page flip can be slow for vmwgfx in some cases, like need to do surface
copy to different surface or waiting for IN_FENCE_FD. Enabling
nonblocking commits for vmwgfx in case userspace request it.

Signed-off-by: Deepak Rawat 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 27 +--
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a7e7863..3f1ed51 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1548,35 +1548,10 @@ vmw_kms_atomic_check_modeset(struct drm_device *dev,
return drm_atomic_helper_check(dev, state);
 }
 
-
-/**
- * vmw_kms_atomic_commit - Perform an atomic state commit
- *
- * @dev: DRM device
- * @state: the driver state object
- * @nonblock: Whether nonblocking behaviour is requested
- *
- * This is a simple wrapper around drm_atomic_helper_commit() for
- * us to clear the nonblocking value.
- *
- * Nonblocking commits currently cause synchronization issues
- * for vmwgfx.
- *
- * RETURNS
- * Zero for success or negative error code on failure.
- */
-int vmw_kms_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool nonblock)
-{
-   return drm_atomic_helper_commit(dev, state, false);
-}
-
-
 static const struct drm_mode_config_funcs vmw_kms_funcs = {
.fb_create = vmw_kms_fb_create,
.atomic_check = vmw_kms_atomic_check_modeset,
-   .atomic_commit = vmw_kms_atomic_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 static int vmw_kms_generic_present(struct vmw_private *dev_priv,
-- 
2.7.4

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

[PATCH 1/7] drm/vmwgfx: Avoid iterating over display unit if crtc is available

[Thomas Hellstrom]

From: Deepak Rawat 

In case of page flip there is no need to iterate over all display unit
in the function "vmw_kms_helper_dirty". If crtc is available then
dirty commands is performed on that crtc only.

Signed-off-by: Deepak Rawat 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 31 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  | 17 -
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 19 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 15 +++
 4 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a2a93d7..cc98e01 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -900,11 +900,11 @@ static int vmw_framebuffer_surface_dirty(struct 
drm_framebuffer *framebuffer,
if (dev_priv->active_display_unit == vmw_du_screen_object)
ret = vmw_kms_sou_do_surface_dirty(dev_priv, >base,
   clips, NULL, NULL, 0, 0,
-  num_clips, inc, NULL);
+  num_clips, inc, NULL, NULL);
else
ret = vmw_kms_stdu_surface_dirty(dev_priv, >base,
 clips, NULL, NULL, 0, 0,
-num_clips, inc, NULL);
+num_clips, inc, NULL, NULL);
 
vmw_fifo_flush(dev_priv, false);
ttm_read_unlock(_priv->reservation_sem);
@@ -940,11 +940,12 @@ int vmw_kms_readback(struct vmw_private *dev_priv,
switch (dev_priv->active_display_unit) {
case vmw_du_screen_object:
return vmw_kms_sou_readback(dev_priv, file_priv, vfb,
-   user_fence_rep, vclips, num_clips);
+   user_fence_rep, vclips, num_clips,
+   NULL);
case vmw_du_screen_target:
return vmw_kms_stdu_dma(dev_priv, file_priv, vfb,
user_fence_rep, NULL, vclips, num_clips,
-   1, false, true);
+   1, false, true, NULL);
default:
WARN_ONCE(true,
  "Readback called with invalid display system.\n");
@@ -1102,12 +1103,12 @@ static int vmw_framebuffer_dmabuf_dirty(struct 
drm_framebuffer *framebuffer,
case vmw_du_screen_target:
ret = vmw_kms_stdu_dma(dev_priv, NULL, >base, NULL,
   clips, NULL, num_clips, increment,
-  true, true);
+  true, true, NULL);
break;
case vmw_du_screen_object:
ret = vmw_kms_sou_do_dmabuf_dirty(dev_priv, >base,
  clips, NULL, num_clips,
- increment, true, NULL);
+ increment, true, NULL, NULL);
break;
case vmw_du_legacy:
ret = vmw_kms_ldu_do_dmabuf_dirty(dev_priv, >base, 0, 0,
@@ -1593,7 +1594,7 @@ static int vmw_kms_generic_present(struct vmw_private 
*dev_priv,
 {
return vmw_kms_sou_do_surface_dirty(dev_priv, vfb, NULL, clips,
>res, destX, destY,
-   num_clips, 1, NULL);
+   num_clips, 1, NULL, NULL);
 }
 
 
@@ -1612,7 +1613,7 @@ int vmw_kms_present(struct vmw_private *dev_priv,
case vmw_du_screen_target:
ret = vmw_kms_stdu_surface_dirty(dev_priv, vfb, NULL, clips,
 >res, destX, destY,
-num_clips, 1, NULL);
+num_clips, 1, NULL, NULL);
break;
case vmw_du_screen_object:
ret = vmw_kms_generic_present(dev_priv, file_priv, vfb, surface,
@@ -2340,10 +2341,16 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv,
 
dirty->dev_priv = dev_priv;
 
-   list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list, head) {
-   if (crtc->primary->fb != >base)
-   continue;
-   units[num_units++] = vmw_crtc_to_du(crtc);
+   /* If crtc is passed, no need to iterate over other display units */
+   if (dirty->crtc) {
+   units[num_units++] = vmw_crtc_to_du(dirty->crtc);
+   } else {
+   list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
+ 

[PATCH 7/7] drm/vmwgfx: Cursor update fixes

[Thomas Hellstrom]

Use drm_plane_helper_check_update also for the cursor plane.
Avoid uploading a new cursor image on each cursor move and
only upload cursor images on cursor fb changes, assuming that we're
in effect page-flipping the cursor, which is exactly what the
legacy helper does. Cursor front-buffer like rendering using atomic
still needs some kind of atomic damage interface.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 45 -
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3f1ed51..34ee856 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -393,21 +393,24 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
du->cursor_surface = vps->surf;
du->cursor_dmabuf = vps->dmabuf;
 
-   /* setup new image */
-   if (vps->surf) {
-   du->cursor_age = du->cursor_surface->snooper.age;
-
-   ret = vmw_cursor_update_image(dev_priv,
- vps->surf->snooper.image,
- 64, 64, hotspot_x, hotspot_y);
-   } else if (vps->dmabuf) {
-   ret = vmw_cursor_update_dmabuf(dev_priv, vps->dmabuf,
-  plane->state->crtc_w,
-  plane->state->crtc_h,
-  hotspot_x, hotspot_y);
-   } else {
-   vmw_cursor_update_position(dev_priv, false, 0, 0);
-   return;
+   /* Do we have a new image? */
+   if (!old_state || !old_state->fb || plane->state->fb != old_state->fb) {
+   if (vps->surf) {
+   du->cursor_age = du->cursor_surface->snooper.age;
+
+   ret = vmw_cursor_update_image(dev_priv,
+ vps->surf->snooper.image,
+ 64, 64, hotspot_x,
+ hotspot_y);
+   } else if (vps->dmabuf) {
+   ret = vmw_cursor_update_dmabuf(dev_priv, vps->dmabuf,
+  plane->state->crtc_w,
+  plane->state->crtc_h,
+  hotspot_x, hotspot_y);
+   } else {
+   vmw_cursor_update_position(dev_priv, false, 0, 0);
+   return;
+   }
}
 
if (!ret) {
@@ -503,11 +506,23 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane 
*plane,
struct vmw_surface *surface = NULL;
struct drm_framebuffer *fb = new_state->fb;
 
+   struct drm_rect src = drm_plane_state_src(new_state);
+   struct drm_rect dest = drm_plane_state_dest(new_state);
+   struct drm_rect clip = dest;
 
/* Turning off */
if (!fb)
return ret;
 
+   ret = drm_plane_helper_check_update(plane, new_state->crtc, fb,
+   , , ,
+   DRM_MODE_ROTATE_0,
+   DRM_PLANE_HELPER_NO_SCALING,
+   DRM_PLANE_HELPER_NO_SCALING,
+   true, true, _state->visible);
+   if (!ret)
+   return ret;
+
/* A lot of the code assumes this */
if (new_state->crtc_w != 64 || new_state->crtc_h != 64) {
DRM_ERROR("Invalid cursor dimensions (%d, %d)\n",
-- 
2.7.4

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

[PATCH 5/7] drm/vmwgfx: Move the stdu vblank event to atomic function

[Thomas Hellstrom]

From: Deepak Rawat 

Atomic ioctl can also send the same page flip flags as legacy ioctl.
In those cases also need to send the vblank event to userspace.

vmwgfx does not support flag DRM_MODE_PAGE_FLIP_ASYNC, so this flag is
never expected.

Signed-off-by: Deepak Rawat 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 142 +++
 1 file changed, 77 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index c86cec1..0e771d6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -494,47 +494,15 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
struct vmw_screen_target_display_unit *stdu = vmw_crtc_to_stdu(crtc);
int ret;
 
-   dev_priv  = vmw_priv(crtc->dev);
-   stdu  = vmw_crtc_to_stdu(crtc);
-
if (!stdu->defined || !vmw_kms_crtc_flippable(dev_priv, crtc))
return -EINVAL;
 
-   /*
-* We're always async, but the helper doesn't know how to set async
-* so lie to the helper. Also, the helper expects someone
-* to pick the event up from the crtc state, and if nobody does,
-* it will free it. Since we handle the event in this function,
-* don't hand it to the helper.
-*/
-   flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
-   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
+   ret = drm_atomic_helper_page_flip(crtc, new_fb, event, flags, ctx);
if (ret) {
DRM_ERROR("Page flip error %d.\n", ret);
return ret;
}
 
-   if (stdu->base.is_implicit)
-   vmw_kms_update_implicit_fb(dev_priv, crtc);
-
-   if (event) {
-   struct vmw_fence_obj *fence = NULL;
-   struct drm_file *file_priv = event->base.file_priv;
-
-   vmw_execbuf_fence_commands(NULL, dev_priv, , NULL);
-   if (!fence)
-   return -ENOMEM;
-
-   ret = vmw_event_fence_action_queue(file_priv, fence,
-  >base,
-  >event.vbl.tv_sec,
-  >event.vbl.tv_usec,
-  true);
-   vmw_fence_obj_unreference();
-   } else {
-   (void) vmw_fifo_flush(dev_priv, false);
-   }
-
return 0;
 }
 
@@ -1323,48 +1291,38 @@ static void
 vmw_stdu_primary_plane_atomic_update(struct drm_plane *plane,
 struct drm_plane_state *old_state)
 {
-   struct vmw_private *dev_priv;
-   struct vmw_screen_target_display_unit *stdu;
struct vmw_plane_state *vps = vmw_plane_state_to_vps(plane->state);
-   struct drm_crtc *crtc = plane->state->crtc ?: old_state->crtc;
-   struct vmw_framebuffer *vfb = NULL;
+   struct drm_crtc *crtc = plane->state->crtc;
+   struct vmw_screen_target_display_unit *stdu;
+   struct drm_pending_vblank_event *event;
+   struct vmw_private *dev_priv;
int ret;
 
-   stdu = vmw_crtc_to_stdu(crtc);
-   dev_priv = vmw_priv(crtc->dev);
-
-   stdu->display_srf = vps->surf;
-   stdu->content_fb_type = vps->content_fb_type;
-   stdu->cpp = vps->cpp;
-   memcpy(>guest_map, >guest_map, sizeof(vps->guest_map));
-   memcpy(>host_map, >host_map, sizeof(vps->host_map));
-
-   if (!stdu->defined)
-   return;
-
-   if (plane->state->fb) {
-   vfb = vmw_framebuffer_to_vfb(plane->state->fb);
-   ret = vmw_stdu_bind_st(dev_priv, stdu, >display_srf->res);
-   } else
-   ret = vmw_stdu_bind_st(dev_priv, stdu, NULL);
-
/*
 * We cannot really fail this function, so if we do, then output an
-* error and quit
+* error and maintain consistent atomic state.
 */
-   if (ret)
-   DRM_ERROR("Failed to bind surface to STDU.\n");
-   else
-   crtc->primary->fb = plane->state->fb;
-
-   if (vfb) {
+   if (crtc && plane->state->fb) {
+   struct vmw_framebuffer *vfb =
+   vmw_framebuffer_to_vfb(plane->state->fb);
struct drm_vmw_rect vclips;
+   stdu = vmw_crtc_to_stdu(crtc);
+   dev_priv = vmw_priv(crtc->dev);
+
+   stdu->display_srf = vps->surf;
+   stdu->content_fb_type = vps->content_fb_type;
+   stdu->cpp = vps->cpp;
+   memcpy(>host_map, >host_map, sizeof(vps->host_map));
 
vclips.x = crtc->x;
vclips.y = crtc->y;
vclips.w = crtc->mode.hdisplay;
vclips.h = crtc->mode.vdisplay;
 
+   

[PATCH 3/7] drm/vmwgfx: Remove drm_crtc_arm_vblank_event from atomic flush

[Thomas Hellstrom]

From: Deepak Rawat 

The function drm_crtc_arm_vblank_event should be used for the driver
which have vblank interrupt support. In case of vmwgfx we do not have
vblank interrupt.

Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index cc98e01..a7e7863 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -572,13 +572,9 @@ void vmw_du_crtc_atomic_flush(struct drm_crtc *crtc,
crtc->state->event = NULL;
 
spin_lock_irq(>dev->event_lock);
-   if (drm_crtc_vblank_get(crtc) == 0)
-   drm_crtc_arm_vblank_event(crtc, event);
-   else
-   drm_crtc_send_vblank_event(crtc, event);
+   drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irq(>dev->event_lock);
}
-
 }
 
 
-- 
2.7.4

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

[PATCH 2/7] drm/vmwgfx: Move surface copy cmd to atomic function

[Thomas Hellstrom]

From: Deepak Rawat 

When display surface is different than the framebuffer surface, atomic
path do not copy the surface data. This commit moved the code to copy
surface from legacy to atomic path.

Signed-off-by: Deepak Rawat 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 47 +---
 1 file changed, 22 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index b2f7db6..c86cec1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -492,8 +492,6 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
 {
struct vmw_private *dev_priv = vmw_priv(crtc->dev);
struct vmw_screen_target_display_unit *stdu = vmw_crtc_to_stdu(crtc);
-   struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(new_fb);
-   struct drm_vmw_rect vclips;
int ret;
 
dev_priv  = vmw_priv(crtc->dev);
@@ -519,26 +517,6 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
if (stdu->base.is_implicit)
vmw_kms_update_implicit_fb(dev_priv, crtc);
 
-   /*
-* Now that we've bound a new surface to the screen target,
-* update the contents.
-*/
-   vclips.x = crtc->x;
-   vclips.y = crtc->y;
-   vclips.w = crtc->mode.hdisplay;
-   vclips.h = crtc->mode.vdisplay;
-
-   if (vfb->dmabuf)
-   ret = vmw_kms_stdu_dma(dev_priv, NULL, vfb, NULL, NULL, ,
-  1, 1, true, false, crtc);
-   else
-   ret = vmw_kms_stdu_surface_dirty(dev_priv, vfb, NULL, ,
-NULL, 0, 0, 1, 1, NULL, crtc);
-   if (ret) {
-   DRM_ERROR("Page flip update error %d.\n", ret);
-   return ret;
-   }
-
if (event) {
struct vmw_fence_obj *fence = NULL;
struct drm_file *file_priv = event->base.file_priv;
@@ -1349,6 +1327,7 @@ vmw_stdu_primary_plane_atomic_update(struct drm_plane 
*plane,
struct vmw_screen_target_display_unit *stdu;
struct vmw_plane_state *vps = vmw_plane_state_to_vps(plane->state);
struct drm_crtc *crtc = plane->state->crtc ?: old_state->crtc;
+   struct vmw_framebuffer *vfb = NULL;
int ret;
 
stdu = vmw_crtc_to_stdu(crtc);
@@ -1363,9 +1342,10 @@ vmw_stdu_primary_plane_atomic_update(struct drm_plane 
*plane,
if (!stdu->defined)
return;
 
-   if (plane->state->fb)
+   if (plane->state->fb) {
+   vfb = vmw_framebuffer_to_vfb(plane->state->fb);
ret = vmw_stdu_bind_st(dev_priv, stdu, >display_srf->res);
-   else
+   } else
ret = vmw_stdu_bind_st(dev_priv, stdu, NULL);
 
/*
@@ -1377,7 +1357,24 @@ vmw_stdu_primary_plane_atomic_update(struct drm_plane 
*plane,
else
crtc->primary->fb = plane->state->fb;
 
-   ret = vmw_stdu_update_st(dev_priv, stdu);
+   if (vfb) {
+   struct drm_vmw_rect vclips;
+
+   vclips.x = crtc->x;
+   vclips.y = crtc->y;
+   vclips.w = crtc->mode.hdisplay;
+   vclips.h = crtc->mode.vdisplay;
+
+   if (vfb->dmabuf)
+   ret = vmw_kms_stdu_dma(dev_priv, NULL, vfb, NULL, NULL,
+  , 1, 1, true, false,
+  crtc);
+   else
+   ret = vmw_kms_stdu_surface_dirty(dev_priv, vfb, NULL,
+, NULL, 0, 0,
+1, 1, NULL, crtc);
+   } else
+   ret = vmw_stdu_update_st(dev_priv, stdu);
 
if (ret)
DRM_ERROR("Failed to update STDU.\n");
-- 
2.7.4

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

[PATCH 0/7] drm/vmwgfx: Various atomic modesetting fixes

[Thomas Hellstrom]

Part of the pageflip functionality that was intended to be performed using
atomic commit was only present in the legacy pageflip ioctl. That problem
is fixed in this series.

We also better support nonblocking commits as some time-consuming operations
previously were performed in the calling process even if that process had
requested a non-blocking commit.

Finally we fix an issue where cursor image updates were performed on each
cursor move.

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