Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

[Nickey Yang]

Hi Brian,


On 2017年12月06日 02:56, Brian Norris wrote:

Hi Nickey,

On Tue, Dec 05, 2017 at 05:14:11PM +0800, Nickey Yang wrote:

On 2017年12月01日 18:07, Philippe CORNU wrote:

On 12/01/2017 10:11 AM, Nickey Yang wrote:

On 2017年12月01日 16:32, Philippe CORNU wrote:

I am sorry to say that but you can not add my "Acked-by" to this patch
because this code is different from the "original" one from Brian (which
got my "Acked-by").

I'm sorry I didn't think much about it, Thank you for correcting me.

Sometimes it is not an issue because differences are not important but
in this particular case, the code is really different: you have remove
platform_set_drvdata() & platform_get_drvdata() in the stm part.

Could you please go back to the original code or propose me an updated
version of this code.

Could you help update new version of this code(stm part) and then test on
stm platform?

I think you can simply goes back to the original version from Brian (see
the discussion thread in https://patchwork.kernel.org/patch/10078493/)
unless you have specific/good reasons for modifying the code as you did.

mmm,I'm sorry, I feel a little puzzled. Do you means we should abandon
Brian's patch (https://patchwork.kernel.org/patch/10078493/)?
I think we need to adjust stm part because  dw_mipi_dsi_stm.c calls
bridge's drivers if we want merge Brian's patch.

It's really simple. Your code is different from the patch I sent, and in
a way that Philippe did not like. I'll highlight it again below:


diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index e5b6310..80f9950 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -66,6 +66,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
struct clk *pllref_clk;
+   struct dw_mipi_dsi *dmd;
};
static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
@@ -318,10 +319,11 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
*pdev)
dw_mipi_dsi_stm_plat_data.base = dsi->base;
dw_mipi_dsi_stm_plat_data.priv_data = dsi;
-   ret = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
-   if (ret) {
+   dsi->dmd = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
+   if (IS_ERR(dsi->dmd)) {
DRM_ERROR("Failed to initialize mipi dsi host\n");
clk_disable_unprepare(dsi->pllref_clk);
+   return PTR_ERR(dsi->dmd);
}
return ret;
@@ -332,7 +334,7 @@ static int dw_mipi_dsi_stm_remove(struct platform_device 
*pdev)
struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
clk_disable_unprepare(dsi->pllref_clk);
-   dw_mipi_dsi_remove(pdev);
+   dw_mipi_dsi_remove(dsi->dmd);
return 0;
}
  
Above is your diff for dw_mipi_dsi-stm.c. Particularly, notice that

remove() is directly referencing the static dw_mipi_dsi_stm_plat_data
struct.

If you look back at my patch [1] you'll see that you're missing hunks
like this:


Thank you for pointing out my mistake.
I will fix this in next version.

Nickey.

  static int dw_mipi_dsi_stm_remove(struct platform_device *pdev)
  {
-   struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
+   struct dw_mipi_dsi_stm *dsi = platform_get_drvdata(pdev);
  
  	clk_disable_unprepare(dsi->pllref_clk);

[...]

Brian

[1] https://patchwork.kernel.org/patch/10078493/






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

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Greg KH]

On Tue, Dec 05, 2017 at 03:01:42PM -0800, Laura Abbott wrote:
> On 12/02/2017 07:53 AM, Greg KH wrote:
> > > This is one of the item in the TODO list before been able to unstage ION
> > > which is my real need.
> > Why does it matter where in the tree this code is?  Don't go adding new
> > things to it that are not needed.  Who needs this?  What userspace code
> > wants this type of multiple ion devices?
> > 
> 
> Requirements came in from several places to split /dev/ion -> /dev/ion0
> and /dev/ion1 so that security policy (i.e. selinux) could be used to
> protect access to certain heaps. I wanted the ABI to be settled before
> trying to move out of staging, hence the line in the TODO list about
> doing the split.

Ok, but we should have some way of testing it works, right?  :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi Rodrigo,

On Tue, 5 Dec 2017 17:21:54 -0800 Rodrigo Vivi  wrote:
>
> I had just written the email for you about this.
> Feel free to ignore that one since you already found the solution
> and sorry for the delay on warning you.

And I should read all my email before responding to earlier ones :-)

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

RE: [PATCH] drm/ttm: swap consecutive allocated pooled pages v4

[He, Roger]

Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Tuesday, December 05, 2017 8:55 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger 

Subject: [PATCH] drm/ttm: swap consecutive allocated pooled pages v4

When we detect consecutive allocation of pages swap them to avoid accidentally 
freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page
v4: don't touch the loop variable

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b6f7ce286fb1..44343a2bf55c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -958,8 +958,15 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
-   pages[count++] = p;
+   first = count;
+   list_for_each_entry(p, , lru) {
+   struct page *tmp = p;
+
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == tmp - 1)
+   swap(tmp, pages[count - 1]);
+   pages[count++] = tmp;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
--
2.11.0

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

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Rodrigo Vivi]

On Wed, Dec 06, 2017 at 01:00:15AM +, Stephen Rothwell wrote:
> Hi all,

Hi Stephen,

I had just written the email for you about this.
Feel free to ignore that one since you already found the solution
and sorry for the delay on warning you.

> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/i915/intel_dsi.c: In function 
> 'intel_dsi_get_panel_orientation':
> drivers/gpu/drm/i915/intel_dsi.c:1673:13: error: storage size of 'plane' 
> isn't known
>   enum plane plane;
>  ^
> 
> Caused by commit
> 
>   82daca297506 ("drm/i915: Add "panel orientation" property to the panel 
> connector, v6.")
> 
> interacting with commit
> 
>   ed15030d7ab0 ("drm/i915: s/enum plane/enum i9xx_plane_id/")
> 
> from the drm-intel tree.
> 
> I have applied the following merge fix patch for today.

Yes, that's the right one.

Thanks,
Rodrigo.

> 
> From: Stephen Rothwell 
> Date: Wed, 6 Dec 2017 11:56:32 +1100
> Subject: [PATCH] drm/i915: fix up for "drm/i915: s/enum plane/enum
>  i9xx_plane_id/"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 1b60df3c14a0..f67d321376e4 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
> intel_connector *connector)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> - enum plane plane;
> + enum i9xx_plane_id plane;
>   u32 val;
>  
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> -- 
> 2.15.0
> 
> -- 
> Cheers,
> Stephen Rothwell
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 374/671] 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:   135bf5e44b3f1a665c9b9aeba34083ce3c626d6e
commit: c1888183e1764d55d51ae051bd8651e634febe4d [374/671] ASoC: AMD: enable 
ACP3x drivers build
config: tile-allyesconfig (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 c1888183e1764d55d51ae051bd8651e634febe4d
# 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

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

linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/i915/intel_dsi.c: In function 'intel_dsi_get_panel_orientation':
drivers/gpu/drm/i915/intel_dsi.c:1673:13: error: storage size of 'plane' isn't 
known
  enum plane plane;
 ^

Caused by commit

  82daca297506 ("drm/i915: Add "panel orientation" property to the panel 
connector, v6.")

interacting with commit

  ed15030d7ab0 ("drm/i915: s/enum plane/enum i9xx_plane_id/")

from the drm-intel tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell 
Date: Wed, 6 Dec 2017 11:56:32 +1100
Subject: [PATCH] drm/i915: fix up for "drm/i915: s/enum plane/enum
 i9xx_plane_id/"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/intel_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1b60df3c14a0..f67d321376e4 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1670,7 +1670,7 @@ static int intel_dsi_get_panel_orientation(struct 
intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
-   enum plane plane;
+   enum i9xx_plane_id plane;
u32 val;
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH v3 4/9] drm: Add some HDCP related #defines

[Chris Wilson]

Quoting Sean Paul (2017-12-05 05:15:03)
> In preparation for implementing HDCP in i915, add some HDCP related
> register offsets and defines. The dpcd register offsets will go in
> drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
> will get stuffed in drm_hdcp.h, which is new.
> 
> Changes in v2:
> - drm_hdcp.h gets MIT license (Daniel)

Speaking of licences, what's the right spdx for drm files?
SPDX-License-Identifier: (GPL-2.0+ OR MIT) ?
It looks like we've already grown quite a few BSD-unfriendly files...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

[Chris Wilson]

Quoting Sean Paul (2017-12-05 05:15:01)
> This patch adds a little more control to a couple wait_for routines such
> that we can avoid open-coding read/wait/timeout patterns which:
>  - need the value of the register after the wait_for
>  - run arbitrary operation for the read portion
> 
> This patch also chooses the correct sleep function (based on
> timers-howto.txt) for the polling interval the caller specifies.
> 
> Changes in v2:
> - Added to the series
> Changes in v3:
> - Rebased on drm-intel-next-queued and the new Wmin/max _wait_for
> - Removed msleep option
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/intel_drv.h| 17 ++---
>  drivers/gpu/drm/i915/intel_uncore.c | 23 ---
>  drivers/gpu/drm/i915/intel_uncore.h | 14 +-
>  3 files changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 64426d3e078e..852b3d161754 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,20 +41,21 @@
>  #include 
>  
>  /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
>   *
> - * Does the right thing for modeset paths when run under kdgb or similar 
> atomic
> - * contexts. Note that it's important that we check the condition again after
> - * having timed out, since the timeout could be due to preemption or similar 
> and
> - * we've never had a chance to check the condition before the timeout.
> + * Macro to help avoid open coding check/wait/timeout patterns. Note that 
> it's
> + * important that we check the condition again after having timed out, since 
> the
> + * timeout could be due to preemption or similar and we've never had a 
> chance to
> + * check the condition before the timeout.
>   */
> -#define _wait_for(COND, US, Wmin, Wmax) ({ \
> +#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
> unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
> long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
> int ret__;  \
> might_sleep();  \
> for (;;) {  \
> bool expired__ = time_after(jiffies, timeout__);\
> +   OP; \
> if (COND) { \
> ret__ = 0;  \
> break;  \
> @@ -70,7 +71,9 @@
> ret__;  \
>  })
>  
> -#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
> +#define _wait_for(COND, US, Wmin, Wmax)__wait_for(;, (COND), (US), 
> (Wmin), \
> +  (Wmax))

Hmm, doesn't an empty OP (__wait_for(, ...)) work?

> +int __intel_wait_for_register(struct drm_i915_private *dev_priv,
> i915_reg_t reg,
> u32 mask,
> u32 value,
> -   unsigned int timeout_ms)
> +   unsigned int fast_timeout_us,
> +   unsigned int slow_timeout_ms,
> +   u32 *out_value)
>  {
> unsigned fw =
> intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
> int ret;
> +   u32 reg_value;

Before int ret; Try to avoid building a Christmas tree if possible.

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

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Laura Abbott]

On 12/02/2017 07:53 AM, Greg KH wrote:

This is one of the item in the TODO list before been able to unstage ION
which is my real need.

Why does it matter where in the tree this code is?  Don't go adding new
things to it that are not needed.  Who needs this?  What userspace code
wants this type of multiple ion devices?



Requirements came in from several places to split /dev/ion -> /dev/ion0
and /dev/ion1 so that security policy (i.e. selinux) could be used to
protect access to certain heaps. I wanted the ABI to be settled before
trying to move out of staging, hence the line in the TODO list about
doing the split.


thanks,

greg k-h


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

Re: [PATCH 0/2] Move scheduler out of AMDGPU

[Alex Deucher]

On Tue, Dec 5, 2017 at 4:18 AM, Lucas Stach  wrote:
> Hi Alex,
>
> Am Montag, den 04.12.2017, 16:47 -0500 schrieb Alex Deucher:
>> On Fri, Dec 1, 2017 at 10:55 AM, Christian König
>> >  wrote:
>> > Am 01.12.2017 um 16:28 schrieb Lucas Stach:
>> > >
>> > > Hi all,
>> > >
>> > > so this is the first step to make the marvelous AMDGPU scheduler useable
>> > > for other drivers. I have a (mostly) working prototype of Etnaviv using
>> > > the scheduler, but those patches need to keep baking for a while.
>> > >
>> > > I'm sending this out as I want to avoid rebasing this change too much
>> > > and don't want to take people by surprise when the Etnaviv implementation
>> > > surfaces. Also this might need some coordination between AMDGPU and
>> > > Etnaviv, which might be good to get going now.
>> > >
>> > > Please speak up now if you have any objections or comments.
>> >
>> >
>> > Looks good to me, but question is what is this based upon?
>> >
>> > I strongly assume drm-next, so question is now if we have any patches 
>> > inside
>> > amd branches we should apply before doing this.
>>
>> We have a bunch of changes queued up which will go usptream for 4.16.
>> See amd-staging-drm-next:
>> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
>> which is a mirror of our main development branch or:
>> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.16-wip
>> which is what is currently queued for 4.16.
>
> Is this branch/tag stable?
>

amd-staging-drm-next rebases periodically.  The wip branches are not
stable.  I'll be sending out a pull request for 4.16 in the next day
or two and that branch (drm-next-4.16) will be stable.

> How would you like to handle the merge? Should I send out patches for
> you to apply and you get me a stable branch to pull into etnaviv, or
> should I provide a stable branch based on the above to pull into both
> amdgpu and etnaviv?

If you want to send patches against amd-staging-drm-next, I can pull
them into our system and include them in my next pull request after
we've tested them internally.  At that point, you can either pull my
stable branch or wait until it gets into Dave's drm-next branch.

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

Re: [PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

[Alex Deucher]

On Tue, Dec 5, 2017 at 1:24 PM, Noralf Trønnes  wrote:
> The helpers are applied and have reached airlied/drm-next.
>
> amd has gained another .poll_changed user since last.

Patches 1, 2, 9 applied to my -next tree.  Thanks!

Alex

>
> i915 doesn't really need the .poll_changed helper since it now does a
> sync and has to open code it after:
> drm/i915/fbdev: Serialise early hotplug events with async fbdev config
>
> vboxvideo will be re-sent when the helper functions have landed in
> Greg's staging tree.
>
> Noralf.
>
> Changes since version 2:
> - Helper functions have been applied
> - Add drm/amd/display: Use drm_fb_helper_poll_changed()
> - Rebase drm/amdgpu patch
> - Rebase drm/msm patch
> - Drop i915 patch, not applicable after:
>   drm/i915/fbdev: Serialise early hotplug events with async fbdev config
> - Drop vboxvideo patch, it will be re-sent when the helper functions
>   have reached Greg's staging tree.
>
> Changes since version 1:
> - drm_device.drm_fb_helper_private -> drm_device.fb_helper (Ville)
>
> Noralf Trønnes (11):
>   drm/amd/display: Use drm_fb_helper_poll_changed()
>   drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/nouveau: Use drm_fb_helper_output_poll_changed()
>   drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
>   drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  9 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 27 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  4 ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
>  drivers/gpu/drm/armada/armada_drm.h   |  1 -
>  drivers/gpu/drm/armada/armada_drv.c   |  8 ++
>  drivers/gpu/drm/armada/armada_fb.c| 11 +---
>  drivers/gpu/drm/armada/armada_fbdev.c |  8 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
>  drivers/gpu/drm/gma500/framebuffer.c  |  9 +-
>  drivers/gpu/drm/gma500/psb_drv.c  | 15 +-
>  drivers/gpu/drm/msm/msm_drv.c | 18 ++--
>  drivers/gpu/drm/nouveau/nouveau_display.c |  3 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  8 --
>  drivers/gpu/drm/nouveau/nouveau_fbcon.h   |  2 --
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  3 +-
>  drivers/gpu/drm/nouveau/nv50_display.c|  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c| 34 
> ++-
>  drivers/gpu/drm/radeon/radeon_display.c   |  9 ++
>  drivers/gpu/drm/radeon/radeon_fb.c| 22 ---
>  drivers/gpu/drm/radeon/radeon_kms.c   |  5 ++--
>  drivers/gpu/drm/radeon/radeon_mode.h  |  3 --
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  9 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  9 +-
>  drivers/gpu/drm/tegra/drm.c   | 13 ++---
>  drivers/gpu/drm/tegra/drm.h   |  4 ---
>  drivers/gpu/drm/tegra/fb.c| 14 --
>  32 files changed, 29 insertions(+), 259 deletions(-)
>
> --
> 2.14.2
>
> ___
> 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

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #16 from denisgolo...@yandex.ru ---
Created attachment 135989
  --> https://bugs.freedesktop.org/attachment.cgi?id=135989=edit
dmesg with vblank interrupt

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

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Daniel Stone]

Hi Pavel,

On 5 December 2017 at 17:34, Pavel Machek  wrote:
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
> Users compiling their own kernels get no benefit from it. Actually it
> looks like this only benefits Intel and Disney. We don't want that.

With all due respect, you can't claim to speak for the entire kernel
and FLOSS community of users and developers.

The feature is optional: it does not enforce additional constraints on
users, but exposes additional functionality already present in
hardware, for those who wish to opt in to it. Those who wish to avoid
it can do so, by simply not making active use of it.

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

Re: [PATCH v2 00/27] Improve DE2 support

[Maxime Ripard]

Hi,

On Tue, Dec 05, 2017 at 04:52:57PM +0100, Jernej Škrabec wrote:
> Dne torek, 05. december 2017 ob 11:36:18 CET je Maxime Ripard napisal(a):
> > Hi,
> > 
> > On Fri, Dec 01, 2017 at 07:05:23AM +0100, Jernej Skrabec wrote:
> > > Current DE2 driver is very basic and uses a lot of magic constants since
> > > there is no documentation and knowledge about it was limited at the time.
> > > 
> > > With studying BSP source code, deeper knowledge was gained which allows
> > > to improve mainline driver considerably.
> > > 
> > > At the beginning of this series, some code refactoring is done as well
> > > as adding some checks (patches 1-15).
> > > 
> > > Further patches add multi-plane support with HW scaling and all possible
> > > RGB formats (patches 16-21).
> > > 
> > > At last, support for YUV formats is added (patches 22-26).
> > > 
> > > At the end, I included patch which puts lowest plane before second lowest.
> > > This should help testing VI planes when mixer has configuration 1 VI plane
> > > and 1 or more UI planes (most SoCs except V3s).
> > > 
> > > This code was developed on H3, but it should work on every SoC if correct
> > > configuration structure is provided.
> > > 
> > > H3 code can be found here:
> > > https://github.com/jernejsk/linux-1/commits/de2_impr_for_next
> > 
> > Thanks a lot for that huge rework.
> > 
> > I've applied the patches 1 to 26, and will push them to drm-misc once
> > the compilations are done.
> > 
> > In the future, if you happen to do such a huge rework again (which
> > hopefully won't be needed :)), please use the -M option of
> > format-patch. It will reduce a lot the verbosity of files renaming and
> > will help the review.
> 
> Noted.

It turned out that there was also a change queued for drm-misc that
was renaming (and changing the prototype of)
drm_plane_helper_check_state into
drm_atomic_helper_check_plane_state. I fixed that up in tree, and
tested on the A83t, but you probably want to double check.

> I think I missed initialization of min_scaler and max_scaler in 
> sun8i_vi_layer_atomic_check() in sun8i_vi_layer.c when I was reworking 
> patches.
> 
> Will you fix patch with those two lines
> min_scale = DRM_PLANE_HELPER_NO_SCALING;
> max_scale = DRM_PLANE_HELPER_NO_SCALING;
> 
> or should I send new patch which fixes that or should I send new version of 
> original patch?

We don't rebase in drm-misc, so please send an additional patch.

Thanks!
Maxime

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


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

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

[bugzilla-daemon]

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

--- Comment #20 from Christoph Schwerdtfeger  ---
I recompiled Mesa with LLVM 6.0 but that didn't change anything.

# glxinfo | grep -i llvm
Device: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 6.0.0) (0x679a)
OpenGL renderer string: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 6.0.0)

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

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Sean Paul]

On Tue, Dec 5, 2017 at 12:34 PM, Pavel Machek  wrote:
> On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
>> On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote:
>> > On Wed 2017-11-29 22:08:56, Sean Paul wrote:
>> > > This patch adds a new optional connector property to allow userspace to 
>> > > enable
>> > > protection over the content it is displaying. This will typically be 
>> > > implemented
>> > > by the driver using HDCP.
>> > >
>> > > The property is a tri-state with the following values:
>> > > - OFF: Self explanatory, no content protection
>> > > - DESIRED: Userspace requests that the driver enable protection
>> > > - ENABLED: Once the driver has authenticated the link, it sets this value
>> > >
>> > > The driver is responsible for downgrading ENABLED to DESIRED if the link 
>> > > becomes
>> > > unprotected. The driver should also maintain the desiredness of 
>> > > protection
>> > > across hotplug/dpms/suspend.
>> >
>> > Why would user of the machine want this to be something else than
>> > 'OFF'?
>> >
>> > If kernel implements this, will it mean hardware vendors will have to
>> > prevent user from updating kernel on machines they own?
>> >
>> > If this is merged, does it open kernel developers to DMCA threats if
>> > they try to change it?
>>
>> Because this just implements one part of the content protection scheme.
>> This only gives you an option to enable HDCP (aka encryption, it's really
>> nothing else) on the cable. Just because it has Content Protection in the
>> name does _not_ mean it is (stand-alone) an effective nor complete content
>> protection scheme. It's simply encrypting data, that's all.
>
> Yep. So my first question was: why would user of the machine ever want
> encryption "ENABLED" or "DESIRED"? Could you answer it?
>

Sure. We have a lot of Chrome OS users who would really like to enjoy
premium hd content on their tvs.


>> If you want to actually lock down a machine to implement content
>> protection, then you need secure boot without unlockable boot-loader and a
>> pile more bits in userspace.  If you do all that, only then do you have
>> full content protection. And yes, then you don't really own the machine
>> fully, and I think users who are concerned with being able to update
>> their
>
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
> Users compiling their own kernels get no benefit from it. Actually it
> looks like this only benefits Intel and Disney. We don't want that.
>

Major citation needed here. Did you actually read the code? If you
did, you would realize that the feature is already latent in your
computer. This patchset merely exposes how that hardware can be
enabled to encrypt your video link. Would you have the same problems
with a new whizzbang video encoding format, or is it just the "Content
Protection" name? Perhaps you'd prefer this feature was implemented in
Intel's firmware, or a userspace blob? It wouldn't change the fact
that those registers exist and _can_ be used for HDCP, it's just that
now you know about it.

Having all of the code in the open allows users to see what is
happening with their hardware, how is this a bad thing?

Sean


>> kernels and be able to exercise their software freedoms already know to
>> avoid such locked down systems.
>>
>> So yeah it would be better to call this the "HDMI/DP cable encryption
>> support", but well, it's not what it's called really.
>
> Well, it does not belong in kernel, no matter what is the name.
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

[Brian Norris]

Hi Nickey,

On Tue, Dec 05, 2017 at 05:14:11PM +0800, Nickey Yang wrote:
> On 2017年12月01日 18:07, Philippe CORNU wrote:
> >On 12/01/2017 10:11 AM, Nickey Yang wrote:
> >>On 2017年12月01日 16:32, Philippe CORNU wrote:
> >>>I am sorry to say that but you can not add my "Acked-by" to this patch
> >>>because this code is different from the "original" one from Brian (which
> >>>got my "Acked-by").
> >>I'm sorry I didn't think much about it, Thank you for correcting me.
> >>>Sometimes it is not an issue because differences are not important but
> >>>in this particular case, the code is really different: you have remove
> >>>platform_set_drvdata() & platform_get_drvdata() in the stm part.
> >>>
> >>>Could you please go back to the original code or propose me an updated
> >>>version of this code.
> >>Could you help update new version of this code(stm part) and then test on
> >>stm platform?
> >I think you can simply goes back to the original version from Brian (see
> >the discussion thread in https://patchwork.kernel.org/patch/10078493/)
> >unless you have specific/good reasons for modifying the code as you did.
> mmm,I'm sorry, I feel a little puzzled. Do you means we should abandon
> Brian's patch (https://patchwork.kernel.org/patch/10078493/)?
> I think we need to adjust stm part because  dw_mipi_dsi_stm.c calls
> bridge's drivers if we want merge Brian's patch.

It's really simple. Your code is different from the patch I sent, and in
a way that Philippe did not like. I'll highlight it again below:

> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index e5b6310..80f9950 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -66,6 +66,7 @@ enum dsi_color {
> struct dw_mipi_dsi_stm {
>   void __iomem *base;
>   struct clk *pllref_clk;
> + struct dw_mipi_dsi *dmd;
> };
> static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, 
>  u32 val)
> @@ -318,10 +319,11 @@ static int dw_mipi_dsi_stm_probe(struct 
> platform_device *pdev)
>   dw_mipi_dsi_stm_plat_data.base = dsi->base;
>   dw_mipi_dsi_stm_plat_data.priv_data = dsi;
> - ret = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
> - if (ret) {
> + dsi->dmd = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
> + if (IS_ERR(dsi->dmd)) {
>   DRM_ERROR("Failed to initialize mipi dsi host\n");
>   clk_disable_unprepare(dsi->pllref_clk);
> + return PTR_ERR(dsi->dmd);
>   }
>   return ret;
> @@ -332,7 +334,7 @@ static int dw_mipi_dsi_stm_remove(struct 
> platform_device *pdev)
>   struct dw_mipi_dsi_stm *dsi = 
>  dw_mipi_dsi_stm_plat_data.priv_data;
>   clk_disable_unprepare(dsi->pllref_clk);
> - dw_mipi_dsi_remove(pdev);
> + dw_mipi_dsi_remove(dsi->dmd);
>   return 0;
> }
 
Above is your diff for dw_mipi_dsi-stm.c. Particularly, notice that
remove() is directly referencing the static dw_mipi_dsi_stm_plat_data
struct.

If you look back at my patch [1] you'll see that you're missing hunks
like this:

 static int dw_mipi_dsi_stm_remove(struct platform_device *pdev)
 {
-   struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
+   struct dw_mipi_dsi_stm *dsi = platform_get_drvdata(pdev);
 
clk_disable_unprepare(dsi->pllref_clk);
[...]

Brian

[1] https://patchwork.kernel.org/patch/10078493/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #14 from vkr...@yahoo.com ---
Hi Rene,

Sorry for the delay in responding. Thanks for your suggestion regarding the
pcieport module. Adding it to RUNTIME_PM_DRIVER_BLACKLIST does fix the problem
while TLP is installed.

Vadym

-- 
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 1/2] drm/nouveau/bar/gf100: fix hang when calling ->fini() before ->init()

[Ben Skeggs]

On Wed, Dec 6, 2017 at 12:30 AM, Jon Hunter  wrote:

>
> On 04/12/17 18:37, Guillaume Tucker wrote:
> > If the firmware fails to load then ->fini() will be called before the
> > device has been initialised, causing the kernel to hang while trying
> > to write to a register.  Add a test in ->fini() to avoid this issue.
> >
> > This fixes a kernel hang on tegra124.
> >
> > Fixes: b17de35a2ebbe ("drm/nouveau/bar: implement bar1 teardown")
> > Signed-off-by: Guillaume Tucker 
> > CC: Ben Skeggs 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> > index a3ba7f50198b..95e2aba64aad 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> > @@ -43,9 +43,12 @@ gf100_bar_bar1_wait(struct nvkm_bar *base)
> >  }
> >
> >  void
> > -gf100_bar_bar1_fini(struct nvkm_bar *bar)
> > +gf100_bar_bar1_fini(struct nvkm_bar *base)
> >  {
> > - nvkm_mask(bar->subdev.device, 0x001704, 0x8000, 0x);
> > + struct nvkm_device *device = base->subdev.device;
> > +
> > + if (base->subdev.oneinit)
> > + nvkm_mask(device, 0x001704, 0x8000, 0x);
> >  }
> >
> >  void
>
> I have tested this and it works for me. Thanks for fixing this! Would be
> good to get Ben's ACK, but you can have my ...
>
I'd love to get a good explanation as to why it hangs without this change,
as, on the surface, it's not immediately obvious as to why it's hanging.

Thanks,
Ben.


>
> Tested-by: Jon Hunter 
>
> Cheers
> Jon
>
> --
> nvpublic
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 11/11] drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Thierry Reding 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 13 ++---
 drivers/gpu/drm/tegra/drm.h |  4 
 drivers/gpu/drm/tegra/fb.c  | 14 --
 3 files changed, 2 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 52552b9b89ef..f157bc675269 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -120,7 +120,7 @@ static int tegra_atomic_commit(struct drm_device *drm,
 static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
 #ifdef CONFIG_DRM_FBDEV_EMULATION
-   .output_poll_changed = tegra_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 #endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = tegra_atomic_commit,
@@ -286,15 +286,6 @@ static void tegra_drm_context_free(struct 
tegra_drm_context *context)
kfree(context);
 }
 
-static void tegra_drm_lastclose(struct drm_device *drm)
-{
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   struct tegra_drm *tegra = drm->dev_private;
-
-   tegra_fbdev_restore_mode(tegra->fbdev);
-#endif
-}
-
 static struct host1x_bo *
 host1x_bo_lookup(struct drm_file *file, u32 handle)
 {
@@ -1100,7 +1091,7 @@ static struct drm_driver tegra_drm_driver = {
.unload = tegra_drm_unload,
.open = tegra_drm_open,
.postclose = tegra_drm_postclose,
-   .lastclose = tegra_drm_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = tegra_debugfs_init,
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index ddae331ad8b6..0009f6ea21b6 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -188,10 +188,6 @@ int tegra_drm_fb_init(struct drm_device *drm);
 void tegra_drm_fb_exit(struct drm_device *drm);
 void tegra_drm_fb_suspend(struct drm_device *drm);
 void tegra_drm_fb_resume(struct drm_device *drm);
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
-void tegra_fb_output_poll_changed(struct drm_device *drm);
-#endif
 
 extern struct platform_driver tegra_dc_driver;
 extern struct platform_driver tegra_hdmi_driver;
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 80540c1c66dc..8dfe3c6c217e 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -361,20 +361,6 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
drm_fb_helper_fini(>base);
tegra_fbdev_free(fbdev);
 }
-
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev)
-{
-   if (fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(>base);
-}
-
-void tegra_fb_output_poll_changed(struct drm_device *drm)
-{
-   struct tegra_drm *tegra = drm->dev_private;
-
-   if (tegra->fbdev)
-   drm_fb_helper_hotplug_event(>fbdev->base);
-}
 #endif
 
 int tegra_drm_fb_prepare(struct drm_device *drm)
-- 
2.14.2

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

[PATCH v3 10/11] drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Mark Yao 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 9 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 9 +
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76d63de5921d..d85431400a0d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -207,13 +207,6 @@ static void rockchip_drm_unbind(struct device *dev)
drm_dev_unref(drm_dev);
 }
 
-static void rockchip_drm_lastclose(struct drm_device *dev)
-{
-   struct rockchip_drm_private *priv = dev->dev_private;
-
-   drm_fb_helper_restore_fbdev_mode_unlocked(>fbdev_helper);
-}
-
 static const struct file_operations rockchip_drm_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -228,7 +221,7 @@ static const struct file_operations 
rockchip_drm_driver_fops = {
 static struct drm_driver rockchip_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM |
  DRIVER_PRIME | DRIVER_ATOMIC,
-   .lastclose  = rockchip_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.gem_vm_ops = _gem_cma_vm_ops,
.gem_free_object_unlocked = rockchip_gem_free_object,
.dumb_create= rockchip_gem_dumb_create,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index cd2ace0c3caa..e266539e04e5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -167,20 +167,13 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(ret);
 }
 
-static void rockchip_drm_output_poll_changed(struct drm_device *dev)
-{
-   struct rockchip_drm_private *private = dev->dev_private;
-
-   drm_fb_helper_hotplug_event(>fbdev_helper);
-}
-
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
.fb_create = rockchip_user_fb_create,
-   .output_poll_changed = rockchip_drm_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.14.2

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

[PATCH v3 08/11] drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Tomi Valkeinen 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 34 ++
 1 file changed, 2 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index cdf5b0601eba..96857c508ee0 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -46,14 +46,6 @@
  * devices
  */
 
-static void omap_fb_output_poll_changed(struct drm_device *dev)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   DBG("dev=%p", dev);
-   if (priv->fbdev)
-   drm_fb_helper_hotplug_event(priv->fbdev);
-}
-
 static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
 {
@@ -132,7 +124,7 @@ static const struct drm_mode_config_helper_funcs 
omap_mode_config_helper_funcs =
 
 static const struct drm_mode_config_funcs omap_mode_config_funcs = {
.fb_create = omap_framebuffer_create,
-   .output_poll_changed = omap_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -467,28 +459,6 @@ static int dev_open(struct drm_device *dev, struct 
drm_file *file)
return 0;
 }
 
-/**
- * lastclose - clean up after all DRM clients have exited
- * @dev: DRM device
- *
- * Take care of cleaning up after all DRM clients have exited.  In the
- * mode setting case, we want to restore the kernel's initial mode (just
- * in case the last client left us in a bad state).
- */
-static void dev_lastclose(struct drm_device *dev)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   int ret;
-
-   DBG("lastclose: dev=%p", dev);
-
-   if (priv->fbdev) {
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-   if (ret)
-   DBG("failed to restore crtc mode");
-   }
-}
-
 static const struct vm_operations_struct omap_gem_vm_ops = {
.fault = omap_gem_fault,
.open = drm_gem_vm_open,
@@ -511,7 +481,7 @@ static struct drm_driver omap_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM  | DRIVER_PRIME |
DRIVER_ATOMIC | DRIVER_RENDER,
.open = dev_open,
-   .lastclose = dev_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
 #endif
-- 
2.14.2

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

[PATCH v3 07/11] drm/nouveau: Use drm_fb_helper_output_poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_output_poll_changed() instead of
its own nouveau_fbcon_output_poll_changed().

Cc: Ben Skeggs 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 3 ++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 8 
 drivers/gpu/drm/nouveau/nouveau_fbcon.h   | 2 --
 drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
 drivers/gpu/drm/nouveau/nv50_display.c| 2 +-
 5 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 2e7785f49e6d..009713404cc4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -292,7 +293,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
 
 static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
.fb_create = nouveau_user_framebuffer_create,
-   .output_poll_changed = nouveau_fbcon_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index c533d8e04afc..45a4572cd2fb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -413,14 +413,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void
-nouveau_fbcon_output_poll_changed(struct drm_device *dev)
-{
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon)
-   drm_fb_helper_hotplug_event(>fbcon->helper);
-}
-
 static int
 nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.h 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
index e2bca729721e..a6f192ea3fa6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
@@ -68,8 +68,6 @@ void nouveau_fbcon_set_suspend(struct drm_device *dev, int 
state);
 void nouveau_fbcon_accel_save_disable(struct drm_device *dev);
 void nouveau_fbcon_accel_restore(struct drm_device *dev);
 
-void nouveau_fbcon_output_poll_changed(struct drm_device *dev);
-
 extern int nouveau_nofbaccel;
 
 #endif /* __NV50_FBCON_H__ */
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 52e52a360fb1..3da5a4305aa4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_acpi.h"
@@ -61,7 +62,7 @@ static void
 nouveau_switcheroo_reprobe(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   nouveau_fbcon_output_poll_changed(dev);
+   drm_fb_helper_output_poll_changed(dev);
 }
 
 static bool
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 65336948e807..b22c37bde13f 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4311,7 +4311,7 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev)
 static const struct drm_mode_config_funcs
 nv50_disp_func = {
.fb_create = nouveau_user_framebuffer_create,
-   .output_poll_changed = nouveau_fbcon_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = nv50_disp_atomic_check,
.atomic_commit = nv50_disp_atomic_commit,
.atomic_state_alloc = nv50_disp_atomic_state_alloc,
-- 
2.14.2

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

[PATCH v3 09/11] drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() in its .lastclose function.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/radeon/radeon_display.c |  9 ++---
 drivers/gpu/drm/radeon/radeon_fb.c  | 22 --
 drivers/gpu/drm/radeon/radeon_kms.c |  5 ++---
 drivers/gpu/drm/radeon/radeon_mode.h|  3 ---
 4 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index ddfe91efa61e..dfda5e0ed166 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1362,15 +1363,9 @@ radeon_user_framebuffer_create(struct drm_device *dev,
return _fb->base;
 }
 
-static void radeon_output_poll_changed(struct drm_device *dev)
-{
-   struct radeon_device *rdev = dev->dev_private;
-   radeon_fb_output_poll_changed(rdev);
-}
-
 static const struct drm_mode_config_funcs radeon_mode_funcs = {
.fb_create = radeon_user_framebuffer_create,
-   .output_poll_changed = radeon_output_poll_changed
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static const struct drm_prop_enum_list radeon_tmds_pll_enum_list[] =
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index 33b821d6d018..57c5404a1654 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -306,12 +306,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void radeon_fb_output_poll_changed(struct radeon_device *rdev)
-{
-   if (rdev->mode_info.rfbdev)
-   drm_fb_helper_hotplug_event(>mode_info.rfbdev->helper);
-}
-
 static int radeon_fbdev_destroy(struct drm_device *dev, struct radeon_fbdev 
*rfbdev)
 {
struct radeon_framebuffer *rfb = >rfb;
@@ -422,19 +416,3 @@ void radeon_fb_remove_connector(struct radeon_device 
*rdev, struct drm_connector
if (rdev->mode_info.rfbdev)

drm_fb_helper_remove_one_connector(>mode_info.rfbdev->helper, connector);
 }
-
-void radeon_fbdev_restore_mode(struct radeon_device *rdev)
-{
-   struct radeon_fbdev *rfbdev = rdev->mode_info.rfbdev;
-   struct drm_fb_helper *fb_helper;
-   int ret;
-
-   if (!rfbdev)
-   return;
-
-   fb_helper = >helper;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-}
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index cde037f213d7..dec1e081f529 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -26,6 +26,7 @@
  *  Jerome Glisse
  */
 #include 
+#include 
 #include "radeon.h"
 #include 
 #include "radeon_asic.h"
@@ -629,9 +630,7 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  */
 void radeon_driver_lastclose_kms(struct drm_device *dev)
 {
-   struct radeon_device *rdev = dev->dev_private;
-
-   radeon_fbdev_restore_mode(rdev);
+   drm_fb_helper_lastclose(dev);
vga_switcheroo_process_delayed_switch();
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index ca0a7ed28c9b..3243e5e01432 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -984,9 +984,6 @@ int radeon_fbdev_init(struct radeon_device *rdev);
 void radeon_fbdev_fini(struct radeon_device *rdev);
 void radeon_fbdev_set_suspend(struct radeon_device *rdev, int state);
 bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo 
*robj);
-void radeon_fbdev_restore_mode(struct radeon_device *rdev);
-
-void radeon_fb_output_poll_changed(struct radeon_device *rdev);
 
 void radeon_crtc_handle_vblank(struct radeon_device *rdev, int crtc_id);
 
-- 
2.14.2

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

[PATCH v3 06/11] drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Rob Clark 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/msm/msm_drv.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0a3ea3034e39..d90ef1d78a1b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -37,16 +37,9 @@
 #define MSM_VERSION_MINOR  3
 #define MSM_VERSION_PATCHLEVEL 0
 
-static void msm_fb_output_poll_changed(struct drm_device *dev)
-{
-   struct msm_drm_private *priv = dev->dev_private;
-   if (priv->fbdev)
-   drm_fb_helper_hotplug_event(priv->fbdev);
-}
-
 static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = msm_framebuffer_create,
-   .output_poll_changed = msm_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = msm_atomic_commit,
.atomic_state_alloc = msm_atomic_state_alloc,
@@ -551,13 +544,6 @@ static void msm_postclose(struct drm_device *dev, struct 
drm_file *file)
context_close(ctx);
 }
 
-static void msm_lastclose(struct drm_device *dev)
-{
-   struct msm_drm_private *priv = dev->dev_private;
-   if (priv->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-}
-
 static irqreturn_t msm_irq(int irq, void *arg)
 {
struct drm_device *dev = arg;
@@ -866,7 +852,7 @@ static struct drm_driver msm_driver = {
DRIVER_MODESET,
.open   = msm_open,
.postclose   = msm_postclose,
-   .lastclose  = msm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.irq_handler= msm_irq,
.irq_preinstall = msm_irq_preinstall,
.irq_postinstall= msm_irq_postinstall,
-- 
2.14.2

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

[PATCH v3 04/11] drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
 4 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 82b72425a42f..2f2bd6e37e62 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -89,11 +90,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
file->driver_priv = NULL;
 }
 
-static void exynos_drm_lastclose(struct drm_device *dev)
-{
-   exynos_drm_fbdev_restore_mode(dev);
-}
-
 static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
.fault = exynos_drm_gem_fault,
.open = drm_gem_vm_open,
@@ -140,7 +136,7 @@ static struct drm_driver exynos_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
  | DRIVER_ATOMIC | DRIVER_RENDER,
.open   = exynos_drm_open,
-   .lastclose  = exynos_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.postclose  = exynos_drm_postclose,
.gem_free_object_unlocked = exynos_drm_gem_free_object,
.gem_vm_ops = _drm_gem_vm_ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 8208df56a88f..0faaf829f5bf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -205,7 +205,7 @@ static struct drm_mode_config_helper_funcs 
exynos_drm_mode_config_helpers = {
 
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
-   .output_poll_changed = exynos_drm_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = exynos_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
 };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index dfb66ecf417b..132dd52d0ac7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -270,24 +270,6 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
private->fb_helper = NULL;
 }
 
-void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-
-   if (!private || !private->fb_helper)
-   return;
-
-   drm_fb_helper_restore_fbdev_mode_unlocked(private->fb_helper);
-}
-
-void exynos_drm_output_poll_changed(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-   struct drm_fb_helper *fb_helper = private->fb_helper;
-
-   drm_fb_helper_hotplug_event(fb_helper);
-}
-
 void exynos_drm_fbdev_suspend(struct drm_device *dev)
 {
struct exynos_drm_private *private = dev->dev_private;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
index 645d1bb7f665..b33847223a85 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
@@ -19,8 +19,6 @@
 
 int exynos_drm_fbdev_init(struct drm_device *dev);
 void exynos_drm_fbdev_fini(struct drm_device *dev);
-void exynos_drm_fbdev_restore_mode(struct drm_device *dev);
-void exynos_drm_output_poll_changed(struct drm_device *dev);
 void exynos_drm_fbdev_suspend(struct drm_device *drm);
 void exynos_drm_fbdev_resume(struct drm_device *drm);
 
-- 
2.14.2

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

[PATCH v3 05/11] drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Patrik Jakobsson 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/framebuffer.c |  9 +
 drivers/gpu/drm/gma500/psb_drv.c | 15 +--
 2 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 2570c7f647a6..cb0a2ae916e0 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -576,13 +576,6 @@ static void psb_fbdev_fini(struct drm_device *dev)
dev_priv->fbdev = NULL;
 }
 
-static void psbfb_output_poll_changed(struct drm_device *dev)
-{
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_fbdev *fbdev = (struct psb_fbdev *)dev_priv->fbdev;
-   drm_fb_helper_hotplug_event(>psb_fb_helper);
-}
-
 /**
  * psb_user_framebuffer_create_handle - add hamdle to a framebuffer
  * @fb: framebuffer
@@ -623,7 +616,7 @@ static void psb_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 
 static const struct drm_mode_config_funcs psb_mode_funcs = {
.fb_create = psb_user_framebuffer_create,
-   .output_poll_changed = psbfb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static void psb_setup_outputs(struct drm_device *dev)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 8f5cc1f471cd..38d09d4b3ed5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -107,19 +107,6 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
 static const struct drm_ioctl_desc psb_ioctls[] = {
 };
 
-static void psb_driver_lastclose(struct drm_device *dev)
-{
-   int ret;
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_fbdev *fbdev = dev_priv->fbdev;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(>psb_fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-
-   return;
-}
-
 static int psb_do_init(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
@@ -479,7 +466,7 @@ static struct drm_driver driver = {
   DRIVER_MODESET | DRIVER_GEM,
.load = psb_driver_load,
.unload = psb_driver_unload,
-   .lastclose = psb_driver_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 
.num_ioctls = ARRAY_SIZE(psb_ioctls),
.irq_preinstall = psb_irq_preinstall,
-- 
2.14.2

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

[PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

[Noralf Trønnes]

The helpers are applied and have reached airlied/drm-next.

amd has gained another .poll_changed user since last.

i915 doesn't really need the .poll_changed helper since it now does a
sync and has to open code it after:
drm/i915/fbdev: Serialise early hotplug events with async fbdev config

vboxvideo will be re-sent when the helper functions have landed in
Greg's staging tree.

Noralf.

Changes since version 2:
- Helper functions have been applied
- Add drm/amd/display: Use drm_fb_helper_poll_changed()
- Rebase drm/amdgpu patch
- Rebase drm/msm patch
- Drop i915 patch, not applicable after:
  drm/i915/fbdev: Serialise early hotplug events with async fbdev config
- Drop vboxvideo patch, it will be re-sent when the helper functions
  have reached Greg's staging tree.

Changes since version 1:
- drm_device.drm_fb_helper_private -> drm_device.fb_helper (Ville)

Noralf Trønnes (11):
  drm/amd/display: Use drm_fb_helper_poll_changed()
  drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/nouveau: Use drm_fb_helper_output_poll_changed()
  drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  9 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 27 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  4 ---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
 drivers/gpu/drm/armada/armada_drm.h   |  1 -
 drivers/gpu/drm/armada/armada_drv.c   |  8 ++
 drivers/gpu/drm/armada/armada_fb.c| 11 +---
 drivers/gpu/drm/armada/armada_fbdev.c |  8 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
 drivers/gpu/drm/gma500/framebuffer.c  |  9 +-
 drivers/gpu/drm/gma500/psb_drv.c  | 15 +-
 drivers/gpu/drm/msm/msm_drv.c | 18 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |  3 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  8 --
 drivers/gpu/drm/nouveau/nouveau_fbcon.h   |  2 --
 drivers/gpu/drm/nouveau/nouveau_vga.c |  3 +-
 drivers/gpu/drm/nouveau/nv50_display.c|  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c| 34 ++-
 drivers/gpu/drm/radeon/radeon_display.c   |  9 ++
 drivers/gpu/drm/radeon/radeon_fb.c| 22 ---
 drivers/gpu/drm/radeon/radeon_kms.c   |  5 ++--
 drivers/gpu/drm/radeon/radeon_mode.h  |  3 --
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  9 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  9 +-
 drivers/gpu/drm/tegra/drm.c   | 13 ++---
 drivers/gpu/drm/tegra/drm.h   |  4 ---
 drivers/gpu/drm/tegra/fb.c| 14 --
 32 files changed, 29 insertions(+), 259 deletions(-)

-- 
2.14.2

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

[PATCH v3 02/11] drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() in its .lastclose function.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.
Remove the unused driver implementations.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  9 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.h |  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  | 27 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  4 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|  4 
 5 files changed, 3 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 138beb550a58..38d47559f098 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void amdgpu_flip_callback(struct dma_fence *f, struct dma_fence_cb *cb)
 {
@@ -556,15 +557,9 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
return _fb->base;
 }
 
-void amdgpu_output_poll_changed(struct drm_device *dev)
-{
-   struct amdgpu_device *adev = dev->dev_private;
-   amdgpu_fb_output_poll_changed(adev);
-}
-
 const struct drm_mode_config_funcs amdgpu_mode_funcs = {
.fb_create = amdgpu_user_framebuffer_create,
-   .output_poll_changed = amdgpu_output_poll_changed
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static const struct drm_prop_enum_list amdgpu_underscan_enum_list[] =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
index 3cc0ef0c055e..7e03002395ff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
@@ -28,6 +28,4 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
   struct drm_file 
*file_priv,
   const struct 
drm_mode_fb_cmd2 *mode_cmd);
 
-void amdgpu_output_poll_changed(struct drm_device *dev);
-
 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 90fa8e8bc6fb..ff3e9beb7d19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -283,12 +283,6 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void amdgpu_fb_output_poll_changed(struct amdgpu_device *adev)
-{
-   if (adev->mode_info.rfbdev)
-   drm_fb_helper_hotplug_event(>mode_info.rfbdev->helper);
-}
-
 static int amdgpu_fbdev_destroy(struct drm_device *dev, struct amdgpu_fbdev 
*rfbdev)
 {
struct amdgpu_framebuffer *rfb = >rfb;
@@ -393,24 +387,3 @@ bool amdgpu_fbdev_robj_is_fb(struct amdgpu_device *adev, 
struct amdgpu_bo *robj)
return true;
return false;
 }
-
-void amdgpu_fbdev_restore_mode(struct amdgpu_device *adev)
-{
-   struct amdgpu_fbdev *afbdev;
-   struct drm_fb_helper *fb_helper;
-   int ret;
-
-   if (!adev)
-   return;
-
-   afbdev = adev->mode_info.rfbdev;
-
-   if (!afbdev)
-   return;
-
-   fb_helper = >helper;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 720139e182a3..c947c2cc813a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -786,9 +786,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  */
 void amdgpu_driver_lastclose_kms(struct drm_device *dev)
 {
-   struct amdgpu_device *adev = dev->dev_private;
-
-   amdgpu_fbdev_restore_mode(adev);
+   drm_fb_helper_lastclose(dev);
vga_switcheroo_process_delayed_switch();
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index ffde1e9666e8..a5ef204e17cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -661,10 +661,6 @@ void amdgpu_fbdev_fini(struct amdgpu_device *adev);
 void amdgpu_fbdev_set_suspend(struct amdgpu_device *adev, int state);
 int amdgpu_fbdev_total_size(struct amdgpu_device *adev);
 bool amdgpu_fbdev_robj_is_fb(struct amdgpu_device *adev, struct amdgpu_bo 
*robj);
-void amdgpu_fbdev_restore_mode(struct amdgpu_device *adev);
-
-void amdgpu_fb_output_poll_changed(struct amdgpu_device *adev);
-
 
 int amdgpu_align_pitch(struct amdgpu_device *adev, int width, int bpp, bool 
tiled);
 
-- 
2.14.2

___
dri-devel mailing list

[PATCH v3 01/11] drm/amd/display: Use drm_fb_helper_poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c324c3b76fac..124229d0af42 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -792,7 +792,7 @@ dm_atomic_state_alloc_free(struct drm_atomic_state *state)
 
 static const struct drm_mode_config_funcs amdgpu_dm_mode_funcs = {
.fb_create = amdgpu_user_framebuffer_create,
-   .output_poll_changed = amdgpu_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = amdgpu_dm_atomic_check,
.atomic_commit = amdgpu_dm_atomic_commit,
.atomic_state_alloc = dm_atomic_state_alloc,
-- 
2.14.2

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

[PATCH v3 03/11] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Russell King 
Signed-off-by: Noralf Trønnes 
Acked-by: Russell King 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_drm.h   |  1 -
 drivers/gpu/drm/armada/armada_drv.c   |  8 ++--
 drivers/gpu/drm/armada/armada_fb.c| 11 +--
 drivers/gpu/drm/armada/armada_fbdev.c |  8 
 4 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index b064879ecdbd..cc4c557c9f66 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -84,7 +84,6 @@ void armada_drm_queue_unref_work(struct drm_device *,
 extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
 
 int armada_fbdev_init(struct drm_device *);
-void armada_fbdev_lastclose(struct drm_device *);
 void armada_fbdev_fini(struct drm_device *);
 
 int armada_overlay_plane_create(struct drm_device *, unsigned long);
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index e857b88a9799..4b11b6b52f1d 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "armada_crtc.h"
 #include "armada_drm.h"
@@ -54,15 +55,10 @@ static struct drm_ioctl_desc armada_ioctls[] = {
DRM_IOCTL_DEF_DRV(ARMADA_GEM_PWRITE, armada_gem_pwrite_ioctl, 0),
 };
 
-static void armada_drm_lastclose(struct drm_device *dev)
-{
-   armada_fbdev_lastclose(dev);
-}
-
 DEFINE_DRM_GEM_FOPS(armada_drm_fops);
 
 static struct drm_driver armada_drm_driver = {
-   .lastclose  = armada_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.gem_free_object_unlocked = armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index a38d5a0892a9..ac92bce07ecd 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -154,16 +154,7 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
return ERR_PTR(ret);
 }
 
-static void armada_output_poll_changed(struct drm_device *dev)
-{
-   struct armada_private *priv = dev->dev_private;
-   struct drm_fb_helper *fbh = priv->fbdev;
-
-   if (fbh)
-   drm_fb_helper_hotplug_event(fbh);
-}
-
 const struct drm_mode_config_funcs armada_drm_mode_config_funcs = {
.fb_create  = armada_fb_create,
-   .output_poll_changed= armada_output_poll_changed,
+   .output_poll_changed= drm_fb_helper_output_poll_changed,
 };
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index a2ce83f84800..2a59db0994b2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -159,14 +159,6 @@ int armada_fbdev_init(struct drm_device *dev)
return ret;
 }
 
-void armada_fbdev_lastclose(struct drm_device *dev)
-{
-   struct armada_private *priv = dev->dev_private;
-
-   if (priv->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-}
-
 void armada_fbdev_fini(struct drm_device *dev)
 {
struct armada_private *priv = dev->dev_private;
-- 
2.14.2

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

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

[bugzilla-daemon]

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

--- Comment #19 from Christoph Schwerdtfeger  ---
Still the same with Mesa 17.2.5

# glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.5
OpenGL version string: 3.0 Mesa 17.2.5
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.2.5

# glxinfo | grep -i llvm
Device: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 5.0.0) (0x679a)
OpenGL renderer string: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 5.0.0)


And also with 17.3.0 rc5.

# glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-rc5
OpenGL version string: 3.0 Mesa 17.3.0-rc5
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.3.0-rc5

# glxinfo | grep -i llvm
Device: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 5.0.0) (0x679a)
OpenGL renderer string: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 5.0.0)

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

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Pavel Machek]

Hi!

> >> > Why would user of the machine want this to be something else than
> >> > 'OFF'?
> >> >
> >> > If kernel implements this, will it mean hardware vendors will have to
> >> > prevent user from updating kernel on machines they own?
> >> >
> >> > If this is merged, does it open kernel developers to DMCA threats if
> >> > they try to change it?
> >>
> >> Because this just implements one part of the content protection scheme.
> >> This only gives you an option to enable HDCP (aka encryption, it's really
> >> nothing else) on the cable. Just because it has Content Protection in the
> >> name does _not_ mean it is (stand-alone) an effective nor complete content
> >> protection scheme. It's simply encrypting data, that's all.
> >
> > Yep. So my first question was: why would user of the machine ever want
> > encryption "ENABLED" or "DESIRED"? Could you answer it?
> 
> How about for sensitive video streams in government offices where you
> want to avoid a spy potentially tapping the cable to see the video
> stream?

Except that spies already have the keys, as every monitor
manufacturer has them?

> >> kernels and be able to exercise their software freedoms already know to
> >> avoid such locked down systems.
> >>
> >> So yeah it would be better to call this the "HDMI/DP cable encryption
> >> support", but well, it's not what it's called really.
> >
> > Well, it does not belong in kernel, no matter what is the name.
> 
> Should we remove support for encrypted file systems and encrypted
> virtual machines?  Just like them the option is there is you want to
> use it.  If you don't want to, you don't have to.

Encrypted file systems benefit users. Encrypted video is designed to
work against users. In particular, users don't have encryption keys
for video they generate. I'd have nothing against feature that would
let users encrypt video with keys they control.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

[PATCH] video/console/sticore: Delete an error message for a failed memory allocation in sti_try_rom_generic()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 5 Dec 2017 18:45:42 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/console/sticore.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
index d1d3796773aa..08b822656846 100644
--- a/drivers/video/console/sticore.c
+++ b/drivers/video/console/sticore.c
@@ -827,10 +827,8 @@ static struct sti_struct *sti_try_rom_generic(unsigned 
long address,
}

sti = kzalloc(sizeof(*sti), GFP_KERNEL);
-   if (!sti) {
-   printk(KERN_ERR "Not enough memory !\n");
+   if (!sti)
return NULL;
-   }
 
spin_lock_init(>lock);
 
-- 
2.15.1

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

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Alex Deucher]

On Tue, Dec 5, 2017 at 12:34 PM, Pavel Machek  wrote:
> On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
>> On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote:
>> > On Wed 2017-11-29 22:08:56, Sean Paul wrote:
>> > > This patch adds a new optional connector property to allow userspace to 
>> > > enable
>> > > protection over the content it is displaying. This will typically be 
>> > > implemented
>> > > by the driver using HDCP.
>> > >
>> > > The property is a tri-state with the following values:
>> > > - OFF: Self explanatory, no content protection
>> > > - DESIRED: Userspace requests that the driver enable protection
>> > > - ENABLED: Once the driver has authenticated the link, it sets this value
>> > >
>> > > The driver is responsible for downgrading ENABLED to DESIRED if the link 
>> > > becomes
>> > > unprotected. The driver should also maintain the desiredness of 
>> > > protection
>> > > across hotplug/dpms/suspend.
>> >
>> > Why would user of the machine want this to be something else than
>> > 'OFF'?
>> >
>> > If kernel implements this, will it mean hardware vendors will have to
>> > prevent user from updating kernel on machines they own?
>> >
>> > If this is merged, does it open kernel developers to DMCA threats if
>> > they try to change it?
>>
>> Because this just implements one part of the content protection scheme.
>> This only gives you an option to enable HDCP (aka encryption, it's really
>> nothing else) on the cable. Just because it has Content Protection in the
>> name does _not_ mean it is (stand-alone) an effective nor complete content
>> protection scheme. It's simply encrypting data, that's all.
>
> Yep. So my first question was: why would user of the machine ever want
> encryption "ENABLED" or "DESIRED"? Could you answer it?

How about for sensitive video streams in government offices where you
want to avoid a spy potentially tapping the cable to see the video
stream?

>
>> If you want to actually lock down a machine to implement content
>> protection, then you need secure boot without unlockable boot-loader and a
>> pile more bits in userspace.  If you do all that, only then do you have
>> full content protection. And yes, then you don't really own the machine
>> fully, and I think users who are concerned with being able to update
>> their
>
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
> Users compiling their own kernels get no benefit from it. Actually it
> looks like this only benefits Intel and Disney. We don't want that.

And just about every SoC manufacturer and google and amazon and a ton
of other companies and organizations.  Who gets to decide who's
benefit gets taken into account?

>
>> kernels and be able to exercise their software freedoms already know to
>> avoid such locked down systems.
>>
>> So yeah it would be better to call this the "HDMI/DP cable encryption
>> support", but well, it's not what it's called really.
>
> Well, it does not belong in kernel, no matter what is the name.

Should we remove support for encrypted file systems and encrypted
virtual machines?  Just like them the option is there is you want to
use it.  If you don't want to, you don't have to.


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

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Pavel Machek]

On Tue 2017-12-05 11:45:38, Daniel Vetter wrote:
> On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote:
> > On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> > > This patch adds a new optional connector property to allow userspace to 
> > > enable
> > > protection over the content it is displaying. This will typically be 
> > > implemented
> > > by the driver using HDCP.
> > > 
> > > The property is a tri-state with the following values:
> > > - OFF: Self explanatory, no content protection
> > > - DESIRED: Userspace requests that the driver enable protection
> > > - ENABLED: Once the driver has authenticated the link, it sets this value
> > > 
> > > The driver is responsible for downgrading ENABLED to DESIRED if the link 
> > > becomes
> > > unprotected. The driver should also maintain the desiredness of protection
> > > across hotplug/dpms/suspend.
> > 
> > Why would user of the machine want this to be something else than
> > 'OFF'?
> > 
> > If kernel implements this, will it mean hardware vendors will have to
> > prevent user from updating kernel on machines they own?
> > 
> > If this is merged, does it open kernel developers to DMCA threats if
> > they try to change it?
> 
> Because this just implements one part of the content protection scheme.
> This only gives you an option to enable HDCP (aka encryption, it's really
> nothing else) on the cable. Just because it has Content Protection in the
> name does _not_ mean it is (stand-alone) an effective nor complete content
> protection scheme. It's simply encrypting data, that's all.

Yep. So my first question was: why would user of the machine ever want
encryption "ENABLED" or "DESIRED"? Could you answer it?

> If you want to actually lock down a machine to implement content
> protection, then you need secure boot without unlockable boot-loader and a
> pile more bits in userspace.  If you do all that, only then do you have
> full content protection. And yes, then you don't really own the machine
> fully, and I think users who are concerned with being able to update
> their

Yes, so... This patch makes it more likely to see machines with locked
down kernels, preventing developers from working with systems their
own, running hardware. That is evil, and direct threat to Free
software movement.

Users compiling their own kernels get no benefit from it. Actually it
looks like this only benefits Intel and Disney. We don't want that.

> kernels and be able to exercise their software freedoms already know to
> avoid such locked down systems.
> 
> So yeah it would be better to call this the "HDMI/DP cable encryption
> support", but well, it's not what it's called really.

Well, it does not belong in kernel, no matter what is the name.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [Intel-gfx] [PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature

[Ville Syrjälä]

On Tue, Dec 05, 2017 at 12:15:05AM -0500, Sean Paul wrote:
> This patch enables the indexed write feature of the GMBUS to concatenate
> 2 consecutive messages into one. The criteria for an indexed write is
> that both messages are writes, the first is length == 1, and the second
> is length > 0. The first message is sent out by the GMBUS as the slave
> command, and the second one is sent via the GMBUS FIFO as usual.
> 
> Changes in v3:
> - Added to series
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/intel_i2c.c | 39 ++-
>  1 file changed, 34 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 49fdf09f9919..7399009aee0a 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -373,7 +373,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
> i2c_msg *msg,
>  
>  static int
>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
> -unsigned short addr, u8 *buf, unsigned int len)
> +unsigned short addr, u8 *buf, unsigned int len,
> +u32 gmbus1_index)
>  {
>   unsigned int chunk_size = len;
>   u32 val, loop;
> @@ -386,7 +387,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  
>   I915_WRITE_FW(GMBUS3, val);
>   I915_WRITE_FW(GMBUS1,
> -   GMBUS_CYCLE_WAIT |
> +   gmbus1_index | GMBUS_CYCLE_WAIT |
> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -409,7 +410,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  }
>  
>  static int
> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
> +  u32 gmbus1_index)
>  {
>   u8 *buf = msg->buf;
>   unsigned int tx_size = msg->len;
> @@ -419,7 +421,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   do {
>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
>  
> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
> +  gmbus1_index);
>   if (ret)
>   return ret;
>  
> @@ -430,6 +433,14 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   return 0;
>  }
>  
> +static int
> +gmbus_xfer_index_write(struct drm_i915_private *dev_priv, u8 cmd,
> +struct i2c_msg *msg)
> +{
> + u8 gmbus1_index = GMBUS_CYCLE_INDEX | (cmd << GMBUS_SLAVE_INDEX_SHIFT);
> + return gmbus_xfer_write(dev_priv, msg, gmbus1_index);
> +}

Instead of a duplicating the entire thing I'd just

- gmbus_xfer_index_read
+ gmbus_xfer_index
  {
  ...
+   if (msgs[1].flags & I2C_M_RD)
gmbus_xfer_read()
+   else
+   gmbus_xfer_write()
  ...
  }

Matches the current pattern better (no 'cmd' passed in), and
will give us the 2 byte index for free as well.

> +
>  /*
>   * The gmbus controller can combine a 1 or 2 byte write with a read that
>   * immediately follows it by using an "INDEX" cycle.
> @@ -444,6 +455,20 @@ gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
>   (msgs[i + 1].flags & I2C_M_RD));
>  }
>  
> +/*
> + * The gmbus controller can combine a 2-msg write into a single write that
> + * immediately follows it by using an "INDEX" cycle.
> + */
> +static bool
> +gmbus_is_index_write(struct i2c_msg *msgs, int i, int num)
> +{
> + return (i + 1 < num &&
> + msgs[i].addr == msgs[i + 1].addr &&
> + !(msgs[i].flags & I2C_M_RD) &&
> + !(msgs[i + 1].flags & I2C_M_RD) &&
> + (msgs[i].len == 1 || msgs[i + 1].len > 0));

Hmm. We don't have the len check for the second msg for reads. I wonder
if gmbus can actually do a zero length "read/write"?

> +}
> +
>  static int
>  gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg 
> *msgs)
>  {
> @@ -489,10 +514,14 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct 
> i2c_msg *msgs, int num)
>   if (gmbus_is_index_read(msgs, i, num)) {
>   ret = gmbus_xfer_index_read(dev_priv, [i]);
>   inc = 2; /* an index read is two msgs */
> + } else if (gmbus_is_index_write(msgs, i, num)) {
> + ret = gmbus_xfer_index_write(dev_priv, msgs[i].buf[0],
> + [i + 1]);
> + inc = 2; /* an index write is two msgs */
>   } else if (msgs[i].flags & I2C_M_RD) {
>   ret = gmbus_xfer_read(dev_priv, 

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

[Harry Wentland]

On 2017-12-05 07:05 AM, Arnd Bergmann wrote:
> On Mon, Dec 4, 2017 at 9:34 PM, Harry Wentland  wrote:
>> On 2017-12-04 08:08 AM, Arnd Bergmann wrote:
>>> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
>>> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many 
>>> functions
>>> that do a comparison of floating-point variables:
>>>
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `dcn_bw_calc_rq_dlg_ttu':
>>> dcn_calcs.c:(.text+0x263): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `hack_force_pipe_split':
>>> dcn_calcs.c:(.text+0x155b): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `dcn_find_dcfclk_suits_all':
>>> dcn_calcs.c:(.text+0x190e): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>>> `dcn_validate_bandwidth':
>>> dcn_calcs.c:(.text+0xe121): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_mod':
>>> dcn_calc_math.c:(.text+0x22): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_min2':
>>> dcn_calc_math.c:(.text+0xb2): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_ceil2':
>>> dcn_calc_math.c:(.text+0x2a0): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_max3':
>>> dcn_calc_math.c:(.text+0x325): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_max5':
>>> dcn_calc_math.c:(.text+0x3c3): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>>> `dcn_bw_log':
>>> dcn_calc_math.c:(.text+0x54e): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> dcn_calc_math.c:(.text+0x57c): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `scaler_settings_calculation':
>>> dcn_calc_auto.c:(.text+0x5c5): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0x137c): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0x9233): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0xb70f): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `mode_support_and_system_configuration':
>>> dcn_calc_auto.c:(.text+0x121fd): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `display_pipe_configuration':
>>> dcn_calc_auto.c:(.text+0x15a2f): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>>> dcn_calc_auto.c:(.text+0x17c2d): undefined reference to 
>>> `__sanitizer_cov_trace_cmpf'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>>> dcn_calc_auto.c:(.text+0x19362): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>>> dcn_calc_auto.c:(.text+0x25575): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>>> dcn_calc_auto.c:(.text+0x27f33): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
>>> `get_refcyc_per_delivery':
>>> display_rq_dlg_calc.c:(.text+0xb5): undefined reference to 
>>> `__sanitizer_cov_trace_cmpd'
>>> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
>>> `calculate_ttu_cursor.isra.1':
>>> display_rq_dlg_calc.c:(.text+0x9f6): undefined reference to 
>>> 

[PATCH 2/2] video: ARM CLCD: Improve a size determination in clcdfb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 5 Dec 2017 17:53:19 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/amba-clcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 79f5ebf23fcd..38c1f324ce15 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -967,7 +967,7 @@ static int clcdfb_probe(struct amba_device *dev, const 
struct amba_id *id)
goto out;
}
 
-   fb = kzalloc(sizeof(struct clcd_fb), GFP_KERNEL);
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb) {
ret = -ENOMEM;
goto free_region;
-- 
2.15.1

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

RE: [PATCH v3 3/9] drm: Add Content Protection property

[C, Ramalingam]

Best Regards,
Ramalingam C

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, December 5, 2017 8:07 PM
> To: C, Ramalingam 
> Cc: dri-devel ; Hans Verkuil
> 
> Subject: Re: [PATCH v3 3/9] drm: Add Content Protection property
> 
> On Tue, Dec 5, 2017 at 9:04 AM, Ramalingam C 
> wrote:
> >
> >
> > On Tuesday 05 December 2017 01:37 PM, Hans Verkuil wrote:
> >
> > On 12/05/2017 06:15 AM, Sean Paul wrote:
> >
> > This patch adds a new optional connector property to allow userspace
> > to enable protection over the content it is displaying. This will
> > typically be implemented by the driver using HDCP.
> >
> > The property is a tri-state with the following values:
> > - OFF: Self explanatory, no content protection
> > - DESIRED: Userspace requests that the driver enable protection
> > - ENABLED: Once the driver has authenticated the link, it sets this
> > value
> >
> > The driver is responsible for downgrading ENABLED to DESIRED if the
> > link becomes unprotected. The driver should also maintain the
> > desiredness of protection across hotplug/dpms/suspend.
> >
> > If this looks familiar, I posted [1] this 3 years ago. We have been
> > using this in ChromeOS across exynos, mediatek, and rockchip over that
> > time.
> >
> > Changes in v2:
> >  - Pimp kerneldoc for content_protection_property (Daniel)
> >  - Drop sysfs attribute
> > Changes in v3:
> >  - None
> >
> > Cc: Daniel Vetter 
> > Signed-off-by: Sean Paul 
> >
> > [1]
> > https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.
> > html
> > ---
> >  drivers/gpu/drm/drm_atomic.c|  8 +
> >  drivers/gpu/drm/drm_connector.c | 71
> > +
> >  drivers/gpu/drm/drm_sysfs.c |  1 +
> >  include/drm/drm_connector.h | 16 ++
> >  include/uapi/drm/drm_mode.h |  4 +++
> >  5 files changed, 100 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c
> > b/drivers/gpu/drm/drm_atomic.c index c2da5585e201..676025d755b2 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1196,6 +1196,12 @@ static int
> > drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> >   state->picture_aspect_ratio = val;
> >   } else if (property == connector->scaling_mode_property) {
> >   state->scaling_mode = val;
> > + } else if (property == connector->content_protection_property) { if
> > + (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> DRM_DEBUG_KMS("only
> > + drivers can set CP Enabled\n"); return -EINVAL; }
> > + state->content_protection = val;
> >   } else if (connector->funcs->atomic_set_property) {
> >   return connector->funcs->atomic_set_property(connector,
> >   state, property, val);
> > @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct
> > drm_connector *connector,
> >   *val = state->picture_aspect_ratio;
> >   } else if (property == connector->scaling_mode_property) {
> >   *val = state->scaling_mode;
> > + } else if (property == connector->content_protection_property) {
> > + *val = state->content_protection;
> >   } else if (connector->funcs->atomic_get_property) {
> >   return connector->funcs->atomic_get_property(connector,
> >   state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c index f14b48e6e839..8626aa8f485e
> > 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list
> > drm_tv_subconnector_enum_list[] = {
> > DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> >   drm_tv_subconnector_enum_list)
> >
> > +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> > +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> > +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> > +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" }, };
> > +DRM_ENUM_NAME_FN(drm_get_content_protection_name,
> drm_cp_enum_list)
> > +
> >  /**
> >   * DOC: standard connector properties
> >   *
> > @@ -764,6 +771,34 @@
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> >   *  after modeset, the kernel driver may set this to "BAD" and issue a
> >   *  hotplug uevent. Drivers should update this value using
> >   *  drm_mode_connector_set_link_status_property().
> > + * Content Protection:
> > + * This property is used by userspace to request the kernel protect
> > + future
> > + * content communicated over the link. When requested, kernel will
> > + apply
> > + * the appropriate means of protection (most often HDCP), and use the
> > + * property to tell userspace the protection is active.
> > + *
> > + * The value of this property can be one of the following:
> > + *
> > + * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> > + * The link is not protected, content is 

Re: [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:01AM -0500, Sean Paul wrote:
> This patch adds a little more control to a couple wait_for routines such
> that we can avoid open-coding read/wait/timeout patterns which:
>  - need the value of the register after the wait_for
>  - run arbitrary operation for the read portion
> 
> This patch also chooses the correct sleep function (based on
> timers-howto.txt) for the polling interval the caller specifies.
> 
> Changes in v2:
> - Added to the series
> Changes in v3:
> - Rebased on drm-intel-next-queued and the new Wmin/max _wait_for
> - Removed msleep option
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Sean Paul 

Patches 1&2:

Reviewed-by: Daniel Vetter 

I can't find the dang docs for patch 3 ... needs a bit of digging or a
different victim.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_drv.h| 17 ++---
>  drivers/gpu/drm/i915/intel_uncore.c | 23 ---
>  drivers/gpu/drm/i915/intel_uncore.h | 14 +-
>  3 files changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 64426d3e078e..852b3d161754 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,20 +41,21 @@
>  #include 
>  
>  /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
>   *
> - * Does the right thing for modeset paths when run under kdgb or similar 
> atomic
> - * contexts. Note that it's important that we check the condition again after
> - * having timed out, since the timeout could be due to preemption or similar 
> and
> - * we've never had a chance to check the condition before the timeout.
> + * Macro to help avoid open coding check/wait/timeout patterns. Note that 
> it's
> + * important that we check the condition again after having timed out, since 
> the
> + * timeout could be due to preemption or similar and we've never had a 
> chance to
> + * check the condition before the timeout.
>   */
> -#define _wait_for(COND, US, Wmin, Wmax) ({ \
> +#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
>   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
>   long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
>   int ret__;  \
>   might_sleep();  \
>   for (;;) {  \
>   bool expired__ = time_after(jiffies, timeout__);\
> + OP; \
>   if (COND) { \
>   ret__ = 0;  \
>   break;  \
> @@ -70,7 +71,9 @@
>   ret__;  \
>  })
>  
> -#define wait_for(COND, MS)   _wait_for((COND), (MS) * 1000, 10, 1000)
> +#define _wait_for(COND, US, Wmin, Wmax)  __wait_for(;, (COND), (US), 
> (Wmin), \
> +(Wmax))
> +#define wait_for(COND, MS)   _wait_for((COND), (MS) * 1000, 10, 1000)
>  
>  /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
>  #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b4621271e7a2..9c7d07151f16 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * intel_wait_for_register - wait until register matches expected state
> + * __intel_wait_for_register - wait until register matches expected state
>   * @dev_priv: the i915 device
>   * @reg: the register to read
>   * @mask: mask to apply to register value
>   * @value: expected value
> - * @timeout_ms: timeout in millisecond
> + * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
> + * @slow_timeout_ms: slow timeout in millisecond
> + * @out_value: optional placeholder to hold registry value
>   *
>   * This routine waits until the target register @reg contains the expected
>   * @value after applying the @mask, i.e. it waits until ::
> @@ -1786,15 +1788,18 @@ int __intel_wait_for_register_fw(struct 
> drm_i915_private *dev_priv,
>   *
>   * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
>   */
> -int intel_wait_for_register(struct drm_i915_private *dev_priv,
> +int __intel_wait_for_register(struct drm_i915_private *dev_priv,
>   i915_reg_t reg,
>   u32 mask,
>   u32 value,
> - unsigned int 

[PATCH 1/2] video: ARM CLCD: Delete an error message for a failed memory allocation in clcdfb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 5 Dec 2017 17:50:11 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/amba-clcd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 36d25190b48c..79f5ebf23fcd 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -969,7 +969,6 @@ static int clcdfb_probe(struct amba_device *dev, const 
struct amba_id *id)
 
fb = kzalloc(sizeof(struct clcd_fb), GFP_KERNEL);
if (!fb) {
-   printk(KERN_INFO "CLCD: could not allocate new clcd_fb 
struct\n");
ret = -ENOMEM;
goto free_region;
}
-- 
2.15.1

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

Re: [PATCH v3 9/9] drm/i915: Implement HDCP for DisplayPort

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:08AM -0500, Sean Paul wrote:
> This patch adds HDCP support for DisplayPort connectors by implementing
> the intel_hdcp_shim.
> 
> Most of this is straightforward read/write from/to DPCD registers. One
> thing worth pointing out is the Aksv output bit. It wasn't easily
> separable like it's HDMI counterpart, so it's crammed in with the rest
> of it.
> 
> Changes in v2:
> - Moved intel_hdcp_check_link out of intel_dp_check_link and only call
>   it on short pulse. Since intel_hdcp_check_link does its own locking,
>   this ensures we don't deadlock when intel_dp_check_link is called
>   holding connection_mutex.
> - Rebased on drm-intel-next
> Changes in v3:
> - Initialize new worker
> - Move intel_hdcp_check_link further out to avoid calling it while
>   holding _any_ locks
> 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 248 
> ++--
>  1 file changed, 241 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c603d4c903e1..dc303e18c1dd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -36,7 +36,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include "intel_drv.h"
>  #include 
>  #include "i915_drv.h"
> @@ -1025,10 +1027,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
>  }
>  
> +static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> +   bool has_aux_irq,
> +   int send_bytes,
> +   uint32_t aux_clock_divider,
> +   bool aksv_write)
> +{
> + uint32_t val = 0;
> +
> + if (aksv_write) {
> + send_bytes += 5;
> + val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
> + }
> +
> + return val | intel_dp->get_aux_send_ctl(intel_dp,
> + has_aux_irq,
> + send_bytes,
> + aux_clock_divider);
> +}
> +
>  static int
>  intel_dp_aux_ch(struct intel_dp *intel_dp,
>   const uint8_t *send, int send_bytes,
> - uint8_t *recv, int recv_size)
> + uint8_t *recv, int recv_size, bool aksv_write)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv =
> @@ -1088,10 +1109,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   }
>  
>   while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
> clock++))) {
> - u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> -   has_aux_irq,
> -   send_bytes,
> -   aux_clock_divider);
> + u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
> +  has_aux_irq,
> +  send_bytes,
> +  aux_clock_divider,
> +  aksv_write);
>  
>   /* Must try at least 3 times according to DP spec */
>   for (try = 0; try < 5; try++) {
> @@ -1228,7 +1250,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   if (msg->buffer)
>   memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
>  
> - ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
> + ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
> +   false);
>   if (ret > 0) {
>   msg->reply = rxbuf[0] >> 4;
>  
> @@ -1250,7 +1273,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   if (WARN_ON(rxsize > 20))
>   return -E2BIG;
>  
> - ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
> + ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
> +   false);
>   if (ret > 0) {
>   msg->reply = rxbuf[0] >> 4;
>   /*
> @@ -4981,6 +5005,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> *intel_encoder)
>   pps_unlock(intel_dp);
>  }
>  
> +static
> +int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> + u8 *an)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
> + uint8_t txbuf[4], rxbuf[2], reply = 0;
> + ssize_t dpcd_ret;
> + int ret;
> +
> + 

[PATCH 0/2] video/fbdev/amba-clcd: Adjustments for clcdfb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 5 Dec 2017 18:07:06 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation
  Improve a size determination

 drivers/video/fbdev/amba-clcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.15.1

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

Re: [PATCH v3 8/9] drm/i915: Implement HDCP for HDMI

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:07AM -0500, Sean Paul wrote:
> This patch adds HDCP support for HDMI connectors by implementing
> the intel_hdcp_shim.
> 
> Nothing too special, just a bunch of DDC reads/writes.
> 
> Changes in v2:
> - Rebased on drm-intel-next
> Changes in v3:
> - Initialize new worker
> 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |   1 +
>  drivers/gpu/drm/i915/intel_ddi.c  |  50 
>  drivers/gpu/drm/i915/intel_drv.h  |   2 +
>  drivers/gpu/drm/i915/intel_hdmi.c | 257 
> ++
>  4 files changed, 310 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 107e16392710..79944ab4218a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8450,6 +8450,7 @@ enum skl_power_gate {
>  #define  TRANS_DDI_EDP_INPUT_A_ONOFF (4<<12)
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
> +#define  TRANS_DDI_HDCP_SIGNALLING   (1<<9)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
>  #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
>  #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index eff3b51872eb..a179fd9968a5 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1615,6 +1615,56 @@ void intel_ddi_disable_transcoder_func(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE(reg, val);
>  }
>  
> +int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)
> +{
> + struct drm_device *dev = intel_encoder->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum pipe pipe = 0;
> + int ret = 0;
> + uint32_t tmp;
> +
> + if (!intel_display_power_get_if_enabled(dev_priv,
> + intel_encoder->power_domain))
> + return -ENXIO;
> +
> + if (!intel_encoder->get_hw_state(intel_encoder, )) {
> + ret = -EIO;
> + goto out;
> + }

Hm, do we really need these checks here? With the new worker design I
think they'd indicate a synchronization bug (misplaced
cancel_delayed_work_sync probably).

If you want to keep them for safetey please wrap in a WARN_ON. Same for
the one below.

Otherwise looks all good to me.

> +
> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
> + tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
> + I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
> +out:
> + intel_display_power_put(dev_priv, intel_encoder->power_domain);
> + return ret;
> +}
> +
> +int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
> +{
> + struct drm_device *dev = intel_encoder->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum pipe pipe = 0;
> + int ret = 0;
> + uint32_t tmp;
> +
> + if (!intel_display_power_get_if_enabled(dev_priv,
> + intel_encoder->power_domain))
> + return -ENXIO;
> +
> + if (!intel_encoder->get_hw_state(intel_encoder, )) {
> + ret = -EIO;
> + goto out;
> + }
> +
> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
> + tmp |= TRANS_DDI_HDCP_SIGNALLING;
> + I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
> +out:
> + intel_display_power_put(dev_priv, intel_encoder->power_domain);
> + return ret;
> +}
> +
>  bool intel_ddi_connector_get_hw_state(struct intel_connector 
> *intel_connector)
>  {
>   struct drm_device *dev = intel_connector->base.dev;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6f47a4227f5f..0b4405f3e988 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1379,6 +1379,8 @@ void intel_ddi_compute_min_voltage_level(struct 
> drm_i915_private *dev_priv,
>  u32 bxt_signal_levels(struct intel_dp *intel_dp);
>  uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
>  u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
> +int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder);
> +int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder);
>  
>  unsigned int intel_fb_align_height(const struct drm_framebuffer *fb,
>  int plane, unsigned int height);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 9d5e72728475..17a525b9fcf9 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "intel_drv.h"
>  #include 
> @@ -873,6 +874,252 @@ void intel_dp_dual_mode_set_tmds_output(struct 
> intel_hdmi *hdmi, bool enable)
>adapter, enable);
>  }
>  
> +static int 

Re: [Intel-gfx] [PATCH v3 7/9] drm/i915: Add function to output Aksv over GMBUS

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:06AM -0500, Sean Paul wrote:
> Once the Aksv is available in the PCH, we need to get it on the wire to
> the receiver via DDC. The hardware doesn't allow us to read the value
> directly, so we need to tell GMBUS to source the Aksv internally and
> send it to the right offset on the receiver.
> 
> The way we do this is to initiate an indexed write where the index is
> the Aksv register offset. We write dummy values to GMBUS3 as if we were
> sending the key, and the hardware slips in the "real" values when it
> goes out.
> 
> Changes in v2:
> - None
> Changes in v3:
> - Uses new index write feature (Ville)
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Sean Paul 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  drivers/gpu/drm/i915/intel_i2c.c | 47 
> +---
>  3 files changed, 46 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bddd65839f60..6b39081c5e53 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -4049,6 +4049,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
> *dev_priv);
>  extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
>  extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
>unsigned int pin);
> +extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
>  
>  extern struct i2c_adapter *
>  intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2bd2cc8441d4..107e16392710 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3043,6 +3043,7 @@ enum i915_power_well_id {
>  # define GPIO_DATA_PULLUP_DISABLE(1 << 13)
>  
>  #define GMBUS0   _MMIO(dev_priv->gpio_mmio_base + 
> 0x5100) /* clock/port select */
> +#define   GMBUS_AKSV_SELECT  (1<<11)
>  #define   GMBUS_RATE_100KHZ  (0<<8)
>  #define   GMBUS_RATE_50KHZ   (1<<8)
>  #define   GMBUS_RATE_400KHZ  (2<<8) /* reserved on Pineview */
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 7399009aee0a..0a4c7486fc7b 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_drv.h"
>  #include 
>  #include "i915_drv.h"
> @@ -497,7 +498,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msgs)
>  }
>  
>  static int
> -do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
> +do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
> +   u32 gmbus0_source)
>  {
>   struct intel_gmbus *bus = container_of(adapter,
>  struct intel_gmbus,
> @@ -507,7 +509,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   int ret = 0;
>  
>  retry:
> - I915_WRITE_FW(GMBUS0, bus->reg0);
> + I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
>  
>   for (; i < num; i += inc) {
>   inc = 1;
> @@ -629,7 +631,7 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   if (ret < 0)
>   bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
>   } else {
> - ret = do_gmbus_xfer(adapter, msgs, num);
> + ret = do_gmbus_xfer(adapter, msgs, num, 0);
>   if (ret == -EAGAIN)
>   bus->force_bit |= GMBUS_FORCE_BIT_RETRY;
>   }
> @@ -639,6 +641,45 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   return ret;
>  }
>  
> +int intel_gmbus_output_aksv(struct i2c_adapter *adapter)
> +{
> + struct intel_gmbus *bus = container_of(adapter, struct intel_gmbus,
> +adapter);
> + struct drm_i915_private *dev_priv = bus->dev_priv;
> + int ret;
> + u8 cmd = DRM_HDCP_DDC_AKSV ;
> + u8 buf[DRM_HDCP_KSV_LEN] = { 0 };
> + struct i2c_msg msgs[] = {
> + {
> + .addr = DRM_HDCP_DDC_ADDR,
> + .flags = 0,
> + .len = sizeof(cmd),
> + .buf = ,
> + },
> + {
> + .addr = DRM_HDCP_DDC_ADDR,
> + .flags = 0,
> + .len = sizeof(buf),
> + .buf = buf,
> + }
> + };
> +
> + intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> + mutex_lock(_priv->gmbus_mutex);
> +
> + /*
> +  * In order to output Aksv to the receiver, use an indexed write to
> +  * pass the i2c command, 

Re: [Intel-gfx] [PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:05AM -0500, Sean Paul wrote:
> This patch enables the indexed write feature of the GMBUS to concatenate
> 2 consecutive messages into one. The criteria for an indexed write is
> that both messages are writes, the first is length == 1, and the second
> is length > 0. The first message is sent out by the GMBUS as the slave
> command, and the second one is sent via the GMBUS FIFO as usual.
> 
> Changes in v3:
> - Added to series
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Sean Paul 

lgtm. Will probably never see a user except the aksv write, but oh well
:-)

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_i2c.c | 39 ++-
>  1 file changed, 34 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 49fdf09f9919..7399009aee0a 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -373,7 +373,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
> i2c_msg *msg,
>  
>  static int
>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
> -unsigned short addr, u8 *buf, unsigned int len)
> +unsigned short addr, u8 *buf, unsigned int len,
> +u32 gmbus1_index)
>  {
>   unsigned int chunk_size = len;
>   u32 val, loop;
> @@ -386,7 +387,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  
>   I915_WRITE_FW(GMBUS3, val);
>   I915_WRITE_FW(GMBUS1,
> -   GMBUS_CYCLE_WAIT |
> +   gmbus1_index | GMBUS_CYCLE_WAIT |
> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -409,7 +410,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  }
>  
>  static int
> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
> +  u32 gmbus1_index)
>  {
>   u8 *buf = msg->buf;
>   unsigned int tx_size = msg->len;
> @@ -419,7 +421,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   do {
>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
>  
> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
> +  gmbus1_index);
>   if (ret)
>   return ret;
>  
> @@ -430,6 +433,14 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   return 0;
>  }
>  
> +static int
> +gmbus_xfer_index_write(struct drm_i915_private *dev_priv, u8 cmd,
> +struct i2c_msg *msg)
> +{
> + u8 gmbus1_index = GMBUS_CYCLE_INDEX | (cmd << GMBUS_SLAVE_INDEX_SHIFT);
> + return gmbus_xfer_write(dev_priv, msg, gmbus1_index);
> +}
> +
>  /*
>   * The gmbus controller can combine a 1 or 2 byte write with a read that
>   * immediately follows it by using an "INDEX" cycle.
> @@ -444,6 +455,20 @@ gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
>   (msgs[i + 1].flags & I2C_M_RD));
>  }
>  
> +/*
> + * The gmbus controller can combine a 2-msg write into a single write that
> + * immediately follows it by using an "INDEX" cycle.
> + */
> +static bool
> +gmbus_is_index_write(struct i2c_msg *msgs, int i, int num)
> +{
> + return (i + 1 < num &&
> + msgs[i].addr == msgs[i + 1].addr &&
> + !(msgs[i].flags & I2C_M_RD) &&
> + !(msgs[i + 1].flags & I2C_M_RD) &&
> + (msgs[i].len == 1 || msgs[i + 1].len > 0));
> +}
> +
>  static int
>  gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg 
> *msgs)
>  {
> @@ -489,10 +514,14 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct 
> i2c_msg *msgs, int num)
>   if (gmbus_is_index_read(msgs, i, num)) {
>   ret = gmbus_xfer_index_read(dev_priv, [i]);
>   inc = 2; /* an index read is two msgs */
> + } else if (gmbus_is_index_write(msgs, i, num)) {
> + ret = gmbus_xfer_index_write(dev_priv, msgs[i].buf[0],
> + [i + 1]);
> + inc = 2; /* an index write is two msgs */
>   } else if (msgs[i].flags & I2C_M_RD) {
>   ret = gmbus_xfer_read(dev_priv, [i], 0);
>   } else {
> - ret = gmbus_xfer_write(dev_priv, [i]);
> + ret = gmbus_xfer_write(dev_priv, [i], 0);
>   }
>  
>   if (!ret)
> -- 
> 2.15.0.531.g2ccb3012c9-goog
> 
> ___
> Intel-gfx mailing list
> 

Re: [PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:04AM -0500, Sean Paul wrote:
> This patch adds the framework required to add HDCP support to intel
> connectors. It implements Aksv loading from fuse, and parts 1/2/3
> of the HDCP authentication scheme.
> 
> Note that without shim implementations, this does not actually implement
> HDCP. That will come in subsequent patches.
> 
> Changes in v2:
> - Don't open code wait_fors (Chris)
> - drm_hdcp.c under MIT license (Daniel)
> - Move intel_hdcp_disable() call above ddi_disable (Ram)
> - Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
> - Justify intel_hdcp_shim with comments (Daniel)
> - Fixed async locking issues by adding hdcp_mutex (Daniel)
> - Don't alter connector_state in enable/disable (Daniel)
> Changes in v3:
> - Added hdcp_mutex/hdcp_value to make async reasonable
> - Added hdcp_prop_work to separate link checking & property setting
> - Added new helper for atomic_check state tracking (Daniel)
> - Moved enable/disable into atomic_commit with matching helpers
> - Moved intel_hdcp_check_link out of all locks when called from dp
> - Bumped up ksv_fifo timeout (noticed failure on one of my dongles)
> 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Ramalingam C 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  83 
>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
>  drivers/gpu/drm/i915/intel_display.c |  14 +
>  drivers/gpu/drm/i915/intel_drv.h |  88 +
>  drivers/gpu/drm/i915/intel_hdcp.c| 731 
> +++
>  6 files changed, 919 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 42bc8bd4ff06..3facea4eefdb 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -107,6 +107,7 @@ i915-y += intel_audio.o \
> intel_fbc.o \
> intel_fifo_underrun.o \
> intel_frontbuffer.o \
> +   intel_hdcp.o \
> intel_hotplug.o \
> intel_modes.o \
> intel_overlay.o \
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 09bf043c1c2e..2bd2cc8441d4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8034,6 +8034,7 @@ enum {
>  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
>  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
>  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
> +#define   SKL_PCODE_LOAD_HDCP_KEYS   0x5

SKL_ prefix feels right here, since this is for skl, kbl, ... only, and
doesn't apply to bxt. So not gen9 stuff.

>  #define   SKL_PCODE_CDCLK_CONTROL0x7
>  #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
>  #define SKL_CDCLK_READY_FOR_CHANGE   0x1
> @@ -8335,6 +8336,88 @@ enum skl_power_gate {
>  #define  SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + SKL_PG1)
>  #define  SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
>  
> +
> +/* HDCP Key Registers */
> +#define SKL_HDCP_KEY_CONF_MMIO(0x66c00)
> +#define   SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER BIT(30)
> +#define SKL_HDCP_KEY_STATUS  _MMIO(0x66c04)
> +#define  SKL_HDCP_FUSE_IN_PROGRESS   BIT(7)
> +#define  SKL_HDCP_FUSE_ERROR BIT(6)
> +#define  SKL_HDCP_FUSE_DONE  BIT(5)
> +#define  SKL_HDCP_KEY_LOAD_STATUSBIT(1)
> +#define  SKL_HDCP_KEY_LOAD_DONE  BIT(0)
> +#define SKL_HDCP_AKSV_LO _MMIO(0x66c10)
> +#define SKL_HDCP_AKSV_HI _MMIO(0x66c14)
> +
> +/* HDCP Repeater Registers */
> +#define SKL_HDCP_REP_CTL _MMIO(0x66d00)
> +#define  SKL_HDCP_DDIB_REP_PRESENT   BIT(30)
> +#define  SKL_HDCP_DDIB_REP_PRESENT   BIT(30)
> +#define  SKL_HDCP_DDIA_REP_PRESENT   BIT(29)
> +#define  SKL_HDCP_DDIC_REP_PRESENT   BIT(28)
> +#define  SKL_HDCP_DDID_REP_PRESENT   BIT(27)
> +#define  SKL_HDCP_DDIF_REP_PRESENT   BIT(26)
> +#define  SKL_HDCP_DDIE_REP_PRESENT   BIT(25)
> +#define  SKL_HDCP_DDIB_SHA1_M0   (1 << 20)
> +#define  SKL_HDCP_DDIA_SHA1_M0   (2 << 20)
> +#define  SKL_HDCP_DDIC_SHA1_M0   (3 << 20)
> +#define  SKL_HDCP_DDID_SHA1_M0   (4 << 20)
> +#define  SKL_HDCP_DDIF_SHA1_M0   (5 << 20)
> +#define  SKL_HDCP_DDIE_SHA1_M0   (6 << 20) /* Bspec says 5? */

Yeah that's one good wtf :-)

> +#define  SKL_HDCP_SHA1_BUSY  BIT(16)
> +#define  SKL_HDCP_SHA1_READY BIT(17)
> +#define  SKL_HDCP_SHA1_COMPLETE  BIT(18)
> +#define  SKL_HDCP_SHA1_V_MATCH   BIT(19)
> +#define  SKL_HDCP_SHA1_TEXT_32   (1 << 1)
> +#define  SKL_HDCP_SHA1_COMPLETE_HASH (2 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_24   (4 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_16 

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 135984
  --> https://bugs.freedesktop.org/attachment.cgi?id=135984=edit
dmesg

-- 
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 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

--- Comment #10 from Mike Lothian  ---
I've just checked
https://www.computeruniverse.net/en/products/90526096/acer-aspire-xc-105.asp

It has HDMI and a VGA connector, I've only ever used the HDMI connector

-- 
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 v3 3/9] drm: Add Content Protection property

[Hans Verkuil]

On 12/05/17 15:36, Sean Paul wrote:
> On Tue, Dec 5, 2017 at 9:04 AM, Ramalingam C  wrote:
>>
>>
>> On Tuesday 05 December 2017 01:37 PM, Hans Verkuil wrote:
>>
>> On 12/05/2017 06:15 AM, Sean Paul wrote:
>>
>> This patch adds a new optional connector property to allow userspace to
>> enable
>> protection over the content it is displaying. This will typically be
>> implemented
>> by the driver using HDCP.
>>
>> The property is a tri-state with the following values:
>> - OFF: Self explanatory, no content protection
>> - DESIRED: Userspace requests that the driver enable protection
>> - ENABLED: Once the driver has authenticated the link, it sets this value
>>
>> The driver is responsible for downgrading ENABLED to DESIRED if the link
>> becomes
>> unprotected. The driver should also maintain the desiredness of protection
>> across hotplug/dpms/suspend.
>>
>> If this looks familiar, I posted [1] this 3 years ago. We have been using
>> this
>> in ChromeOS across exynos, mediatek, and rockchip over that time.
>>
>> Changes in v2:
>>  - Pimp kerneldoc for content_protection_property (Daniel)
>>  - Drop sysfs attribute
>> Changes in v3:
>>  - None
>>
>> Cc: Daniel Vetter 
>> Signed-off-by: Sean Paul 
>>
>> [1]
>> https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
>> ---
>>  drivers/gpu/drm/drm_atomic.c|  8 +
>>  drivers/gpu/drm/drm_connector.c | 71
>> +
>>  drivers/gpu/drm/drm_sysfs.c |  1 +
>>  include/drm/drm_connector.h | 16 ++
>>  include/uapi/drm/drm_mode.h |  4 +++
>>  5 files changed, 100 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index c2da5585e201..676025d755b2 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct
>> drm_connector *connector,
>>   state->picture_aspect_ratio = val;
>>   } else if (property == connector->scaling_mode_property) {
>>   state->scaling_mode = val;
>> + } else if (property == connector->content_protection_property) {
>> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
>> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
>> + return -EINVAL;
>> + }
>> + state->content_protection = val;
>>   } else if (connector->funcs->atomic_set_property) {
>>   return connector->funcs->atomic_set_property(connector,
>>   state, property, val);
>> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector
>> *connector,
>>   *val = state->picture_aspect_ratio;
>>   } else if (property == connector->scaling_mode_property) {
>>   *val = state->scaling_mode;
>> + } else if (property == connector->content_protection_property) {
>> + *val = state->content_protection;
>>   } else if (connector->funcs->atomic_get_property) {
>>   return connector->funcs->atomic_get_property(connector,
>>   state, property, val);
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index f14b48e6e839..8626aa8f485e 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list
>> drm_tv_subconnector_enum_list[] = {
>>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>>   drm_tv_subconnector_enum_list)
>>
>> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
>> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
>> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
>> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
>> +};
>> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
>> +
>>  /**
>>   * DOC: standard connector properties
>>   *
>> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>>   *  after modeset, the kernel driver may set this to "BAD" and issue a
>>   *  hotplug uevent. Drivers should update this value using
>>   *  drm_mode_connector_set_link_status_property().
>> + * Content Protection:
>> + * This property is used by userspace to request the kernel protect future
>> + * content communicated over the link. When requested, kernel will apply
>> + * the appropriate means of protection (most often HDCP), and use the
>> + * property to tell userspace the protection is active.
>> + *
>> + * The value of this property can be one of the following:
>> + *
>> + * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
>> + * The link is not protected, content is transmitted in the clear.
>> + * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
>> + * Userspace has requested content protection, but the link is not
>> + * currently protected. When in this state, kernel should enable
>> + * Content Protection as soon as possible.
>> + * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
>> + * Userspace has requested content protection, and the link is
>> + * protected. Only the driver can set the property to 

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher  ---
What physical display connectors are actually on the board?

-- 
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 v3 05/15] drm/sun4i: Fix error path handling

[Chen-Yu Tsai]

On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
 wrote:
> The commit 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap
> initialization sequence") moved a bunch of logic around, but forgot to
> update the gotos after the introduction of the err_free_dotclock label.
>
> It means that if we fail later that the one introduced in that commit,
> we'll just to the old label which isn't free the clock we created. This
> will result in a breakage as soon as someone tries to do something with
> that clock, since its resources will have been long reclaimed.
>
> Cc: 
> Fixes: 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap initialization 
> sequence")
> Signed-off-by: Maxime Ripard 

Thanks.

I think this was reported, or I noticed it after the patch was merged,
but then I got busy with other stuff.

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

[Chris Wilson]

Quoting Daniel Vetter (2017-12-05 15:34:36)
> Two bits missing imo:
> - Should explain that userspace should poll this property to detect a
>   change from ENABLED to DESIRED (and take adequate actions and e.g. stop
>   the stream). No uevent will be sent out because the HDCP specs require
>   polling anyway.

What's more polling than poll()? :-p
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/9] drm: Add Content Protection property

[Daniel Vetter]

On Tue, Dec 05, 2017 at 12:15:02AM -0500, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be 
> implemented
> by the driver using HDCP.
> 
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
> 
> The driver is responsible for downgrading ENABLED to DESIRED if the link 
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.
> 
> If this looks familiar, I posted [1] this 3 years ago. We have been using this
> in ChromeOS across exynos, mediatek, and rockchip over that time.
> 
> Changes in v2:
>  - Pimp kerneldoc for content_protection_property (Daniel)
>  - Drop sysfs attribute
> Changes in v3:
>  - None
> 
> Cc: Daniel Vetter 
> Signed-off-by: Sean Paul 
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 +
>  drivers/gpu/drm/drm_connector.c | 71 
> +
>  drivers/gpu/drm/drm_sysfs.c |  1 +
>  include/drm/drm_connector.h | 16 ++
>  include/uapi/drm/drm_mode.h |  4 +++
>  5 files changed, 100 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..676025d755b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == connector->content_protection_property) {
> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> + return -EINVAL;
> + }
> + state->content_protection = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == connector->content_protection_property) {
> + *val = state->content_protection;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f14b48e6e839..8626aa8f485e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
> drm_tv_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *  after modeset, the kernel driver may set this to "BAD" and issue a
>   *  hotplug uevent. Drivers should update this value using
>   *  drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + *   This property is used by userspace to request the kernel protect future
> + *   content communicated over the link. When requested, kernel will apply
> + *   the appropriate means of protection (most often HDCP), and use the
> + *   property to tell userspace the protection is active.
> + *
> + *   The value of this property can be one of the following:
> + *
> + *   - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> + *   The link is not protected, content is transmitted in the clear.
> + *   - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> + *   Userspace has requested content protection, but the link is not
> + *   currently protected. When in this state, kernel should enable
> + *   Content Protection as soon as possible.
> + *   - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
> + *   Userspace has requested content protection, and the link is
> + *

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

[Daniel Vetter]

On Tue, Dec 05, 2017 at 09:07:58AM +0100, Hans Verkuil wrote:
> On 12/05/2017 06:15 AM, Sean Paul wrote:
> > This patch adds a new optional connector property to allow userspace to 
> > enable
> > protection over the content it is displaying. This will typically be 
> > implemented
> > by the driver using HDCP.
> > 
> > The property is a tri-state with the following values:
> > - OFF: Self explanatory, no content protection
> > - DESIRED: Userspace requests that the driver enable protection
> > - ENABLED: Once the driver has authenticated the link, it sets this value
> > 
> > The driver is responsible for downgrading ENABLED to DESIRED if the link 
> > becomes
> > unprotected. The driver should also maintain the desiredness of protection
> > across hotplug/dpms/suspend.
> > 
> > If this looks familiar, I posted [1] this 3 years ago. We have been using 
> > this
> > in ChromeOS across exynos, mediatek, and rockchip over that time.
> > 
> > Changes in v2:
> >  - Pimp kerneldoc for content_protection_property (Daniel)
> >  - Drop sysfs attribute
> > Changes in v3:
> >  - None
> > 
> > Cc: Daniel Vetter 
> > Signed-off-by: Sean Paul 
> > 
> > [1] 
> > https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> > ---
> >  drivers/gpu/drm/drm_atomic.c|  8 +
> >  drivers/gpu/drm/drm_connector.c | 71 
> > +
> >  drivers/gpu/drm/drm_sysfs.c |  1 +
> >  include/drm/drm_connector.h | 16 ++
> >  include/uapi/drm/drm_mode.h |  4 +++
> >  5 files changed, 100 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index c2da5585e201..676025d755b2 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> > state->picture_aspect_ratio = val;
> > } else if (property == connector->scaling_mode_property) {
> > state->scaling_mode = val;
> > +   } else if (property == connector->content_protection_property) {
> > +   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> > +   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> > +   return -EINVAL;
> > +   }
> > +   state->content_protection = val;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct 
> > drm_connector *connector,
> > *val = state->picture_aspect_ratio;
> > } else if (property == connector->scaling_mode_property) {
> > *val = state->scaling_mode;
> > +   } else if (property == connector->content_protection_property) {
> > +   *val = state->content_protection;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index f14b48e6e839..8626aa8f485e 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
> > drm_tv_subconnector_enum_list[] = {
> >  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> >  drm_tv_subconnector_enum_list)
> >  
> > +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> > +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> > +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> > +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> > +};
> > +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> > +
> >  /**
> >   * DOC: standard connector properties
> >   *
> > @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> >   *  after modeset, the kernel driver may set this to "BAD" and issue a
> >   *  hotplug uevent. Drivers should update this value using
> >   *  drm_mode_connector_set_link_status_property().
> > + * Content Protection:
> > + * This property is used by userspace to request the kernel protect future
> > + * content communicated over the link. When requested, kernel will apply
> > + * the appropriate means of protection (most often HDCP), and use the
> > + * property to tell userspace the protection is active.
> > + *
> > + * The value of this property can be one of the following:
> > + *
> > + * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> > + * The link is not protected, content is transmitted in the clear.
> > + * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> > + * Userspace has requested content protection, but the link is not
> > + * currently protected. When in this state, kernel 

[PATCH v3 11/15] ARM: dts: sun8i: a83t: Enable the PWM

[Maxime Ripard]

The A83T has the same PWM block than the H3. Add it to our DT.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi |  9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e4db38c717d9..7a49b9f085eb 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -497,6 +497,15 @@
status = "disabled";
};
 
+   pwm: pwm@1c21400 {
+   compatible = "allwinner,sun8i-a83t-pwm",
+"allwinner,sun8i-h3-pwm";
+   reg = <0x01c21400 0x400>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 12/15] ARM: dts: sun8i: a83t: Add LVDS pins group

[Maxime Ripard]

The A83T has an LVDS bus that can be connected to a panel or a bridge. Add
the pinctrl group for it.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7a49b9f085eb..e200df5a9058 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -415,6 +415,12 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
 
+   lcd_lvds_pins: lcd-lvds-pins {
+   pins = "PD18", "PD19", "PD20", "PD21", "PD22",
+  "PD23", "PD24", "PD25", "PD26", "PD27";
+   function = "lvds0";
+   };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2",
   "PF3", "PF4", "PF5";
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 13/15] ARM: dts: sun8i: a83t: Add the PWM pin group

[Maxime Ripard]

The A83T has a PWM that can be output from the SoC. Let's add a pinctrl
group for it.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e200df5a9058..a37517d4472a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -446,6 +446,11 @@
bias-pull-up;
};
 
+   pwm_pin: pwm-pin {
+   pins = "PD28";
+   function = "pwm";
+   };
+
spdif_tx_pin: spdif-tx-pin {
pins = "PE18";
function = "spdif";
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 14/15] ARM: dts: sun8i: a711: Reinstate the PMIC compatible

[Maxime Ripard]

When we added the regulator support in commit 90c5d7cdae64 ("ARM: dts:
sun8i: a711: Add regulator support"), we also dropped the PMIC's
compatible. Since it's not in the PMIC DTSI, unlike most other PMIC
DTSI, it obviously wasn't probing anymore.

Re-add it so that everything works again.

Fixes: 90c5d7cdae64 ("ARM: dts: sun8i: a711: Add regulator support")
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index 98715538932f..a021ee6da396 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -146,6 +146,7 @@
status = "okay";
 
axp81x: pmic@3a3 {
+   compatible = "x-powers,axp813";
reg = <0x3a3>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 15/15] ARM: dts: sun8i: a711: Enable the LCD

[Maxime Ripard]

The A711 has 1024x600 LVDS panel, with a PWM-based backlight. Add it to our
DT.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 61 -
 1 file changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index a021ee6da396..511fca491fe8 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -45,6 +45,7 @@
 #include "sun8i-a83t.dtsi"
 
 #include 
+#include 
 
 / {
model = "TBS A711 Tablet";
@@ -59,6 +60,44 @@
stdout-path = "serial0:115200n8";
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   enable-gpios = < 3 29 GPIO_ACTIVE_HIGH>;
+
+   brightness-levels = <0 1 2 4 8 16 32 64 128 255>;
+   default-brightness-level = <9>;
+   };
+
+   panel {
+   compatible = "tbs,a711-panel", "panel-lvds";
+   backlight = <>;
+   power-supply = <_sw>;
+
+   width-mm = <153>;
+   height-mm = <90>;
+   data-mapping = "vesa-24";
+
+   panel-timing {
+   /* 1024x600 @60Hz */
+   clock-frequency = <5200>;
+   hactive = <1024>;
+   vactive = <600>;
+   hsync-len = <20>;
+   hfront-porch = <180>;
+   hback-porch = <160>;
+   vfront-porch = <12>;
+   vback-porch = <23>;
+   vsync-len = <5>;
+   };
+
+   port {
+   panel_input: endpoint {
+   remote-endpoint = <_out_lcd>;
+   };
+   };
+   };
+
reg_vbat: reg-vbat {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -89,6 +128,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
 /*
  * An USB-2 hub is connected here, which also means we don't need to
  * enable the OHCI controller.
@@ -142,6 +185,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin>;
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
@@ -323,6 +372,18 @@
regulator-name = "vcc-lcd";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lvds_pins>;
+};
+
+_out {
+   tcon0_out_lcd: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 09/15] drm/sun4i: Add A83T support

[Maxime Ripard]

Add support for the A83T display pipeline.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c   |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c  |  5 +
 drivers/gpu/drm/sun4i/sun8i_mixer.c |  9 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 49215d91c853..6f5e721b545e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -347,6 +347,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun7i-a20-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+   { .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
 };
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 92f4738101e6..9b757450555f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1132,6 +1132,10 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = 
{
.has_lvds_pll   = true,
 };
 
+static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+   /* nothing is supported */
+};
+
 static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
/* nothing is supported */
 };
@@ -1144,6 +1148,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = _a31s_quirks 
},
{ .compatible = "allwinner,sun7i-a20-tcon", .data = _a20_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = _a33_quirks },
+   { .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data = 
_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ }
 };
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index ff235e3228ce..6829bec4ba68 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -477,6 +477,11 @@ static int sun8i_mixer_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct sun8i_mixer_cfg sun8i_a83t_mixer_cfg = {
+   .vi_num = 1,
+   .ui_num = 3,
+};
+
 static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -487,6 +492,10 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
 
 static const struct of_device_id sun8i_mixer_of_table[] = {
{
+   .compatible = "allwinner,sun8i-a83t-de2-mixer-0",
+   .data = _a83t_mixer_cfg,
+   },
+   {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = _v3s_mixer_cfg,
},
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 06/15] drm/sun4i: Force the mixer rate at 150MHz

[Maxime Ripard]

It seems like the mixer can only run properly when clocked at 150MHz. In
order to have something more robust than simply a fire-and-forget
assigned-clocks-rate, let's put that in the code.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun8i_mixer.c |  9 +
 drivers/gpu/drm/sun4i/sun8i_mixer.h |  3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 29ceeb016d72..ff235e3228ce 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -400,6 +400,14 @@ static int sun8i_mixer_bind(struct device *dev, struct 
device *master,
}
clk_prepare_enable(mixer->mod_clk);
 
+   /*
+* It seems that we need to enforce that rate for whatever
+* reason for the mixer to be functional. Make sure it's the
+* case.
+*/
+   if (mixer->cfg->mod_rate)
+   clk_set_rate(mixer->mod_clk, mixer->cfg->mod_rate);
+
list_add_tail(>engine.list, >engine_list);
 
/* Reset the registers */
@@ -474,6 +482,7 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.ui_num = 1,
.scaler_mask = 0x3,
.ccsc = 0,
+   .mod_rate = 15000,
 };
 
 static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h 
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index bc58040a88f9..f34e70c42adf 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -121,12 +121,15 @@ struct de2_fmt_info {
  * Set value to 0 if this is first mixer or second mixer with VEP support.
  * Set value to 1 if this is second mixer without VEP support. Other values
  * are invalid.
+ * @mod_rate: module clock rate that needs to be set in order to have
+ * a functional block.
  */
 struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
int ccsc;
+   unsigned long   mod_rate;
 };
 
 struct sun8i_mixer {
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 08/15] drm/sun4i: Add LVDS support

[Maxime Ripard]

The TCON supports the LVDS interface to output to a panel or a bridge.
Let's add support for it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/Makefile |   1 +-
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 +++-
 drivers/gpu/drm/sun4i/sun4i_lvds.h |  18 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 238 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  29 -
 5 files changed, 467 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 82a6ac57fbe3..2b37a6abbb1d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -15,6 +15,7 @@ sun8i-mixer-y += sun8i_mixer.o 
sun8i_ui_layer.o \
 
 sun4i-tcon-y   += sun4i_crtc.o
 sun4i-tcon-y   += sun4i_dotclock.o
+sun4i-tcon-y   += sun4i_lvds.o
 sun4i-tcon-y   += sun4i_tcon.o
 sun4i-tcon-y   += sun4i_rgb.o
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
new file mode 100644
index ..635a3f505ecb
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2015 NextThing Co
+ * Copyright (C) 2015-2017 Free Electrons
+ *
+ * Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun4i_crtc.h"
+#include "sun4i_tcon.h"
+#include "sun4i_lvds.h"
+
+struct sun4i_lvds {
+   struct drm_connectorconnector;
+   struct drm_encoder  encoder;
+
+   struct sun4i_tcon   *tcon;
+};
+
+static inline struct sun4i_lvds *
+drm_connector_to_sun4i_lvds(struct drm_connector *connector)
+{
+   return container_of(connector, struct sun4i_lvds,
+   connector);
+}
+
+static inline struct sun4i_lvds *
+drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
+{
+   return container_of(encoder, struct sun4i_lvds,
+   encoder);
+}
+
+static int sun4i_lvds_get_modes(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds =
+   drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   return drm_panel_get_modes(tcon->panel);
+}
+
+static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
+   .get_modes  = sun4i_lvds_get_modes,
+};
+
+static void
+sun4i_lvds_connector_destroy(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   drm_panel_detach(tcon->panel);
+   drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy= sun4i_lvds_connector_destroy,
+   .reset  = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
+};
+
+static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
+
+   if (!IS_ERR(tcon->panel)) {
+   drm_panel_prepare(tcon->panel);
+   drm_panel_enable(tcon->panel);
+   }
+}
+
+static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_tcon *tcon = lvds->tcon;
+
+   DRM_DEBUG_DRIVER("Disabling LVDS output\n");
+
+   if (!IS_ERR(tcon->panel)) {
+   drm_panel_disable(tcon->panel);
+   drm_panel_unprepare(tcon->panel);
+   }
+}
+
+static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
+   .disable= sun4i_lvds_encoder_disable,
+   .enable = sun4i_lvds_encoder_enable,
+};
+
+static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
+   .destroy= drm_encoder_cleanup,
+};
+
+int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
+{
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;
+   struct sun4i_lvds *lvds;
+   int ret;
+
+   lvds = devm_kzalloc(drm->dev, sizeof(*lvds), GFP_KERNEL);
+   if (!lvds)
+   return -ENOMEM;
+   lvds->tcon = tcon;
+   

[PATCH v3 04/15] dt-bindings: display: sun4i-drm: Add A83T pipeline

[Maxime Ripard]

The A83T has two video pipelines in parallel that looks quite similar to
the other SoCs.

The video planes are handled through a controller called the mixer, and the
video signal is then passed to the timing controller (TCON).

And while there is two instances of the mixers and TCONs, they have a
significant number of differences. The TCONs are quite easy to deal with,
one is supposed to generate TV (in the broader term, so including things
like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
call them TCON-TV and TCON-LCD, which seems more appropriate.

However, the mixers differ mostly by their capabilities, with some features
being available only in the first one, or the number of planes they expose,
but also through their register layout. And while the capabilities could be
represented as properties, the register layout differences would need to
express all the registers offsets as properties, which is usually quite
bad. Especially since documentation on that hardware block is close to
non-existant and we don't even have the list of all those registers in the
first place.

So let's call them mixer 0 and 1 in our compatibles, even though the name
is pretty bad...

At the moment, we only have tested the code on a board that has a single
display output, so we're leaving the tcon-tv and mixer1 out.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index d4259a4f5171..338cb6bbf25c 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -93,6 +93,7 @@ Required properties:
* allwinner,sun6i-a31s-tcon
* allwinner,sun7i-a20-tcon
* allwinner,sun8i-a33-tcon
+   * allwinner,sun8i-a83t-tcon-lcd
* allwinner,sun8i-v3s-tcon
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
@@ -224,6 +225,7 @@ supported.
 
 Required properties:
   - compatible: value must be one of:
+* allwinner,sun8i-a83t-de2-mixer-0
 * allwinner,sun8i-v3s-de2-mixer
   - reg: base address and size of the memory-mapped region.
   - clocks: phandles to the clocks feeding the mixer
@@ -253,6 +255,7 @@ Required properties:
 * allwinner,sun6i-a31s-display-engine
 * allwinner,sun7i-a20-display-engine
 * allwinner,sun8i-a33-display-engine
+* allwinner,sun8i-a83t-display-engine
 * allwinner,sun8i-v3s-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties

[Maxime Ripard]

Some clocks and resets supposed to drive the LVDS logic in the display
engine have been overlooked when the driver was first introduced.

Add those additional resources to the binding, and we'll deal with the ABI
stability in the code.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 8 +++-
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 50cc72ee1168..d4259a4f5171 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -121,6 +121,14 @@ Required properties:
 On SoCs other than the A33 and V3s, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
 
+On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
+need one more reset line:
+   - 'lvds': The reset line driving the LVDS logic
+
+And on the SoCs newer than the A31 (sun6i and sun8i families), you
+need one more clock line:
+   - 'lvds-pll': The PLL that can be used to drive the LVDS clock
+
 DRC
 ---
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 02/15] drm/panel: lvds: Add support for the power-supply property

[Maxime Ripard]

A significant number of panels need to power up a regulator in order to
operate properly. Add support for the power-supply property to enable and
disable such a regulator whenever needed.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/panel-lvds.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index e2d57c01200b..57e38a9e7ab4 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -39,6 +40,7 @@ struct panel_lvds {
bool data_mirror;
 
struct backlight_device *backlight;
+   struct regulator *supply;
 
struct gpio_desc *enable_gpio;
struct gpio_desc *reset_gpio;
@@ -69,6 +71,9 @@ static int panel_lvds_unprepare(struct drm_panel *panel)
if (lvds->enable_gpio)
gpiod_set_value_cansleep(lvds->enable_gpio, 0);
 
+   if (lvds->supply)
+   regulator_disable(lvds->supply);
+
return 0;
 }
 
@@ -76,6 +81,17 @@ static int panel_lvds_prepare(struct drm_panel *panel)
 {
struct panel_lvds *lvds = to_panel_lvds(panel);
 
+   if (lvds->supply) {
+   int err;
+
+   err = regulator_enable(lvds->supply);
+   if (err < 0) {
+   dev_err(lvds->dev, "failed to enable supply: %d\n",
+   err);
+   return err;
+   }
+   }
+
if (lvds->enable_gpio)
gpiod_set_value_cansleep(lvds->enable_gpio, 1);
 
@@ -196,6 +212,13 @@ static int panel_lvds_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
+   lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
+   if (IS_ERR(lvds->supply)) {
+   ret = PTR_ERR(lvds->supply);
+   dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
+   return ret;
+   }
+
/* Get GPIOs and backlight controller. */
lvds->enable_gpio = devm_gpiod_get_optional(lvds->dev, "enable",
 GPIOD_OUT_LOW);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 05/15] drm/sun4i: Fix error path handling

[Maxime Ripard]

The commit 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap
initialization sequence") moved a bunch of logic around, but forgot to
update the gotos after the introduction of the err_free_dotclock label.

It means that if we fail later that the one introduced in that commit,
we'll just to the old label which isn't free the clock we created. This
will result in a breakage as soon as someone tries to do something with
that clock, since its resources will have been long reclaimed.

Cc: 
Fixes: 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap initialization 
sequence")
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index a1ed462c2430..ea056a3d2131 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -724,12 +724,12 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
ret = PTR_ERR(tcon->crtc);
-   goto err_free_clocks;
+   goto err_free_dotclock;
}
 
ret = sun4i_rgb_init(drm, tcon);
if (ret < 0)
-   goto err_free_clocks;
+   goto err_free_dotclock;
 
if (tcon->quirks->needs_de_be_mux) {
/*
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 07/15] drm/sun4i: Create minimal multipliers and dividers

[Maxime Ripard]

The various outputs the TCON can provide have different constraints on the
dotclock divider. Let's make them configurable by the various mode_set
functions.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_dotclock.c | 10 +++---
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  2 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c 
b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
index d401156490f3..023f39bda633 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
@@ -17,8 +17,9 @@
 #include "sun4i_dotclock.h"
 
 struct sun4i_dclk {
-   struct clk_hw   hw;
-   struct regmap   *regmap;
+   struct clk_hw   hw;
+   struct regmap   *regmap;
+   struct sun4i_tcon   *tcon;
 };
 
 static inline struct sun4i_dclk *hw_to_dclk(struct clk_hw *hw)
@@ -73,11 +74,13 @@ static unsigned long sun4i_dclk_recalc_rate(struct clk_hw 
*hw,
 static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
  unsigned long *parent_rate)
 {
+   struct sun4i_dclk *dclk = hw_to_dclk(hw);
+   struct sun4i_tcon *tcon = dclk->tcon;
unsigned long best_parent = 0;
u8 best_div = 1;
int i;
 
-   for (i = 6; i <= 127; i++) {
+   for (i = tcon->dclk_min_div; i <= tcon->dclk_max_div; i++) {
unsigned long ideal = rate * i;
unsigned long rounded;
 
@@ -167,6 +170,7 @@ int sun4i_dclk_create(struct device *dev, struct sun4i_tcon 
*tcon)
dclk = devm_kzalloc(dev, sizeof(*dclk), GFP_KERNEL);
if (!dclk)
return -ENOMEM;
+   dclk->tcon = tcon;
 
init.name = clk_name;
init.ops = _dclk_ops;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ea056a3d2131..46e28ca1f676 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -177,6 +177,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
u8 clk_delay;
u32 val = 0;
 
+   tcon->dclk_min_div = 6;
+   tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
 
/* Adjust clock delay */
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 839266a38505..bd3ad7684870 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -169,6 +169,8 @@ struct sun4i_tcon {
 
/* Pixel clock */
struct clk  *dclk;
+   u8  dclk_max_div;
+   u8  dclk_min_div;
 
/* Reset control */
struct reset_control*lcd_rst;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 00/15] drm/sun4i: Add A83t LVDS support

[Maxime Ripard]

Hi,

Here is an attempt at supporting the LVDS output in our DRM driver. This
has been tested on the A83T (with DE2), but since everything is basically
in the TCON, it should also be usable on the older SoCs with minor
modifications.

This was the occasion to refactor a bunch of things. The most notable ones
would be the documentation, and split of the UI layers in the mixer code,
and the switch to kfifo for our endpoint parsing code in the driver that
fixes an issue introduced by the switch to BFS.

Let me know what you think,
Maxime

Changes from v2:
  - Move the module clock rate to the mixer structure
  - Adjusted the simple-panel documentation for power-supply
  - Changed the compatible for the first A83t mixer to mixer 0
  - Rebased on top of current drm-misc
  - Split out the A83t bindings in its separate patch

Changes from v1:
  - Added a fix for the error path handling in the TCON
  - Enable the TCON by default
  - Removed the patch that changes the channels offset but kept most of the
modifications as a cleanup
  - Deal with the LVDS clock being able to have another PLL parent on some
SoCs
  - Renamed the TCON compatible to TCON-TV, following the convention used
on newer SoCs
  - Removed the hardcoded timings
  - Moved LVDS enable quirks to a separate function
  - Used clock indices define in the DT
  - Removed the hardcoded clock rate in the DT and moved it to the driver
  - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent
  - Added the various tags collected
  - Rebased on top of 4.15

Maxime Ripard (15):
  dt-bindings: panel: lvds: Document power-supply property
  drm/panel: lvds: Add support for the power-supply property
  dt-bindings: display: sun4i-drm: Add LVDS properties
  dt-bindings: display: sun4i-drm: Add A83T pipeline
  drm/sun4i: Fix error path handling
  drm/sun4i: Force the mixer rate at 150MHz
  drm/sun4i: Create minimal multipliers and dividers
  drm/sun4i: Add LVDS support
  drm/sun4i: Add A83T support
  ARM: dts: sun8i: a83t: Add display pipeline
  ARM: dts: sun8i: a83t: Enable the PWM
  ARM: dts: sun8i: a83t: Add LVDS pins group
  ARM: dts: sun8i: a83t: Add the PWM pin group
  ARM: dts: sun8i: a711: Reinstate the PMIC compatible
  ARM: dts: sun8i: a711: Enable the LCD

 Documentation/devicetree/bindings/display/panel/panel-common.txt |   6 ++-
 Documentation/devicetree/bindings/display/panel/panel-lvds.txt   |   1 +-
 Documentation/devicetree/bindings/display/panel/simple-panel.txt |   2 +-
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt|  11 +++-
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts|  62 
++-
 arch/arm/boot/dts/sun8i-a83t.dtsi|  99 
+-
 drivers/gpu/drm/panel/panel-lvds.c   |  23 +++-
 drivers/gpu/drm/sun4i/Makefile   |   1 +-
 drivers/gpu/drm/sun4i/sun4i_dotclock.c   |  10 ++-
 drivers/gpu/drm/sun4i/sun4i_drv.c|   1 +-
 drivers/gpu/drm/sun4i/sun4i_lvds.c   | 183 
+-
 drivers/gpu/drm/sun4i/sun4i_lvds.h   |  18 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 247 
+++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h   |  31 
+-
 drivers/gpu/drm/sun4i/sun8i_mixer.c  |  18 +-
 drivers/gpu/drm/sun4i/sun8i_mixer.h  |   3 +-
 16 files changed, 709 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

base-commit: 3b71239181e5429702387666f1ac70a9e6856cce
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 01/15] dt-bindings: panel: lvds: Document power-supply property

[Maxime Ripard]

The power-supply property is used by a vast majority of panels, including
panel-simple. Let's document it as a common property

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++
 Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
 Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
b/Documentation/devicetree/bindings/display/panel/panel-common.txt
index ec52c472c845..125ea68052af 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
@@ -78,6 +78,12 @@ used for panels that implement compatible control signals.
   while active. Active high reset signals can be supported by inverting the
   GPIO specifier polarity flag.
 
+Power
+-
+
+- power-supply: many display panels need an additional power supply in
+  order to be fully powered-up. For such panels, power-supply contains
+  a phandle to the regulator powering the panel.
 
 Backlight
 -
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt 
b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
index b938269f841e..250850a2150b 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
@@ -32,6 +32,7 @@ Optional properties:
 - label: See panel-common.txt.
 - gpios: See panel-common.txt.
 - backlight: See panel-common.txt.
+- power-supply: See panel-common.txt.
 - data-mirror: If set, reverse the bit order described in the data mappings
   below on all data lanes, transmitting bits for slots 6 to 0 instead of
   0 to 6.
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 1341bbf4aa3d..16d8ff088b7d 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -1,7 +1,7 @@
 Simple display panel
 
 Required properties:
-- power-supply: regulator to provide the supply voltage
+- power-supply: See panel-common.txt
 
 Optional properties:
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 10/15] ARM: dts: sun8i: a83t: Add display pipeline

[Maxime Ripard]

The display pipeline on the A83T is mainly composed of the mixers and
TCONs, plus various encoders.

Let's add the first mixer and TCON to the DTSI since the only board I have
can use only the LVDS output on the first TCON. The other parts will be
added eventually.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 79 -
 1 file changed, 79 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 19acae1b4089..e4db38c717d9 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -45,8 +45,10 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -151,6 +153,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun8i-a83t-display-engine";
+   allwinner,pipelines = <>;
+   status = "disabled";
+   };
+
memory {
reg = <0x4000 0x8000>;
device_type = "memory";
@@ -162,6 +170,44 @@
#size-cells = <1>;
ranges;
 
+   display_clocks: clock@100 {
+   compatible = "allwinner,sun8i-a83t-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_PLL_DE>,
+< CLK_BUS_DE>;
+   clock-names = "mod",
+ "bus";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-a83t-de2-mixer-0";
+   reg = <0x0110 0x10>;
+   clocks = <_clocks CLK_BUS_MIXER0>,
+<_clocks CLK_MIXER0>;
+   clock-names = "bus",
+ "mod";
+   resets = <_clocks RST_MIXER0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_mixer0>;
+   };
+   };
+   };
+   };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -177,6 +223,39 @@
#dma-cells = <1>;
};
 
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-a83t-tcon-lcd";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
+   clock-names = "ahb", "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = < RST_BUS_TCON0>, < RST_BUS_LVDS>;
+   reset-names = "lcd", "lvds";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_mixer0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
 "allwinner,sun7i-a20-mmc";
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: swap consecutive allocated pooled pages v4

[Michel Dänzer]

On 2017-12-05 01:54 PM, Christian König wrote:
> When we detect consecutive allocation of pages swap them to avoid
> accidentally freeing them as huge page.
> 
> v2: use swap
> v3: check if it's really the first allocated page
> v4: don't touch the loop variable
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index b6f7ce286fb1..44343a2bf55c 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -958,8 +958,15 @@ static int ttm_get_pages(struct page **pages, unsigned 
> npages, int flags,
>   r = ttm_page_pool_get_pages(pool, , flags, cstate,
>   npages - count, 0);
>  
> - list_for_each_entry(p, , lru)
> - pages[count++] = p;
> + first = count;
> + list_for_each_entry(p, , lru) {
> + struct page *tmp = p;
> +
> + /* Swap the pages if we detect consecutive order */
> + if (count > first && pages[count - 1] == tmp - 1)
> + swap(tmp, pages[count - 1]);
> + pages[count++] = tmp;
> + }
>  
>   if (r) {
>   /* If there is any pages in the list put them back to
> 

Reviewed-by: Michel Dänzer 


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

Re: [Intel-gfx] [RFC PATCH 0/6] drm/i915: Implement HDCP

[Sean Paul]

On Tue, Dec 5, 2017 at 8:45 AM, Ville Syrjälä
 wrote:
> On Thu, Nov 30, 2017 at 08:50:38AM +0100, Daniel Vetter wrote:
>> On Wed, Nov 29, 2017 at 10:08:55PM -0500, Sean Paul wrote:
>> > Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've 
>> > been
>> > using in Chrome for the past 3 years. I posted the property to the list 
>> > back
>> > then, but never had a mainline driver to implement it. I do now :-)
>> >
>> > Things are mostly in place, danvet gave me some feedback that I will
>> > incorporate in v1. However, in the interest of gaining more early 
>> > feedback, I'm
>> > posting this now.
>> >
>> > TODO:
>> > - Add kerneldoc for property
>>
>> The big thing I'd like to see here is clear description of the flows
>> between kernel and userspace (since there's no helpers on the kernel side
>> to standardize this).
>>
>> One thing we discussed in that context is the addition of an uevent (like
>> we do for anything else that changes with connectors, link_status is one
>> example). But since the hdcp spec explicitly demands that the video player
>> must poll the status an event is moot and won't be used. And I'm no fan of
>> speculative uapi :-)
>
> Speaking of uapi... Do we have an open source userspace and igts for
> this somewhere?
>

The userspace is implemented in Chrome for Chrome OS:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc

I posted an igt test on the list earlier today.

Sean

> I'm also concerned about debugging this. It will be a real PITA
> to do if we can't even test it easily.
>
>>
>> > - Fix '//' comments
>> > - Change to MIT license
>> > - Rebase on Ville's gmbus fixes (thanks Ville)
>> > - Improve documentation on drm_intel_hdcp_shim
>> > - Fix async commit locking (ie: don't use connection_mutex)
>> > - Don't change connector->state in enable, defer to worker
>>
>> Same holds for the disable callback, you can't touch state in there.
>>
>> With the link_status prop (which is somewhat similar) we only reset it in
>> atomic_check (where we hold the state locks) and in the async worker (same
>> applies).
>> -Daniel
>>
>> > - Add igt coverage for the feature.
>> >
>> > Thanks!
>> >
>> > Sean
>> >
>> >
>> > Sean Paul (6):
>> >   drm: Add Content Protection property
>> >   drm: Add some HDCP related #defines
>> >   drm/i915: Add HDCP framework + base implementation
>> >   drm/i915: Add function to output Aksv over GMBUS
>> >   drm/i915: Implement HDCP for HDMI
>> >   drm/i915: Implement HDCP for DisplayPort
>> >
>> >  drivers/gpu/drm/drm_atomic.c|   8 +
>> >  drivers/gpu/drm/drm_connector.c |  43 +++
>> >  drivers/gpu/drm/drm_sysfs.c |  29 ++
>> >  drivers/gpu/drm/i915/Makefile   |   1 +
>> >  drivers/gpu/drm/i915/i915_drv.h |   1 +
>> >  drivers/gpu/drm/i915/i915_reg.h |  85 +
>> >  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>> >  drivers/gpu/drm/i915/intel_ddi.c|  64 
>> >  drivers/gpu/drm/i915/intel_dp.c | 243 +-
>> >  drivers/gpu/drm/i915/intel_drv.h|  53 +++
>> >  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
>> > 
>> >  drivers/gpu/drm/i915/intel_hdmi.c   | 253 ++
>> >  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
>> >  include/drm/drm_connector.h |  16 +
>> >  include/drm/drm_dp_helper.h |  17 +
>> >  include/drm/drm_hdcp.h  |  44 +++
>> >  include/uapi/drm/drm_mode.h |   4 +
>> >  17 files changed, 1560 insertions(+), 17 deletions(-)
>> >  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>> >  create mode 100644 include/drm/drm_hdcp.h
>> >
>> > --
>> > 2.15.0.531.g2ccb3012c9-goog
>> >
>> > ___
>> > Intel-gfx mailing list
>> > intel-...@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

[bugzilla-daemon]

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

--- Comment #15 from letha...@gmail.com ---
dc_log enabled:

:~# dmesg | grep drm
[1.413712] [drm] amdgpu kernel modesetting enabled.
[1.420821] fb: switching to amdgpudrmfb from VESA VGA
[1.421365] [drm] initializing kernel modesetting (POLARIS12 0x1002:0x699F
0x1DA2:0xE367 0xC7).
[1.421375] [drm] register mmio base: 0xFF9C
[1.421376] [drm] register mmio size: 262144
[1.421386] [drm] probing gen 2 caps for device 8086:277d = 2012501/0
[1.421387] [drm] probing mlw for device 8086:277d = 2012501
[1.421395] [drm] UVD is enabled in VM mode
[1.421396] [drm] UVD ENC is enabled in VM mode
[1.421398] [drm] VCE enabled in VM mode
[1.422382] [drm] GPU post is not needed
[1.422402] [drm] vm size is 64 GB, block size is 13-bit, fragment size is
9-bit
[1.422452] [drm] Detected VRAM RAM=2048M, BAR=256M
[1.422453] [drm] RAM width 128bits GDDR5
[1.422538] [drm] amdgpu: 2048M of VRAM memory ready
[1.422539] [drm] amdgpu: 3072M of GTT memory ready.
[1.422547] [drm] GART: num cpu pages 65536, num gpu pages 65536
[1.422597] [drm] PCIE GART of 256M enabled (table at 0x00F40004).
[1.422690] [drm] amdgpu: irq initialized.
[1.422768] [drm] Chained IB support enabled!
[1.424499] [drm] Found UVD firmware Version: 1.79 Family ID: 16
[1.425670] [drm] Found VCE firmware Version: 52.4 Binary ID: 3
[1.505597] [drm] DM_PPLIB: values for Engine clock
[1.505599] [drm] DM_PPLIB:   21400
[1.505600] [drm] DM_PPLIB:   55100
[1.505600] [drm] DM_PPLIB:   73400
[1.505601] [drm] DM_PPLIB:   98000
[1.505601] [drm] DM_PPLIB:   104600
[1.505602] [drm] DM_PPLIB:   109800
[1.505602] [drm] DM_PPLIB:   112400
[1.505603] [drm] DM_PPLIB:   120600
[1.505603] [drm] DM_PPLIB: Warning: using default validation clocks!
[1.505604] [drm] DM_PPLIB: Validation clocks:
[1.505605] [drm] DM_PPLIB:engine_max_clock: 72000
[1.505605] [drm] DM_PPLIB:memory_max_clock: 8
[1.505606] [drm] DM_PPLIB:level   : 0
[1.505606] [drm] DM_PPLIB: reducing engine clock level from 8 to 2
[1.505608] [drm] DM_PPLIB: values for Memory clock
[1.505608] [drm] DM_PPLIB:   3
[1.505609] [drm] DM_PPLIB:   62500
[1.505609] [drm] DM_PPLIB:   175000
[1.505610] [drm] DM_PPLIB: Warning: using default validation clocks!
[1.505611] [drm] DM_PPLIB: Validation clocks:
[1.505611] [drm] DM_PPLIB:engine_max_clock: 72000
[1.505612] [drm] DM_PPLIB:memory_max_clock: 8
[1.505612] [drm] DM_PPLIB:level   : 0
[1.505613] [drm] DM_PPLIB: reducing memory clock level from 3 to 2
[1.505615] [drm] DC: create_links: connectors_num: physical:3, virtual:0
[1.505620] [drm] Connector[0] description:signal 32
[1.505637] [drm] Connector[1] description:signal 4
[1.505650] [drm] Connector[2] description:signal 2
[1.515049] [drm] Display Core initialized
[1.515051] [drm] Display Core initialized!
[1.515588] [drm] link=0, dc_sink_in=  (null) is now Disconnected
[1.540524] [drm] [Detect]   [HDMIA][ConnIdx:1] DENON-AVAMP: [Block 0] 00 FF
FF FF FF FF FF 00 11 EE 29 00 01 01 01 01 00 15 01 03 80 00 00 78 0A DA FF A3
58 4A A2 29 17 49 4B 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 1D 80 D0 72 1C 16 20 10 2C 25 80 9A 26 53 00 00 9E 01 1D 80 18 71 1C 16 20
58 2C 25 00 9A 26 53 00 00 9E 00 00 00 FC 00 44 45 4E 4F 4E 2D 41 56 41 4D 50
0A 20 00 00 00 FD 00 17 3D 0F 44 0F 00 0A 20 20 20 20 20 20 01 CA ^
[1.540538] [drm] [Detect]   [HDMIA][ConnIdx:1] DENON-AVAMP: [Block 1] 02 03
3B 72 58 13 04 94 85 1F 10 20 12 03 11 02 16 07 15 06 01 0E 23 0F 24 1D 25 1E
26 32 0F 7F 07 3D 1E C0 15 07 50 5F 7E 01 57 06 00 67 7E 00 83 5F 00 00 66 03
0C 00 12 00 80 01 1D 80 D0 72 1C 16 20 10 2C 25 80 9A 26 53 00 00 9E 8C 0A D0
90 20 40 31 20 0C 40 55 00 9A 26 53 00 00 18 01 1D 80 18 71 1C 16 20 58 2C 25
00 9A 26 53 00 00 9E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CB ^
[1.540541] [drm] dc_link_detect: manufacturer_id = EE11, product_id = 29,
serial_number = 1010101, manufacture_week = 0, manufacture_year = 21,
display_name = DENON-AVAMP, speaker_flag = 95, audio_mode_count = 6
[1.540542] [drm] dc_link_detect: mode number = 0, format_code = 1,
channel_count = 7, sample_rate = 127, sample_size = 7
[1.540543] [drm] dc_link_detect: mode number = 1, format_code = 7,
channel_count = 5, sample_rate = 30, sample_size = 192
[1.540545] [drm] dc_link_detect: mode number = 2, format_code = 2,
channel_count = 5, sample_rate = 7, sample_size = 80
[1.540546] [drm] dc_link_detect: mode number = 3, format_code = 11,
channel_count = 7, sample_rate = 126, sample_size = 1
[1.540547] [drm] dc_link_detect: mode number = 4, format_code = 10,
channel_count = 7, sample_rate = 6, sample_size = 0
[1.540549] [drm] dc_link_detect: mode number = 5, format_code = 12,
channel_count = 7, sample_rate = 126, 

Re: [PATCH v3 3/9] drm: Add Content Protection property

[Sean Paul]

On Tue, Dec 5, 2017 at 9:04 AM, Ramalingam C  wrote:
>
>
> On Tuesday 05 December 2017 01:37 PM, Hans Verkuil wrote:
>
> On 12/05/2017 06:15 AM, Sean Paul wrote:
>
> This patch adds a new optional connector property to allow userspace to
> enable
> protection over the content it is displaying. This will typically be
> implemented
> by the driver using HDCP.
>
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
>
> The driver is responsible for downgrading ENABLED to DESIRED if the link
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.
>
> If this looks familiar, I posted [1] this 3 years ago. We have been using
> this
> in ChromeOS across exynos, mediatek, and rockchip over that time.
>
> Changes in v2:
>  - Pimp kerneldoc for content_protection_property (Daniel)
>  - Drop sysfs attribute
> Changes in v3:
>  - None
>
> Cc: Daniel Vetter 
> Signed-off-by: Sean Paul 
>
> [1]
> https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 +
>  drivers/gpu/drm/drm_connector.c | 71
> +
>  drivers/gpu/drm/drm_sysfs.c |  1 +
>  include/drm/drm_connector.h | 16 ++
>  include/uapi/drm/drm_mode.h |  4 +++
>  5 files changed, 100 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..676025d755b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == connector->content_protection_property) {
> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> + return -EINVAL;
> + }
> + state->content_protection = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == connector->content_protection_property) {
> + *val = state->content_protection;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index f14b48e6e839..8626aa8f485e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   drm_tv_subconnector_enum_list)
>
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *  after modeset, the kernel driver may set this to "BAD" and issue a
>   *  hotplug uevent. Drivers should update this value using
>   *  drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + * This property is used by userspace to request the kernel protect future
> + * content communicated over the link. When requested, kernel will apply
> + * the appropriate means of protection (most often HDCP), and use the
> + * property to tell userspace the protection is active.
> + *
> + * The value of this property can be one of the following:
> + *
> + * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> + * The link is not protected, content is transmitted in the clear.
> + * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> + * Userspace has requested content protection, but the link is not
> + * currently protected. When in this state, kernel should enable
> + * Content Protection as soon as possible.
> + * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
> + * Userspace has requested content protection, and the link is
> + * protected. Only the driver can set the property to this value.
> + * If userspace attempts to set to ENABLED, kernel will return
> + * -EINVAL.
> + *
> + * A few guidelines:
> + *
> + * - DESIRED state 

Re: [PATCH v3 9/9] drm/i915: Implement HDCP for DisplayPort

[Ramalingam C]

On Tuesday 05 December 2017 10:45 AM, Sean Paul wrote:

+static
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+{
+   ssize_t ret;
+   u8 bstatus;
+   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
+  , 1);
+   if (ret != 1) {
+   DRM_ERROR("Read bstatus from DP/AUX failed (%ld)\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+   return !(bstatus & DP_BSTATUS_LINK_FAILURE);
+}
as per link integrity check should cover other indication from the 
repeater like


REAUTHENTICATION_REQUEST - request for reauth due to unauthenticated 
state at downstream for some unknown reason


-Ram

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

[bugzilla-daemon]

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

--- Comment #14 from letha...@gmail.com ---
Created attachment 135979
  --> https://bugs.freedesktop.org/attachment.cgi?id=135979=edit
recording of audio LPCM output from RX550 card

-- 
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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

[bugzilla-daemon]

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

--- Comment #13 from letha...@gmail.com ---
This is an example running mpv & decoding the stereo pcm_s16le 2ch 48000Hz to 6
channels 48Khz.

This generates the audio + noise ( small wav recording attached to this case)


mpv command & verbose:
~# DISPLAY=:0.0 mpv --audio-device='alsa/hdmi:CARD=HDMI,DEV=3' /Fr* -vo vdpau
--audio-channels=8 -vo gpu -v
[cplayer] Command line options: '--audio-device=alsa/hdmi:CARD=HDMI,DEV=3'
'/Francis.mkv' '-vo' 'vdpau' '--audio-channels=8' '-vo' 'gpu' '-v'
[cplayer] mpv git-2017-10-14-b299a3f (C) 2000-2017 mpv/MPlayer/mplayer2
projects
[cplayer]  built on Tue Oct 17 01:30:07 UTC 2017
[cplayer] ffmpeg library versions:
[cplayer]libavutil   55.79.100
[cplayer]libavcodec  57.108.100
[cplayer]libavformat 57.84.100
[cplayer]libswscale  4.9.100
[cplayer]libavfilter 6.108.100
[cplayer]libswresample   2.10.100
[cplayer] ffmpeg version: git-2017-10-14-0655810
[cplayer]
[cplayer] Configuration: ./waf configure CC=clang-4.0 --enable-pdf-build
--enable-dvbin --enable-dvdread --enable-dvdnav --enable-html-build
--prefix=/usr --confdir=/etc/mpv
[cplayer] List of enabled features: 52arch alsa asm atomics
avutil-content-light-level avutil-icc-profile avutil-spherical build-date
cplayer cplugins cuda-hwaccel debug-build drm dvbin dvdnav dvdread
dvdread-common egl-drm egl-helpers egl-x11 encoding fchmod gbm gbm.h gl
gl-wayland gl-x11 glibc-thread-name glob glob-posix gnuc gpl iconv is_ffmpeg
jack jpeg lcms2 libaf libass libass-osd libav libavcodec libavdevice libbluray
libdl libm librt linux-fstatfs lua nanosleep optimize oss-audio posix
posix-or-mingw posix-spawn posix-spawn-native pthreads pulse rubberband shm
stdatomic termios uchardet vaapi vaapi-drm vaapi-egl vaapi-glx vaapi-hwaccel
vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vdpau-gl-x11 vdpau-hwaccel vt.h
wayland wayland-protocols x11 xv zlib


[bdmv/bluray] Opening /Francis.mkv
[file] Opening /Francis.mkv
[file] Stream opened successfully.
[demux] Trying demuxers for level=normal.
[mkv] Found the head...
[mkv] + a segment...
[mkv] Parsing seek head...
[mkv] |+ segment information...
[mkv] | + muxing app: libebml v1.3.5 + libmatroska v1.4.5
[mkv] | + writing app: mkvmerge v15.0.0 ('Duel with the Devil') 64-bit
[mkv] | + timecode scale: 100
[mkv] | + duration: 10595.641s
[mkv] | + segment uid 9f 5f 3d 2a 9c 0f 87 99 b4 ab 82 7c e8 54 b3 21
[mkv] |+ segment tracks...
[mkv] | + a track...
[mkv] |  + Track number: 1
[mkv] |  + Track type: Video
[mkv] |  + Video track
[mkv] |   + Display width: 1920
[mkv] |   + Display height: 1080
[mkv] |   + Pixel width: 1920
[mkv] |   + Pixel height: 1080
[mkv] |  + Codec ID: V_MPEG4/ISO/AVC
[mkv] |  + CodecPrivate, length 58
[mkv] |  + Language: und
[mkv] |  + Default duration: 40.000ms ( = 25.000 fps)
[mkv] | + a track...
[mkv] |  + Track number: 2
[mkv] |  + Track type: Audio
[mkv] |  + Audio track
[mkv] |   + Sampling frequency: 48000.00
[mkv] |   + Bit depth: 16
[mkv] |   + Channels: 2
[mkv] |  + Codec ID: A_PCM/INT/LIT
[mkv] |  + Language: und
[mkv] |  + Default duration: 31.250ms ( = 32.000 fps)
[mkv] | + a track...
[mkv] |  + Track number: 3
[mkv] |  + Track type: Audio
[mkv] |  + Audio track
[mkv] |   + Sampling frequency: 48000.00
[mkv] |   + Bit depth: 24
[mkv] |   + Channels: 6
[mkv] |  + Codec ID: A_DTS
[mkv] |  + Language: und
[mkv] |  + Default flag: 0
[mkv] |  + Default duration: 10.667ms ( = 93.750 fps)
[mkv] Parsing chapters...
[mkv] New edition 0
[mkv] Default edition flag: 0
[mkv] |+ found cluster
[mkv] SeekHead position beyond end of file - incomplete file?
[mkv] All headers are parsed!
[demux] Detected file format: Matroska
[cplayer] Opening done: /Francis.mkv
[find_files] Loading external files in /

[cplayer] Running hook: ytdl_hook/on_preloaded
[cplayer] Run command: hook-ack, flags=0, args=[on_preloaded]
[cplayer]  (+) Video --vid=1 (*) (h264 1920x1080 25.000fps)
[cplayer]  (+) Audio --aid=1 (*) (pcm_s16le 2ch 48000Hz)
[cplayer]  Audio --aid=2 (dts 6ch 48000Hz)
[vo/gpu] Probing for best GPU context.
[vo/gpu/opengl] Initializing GPU context 'x11probe'
[vo/gpu/x11] X11 opening display: :0.0
[vo/gpu/x11] X11 running at 1920x1080 (":0.0" => local display)
[vo/gpu/x11] Unknown wm type...
[vo/gpu/x11] Display 0 (HDMI-A-0): [0, 0, 1920, 1080] @ 60.00 FPS
[vo/gpu/x11] Current display FPS: 60.00
[vo/gpu/opengl] GLX chose FB config with ID 0xad
[vo/gpu/opengl] GLX chose visual with ID 0x303
[vo/gpu/opengl] Creating OpenGL 4.4 context...
[vo/gpu] GL_VERSION='4.5 (Core Profile) Mesa 17.4.0-devel - padoka PPA'
[vo/gpu] Detected desktop OpenGL 4.5.
[vo/gpu] GL_VENDOR='X.Org'
[vo/gpu] GL_RENDERER='Radeon RX 550 Series (POLARIS12 / DRM 3.23.0 /
4.15.0-041500rc2-lowlatency, LLVM 6.0.0)'
[vo/gpu] GL_SHADING_LANGUAGE_VERSION='4.50'
[vo/gpu] Loaded extension GLX_SGI_swap_control.
[vo/gpu] Loaded extension GLX_MESA_swap_control.
[vo/gpu] Loaded extension GLX_SGI_video_sync.

Re: [PATCH 1/2] drm/nouveau/bar/gf100: fix hang when calling ->fini() before ->init()

[Jon Hunter]

On 04/12/17 18:37, Guillaume Tucker wrote:
> If the firmware fails to load then ->fini() will be called before the
> device has been initialised, causing the kernel to hang while trying
> to write to a register.  Add a test in ->fini() to avoid this issue.
> 
> This fixes a kernel hang on tegra124.
> 
> Fixes: b17de35a2ebbe ("drm/nouveau/bar: implement bar1 teardown")
> Signed-off-by: Guillaume Tucker 
> CC: Ben Skeggs 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> index a3ba7f50198b..95e2aba64aad 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
> @@ -43,9 +43,12 @@ gf100_bar_bar1_wait(struct nvkm_bar *base)
>  }
>  
>  void
> -gf100_bar_bar1_fini(struct nvkm_bar *bar)
> +gf100_bar_bar1_fini(struct nvkm_bar *base)
>  {
> - nvkm_mask(bar->subdev.device, 0x001704, 0x8000, 0x);
> + struct nvkm_device *device = base->subdev.device;
> +
> + if (base->subdev.oneinit)
> + nvkm_mask(device, 0x001704, 0x8000, 0x);
>  }
>  
>  void

I have tested this and it works for me. Thanks for fixing this! Would be
good to get Ben's ACK, but you can have my ...

Tested-by: Jon Hunter 

Cheers
Jon

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

Re: [PATCH] drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback

[Marek Szyprowski]

Hi Misha,

On 2017-12-05 15:06, Misha Komarovskiy wrote:

On Mon, Nov 27, 2017 at 6:40 AM, Archit Taneja  wrote:

On 11/21/2017 01:19 PM, Marek Szyprowski wrote:

get_modes() callback might be called asynchronously from the DRM core and
it is not synchronized with bridge_enable(), which sets proper runtime PM
state of the main DP device. Fix this by calling pm_runtime_get_sync()
before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and
analogix_dp_transfer() to ensure that main DP device is runtime active
when doing any access to its registers.

Looks good to me. Would be nice to get an ack from rockchip too. Will queue
it
to drm-misc-fixes (so that it's merged for 4.15-rc2) if no one has any
objections.

After this patch accepted to 4.15-rc2 any chances to have it also in
4.14 stable?

I tested it manualy and it fixes boot freeze on snow with 4.14.
If required,
Tested-by: Misha Komarovskiy 


The patch is tagged cc: stable, so it should automatically get into v4.14.y
series once it finally lands in v4.15-rcX series.

> ...

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [PATCH v3 3/9] drm: Add Content Protection property

[Ramalingam C]

On Tuesday 05 December 2017 01:37 PM, Hans Verkuil wrote:

On 12/05/2017 06:15 AM, Sean Paul wrote:

This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.

The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value

The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.

If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.

Changes in v2:
  - Pimp kerneldoc for content_protection_property (Daniel)
  - Drop sysfs attribute
Changes in v3:
  - None

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 

[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
---
  drivers/gpu/drm/drm_atomic.c|  8 +
  drivers/gpu/drm/drm_connector.c | 71 +
  drivers/gpu/drm/drm_sysfs.c |  1 +
  include/drm/drm_connector.h | 16 ++
  include/uapi/drm/drm_mode.h |  4 +++
  5 files changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2da5585e201..676025d755b2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == connector->content_protection_property) {
+   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
+   return -EINVAL;
+   }
+   state->content_protection = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == connector->content_protection_property) {
+   *val = state->content_protection;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f14b48e6e839..8626aa8f485e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
  
+static struct drm_prop_enum_list drm_cp_enum_list[] = {

+{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
+{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
  /**
   * DOC: standard connector properties
   *
@@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
   *  after modeset, the kernel driver may set this to "BAD" and issue a
   *  hotplug uevent. Drivers should update this value using
   *  drm_mode_connector_set_link_status_property().
+ * Content Protection:
+ * This property is used by userspace to request the kernel protect future
+ * content communicated over the link. When requested, kernel will apply
+ * the appropriate means of protection (most often HDCP), and use the
+ * property to tell userspace the protection is active.
+ *
+ * The value of this property can be one of the following:
+ *
+ * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
+ * The link is not protected, content is transmitted in the clear.
+ * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
+ * Userspace has requested content protection, but the link is not
+ * currently protected. When in this state, kernel should enable
+ * Content Protection as soon as possible.
+ * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
+ * Userspace has requested content protection, and the link is
+ * protected. Only the driver can set the property to this value.
+ *   

Re: [Intel-gfx] [RFC PATCH 0/6] drm/i915: Implement HDCP

[Ville Syrjälä]

On Thu, Nov 30, 2017 at 08:50:38AM +0100, Daniel Vetter wrote:
> On Wed, Nov 29, 2017 at 10:08:55PM -0500, Sean Paul wrote:
> > Here's the RFC for my i915 HDCP patchset. The UABI is based on what we've 
> > been
> > using in Chrome for the past 3 years. I posted the property to the list back
> > then, but never had a mainline driver to implement it. I do now :-)
> > 
> > Things are mostly in place, danvet gave me some feedback that I will
> > incorporate in v1. However, in the interest of gaining more early feedback, 
> > I'm
> > posting this now.
> > 
> > TODO:
> > - Add kerneldoc for property
> 
> The big thing I'd like to see here is clear description of the flows
> between kernel and userspace (since there's no helpers on the kernel side
> to standardize this).
> 
> One thing we discussed in that context is the addition of an uevent (like
> we do for anything else that changes with connectors, link_status is one
> example). But since the hdcp spec explicitly demands that the video player
> must poll the status an event is moot and won't be used. And I'm no fan of
> speculative uapi :-)

Speaking of uapi... Do we have an open source userspace and igts for
this somewhere?

I'm also concerned about debugging this. It will be a real PITA
to do if we can't even test it easily.

> 
> > - Fix '//' comments
> > - Change to MIT license
> > - Rebase on Ville's gmbus fixes (thanks Ville)
> > - Improve documentation on drm_intel_hdcp_shim
> > - Fix async commit locking (ie: don't use connection_mutex)
> > - Don't change connector->state in enable, defer to worker
> 
> Same holds for the disable callback, you can't touch state in there.
> 
> With the link_status prop (which is somewhat similar) we only reset it in
> atomic_check (where we hold the state locks) and in the async worker (same
> applies).
> -Daniel
> 
> > - Add igt coverage for the feature.
> > 
> > Thanks!
> > 
> > Sean
> > 
> > 
> > Sean Paul (6):
> >   drm: Add Content Protection property
> >   drm: Add some HDCP related #defines
> >   drm/i915: Add HDCP framework + base implementation
> >   drm/i915: Add function to output Aksv over GMBUS
> >   drm/i915: Implement HDCP for HDMI
> >   drm/i915: Implement HDCP for DisplayPort
> > 
> >  drivers/gpu/drm/drm_atomic.c|   8 +
> >  drivers/gpu/drm/drm_connector.c |  43 +++
> >  drivers/gpu/drm/drm_sysfs.c |  29 ++
> >  drivers/gpu/drm/i915/Makefile   |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h |   1 +
> >  drivers/gpu/drm/i915/i915_reg.h |  85 +
> >  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> >  drivers/gpu/drm/i915/intel_ddi.c|  64 
> >  drivers/gpu/drm/i915/intel_dp.c | 243 +-
> >  drivers/gpu/drm/i915/intel_drv.h|  53 +++
> >  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> > 
> >  drivers/gpu/drm/i915/intel_hdmi.c   | 253 ++
> >  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
> >  include/drm/drm_connector.h |  16 +
> >  include/drm/drm_dp_helper.h |  17 +
> >  include/drm/drm_hdcp.h  |  44 +++
> >  include/uapi/drm/drm_mode.h |   4 +
> >  17 files changed, 1560 insertions(+), 17 deletions(-)
> >  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> >  create mode 100644 include/drm/drm_hdcp.h
> > 
> > -- 
> > 2.15.0.531.g2ccb3012c9-goog
> > 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH libdrm] amdgpu.ids: Refresh from AMD 17.40 release

[Christian König]

Am 05.12.2017 um 12:59 schrieb Michel Dänzer:

From: Michel Dänzer 

Reviewed-by: Alex Deucher 
Signed-off-by: Michel Dänzer 


Acked-by: Christian König 


---
  data/amdgpu.ids | 31 +--
  1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/data/amdgpu.ids b/data/amdgpu.ids
index f6c65dd9..1828e410 100644
--- a/data/amdgpu.ids
+++ b/data/amdgpu.ids
@@ -62,6 +62,7 @@
  67DF, C6, Radeon RX 570 Series
  67DF, C7, AMD Radeon (TM) RX 480 Graphics
  67DF, CF, AMD Radeon (TM) RX 470 Graphics
+67DF,  D7, Radeon(TM) RX 470 Graphics
  67DF, E3, Radeon RX Series
  67DF, E7, Radeon RX 580 Series
  67DF, EF, Radeon RX 570 Series
@@ -84,13 +85,16 @@
  67EF, C5, AMD Radeon (TM) RX 460 Graphics
  67EF, C7, AMD Radeon (TM) RX Graphics
  67EF, CF, AMD Radeon (TM) RX 460 Graphics
+67EF,  E0, Radeon RX 560 Series
  67EF, E1, Radeon RX Series
  67EF, E3, Radeon RX Series
-67EF,  E7, Radeon RX Series
+67EF,  E5, Radeon RX 560 Series
  67EF, EF, AMD Radeon (TM) RX Graphics
-67EF,  FF, Radeon RX Series
+67EF,  FF, Radeon(TM) RX 460 Graphics
  67FF, C0, AMD Radeon (TM) RX Graphics
  67FF, C1, AMD Radeon (TM) RX Graphics
+67FF,  CF, Radeon RX 560 Series
+67FF,  EF, Radeon RX 560 Series
  67FF, FF, Radeon RX 550 Series
  6800, 0,  AMD Radeon HD 7970M
  6801, 0,  AMD Radeon(TM) HD8970M
@@ -122,6 +126,25 @@
  6837, 0,  AMD Radeon HD7700 Series
  683D, 0,  AMD Radeon HD 7700 Series
  683F, 0,  AMD Radeon HD 7700 Series
+6860,  00, Radeon Instinct MI25
+6860,  01, Radeon Pro V320
+6860,  02, Radeon Instinct MI25
+6860,  03, Radeon Pro V340
+6860,  04, Radeon Instinct MI25x2
+6861,  00, Radeon(TM) Pro WX9100
+6862,  00, Radeon Pro SSG
+6863,  00, Radeon Vega Frontier Edition
+6864,  03, Radeon Pro V340
+6864,  04, Instinct MI25x2
+6868,  00, Radeon(TM) Pro WX8100
+686C,  00, GLXT (Radeon Instinct MI25) MxGPU VFID
+686C,  01, GLXT (Radeon Pro V320) MxGPU
+686C,  02, GLXT (Radeon Instinct MI25) MxGPU
+686C,  03, GLXT (Radeon Pro V340) MxGPU
+686C,  04, GLXT (Radeon Instinct MI25x2) MxGPU
+687F,  C0, Radeon RX Vega
+687F,  C1, Radeon RX Vega
+687F,  C3, Radeon RX Vega
  6900, 0,  AMD Radeon R7 M260
  6900, 81, AMD Radeon (TM) R7 M360
  6900, 83, AMD Radeon (TM) R7 M340
@@ -139,8 +162,12 @@
  6939, F0, AMD Radeon R9 200 Series
  6939, 0,  AMD Radeon R9 200 Series
  6939, F1, AMD Radeon (TM) R9 380 Series
+6980,  00, Radeon Pro WX3100
  6985, 00, AMD Radeon Pro WX3100
+6987,  80, AMD Embedded Radeon E9171
  6995, 00, AMD Radeon Pro WX2100
+6997,  00, Radeon Pro WX2100
+699F,  81, AMD Embedded Radeon E9170 Series
  699F, C0, Radeon 500 Series
  699F, C3, Radeon 500 Series
  699F, C7, Radeon RX 550 Series


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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

--- Comment #8 from Mike Lothian  ---
Looks like X starts now with the drm-next-4.16-wip branch

There's still an error in the logs:

[0.604111] [drm] amdgpu: dpm initialized
[0.605298] [drm] Found UVD firmware Version: 1.64 Family ID: 9
[0.605737] [drm] Found VCE firmware Version: 50.10 Binary ID: 2
[0.606558] [drm] DC: create_links: connectors_num: physical:3, virtual:0
[0.606596] [drm:construct] *ERROR* construct: Invalid Connector ObjectID
from Adapter Service for connector index:1!
[0.606606] [drm] dal_graphics_object_id_is_equal: Warning: comparing
invalid object 'id2'!
[0.609069] [drm] Display Core initialized!
[0.642428] [drm] dc_link_detect: manufacturer_id = 2D4C, product_id = C00,
serial_number = 1000601, manufacture_week = 42, manufacture_year = 24,
display_name = SAMSUNG, speaker_flag = 1, audio_mode_count = 3
[0.642444] [drm] dc_link_detect: mode number = 0, format_code = 1,
channel_count = 1, sample_rate = 7, sample_size = 7
[0.642454] [drm] dc_link_detect: mode number = 1, format_code = 2,
channel_count = 5, sample_rate = 7, sample_size = 80
[0.642464] [drm] dc_link_detect: mode number = 2, format_code = 7,
channel_count = 5, sample_rate = 4, sample_size = 192

I'll check drm-next and Linus's branches when I get home so we can hopefully
revert the kabini disablement on DC

-- 
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 libdrm] amdgpu.ids: Refresh from AMD 17.40 release

[Michel Dänzer]

From: Michel Dänzer 

Reviewed-by: Alex Deucher 
Signed-off-by: Michel Dänzer 
---
 data/amdgpu.ids | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/data/amdgpu.ids b/data/amdgpu.ids
index f6c65dd9..1828e410 100644
--- a/data/amdgpu.ids
+++ b/data/amdgpu.ids
@@ -62,6 +62,7 @@
 67DF,  C6, Radeon RX 570 Series
 67DF,  C7, AMD Radeon (TM) RX 480 Graphics
 67DF,  CF, AMD Radeon (TM) RX 470 Graphics
+67DF,  D7, Radeon(TM) RX 470 Graphics
 67DF,  E3, Radeon RX Series
 67DF,  E7, Radeon RX 580 Series
 67DF,  EF, Radeon RX 570 Series
@@ -84,13 +85,16 @@
 67EF,  C5, AMD Radeon (TM) RX 460 Graphics
 67EF,  C7, AMD Radeon (TM) RX Graphics
 67EF,  CF, AMD Radeon (TM) RX 460 Graphics
+67EF,  E0, Radeon RX 560 Series
 67EF,  E1, Radeon RX Series
 67EF,  E3, Radeon RX Series
-67EF,  E7, Radeon RX Series
+67EF,  E5, Radeon RX 560 Series
 67EF,  EF, AMD Radeon (TM) RX Graphics
-67EF,  FF, Radeon RX Series
+67EF,  FF, Radeon(TM) RX 460 Graphics
 67FF,  C0, AMD Radeon (TM) RX Graphics
 67FF,  C1, AMD Radeon (TM) RX Graphics
+67FF,  CF, Radeon RX 560 Series
+67FF,  EF, Radeon RX 560 Series
 67FF,  FF, Radeon RX 550 Series
 6800,  0,  AMD Radeon HD 7970M
 6801,  0,  AMD Radeon(TM) HD8970M
@@ -122,6 +126,25 @@
 6837,  0,  AMD Radeon HD7700 Series
 683D,  0,  AMD Radeon HD 7700 Series
 683F,  0,  AMD Radeon HD 7700 Series
+6860,  00, Radeon Instinct MI25
+6860,  01, Radeon Pro V320
+6860,  02, Radeon Instinct MI25
+6860,  03, Radeon Pro V340
+6860,  04, Radeon Instinct MI25x2
+6861,  00, Radeon(TM) Pro WX9100
+6862,  00, Radeon Pro SSG
+6863,  00, Radeon Vega Frontier Edition
+6864,  03, Radeon Pro V340
+6864,  04, Instinct MI25x2
+6868,  00, Radeon(TM) Pro WX8100
+686C,  00, GLXT (Radeon Instinct MI25) MxGPU VFID
+686C,  01, GLXT (Radeon Pro V320) MxGPU
+686C,  02, GLXT (Radeon Instinct MI25) MxGPU
+686C,  03, GLXT (Radeon Pro V340) MxGPU
+686C,  04, GLXT (Radeon Instinct MI25x2) MxGPU
+687F,  C0, Radeon RX Vega
+687F,  C1, Radeon RX Vega
+687F,  C3, Radeon RX Vega
 6900,  0,  AMD Radeon R7 M260
 6900,  81, AMD Radeon (TM) R7 M360
 6900,  83, AMD Radeon (TM) R7 M340
@@ -139,8 +162,12 @@
 6939,  F0, AMD Radeon R9 200 Series
 6939,  0,  AMD Radeon R9 200 Series
 6939,  F1, AMD Radeon (TM) R9 380 Series
+6980,  00, Radeon Pro WX3100
 6985,  00, AMD Radeon Pro WX3100
+6987,  80, AMD Embedded Radeon E9171
 6995,  00, AMD Radeon Pro WX2100
+6997,  00, Radeon Pro WX2100
+699F,  81, AMD Embedded Radeon E9170 Series
 699F,  C0, Radeon 500 Series
 699F,  C3, Radeon 500 Series
 699F,  C7, Radeon RX 550 Series
-- 
2.15.0

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

Re: [PATCH] drm/vmwgfx_kms: Fix potential NULL pointer dereference

[Ville Syrjälä]

On Mon, Dec 04, 2017 at 03:54:18PM -0600, Gustavo A. R. Silva wrote:
> crtc_state is being null checked in a previous code block, which implies
> that such pointer might be null.
> 
> crtc_state is dereferenced in drm_atomic_helper_check_plane_state, hence
> there is a potential null pointer dereference.

This is a false positive. drm_atomic_helper_check_plane_state() will not
dereference crtc_state when plane_state->crtc is NULL.

> 
> Fix this by warning-on and returning -EINVAL in case crtc_state is null.
> 
> Addresses-Coverity-ID: 1462412 ("Dereference after null check")
> Fixes: a01cb8ba3f62 ("drm: Move drm_plane_helper_check_state() into 
> drm_atomic_helper.c")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index a2a93d7..72c3b290 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -454,6 +454,9 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane 
> *plane,
>   clip.y2 = crtc_state->adjusted_mode.vdisplay;
>   }
>  
> + if (WARN_ON(!crtc_state))
> + return -EINVAL;

This would in fact break the driver because it would flag an error
whenever the plane is disabled.

> +
>   ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
> DRM_PLANE_HELPER_NO_SCALING,
> DRM_PLANE_HELPER_NO_SCALING,
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 Attachment #134327|0   |1
is obsolete||

--- Comment #7 from Mike Lothian  ---
Created attachment 135974
  --> https://bugs.freedesktop.org/attachment.cgi?id=135974=edit
Xorg.0.log

-- 
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 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 Attachment #134326|0   |1
is obsolete||

--- Comment #6 from Mike Lothian  ---
Created attachment 135973
  --> https://bugs.freedesktop.org/attachment.cgi?id=135973=edit
Dmesg

-- 
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 v3 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Noralf Trønnes]

Den 14.11.2017 22.25, skrev Noralf Trønnes:

Replace driver's code with the generic helpers that do the same thing.

Cc: Stefan Agner 
Cc: Alison Wang 
Signed-off-by: Noralf Trønnes 
Acked-by: Stefan Agner 
---


Applied to drm-misc.

Noralf.


Stefan, I didn't retain your tested-by tag now that I have rebased.


  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 ++---
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
  2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index faf17b83b910..80232321a244 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "fsl_dcu_drm_crtc.h"

  #include "fsl_dcu_drm_drv.h"
@@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
  static int fsl_dcu_drm_pm_suspend(struct device *dev)
  {
struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
+   int ret;
  
  	if (!fsl_dev)

return 0;
  
  	disable_irq(fsl_dev->irq);

-   drm_kms_helper_poll_disable(fsl_dev->drm);
  
-	console_lock();

-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
-   console_unlock();
-
-   fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
-   if (IS_ERR(fsl_dev->state)) {
-   console_lock();
-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
-
-   drm_kms_helper_poll_enable(fsl_dev->drm);
+   ret = drm_mode_config_helper_suspend(fsl_dev->drm);
+   if (ret) {
enable_irq(fsl_dev->irq);
-   return PTR_ERR(fsl_dev->state);
+   return ret;
}
  
  	clk_disable_unprepare(fsl_dev->clk);

@@ -233,13 +225,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
enable_irq(fsl_dev->irq);
-   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
  
-	console_lock();

-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
-
-   drm_kms_helper_poll_enable(fsl_dev->drm);
+   drm_mode_config_helper_resume(fsl_dev->drm);
  
  	return 0;

  }
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index da9bfd432ca6..93bfb98012d4 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
struct drm_encoder encoder;
struct fsl_dcu_drm_connector connector;
const struct fsl_dcu_soc_data *soc;
-   struct drm_atomic_state *state;
  };
  
  int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);


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

[PATCH] drm/ttm: swap consecutive allocated pooled pages v4

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page
v4: don't touch the loop variable

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b6f7ce286fb1..44343a2bf55c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -958,8 +958,15 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
-   pages[count++] = p;
+   first = count;
+   list_for_each_entry(p, , lru) {
+   struct page *tmp = p;
+
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == tmp - 1)
+   swap(tmp, pages[count - 1]);
+   pages[count++] = tmp;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
-- 
2.11.0

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

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 05-12-2017 11:53, Alexey Brodkin wrote:
>
> From my note above about udl_drm_gem_mmap() being only used in case of Xserver
> I barely may conclude anything. Given my lack of knowledge of DRM guts
> especially
> when it comes to complicated cases with DMA buffer exports/imports I cannot 
> say
> immediately if that's just improper implementation of
> udl_drm_gem_mmap() or not.
> Even though I do see some differences between implementation of 
> file_operations->mmap()
> callback in UDL and
> say exynos_drm_gem_mmap() or qxl_mmap() it's not clear
> why this and that implementation was done.

Oh, I've seen this before. This is the same thing that arcpgu
used to do in the mmap callback! Please comment out the call to
update_vm_cache_attr() in the mmap callback and check if it works.
___
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 Mon, Dec 4, 2017 at 9:34 PM, Harry Wentland  wrote:
> On 2017-12-04 08:08 AM, Arnd Bergmann wrote:
>> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
>> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
>> that do a comparison of floating-point variables:
>>
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>> `dcn_bw_calc_rq_dlg_ttu':
>> dcn_calcs.c:(.text+0x263): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>> `hack_force_pipe_split':
>> dcn_calcs.c:(.text+0x155b): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>> `dcn_find_dcfclk_suits_all':
>> dcn_calcs.c:(.text+0x190e): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
>> `dcn_validate_bandwidth':
>> dcn_calcs.c:(.text+0xe121): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>> `dcn_bw_mod':
>> dcn_calc_math.c:(.text+0x22): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>> `dcn_bw_min2':
>> dcn_calc_math.c:(.text+0xb2): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>> `dcn_bw_ceil2':
>> dcn_calc_math.c:(.text+0x2a0): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>> `dcn_bw_max3':
>> dcn_calc_math.c:(.text+0x325): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>> `dcn_bw_max5':
>> dcn_calc_math.c:(.text+0x3c3): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
>> `dcn_bw_log':
>> dcn_calc_math.c:(.text+0x54e): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> dcn_calc_math.c:(.text+0x57c): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `scaler_settings_calculation':
>> dcn_calc_auto.c:(.text+0x5c5): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `mode_support_and_system_configuration':
>> dcn_calc_auto.c:(.text+0x137c): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `mode_support_and_system_configuration':
>> dcn_calc_auto.c:(.text+0x9233): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `mode_support_and_system_configuration':
>> dcn_calc_auto.c:(.text+0xb70f): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `mode_support_and_system_configuration':
>> dcn_calc_auto.c:(.text+0x121fd): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `display_pipe_configuration':
>> dcn_calc_auto.c:(.text+0x15a2f): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>> dcn_calc_auto.c:(.text+0x17c2d): undefined reference to 
>> `__sanitizer_cov_trace_cmpf'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>> dcn_calc_auto.c:(.text+0x19362): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>> dcn_calc_auto.c:(.text+0x25575): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
>> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
>> dcn_calc_auto.c:(.text+0x27f33): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
>> `get_refcyc_per_delivery':
>> display_rq_dlg_calc.c:(.text+0xb5): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
>> `calculate_ttu_cursor.isra.1':
>> display_rq_dlg_calc.c:(.text+0x9f6): undefined reference to 
>> `__sanitizer_cov_trace_cmpd'
>> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
>> `dml_rq_dlg_get_dlg_params':
>> 

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #15 from Michel Dänzer  ---
Created attachment 135969
  --> https://bugs.freedesktop.org/attachment.cgi?id=135969=edit
Debugging output related to enabling/disabling the vblank interrupt

Another iteration, to find out why the vblank interrupt doesn't get enabled.

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

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Daniel Vetter]

On Tue, Dec 05, 2017 at 11:28:40AM +0100, Pavel Machek wrote:
> On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> > This patch adds a new optional connector property to allow userspace to 
> > enable
> > protection over the content it is displaying. This will typically be 
> > implemented
> > by the driver using HDCP.
> > 
> > The property is a tri-state with the following values:
> > - OFF: Self explanatory, no content protection
> > - DESIRED: Userspace requests that the driver enable protection
> > - ENABLED: Once the driver has authenticated the link, it sets this value
> > 
> > The driver is responsible for downgrading ENABLED to DESIRED if the link 
> > becomes
> > unprotected. The driver should also maintain the desiredness of protection
> > across hotplug/dpms/suspend.
> 
> Why would user of the machine want this to be something else than
> 'OFF'?
> 
> If kernel implements this, will it mean hardware vendors will have to
> prevent user from updating kernel on machines they own?
> 
> If this is merged, does it open kernel developers to DMCA threats if
> they try to change it?

Because this just implements one part of the content protection scheme.
This only gives you an option to enable HDCP (aka encryption, it's really
nothing else) on the cable. Just because it has Content Protection in the
name does _not_ mean it is (stand-alone) an effective nor complete content
protection scheme. It's simply encrypting data, that's all.

If you want to actually lock down a machine to implement content
protection, then you need secure boot without unlockable boot-loader and a
pile more bits in userspace.  If you do all that, only then do you have
full content protection. And yes, then you don't really own the machine
fully, and I think users who are concerned with being able to update their
kernels and be able to exercise their software freedoms already know to
avoid such locked down systems.

So yeah it would be better to call this the "HDMI/DP cable encryption
support", but well, it's not what it's called really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

Hi Alexey,

On 04-12-2017 17:29, Alexey Brodkin wrote:
>
> Indeed, in case of kmscube etnaviv is a renderer while UDL
> outputs the picture on the screen.

Thats nice :)

Ok, from your logs I was not able to see anything wrong. X server
does not error exit and Prime seems to be working in DRM ...

Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f)
and try to correlate the log with the actions. i.e.

[boot]
[log]
[x start]
[log]
[xclock start]
[log]
[glmark2-es2 start]
[log]

If that does not give any more info then maybe someone with
better understanding of etnaviv, UDL and X can help (maybe cc X
devel list also ...)

Best Regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/27] Improve DE2 support

[Maxime Ripard]

Hi,

On Fri, Dec 01, 2017 at 07:05:23AM +0100, Jernej Skrabec wrote:
> Current DE2 driver is very basic and uses a lot of magic constants since
> there is no documentation and knowledge about it was limited at the time.
> 
> With studying BSP source code, deeper knowledge was gained which allows
> to improve mainline driver considerably.
> 
> At the beginning of this series, some code refactoring is done as well
> as adding some checks (patches 1-15).
> 
> Further patches add multi-plane support with HW scaling and all possible
> RGB formats (patches 16-21).
> 
> At last, support for YUV formats is added (patches 22-26).
> 
> At the end, I included patch which puts lowest plane before second lowest.
> This should help testing VI planes when mixer has configuration 1 VI plane
> and 1 or more UI planes (most SoCs except V3s).
> 
> This code was developed on H3, but it should work on every SoC if correct
> configuration structure is provided.
> 
> H3 code can be found here:
> https://github.com/jernejsk/linux-1/commits/de2_impr_for_next

Thanks a lot for that huge rework.

I've applied the patches 1 to 26, and will push them to drm-misc once
the compilations are done.

In the future, if you happen to do such a huge rework again (which
hopefully won't be needed :)), please use the -M option of
format-patch. It will reduce a lot the verbosity of files renaming and
will help the review.

Thanks!
Maxime

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


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

[RFC 0/2] dt-bindings: mipi-dsi: dual-channel DSI bindings

[Archit Taneja]

DSI host controllers these days can be ganged together to drive larger
displays. Every SoC vendor supporting this is trying to add their own
DT property so that the corresponding drivers can identify that they
need to operate in the dual DSI mode. If we use the graph bindings, we
don't really need an additional DT property in the DSI host controller
to tell it that it's operating in dual-channel mode. It's something that
can be inferred 

I don't know much about how dual-channel is implemented on anything apart
from MSM chipsets, but one thing that seems universal is that the clock
driving both the DSI controllers (and corresponding PHYs) should have the
same clock source. The DSI instance that drives this clock is generally
called the "master", and the other instance the "slave". A "clock-master"
DT property has been proposed for the same.

There are some open item(s) that aren't described in the mipi DSI/DCS
spec, but we might need to have either as bindings or some sort of DSI
flags:

- When sending commands over DSI to peripherals with 2 DSI channels,
  some peripherals seem to have a requirement that both the DSIs trigger
  the same command at the same time. Otherwise, the controller on the
  peripheral goes a bit nuts. Is this common to all peripherals? Or are
  there devices where we just need to send the DCS/generic commands to
  the "master" DSI channel?

- When trying to read something back from the panel (a DCS read command
  followed by a BTA etc.), should both the DSI controllers be listening
  for data, or only the master?

- Anything else?

The first patch adds some explanation on how to deal with peripherals
that do DSI, but have a different control bus. This is something we've
already started using, but didn't have properly documented anywhere.

The second patch proposes bindings for DSI hosts/peripherals that
implement dual-channel DSI. 

Archit Taneja (2):
  dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control
bus
  dt-bindings: mipi-dsi: Add dual-channel DSI related info

 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 152 -
 1 file changed, 145 insertions(+), 7 deletions(-)

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

[RFC 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus

[Archit Taneja]

Add a section that describes dt-bindings for peripherals that support
MIPI DSI, but have a different bus as the primary control bus. Add an
example for such peripherals.

Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/display/mipi-dsi-bus.txt   | 75 --
 1 file changed, 68 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 973c27273772..77a7cec15f5b 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
connected to a DSI
 host. Experience shows that this is true for the large majority of setups.
 
 DSI host
-
+
 
 In addition to the standard properties and those defined by the parent bus of
 a DSI host, the following properties apply to a node representing a DSI host.
@@ -30,11 +30,15 @@ Required properties:
   different value here. See below.
 
 DSI peripheral
---
+==
 
-Peripherals are represented as child nodes of the DSI host's node. Properties
-described here apply to all DSI peripherals, but individual bindings may want
-to define additional, device-specific properties.
+Peripherals with DSI as control bus
+
+
+Peripherals with the DSI bus as the primary control path are represented as
+child nodes of the DSI host's node. Properties described here apply to all DSI
+peripherals, but individual bindings may want to define additional,
+device-specific properties.
 
 Required properties:
 - reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +53,25 @@ case two alternative representations can be chosen:
   property is the number of the first virtual channel and the second cell is
   the number of consecutive virtual channels.
 
-Example

+Peripherals with a different control bus
+
+
+There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
+primary control bus, but are also connected to a DSI bus (mostly for the data
+path). Connections between such peripherals and a DSI host can be represented
+using the graph bindings [1], [2].
+
+[1] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
 
+Examples
+
+- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
+  with different virtual channel configurations.
+- (4) is an example of a peripheral on a I2C control bus connected with to
+  a DSI host using of-graph bindings.
+
+1)
dsi-host {
...
 
@@ -67,6 +87,7 @@ Example
...
};
 
+2)
dsi-host {
...
 
@@ -82,6 +103,7 @@ Example
...
};
 
+3)
dsi-host {
...
 
@@ -96,3 +118,42 @@ Example
 
...
};
+
+4)
+   i2c-host {
+   ...
+
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ...
+
+   port@0 {
+   bridge_mipi_in: endpoint {
+   remote-endpoint = 
<_mipi_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi-host {
+   ...
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   ...
+
+   port@0 {
+   host_mipi_out: endpoint {
+   remote-endpoint = <_mipi_in>;
+   };
+   };
+   };
+   };
-- 
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