Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)

[zhoucm1]

On 2017年05月12日 12:17, Dave Airlie wrote:

On 12 May 2017 at 13:34, zhoucm1  wrote:

1. generally, functions in amdgpu_cs.c should be with amdgpu_cs_ as prefix.

Okay I've fixed this and previous patch up locally.


2. If I'm not wrong to your proposal, SYNCOBJ_IN is to semaphore wait while
SYNCOBJ_OUT is to semaphore signal. SYNCOBJ_IN/OUT both are based on command
submission ioctl, that means user space must generate CS when using
semaphore?  but with my understand, they should not be dependent with that,
they can be used independently, right?

Yes in is WAIT and out is signal, however OUT could also be used to
write a syncobj as a fence if needed, hence why I moved away from
semaphore naming.

The only place I can see them being used independently is a possible
signal operation after present, due not being able to pass the
semaphores over dri3 yet. I think I've said this before and Christian
has confirmed that doing anything with semaphores not via the command
submission ioctl is going to be messy as they have to queue jobs in
the scheduler, so if we need to tune the command submission ioctl to
take empty CS or add a flag to just do semaphore operations we should
do so in the future when we have a clear use case for it (and we see
the need to optimise for it).

I see.
+David Mao and Jacob to aware, they are expert of Vulkan, if they have 
no concern, It's ok.


Regards,
David Zhou


Dave.


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

Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)

[Dave Airlie]

On 12 May 2017 at 13:34, zhoucm1  wrote:
> 1. generally, functions in amdgpu_cs.c should be with amdgpu_cs_ as prefix.

Okay I've fixed this and previous patch up locally.

> 2. If I'm not wrong to your proposal, SYNCOBJ_IN is to semaphore wait while
> SYNCOBJ_OUT is to semaphore signal. SYNCOBJ_IN/OUT both are based on command
> submission ioctl, that means user space must generate CS when using
> semaphore?  but with my understand, they should not be dependent with that,
> they can be used independently, right?

Yes in is WAIT and out is signal, however OUT could also be used to
write a syncobj as a fence if needed, hence why I moved away from
semaphore naming.

The only place I can see them being used independently is a possible
signal operation after present, due not being able to pass the
semaphores over dri3 yet. I think I've said this before and Christian
has confirmed that doing anything with semaphores not via the command
submission ioctl is going to be messy as they have to queue jobs in
the scheduler, so if we need to tune the command submission ioctl to
take empty CS or add a flag to just do semaphore operations we should
do so in the future when we have a clear use case for it (and we see
the need to optimise for it).

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

Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)

[zhoucm1]

1. generally, functions in amdgpu_cs.c should be with amdgpu_cs_ as prefix.
2. If I'm not wrong to your proposal, SYNCOBJ_IN is to semaphore wait 
while SYNCOBJ_OUT is to semaphore signal. SYNCOBJ_IN/OUT both are based 
on command submission ioctl, that means user space must generate CS when 
using semaphore? but with my understand, they should not be dependent 
with that, they can be used independently, right?


Anything I missed, if yes, pls correct me.

+   case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:

Regards,
David Zhou
On 2017年05月12日 08:34, Dave Airlie wrote:

From: Dave Airlie 

This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.

Sync objects are managed via the drm syncobj ioctls.

The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.

This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.

In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.

NOTE: this interface addition needs a version bump to expose
it to userspace.

v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.

Signed-off-by: Dave Airlie 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 81 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
  include/uapi/drm/amdgpu_drm.h   |  6 +++
  3 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index df25b32..e86c832 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "amdgpu_trace.h"
  
@@ -217,6 +218,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void *data)

break;
  
  		case AMDGPU_CHUNK_ID_DEPENDENCIES:

+   case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
  
  		default:

@@ -1008,6 +1011,40 @@ static int amdgpu_process_fence_dep(struct 
amdgpu_cs_parser *p,
return 0;
  }
  
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,

+uint32_t handle)
+{
+   int r;
+   struct dma_fence *fence;
+   r = drm_syncobj_fence_get(p->filp, handle, );
+   if (r)
+   return r;
+
+   r = amdgpu_sync_fence(p->adev, >job->sync, fence);
+   dma_fence_put(fence);
+
+   return r;
+}
+
+static int amdgpu_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
  static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
  struct amdgpu_cs_parser *p)
  {
@@ -1022,12 +1059,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device 
*adev,
r = amdgpu_process_fence_dep(p, chunk);
if (r)
return r;
+   } else if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_IN) {
+   r = amdgpu_process_syncobj_in_dep(p, chunk);
+   if (r)
+   return r;
}
}
  
  	return 0;

  }
  
+static int amdgpu_process_syncobj_out_dep(struct amdgpu_cs_parser *p,

+ struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = drm_syncobj_replace_fence(p->filp, deps[i].handle,
+ p->fence);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
+static int 

[radeon-alex:raven-acp 137/337] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/pp_overdriver.h:48:6: sparse: no newline at end of file

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git raven-acp
head:   465122e3ee134fb29075d92712676aa92c2b20c2
commit: 0a1b27b47671d195a903037880496ec893a82add [137/337] drm/amd/powerplay: 
add avfs fuse overdriver func.
reproduce:
# apt-get install sparse
git checkout 0a1b27b47671d195a903037880496ec893a82add
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/pp_overdriver.h:48:6: sparse: 
>> no newline at end of file
   include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_address': 
unknown attribute

vim +48 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/pp_overdriver.h

32  uint32_t VFT2_m1;
33  uint32_t VFT2_m2;
34  uint32_t VFT2_b;
35  uint32_t VFT1_m1;
36  uint32_t VFT1_m2;
37  uint32_t VFT1_b;
38  uint32_t VFT0_m1;
39  uint32_t VFT0_m2;
40  uint32_t VFT0_b;
41  };
42  
43  extern struct phm_fuses_default vega10_fuses_default[];
44  extern int pp_override_get_default_fuse_value(uint64_t key,
45  struct phm_fuses_default list[],
46  struct phm_fuses_default *result);
47  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-4.11 500/1085] drivers/gpu/drm/amd/amdgpu/../display/dc/basics/logger.c:74:2-34: duplicated argument to & or | (fwd)

[Julia Lawall]

Hello,

It seems that (1 << LOG_DETECTION_EDID_PARSER) appears more than once in
the bit or (only one instance shown, on line 74).

julia

-- Forwarded message --
Date: Fri, 12 May 2017 09:54:09 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: [radeon-alex:amd-staging-4.11 500/1085]
drivers/gpu/drm/amd/amdgpu/../display/dc/basics/logger.c:74:2-34: duplicated
 argument to & or |

CC: kbuild-...@01.org
CC: dri-devel@lists.freedesktop.org
TO: Harry Wentland 
CC: Alex Deucher 

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head:   c285c73f2213f503a93aa142fff186e160b4a371
commit: 105f1512a3e60d5060a87d235c5d5fe127bf5e0a [500/1085] drm/amd/dc: Add dc 
display driver (v2)
:: branch date: 7 hours ago
:: commit date: 10 days ago

>> drivers/gpu/drm/amd/amdgpu/../display/dc/basics/logger.c:74:2-34: duplicated 
>> argument to & or |

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout 105f1512a3e60d5060a87d235c5d5fe127bf5e0a
vim +74 drivers/gpu/drm/amd/amdgpu/../display/dc/basics/logger.c

105f1512 Harry Wentland 2017-04-18  58  
{LOG_EVENT_LINK_TRAINING,   "LKTN"},
105f1512 Harry Wentland 2017-04-18  59  {LOG_EVENT_LINK_LOSS,   
"LinkLoss"},
105f1512 Harry Wentland 2017-04-18  60  {LOG_EVENT_UNDERFLOW,   
"Underflow"},
105f1512 Harry Wentland 2017-04-18  61  {LOG_IF_TRACE,  
"InterfaceTrace"}
105f1512 Harry Wentland 2017-04-18  62  };
105f1512 Harry Wentland 2017-04-18  63
105f1512 Harry Wentland 2017-04-18  64
105f1512 Harry Wentland 2017-04-18  65  #define DC_DEFAULT_LOG_MASK ((1 << 
LOG_ERROR) | \
105f1512 Harry Wentland 2017-04-18  66  (1 << LOG_WARNING) | \
105f1512 Harry Wentland 2017-04-18  67  (1 << 
LOG_EVENT_MODE_SET) | \
105f1512 Harry Wentland 2017-04-18  68  (1 << 
LOG_EVENT_DETECTION) | \
105f1512 Harry Wentland 2017-04-18  69  (1 << 
LOG_EVENT_LINK_TRAINING) | \
105f1512 Harry Wentland 2017-04-18  70  (1 << 
LOG_EVENT_LINK_LOSS) | \
105f1512 Harry Wentland 2017-04-18  71  (1 << 
LOG_EVENT_UNDERFLOW) | \
105f1512 Harry Wentland 2017-04-18  72  (1 << LOG_RESOURCE) | \
105f1512 Harry Wentland 2017-04-18  73  (1 << 
LOG_FEATURE_OVERRIDE) | \
105f1512 Harry Wentland 2017-04-18 @74  (1 << 
LOG_DETECTION_EDID_PARSER) | \
105f1512 Harry Wentland 2017-04-18  75  (1 << LOG_DC) | \
105f1512 Harry Wentland 2017-04-18  76  (1 << LOG_HW_HOTPLUG) | 
\
105f1512 Harry Wentland 2017-04-18  77  (1 << LOG_HW_SET_MODE) 
| \
105f1512 Harry Wentland 2017-04-18  78  (1 << LOG_HW_RESUME_S3) 
| \
105f1512 Harry Wentland 2017-04-18  79  (1 << LOG_HW_HPD_IRQ) | 
\
105f1512 Harry Wentland 2017-04-18  80  (1 << LOG_SYNC) | \
105f1512 Harry Wentland 2017-04-18  81  (1 << 
LOG_BANDWIDTH_VALIDATION) | \
105f1512 Harry Wentland 2017-04-18  82  (1 << LOG_MST) | \

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101003] segfault with ideas test of glmark2

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
Please attach a backtrace of the crash.

-- 
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 v7 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

There are some panel that
(1) does not support display backlight enable via AUX
(2) support display backlight adjustment via AUX
(3) support display backlight enable via eDP BL_ENABLE pin

The current driver required that (1) must be support to enable (2).
This patch drops that requirement.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 870c03fc0f3a..c22712762957 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
 {
uint8_t reg_val = 0;
 
+   /* Early return when display use other mechanism to enable backlight. */
+   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+   return;
+
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
  _val) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 * the panel can support backlight control over the aux channel
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

[Tony Lindgren]

* Tomi Valkeinen  [170511 01:37]:
> On 10/05/17 21:29, Tony Lindgren wrote:
> > * Tomi Valkeinen  [170510 10:44]:
> >>
> >>
> >> On 10/05/17 19:46, Tony Lindgren wrote:
> >>> * Tomi Valkeinen  [170510 00:26]:
>  On 09/05/17 18:05, Sebastian Reichel wrote:
> 
> > patch 10:
> > I think dsi pin muxing should be done by providing pinmux
> > info via DT.
> 
>  Unfortunately there's no pinmux driver for the kind of register we have
>  for DSI. At least this was the case not that long ago.
> >>>
> >>> What are the TRM names for the registers you need to mux?
> >>
> >> CONTROL_DSIPHY
> > 
> > Oh just one register with few bits? That should be doable in
> > dts with pinctrl-single,bit-per-mux and pinctrl-single,bits.
> 
> No, I don't think it works. Or at least I can't figure out how.
> 
> pinctrl-single doesn't allow to freely set the bits, but requires the
> pins to have similar bit structure (function-mask). In CONTROL_DSIPHY,
> DSI1 and DSI2 have different bit structures.

OK if the register mixes different types of controllers that
can't be partitioned into separate 8 or 16 bit instances then
you're out of luck with pinctrl-single. If it does not fit, no
point trying to force it, then you need a custom pinctrl driver.

> I don't understand why pinctrl-single tries so hard to fit things into
> one mold...

Basically on many SoCs pinctrl is just the same exact control
register repeated for each pin on the SoC:

$ git grep '"pinctrl-single"' arch/arm*/boot/dts | sort | uniq | wc -l
20

Regards,

Tony


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

Re: [drm:qxl] BUG: sleeping function called from invalid context - qxl_bo_kmap_atomic_page()...splat

[Mike Galbraith]

On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
> 
> > Thanks for reporting this.  Can you confirm the following patch prevents
> > the issue?
> 
> Nope, it still gripes.

The reason for this gripe is that we find that we don't have memory
reserved.. a tad too late.

Xorg-2252  [000]    135.409756: qxl_release_map 
<-qxl_cursor_atomic_update
Xorg-2252  [000]    135.409756: qxl_bo_kmap_atomic_page 
<-qxl_release_map
Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: ENTER
Xorg-2252  [000]    135.409757: ttm_mem_io_lock 
<-qxl_bo_kmap_atomic_page
Xorg-2252  [000]    135.409757: ttm_mem_io_reserve 
<-qxl_bo_kmap_atomic_page
Xorg-2252  [000]    135.409757: qxl_ttm_io_mem_reserve 
<-ttm_mem_io_reserve
Xorg-2252  [000]    135.409757: ttm_mem_io_unlock 
<-qxl_bo_kmap_atomic_page
Xorg-2252  [000]    135.409757: qxl_bo_kmap_atomic_page: 
PREEMPTION DISABLED
Xorg-2252  [000] ...1   135.409758: qxl_bo_kmap 
<-qxl_cursor_atomic_update
Xorg-2252  [000] ...1   135.409758: ttm_bo_kmap <-qxl_bo_kmap  <== 
too late
Xorg-2252  [000] ...1   135.409758: ttm_mem_io_reserve <-ttm_bo_kmap
Xorg-2252  [000] ...1   135.409758: qxl_ttm_io_mem_reserve 
<-ttm_mem_io_reserve
Xorg-2252  [000] ...1   135.409759: ioremap_nocache <-ttm_bo_kmap 
<== game over
Xorg-2252  [000] ...1   135.409759: __ioremap_caller 
<-ioremap_nocache
Xorg-2252  [000] ...1   135.409759: walk_system_ram_range 
<-__ioremap_caller
Xorg-2252  [000] ...1   135.409759: find_next_iomem_res 
<-walk_system_ram_range
Xorg-2252  [000] ...1   135.409759: _raw_read_lock 
<-find_next_iomem_res
Xorg-2252  [000] ...1   135.409760: reserve_memtype 
<-__ioremap_caller
Xorg-2252  [000] ...1   135.409760: pat_pagerange_is_ram 
<-reserve_memtype
Xorg-2252  [000] ...1   135.409761: walk_system_ram_range 
<-pat_pagerange_is_ram
Xorg-2252  [000] ...1   135.409761: find_next_iomem_res 
<-walk_system_ram_range
Xorg-2252  [000] ...1   135.409761: _raw_read_lock 
<-find_next_iomem_res
Xorg-2252  [000] ...1   135.409761: kmem_cache_alloc_trace 
<-reserve_memtype
Xorg-2252  [000] ...1   135.409761: __might_sleep 
<-kmem_cache_alloc_trace
Xorg-2252  [000] ...1   135.409762: ___might_sleep <-__might_sleep
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v6 6/9] drm/i915: Support dynamic backlight via DPCD register

[Pandiyan, Dhinakaran]

On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> This patch enables dynamic backlight by default for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.

I realized I replied to the previous version of this patch.

Should there be a switch for a feature like this that can affect image
quality?

-DK

> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 39 
> ++-
>  1 file changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 5ef3ade7c40e..7d323af96636 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
> *connector, u32 level)
>   }
>  }
>  
> +/*
> + * Set minimum / maximum dynamic brightness percentage. This value is 
> expressed
> + * as the percentage of normal brightness in 5% increments.
> + */
> +static void
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> +   dbc, sizeof(dbc) < 0)) {
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + }
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t new_dpcd_buf = 0;
>   uint8_t edp_backlight_mode = 0;
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
> @@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   return;
>   }
>  
> + new_dpcd_buf = dpcd_buf;
>   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>  
>   switch (edp_backlight_mode) {
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> - if (drm_dp_dpcd_writeb(_dp->aux,
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
> - DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> - }
> + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>   break;
>  
>   /* Do nothing when it is already DPCD mode */
> @@ -130,6 +144,19 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   break;
>   }
>  
> + if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
> + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> + intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
> + DRM_DEBUG_KMS("Enable dynamic brightness.\n");
> + }
> +
> + if (new_dpcd_buf != dpcd_buf) {
> + if (drm_dp_dpcd_writeb(_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> + }
> + }
> +
>   set_aux_backlight_enable(intel_dp, true);
>  }
>  

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

[PATCH v3 2/6] drm: Add drm_{crtc/encoder/connector}_mode_valid()

[Jose Abreu]

Add a new helper to call crtc->mode_valid, connector->mode_valid
and encoder->mode_valid callbacks.

Suggested-by: Ville Syrjälä 
Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v2->v3:
- Move helpers to drm_probe_helper.c (Daniel)
- Squeeze patches that introduce the helpers into a single
one (Daniel)

 drivers/gpu/drm/drm_crtc_helper_internal.h | 13 ++
 drivers/gpu/drm/drm_probe_helper.c | 38 ++
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h 
b/drivers/gpu/drm/drm_crtc_helper_internal.h
index 28295e5..97dfe20 100644
--- a/drivers/gpu/drm/drm_crtc_helper_internal.h
+++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
@@ -26,7 +26,11 @@
  * implementation details and are not exported to drivers.
  */
 
+#include 
+#include 
 #include 
+#include 
+#include 
 
 /* drm_fb_helper.c */
 #ifdef CONFIG_DRM_FBDEV_EMULATION
@@ -62,4 +66,13 @@ static inline int drm_dp_aux_register_devnode(struct 
drm_dp_aux *aux)
 static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
 {
 }
+
+/* drm_probe_helper.c */
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode);
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode 
*mode);
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode);
+
 #endif
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 1b0c14a..f01abdc 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -38,6 +38,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "drm_crtc_helper_internal.h"
 
 /**
  * DOC: output probing helper overview
@@ -113,6 +116,41 @@ static int drm_helper_probe_add_cmdline_mode(struct 
drm_connector *connector)
return 1;
 }
 
+enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+
+   if (!crtc_funcs || !crtc_funcs->mode_valid)
+   return MODE_OK;
+
+   return crtc_funcs->mode_valid(crtc, mode);
+}
+
+enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   const struct drm_encoder_helper_funcs *encoder_funcs =
+   encoder->helper_private;
+
+   if (!encoder_funcs || !encoder_funcs->mode_valid)
+   return MODE_OK;
+
+   return encoder_funcs->mode_valid(encoder, mode);
+}
+
+enum drm_mode_status drm_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   const struct drm_connector_helper_funcs *connector_funcs =
+   connector->helper_private;
+
+   if (!connector_funcs || !connector_funcs->mode_valid)
+   return MODE_OK;
+
+   return connector_funcs->mode_valid(connector, mode);
+}
+
 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
 /**
  * drm_kms_helper_poll_enable - re-enable output polling.
-- 
1.9.1


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

[PATCH] drm/hisilicon: Ensure LDI regs are properly configured.

[Peter Griffin]

This patch fixes the following soft lockup:
  BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]

On weston idle-timeout the IP is powered down and reset
asserted. On weston resume we get a massive vblank
IRQ storm due to the LDI registers having lost some state.

This state loss is caused by ade_crtc_atomic_begin() not
calling ade_ldi_set_mode(). With this patch applied
resuming from Weston idle-timeout works well.

Signed-off-by: Peter Griffin 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 9a0678a..c09600c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -521,9 +521,12 @@ static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
 {
struct ade_crtc *acrtc = to_ade_crtc(crtc);
struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct drm_display_mode *mode = >state->mode;
+   struct drm_display_mode *adj_mode = >state->adjusted_mode;
 
if (!ctx->power_on)
(void)ade_power_up(ctx);
+   ade_ldi_set_mode(acrtc, mode, adj_mode);
 }
 
 static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
-- 
2.7.4

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

[PATCH v7 6/9] drm/i915: Add option to support dynamic backlight via DPCD

[Puthikorn Voravootivat]

This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  5 
 drivers/gpu/drm/i915/i915_params.h|  3 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 40 +++
 3 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 13cf3f1572ab..6eaf660e74da 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
+   .enable_dbc = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -255,3 +256,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host 
support(default:false)");
+
+module_param_named(enable_dbc, i915.enable_dbc, bool, 0600);
+MODULE_PARM_DESC(enable_dbc,
+   "Enable support for dynamic backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index ac02efce6e22..2de3e2850b54 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,7 +67,8 @@
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
func(int, enable_dpcd_backlight); \
-   func(bool, enable_gvt)
+   func(bool, enable_gvt); \
+   func(bool, enable_dbc)
 
 #define MEMBER(T, member) T member
 struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index a72893da78d0..1c5459bc20ae 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
*connector, u32 level)
}
 }
 
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+  u32 min, u32 max)
+{
+   u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc) < 0)) {
+   DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
if (drm_dp_dpcd_readb(_dp->aux,
@@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
return;
}
 
+   new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
 
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
-   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
-   if (drm_dp_dpcd_writeb(_dp->aux,
-   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
-   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
-   }
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
 
/* Do nothing when it is already DPCD mode */
@@ -130,6 +144,20 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
break;
}
 
+   if (i915.enable_dbc &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
+   new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+   DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+   }
+
+   if (new_dpcd_buf != dpcd_buf) {
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   }
+
set_aux_backlight_enable(intel_dp, true);
 }
 
-- 
2.13.0.rc2.291.g57267f2277-goog

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

On Wed, May 10, 2017 at 5:39 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> > There are some panel that
> > (1) does not support display backlight enable via AUX
> > (2) support display backlight adjustment via AUX
> > (3) support display backlight enable via eDP BL_ENABLE pin
> >
> > The current driver required that (1) must be support to enable (2).
> > This patch drops that requirement.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 870c03fc0f3a..c22712762957 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
> >  {
> >   uint8_t reg_val = 0;
> >
> > +   /* Early return when display use other mechanism to enable
> backlight. */
> > + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> > + return;
>
> Won't DP_EDP_BACKLIGHT_AUX_ENABLE_CAP be 1 always? The code below, in
> intel_dp_aux_display_control_capable(), makes sure
> DP_EDP_BACKLIGHT_PIN_ENABLE_CAP=0. The spec says at least one of these
> has to be 1.
>
> We will drop the  DP_EDP_BACKLIGHT_PIN_ENABLE_CAP != 0 check in next
patch set.
This patch adds check here to prepare for that.

>
> "BACKLIGHT_AUX_ENABLE_CAPABLE
> 1 = Indicates that the Sink device supports display backlight
> enable through the BACKLIGHT_ENABLE bit in the
> EDP_DISPLAY_CONTROL register (DPCD Address 00720h, bit 0).
> Must be set to 1 if the BACKLIGHT_PIN_ENABLE_CAPABLE bit (bit 1)
> is cleared to 0."
>
> -DK
>
> > +
> >   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_
> REGISTER,
> > _val) < 0) {
> >   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > @@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> >* the panel can support backlight control over the aux channel
> >*/
> >   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP
> &&
> > - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)
> &&
> >   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> > (intel_dp->edp_dpcd[2] & 
> > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP)))
> {
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[Puthikorn Voravootivat]

Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  8 +---
 drivers/gpu/drm/i915/i915_params.h|  2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 24 +++-
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_dpcd_backlight = false,
+   .enable_dpcd_backlight = -1,
.enable_gvt = false,
 };
 
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
0600);
 MODULE_PARM_DESC(enable_dpcd_backlight,
-   "Enable support for DPCD backlight control (default:false)");
+   "Enable support for DPCD backlight control "
+   "(-1:disable (default), 0:Use PWM pin if both supported, "
+   "1:Use DPCD if both supported");
 
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
-   func(bool, enable_dpcd_backlight); \
+   func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
 #define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index c22712762957..5ee1d90a3263 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -167,21 +167,35 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
/* Check the  eDP Display control capabilities registers to determine if
 * the panel can support backlight control over the aux channel
 */
-   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
-   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
- (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
+   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
 }
 
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+
+   /* Check the  eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+   return (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP);
+}
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
 
-   if (!i915.enable_dpcd_backlight)
+   if (i915.enable_dpcd_backlight == -1)
+   return -ENODEV;
+
+   if (i915.enable_dpcd_backlight == 0 &&
+   intel_dp_pwm_pin_display_control_capable(intel_connector))
return -ENODEV;
 
if (!intel_dp_aux_display_control_capable(intel_connector))
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [linux-sunxi] [PATCH v2 20/20] ARM: sun5i: a10s-olinuxino: Enable HDMI

[icenowy]

在 2017-05-11 03:23，Maxime Ripard 写道：

Hi,

On Thu, May 04, 2017 at 04:05:18PM +0800, Chen-Yu Tsai wrote:

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The A10s Olinuxino has an HDMI connector. Make sure we can use it.
>
> Acked-by: Chen-Yu Tsai 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 29 +-
>  1 file changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> index 894f874a5beb..1d13b6407222 100644
> --- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> @@ -63,6 +63,17 @@
> stdout-path = "serial0:115200n8";
> };
>
> +   connector {
> +   compatible = "hdmi-connector";
> +   type = "a";

Just curious, should we take this into consideration when creating
drm_connector?


I'm not sure, no other driver does so. And I haven't seen any of our
boards with a HDMI-B, C or mini-HDMI connector.


Tablets usually come with micro-HDMI connector.



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[PATCH v3 4/6] drm: Use new mode_valid() helpers in connector probe helper

[Jose Abreu]

This changes the connector probe helper function to use the new
encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
helper callbacks to validate the modes.

The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
through all the connector's encodersXbridgesXcrtcs and calls the
callback.

If at least a valid encoderXbridgeXcrtc combination is found which
accepts the mode then the function returns MODE_OK.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v2->v3:
- Call also bridge->mode_valid (Daniel)
Changes v1->v2:
- Use new helpers suggested by Ville
- Change documentation (Daniel)

 drivers/gpu/drm/drm_probe_helper.c | 65 --
 1 file changed, 62 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index f01abdc..84d660e 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -83,6 +83,61 @@
return MODE_OK;
 }
 
+static enum drm_mode_status
+drm_mode_validate_connector(struct drm_connector *connector,
+   struct drm_display_mode *mode)
+{
+   struct drm_device *dev = connector->dev;
+   uint32_t *ids = connector->encoder_ids;
+   enum drm_mode_status ret = MODE_OK;
+   unsigned int i;
+
+   /* Step 1: Validate against connector */
+   ret = drm_connector_mode_valid(connector, mode);
+   if (ret != MODE_OK)
+   return ret;
+
+   /* Step 2: Validate against encoders and crtcs */
+   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+   struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
+   struct drm_crtc *crtc;
+
+   if (!encoder)
+   continue;
+
+   ret = drm_encoder_mode_valid(encoder, mode);
+   if (ret != MODE_OK) {
+   /* No point in continuing for crtc check as this encoder
+* will not accept the mode anyway. If all encoders
+* reject the mode then, at exit, ret will not be
+* MODE_OK. */
+   continue;
+   }
+
+   ret = drm_bridge_mode_valid(encoder->bridge, mode);
+   if (ret != MODE_OK) {
+   /* There is also no point in continuing for crtc check
+* here. */
+   continue;
+   }
+
+   drm_for_each_crtc(crtc, dev) {
+   if (!drm_encoder_crtc_ok(encoder, crtc))
+   continue;
+
+   ret = drm_crtc_mode_valid(crtc, mode);
+   if (ret == MODE_OK) {
+   /* If we get to this point there is at least
+* one combination of encoder+crtc that works
+* for this mode. Lets return now. */
+   return ret;
+   }
+   }
+   }
+
+   return ret;
+}
+
 static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
 {
struct drm_cmdline_mode *cmdline_mode;
@@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
  *- drm_mode_validate_flag() checks the modes against basic connector
  *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
  *- the optional _connector_helper_funcs.mode_valid helper can perform
- *  driver and/or hardware specific checks
+ *  driver and/or sink specific checks
+ *- the optional _crtc_helper_funcs.mode_valid,
+ *  _bridge_funcs.mode_valid and _encoder_helper_funcs.mode_valid
+ *  helpers can perform driver and/or source specific checks which are also
+ *  enforced by the modeset/atomic helpers
  *
  * 5. Any mode whose status is not OK is pruned from the connector's modes 
list,
  *accompanied by a debug message indicating the reason for the mode's
@@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_flag(mode, mode_flags);
 
-   if (mode->status == MODE_OK && connector_funcs->mode_valid)
-   mode->status = connector_funcs->mode_valid(connector,
+   if (mode->status == MODE_OK)
+   mode->status = drm_mode_validate_connector(connector,
   

[PATCH v7 0/9] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

This patch set contain 9 patches.
- First five patches fix bug in the driver and allow choosing which
  way to adjust brightness if both PWM pin and AUX are supported
- Next patch adds enable DBC by default
- Next patch makes the driver restore last brightness level after
  turning display off and on.
- Last two patches set the PWM freqency to match data in panel vbt.

This patch set is reviewed by Dhinakaran in patch #1, 2, 5, 7, 8

Change log:
v7:
- Add check in intel_dp_pwm_pin_display_control_capable in patch #4
- Add option in patch #6 to enable DPCD or not
- Change definition in patch #8 and implementation in #9 to use Khz
- Fix compiler warning from build bot in patch #9

v6:
- Address review from Dhinakaran
- Make PWM frequency to have highest value of Pn that make the
  frequency still within 25% of desired frequency.

v5:
- Split first patch in v4 to 3 patches
- Bump priority for "Correctly enable backlight brightness adjustment via DPCD"
- Make logic clearer for the case that both PWM pin and AUX are supported
- Add more log when write to register fail
- Add log when enable DBC

v4:
- Rebase / minor typo fix.

v3:
- Add new implementation of PWM frequency patch

v2:
- Drop PWM frequency patch
- Address suggestion from Jani Nikula


Puthikorn Voravootivat (9):
  drm/i915: Fix cap check for intel_dp_aux_backlight driver
  drm/i915: Correctly enable backlight brightness adjustment via DPCD
  drm/i915: Drop AUX backlight enable check for backlight control
  drm/i915: Allow choosing how to adjust brightness if both supported
  drm/i915: Set backlight mode before enable backlight
  drm/i915: Add option to support dynamic backlight via DPCD
  drm/i915: Restore brightness level in aux backlight driver
  drm: Add definition for eDP backlight frequency
  drm/i915: Set PWM divider to match desired frequency in vbt

 drivers/gpu/drm/i915/i915_params.c|  13 +-
 drivers/gpu/drm/i915/i915_params.h|   5 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 --
 include/drm/drm_dp_helper.h   |   2 +
 4 files changed, 176 insertions(+), 17 deletions(-)

-- 
2.13.0.rc2.291.g57267f2277-goog

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

[PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency is still within 25%
of the desired frequency.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 0b48851013cc..6f10a2f1ab76 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
intel_dp *intel_dp,
}
 }
 
+/*
+ * Set PWM Frequency divider to match desired frequency in vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
+static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+   int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
+   u8 pn, pn_min, pn_max;
+
+   /* Find desired value of (F x P)
+* Note that, if F x P is out of supported range, the maximum value or
+* minimum value will applied automatically. So no need to check that.
+*/
+   freq = dev_priv->vbt.backlight.pwm_freq_hz;
+   DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
+   if (!freq) {
+   DRM_DEBUG_KMS("Use panel default backlight frequency\n");
+   return;
+   }
+
+   fxp = KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ) / freq;
+
+   /* Use highest possible value of Pn for more granularity of brightness
+* adjustment while satifying the conditions below.
+* - Pn is in the range of Pn_min and Pn_max
+* - F is in the range of 1 and 255
+* - Effective frequency is within 25% of desired frequency.
+*/
+   if (drm_dp_dpcd_readb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+   return;
+   }
+   if (drm_dp_dpcd_readb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
+   return;
+   }
+   pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+   pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+
+   fxp_min = fxp * 3 / 4;
+   fxp_max = fxp * 5 / 4;
+   if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
+   DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
+   return;
+   }
+
+   for (pn = pn_max; pn > pn_min; pn--) {
+   f = clamp(fxp >> pn, 1, 255);
+   fxp_actual = f << pn;
+   if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
+   break;
+   }
+
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+   return;
+   }
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
+   return;
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
+   bool freq_cap;
 
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
@@ -151,6 +225,10 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
DRM_DEBUG_KMS("Enable dynamic brightness.\n");
}
 
+   freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
+   if (freq_cap)
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
@@ -158,6 +236,9 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
}
 
+   if (freq_cap)
+   intel_dp_aux_set_pwm_freq(connector);
+

[PATCH v3 0/6] Introduce new mode validation callbacks

[Jose Abreu]

This series is a follow up from the discussion at [1]. We start by
introducing crtc->mode_valid(), encoder->mode_valid() and
bridge->mode_valid() callbacks which will be used in followup
patches and also by cleaning the documentation a little bit.

We proceed by introducing new helpers to call this new callbacks
at 2/6.

At 3/6 a helper function is introduced that calls all mode_valid()
from a set of bridges.

Next, at 4/6 we modify the connector probe helper so that only modes
which are supported by a given bridge+encoder+crtc combination are
probbed.

At 5/6 we call all the mode_valid() callbacks for a given pipeline,
except the connector->mode_valid one, so that the mode is validated.
This is done before calling mode_fixup().

Finally, at 6/6 we use the new crtc->mode_valid() callback in arcpgu
and remove the atomic_check() callback.

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

Jose Abreu (6):
  drm: Add crtc/encoder/bridge->mode_valid() callbacks
  drm: Add drm_{crtc/encoder/connector}_mode_valid()
  drm: Introduce drm_bridge_mode_valid()
  drm: Use new mode_valid() helpers in connector probe helper
  drm: Use mode_valid() in atomic modeset
  drm: arc: Use crtc->mode_valid() callback

Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 

 drivers/gpu/drm/arc/arcpgu_crtc.c  |  39 ++
 drivers/gpu/drm/drm_atomic_helper.c|  76 +++-
 drivers/gpu/drm/drm_bridge.c   |  33 +
 drivers/gpu/drm/drm_crtc_helper_internal.h |  13 
 drivers/gpu/drm/drm_probe_helper.c | 103 ++-
 include/drm/drm_bridge.h   |  22 ++
 include/drm/drm_modeset_helper_vtables.h   | 110 ++---
 7 files changed, 348 insertions(+), 48 deletions(-)

-- 
1.9.1


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

[PATCH v3 6/6] drm: arc: Use crtc->mode_valid() callback

[Jose Abreu]

Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.

This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly this clock
does not support all the needed ranges.

Also, remove the atomic_check() callback as mode_valid() callback
will be called before.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a959..01cae0a 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -32,6 +32,18 @@
{ "r8g8b8", 24, {16, 8}, {8, 8}, {0, 8}, {0, 0}, DRM_FORMAT_RGB888 },
 };
 
+static bool arc_pgu_is_mode_valid(struct arcpgu_drm_private *arcpgu,
+ const struct drm_display_mode *mode)
+{
+   long rate, clk_rate = mode->clock * 1000;
+
+   rate = clk_round_rate(arcpgu->clk, clk_rate);
+   if (rate != clk_rate)
+   return false;
+
+   return true;
+}
+
 static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -64,6 +76,17 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
+enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode 
*mode)
+{
+   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+
+   if (!arc_pgu_is_mode_valid(arcpgu, mode))
+   return MODE_NOCLOCK;
+
+   return MODE_OK;
+}
+
 static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -129,20 +152,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
-   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = >adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
-
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
-
-   return 0;
-}
-
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *state)
 {
@@ -158,6 +167,7 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
+   .mode_valid = arc_pgu_crtc_mode_valid,
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
@@ -165,7 +175,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
1.9.1


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

[PATCH v3 1/6] drm: Add crtc/encoder/bridge->mode_valid() callbacks

[Jose Abreu]

This adds a new callback to crtc, encoder and bridge helper functions
called mode_valid(). This callback shall be implemented if the
corresponding component has some sort of restriction in the modes
that can be displayed. A NULL callback implicates that the component
can display all the modes.

We also change the documentation so that the new and old callbacks
are correctly documented.

Only the callbacks were implemented to simplify review process,
following patches will make use of them.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v2->v3:
- Try to document the callbacks a little bit better and
review current documentation (Daniel)
Changes v1->v2:
- Change description of connector->mode_valid() (Daniel)

 include/drm/drm_bridge.h |  20 ++
 include/drm/drm_modeset_helper_vtables.h | 110 +++
 2 files changed, 103 insertions(+), 27 deletions(-)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index fdd82fc..00c6c36 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -59,6 +59,26 @@ struct drm_bridge_funcs {
void (*detach)(struct drm_bridge *bridge);
 
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* bridge. This should be implemented if the bridge has some sort of
+* restriction in the modes it can display. For example, a given bridge
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+   enum drm_mode_status (*mode_valid)(struct drm_bridge *crtc,
+  const struct drm_display_mode *mode);
+
+   /**
 * @mode_fixup:
 *
 * This callback is used to validate and adjust a mode. The paramater
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index c01c328..b07b7cd 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -106,14 +106,37 @@ struct drm_crtc_helper_funcs {
void (*commit)(struct drm_crtc *crtc);
 
/**
+* @mode_valid:
+*
+* This callback is used to check if a specific mode is valid in this
+* crtc. This should be implemented if the crtc has some sort of
+* restriction in the modes it can display. For example, a given crtc
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of modes to only the ones that
+* can be displayed.
+*
+* This is called at mode probe and at atomic check phase.
+*
+* RETURNS:
+*
+* drm_mode_status Enum
+*/
+   enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+  const struct drm_display_mode *mode);
+
+   /**
 * @mode_fixup:
 *
-* This callback is used to validate a mode. The parameter mode is the
-* display mode that userspace requested, adjusted_mode is the mode the
-* encoders need to be fed with. Note that this is the inverse semantics
-* of the meaning for the _encoder and _bridge_funcs.mode_fixup
-* vfunc. If the CRTC cannot support the requested conversion from mode
-* to adjusted_mode it should reject the modeset.
+* This callback is used to do the validation of an adjusted mode in the
+* crtc. The parameter mode is the display mode that userspace 
requested,
+* adjusted_mode is the mode the encoders need to be fed with. Note that
+* this is the inverse semantics of the meaning for the _encoder and
+* _bridge_funcs.mode_fixup vfunc. If the CRTC cannot support the
+* requested conversion from mode to adjusted_mode it should reject the
+* modeset. Also note that initial validation of a mode supplied by
+* userspace should be done in _crtc_helper_funcs.mode_valid and not
+* in this callback.
 *
 * This function is used by both legacy CRTC helpers and atomic helpers.
 * With atomic helpers it is optional.
@@ -135,17 +158,19 @@ struct drm_crtc_helper_funcs {
 

[PATCH v7 8/9] drm: Add definition for eDP backlight frequency

[Puthikorn Voravootivat]

This patch adds the following definition
- Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
  register which only use bit 0:4
- Base frequency (27 MHz) for backlight PWM frequency
  generator.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..eaa307f6ae8c 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -572,10 +572,12 @@
 #define DP_EDP_PWMGEN_BIT_COUNT 0x724
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
+# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (0x1f << 0)
 
 #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
 
 #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
+# define DP_EDP_BACKLIGHT_FREQ_BASE_KHZ 27000
 
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH v6 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

[Pandiyan, Dhinakaran]

On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> intel_dp_aux_backlight driver should check for the
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver.
> 
> Signed-off-by: Puthikorn Voravootivat 


Reviewed-by: Dhinakaran Pandiyan 


> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 6532e226db29..341bf2cb0c25 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -144,6 +144,7 @@ intel_dp_aux_display_control_capable(struct 
> intel_connector *connector)
>*/
>   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
>   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
>   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> (intel_dp->edp_dpcd[2] & 
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
>   DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");

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

Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

[m . t]

> Sinclair Yeh hat am 10. Mai 2017 um 18:46 geschrieben:
> 
> 
> Hi,

Hi,
 
> On Wed, May 10, 2017 at 12:31:39PM +0200, m.t wrote:
> > 
> > > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben:
> > > 
> > > Hi,
> > > 
> > > Thanks for reporting.
> > 
> > I would have reported earlier if it had not taken 3 days on the vm to 
> > bisect.
> > 
> > > I think there is a fix for this either in preparation or queued for
> > > submission. Sinclair (CC'd) should know more.
> > 
> > If you point me to a patch I can test it.
> 
> please give this patch a try:
> 
> https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=324722b1e1582d45e865dcd2233a17edcfbd1638

Works fine. Thanks

> If it doesn't work, then please send me the following:
>   1. dmesg from the guest
>   2. vmware.log from the host
>   3. .vmx file for your VM
> 
> thanks,
> 
> Sinclair

you're welcome

Mark
 
> > 
> > > Thanks,
> > > Thomas
> > 
> > Mark
> > 
> > > 
> > > On 05/10/2017 09:17 AM, m.t wrote:
> > > > Hi,
> > > > I don't have a mouse cursor in my virtual machine (vmware workstation 
> > > > 12.5.5 
> > > > build-5234757) with latest master from 
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_=DwICAg=uilaK90D4TOVoH58JNXRgQ=j2ey7nuAQ5d6NbMmCOnRsTIJfmv7blo3UCKagbsM9o2-No8JdlhkKK3ty481ErVu=DWnNRbcrxMhc78PIvembLdV3OsJi3vPwcdG03kqVpJo=mc7-KF2t4BktXs11MShGZBf9bzgxumqhmVQ0ocAIS0k=
> > > >  
> > > > kernel/git/torvalds/linux.git
> > > >
> > > > git bisect led me to 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b as 
> > > > culprit.
> > > >
> > > > Regards 
> > > > Mark
> > > > ___
> > > > Sent to linux-graphics-maintai...@vmware.com
> > > 
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 5/9] drm/i915: Set backlight mode before enable backlight

[Puthikorn Voravootivat]

We should set backlight mode register before set register to
enable the backlight.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 5ee1d90a3263..a72893da78d0 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -103,8 +103,6 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
uint8_t dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
-   set_aux_backlight_enable(intel_dp, true);
-
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -131,6 +129,8 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
default:
break;
}
+
+   set_aux_backlight_enable(intel_dp, true);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH v5 6/9] drm/i915: Support dynamic backlight via DPCD register

[Puthikorn Voravootivat]

Fair enough. Will add kernel switch in next version.

On Wed, May 10, 2017 at 6:26 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> > This patch enables dynamic backlight by default for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness to 0% and 100% of the
> > normal brightness.
>
>
> I read the link that you shared last time, should there be a switch for
> a feature like this that can affect image quality? Should this be a
> decision in the kernel with no provision to turn off/on?
>
>
> -DK
>
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 39
> ++-
> >  1 file changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 5ef3ade7c40e..7d323af96636 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector
> *connector, u32 level)
> >   }
> >  }
> >
> > +/*
> > + * Set minimum / maximum dynamic brightness percentage. This value is
> expressed
> > + * as the percentage of normal brightness in 5% increments.
> > + */
> > +static void
> > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > +u32 min, u32 max)
> > +{
> > + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5)
> };
> > +
> > + if (drm_dp_dpcd_write(_dp->aux,
> DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > +   dbc, sizeof(dbc) < 0)) {
> > + DRM_DEBUG_KMS("Failed to write aux DBC brightness
> level\n");
> > + }
> > +}
> > +
> >  static void intel_dp_aux_enable_backlight(struct intel_connector
> *connector)
> >  {
> >   struct intel_dp *intel_dp = enc_to_intel_dp(>
> encoder->base);
> >   uint8_t dpcd_buf = 0;
> > + uint8_t new_dpcd_buf = 0;
> >   uint8_t edp_backlight_mode = 0;
> >
> >   if (drm_dp_dpcd_readb(_dp->aux,
> > @@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct
> intel_connector *connector)
> >   return;
> >   }
> >
> > + new_dpcd_buf = dpcd_buf;
> >   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_
> MASK;
> >
> >   switch (edp_backlight_mode) {
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> > - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> > - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > - if (drm_dp_dpcd_writeb(_dp->aux,
> > - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) <
> 0) {
> > - DRM_DEBUG_KMS("Failed to write aux backlight
> mode\n");
> > - }
> > + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> > + new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> >   break;
> >
> >   /* Do nothing when it is already DPCD mode */
> > @@ -130,6 +144,19 @@ static void intel_dp_aux_enable_backlight(struct
> intel_connector *connector)
> >   break;
> >   }
> >
> > + if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
> > + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> > + intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0,
> 100);
> > + DRM_DEBUG_KMS("Enable dynamic brightness.\n");
> > + }
> > +
> > + if (new_dpcd_buf != dpcd_buf) {
> > + if (drm_dp_dpcd_writeb(_dp->aux,
> > + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf)
> < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight
> mode\n");
> > + }
> > + }
> > +
> >   set_aux_backlight_enable(intel_dp, true);
> >  }
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/6] drm: Introduce drm_bridge_mode_valid()

[Jose Abreu]

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);
 
 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls _bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,
-- 
1.9.1


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

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Pandiyan, Dhinakaran]

On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> There are some panel that
> (1) does not support display backlight enable via AUX
> (2) support display backlight adjustment via AUX
> (3) support display backlight enable via eDP BL_ENABLE pin
> 
> The current driver required that (1) must be support to enable (2).
> This patch drops that requirement.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 870c03fc0f3a..c22712762957 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
> *intel_dp, bool enable)
>  {
>   uint8_t reg_val = 0;
>  
> +   /* Early return when display use other mechanism to enable backlight. 
> */
> + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> + return;

Won't DP_EDP_BACKLIGHT_AUX_ENABLE_CAP be 1 always? The code below, in
intel_dp_aux_display_control_capable(), makes sure
DP_EDP_BACKLIGHT_PIN_ENABLE_CAP=0. The spec says at least one of these
has to be 1.


"BACKLIGHT_AUX_ENABLE_CAPABLE
1 = Indicates that the Sink device supports display backlight
enable through the BACKLIGHT_ENABLE bit in the
EDP_DISPLAY_CONTROL register (DPCD Address 00720h, bit 0).
Must be set to 1 if the BACKLIGHT_PIN_ENABLE_CAPABLE bit (bit 1)
is cleared to 0."

-DK

> +
>   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
> _val) < 0) {
>   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> @@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct 
> intel_connector *connector)
>* the panel can support backlight control over the aux channel
>*/
>   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
>   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
>   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> (intel_dp->edp_dpcd[2] & 
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {

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

Testing dc-drm-next-atomic-wip

[Ernst Sjöstrand]

Hi,

this is more feedback about how the code works and runs rather than
what you're really looking for, so I thought I'd start a new thread.
:-)

I get the following error when compiling and (obviously) forgetting to
enable the new DC option.
I see the option will be removed, so maybe that doesn't matter?

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_device_init’:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1956:6: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state = kzalloc(sizeof(*adev->dm_state), GFP_KERNEL);
  ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1956:39: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state = kzalloc(sizeof(*adev->dm_state), GFP_KERNEL);
   ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1957:10: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  if (adev->dm_state == NULL)
  ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1959:6: error: ‘struct
amdgpu_device’ has no member named ‘dm_state’; did you mean
‘mm_stats’?
  adev->dm_state->dev = adev;
  ^~

Btw, perhaps you should add a dc-wip-something tag under versions in bugzilla?

Regards
//Ernst


2017-05-03 16:13 GMT+02:00 Harry Wentland :
> Hi all,
>
> Over the last few months we (mostly Andrey and myself) have taken and
> addressed some of the feedback received from December's DC RFC. A lot of our
> work so far centers around atomic. We were able to take a whole bunch of the
> areas where we rolled our own solution and use DRM atomic helpers instead.
>
> You can find our most recent drm-next based tree at
> https://cgit.freedesktop.org/~hwentland/linux/log/?h=dc-drm-next-atomic-wip
>
> An outline of the changes with commit hashes from that tree are listed
> below. They aren't necessarily in order but are grouped by functionality.
>
> I would like to solicit input on the changes and the current state of
> amd/display in general.
>
> I'm on IRC every weekday from 9-5 eastern time, sometimes at other hours.
> Feel free to ask questions, discuss, leave comments. Let me know if there's
> anything else I can do to facilitate review.
>
> We know there's more work to be done but would much rather prioritize that
> work based on community feedback than merely our own impressions.
>
> We haven't finished plumbing drm types to the dc types yet, and there are
> still a bunch of other things in progress.  We are not looking to re-hash
> the previous discussion, but rather we'd like some feedback on our work so
> far.
>
> The list of changes (trimmed commit tags):
>
> == Use common helpers for pageflip ==
> 144da239b047 Use pflip prepare and submit parts (v2)
> ff7ac264a9a1 Fix page flip after daniel's acquire_ctx change
>
>
> == implement atomic_get_properties ==
> cf4a84df7189 Fallback on legacy properties in atomic_get_properties
> 01f96706b6ca get_atomic_property missing for drm_connector_funcs
>
>
> == Use common helpers for gamma ==
> 3f547d7098de Use atomic helpers for gamma
>
>
> == Use atomic helpers for commit ==
> 41831f55bd58 Refactor atomic commit implementation. (v2)
> 6c67dd3c5cd5 Refactor headless to use atomic commit.
> eb22ef1ecb16 Remove page_fleep_needed function.
>
>
> == Use atomic helpers for S3 ==
> 5a6ae6f76249 Switch to DRM helpers in s3.
>
>
> == Simmplify mapping between DRM and DC objects ==
> 84a3ee023b9b Remove get_connector_for_link.
> 6d8978a98b40 Remove get_connector_for_sink.
>
>
> == Use DRM EDID read instead of DC ==
> 566969dacfad Fix i2c write flag.
> 527c3699ff3c Refactor edid read.
> 5ac51023d275 Fix missing irq refactor causing potential i2c race
>
>
> == Save DC validate_ctx in atomic_check and use in commit ==
> 8c194d8e4ee9 pull commit_surfaces out of atomic_commit into helper function
> 27eef98b38c8 Return context from validate_context
> ca3ee10e915b Add DM global atomic state
> 8ba1ca856532 Hook dm private state into atomic_check
> 10160455ac6d Add correct retain/release for objs in dm_atomic_state
> 0f1b2e2aecbb Commit validation set from state
> 258e6a91fc61 Add validate_context to atomic_state
> 64f569b5df20 Use validate_context from atomic_check in commit
>
>
> == Start multi-plane implementation ==
> 601ff4e70b7c decouple per-crtc-plane model
> a0b859a0b114 Fix cleanup in amdgpu_dm_initialize_drm_device
> ee02010d7a82 update plane functionalities
> 3b7345fd1abb Allow planes on all crtcs
> d9cf37462156 initialize YUV plane capabilities
> 248f06b2613e Universal cursor plane hook-up.
>
>
> == Minor cleanups ==
> d99bf02cb8fc Rename atomic_commit parameter.
> f15fb9726502 Use amdgpu mode funcs statically
> d3e37fa70643 Remove unused define from amdgpu_dm_types
> 80a38ad58125 Add lock around updating freesync property
> 8c7f16853824 Use new drm_dp_find_vcpi_slots to compute slots
>
> Regards,
> Harry
> ___
> amd-gfx 

[PATCH v3 5/6] drm: Use mode_valid() in atomic modeset

[Jose Abreu]

This patches makes use of the new mode_valid() callbacks introduced
previously to validate the full video pipeline when modesetting.

This calls the encoder->mode_valid(), bridge->mode_valid() and
crtc->mode_valid() so that we can make sure that the mode will
be accepted in every components.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
---

Changes v1->v2:
- Removed call to connector->mode_valid (Ville, Daniel)
- Change function name (Ville)
- Use for_each_new_connector_in_state (Ville)
- Do not validate if connector and mode didn't change (Ville)
- Use new helpers to call mode_valid

 drivers/gpu/drm/drm_atomic_helper.c | 76 +++--
 1 file changed, 73 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..5a3c458 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 
+#include "drm_crtc_helper_internal.h"
 #include "drm_crtc_internal.h"
 
 /**
@@ -452,6 +453,69 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
return 0;
 }
 
+static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
+   struct drm_encoder *encoder,
+   struct drm_crtc *crtc,
+   struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret;
+
+   ret = drm_encoder_mode_valid(encoder, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] mode_valid() failed\n",
+   encoder->base.id, encoder->name);
+   return ret;
+   }
+
+   ret = drm_bridge_mode_valid(encoder->bridge, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[BRIDGE] mode_valid() failed\n");
+   return ret;
+   }
+
+   ret = drm_crtc_mode_valid(crtc, mode);
+   if (ret != MODE_OK) {
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n",
+   crtc->base.id, crtc->name);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int
+mode_valid(struct drm_atomic_state *state)
+{
+   struct drm_connector_state *conn_state;
+   struct drm_connector *connector;
+   int i;
+
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
+   struct drm_encoder *encoder = conn_state->best_encoder;
+   struct drm_crtc *crtc = conn_state->crtc;
+   struct drm_crtc_state *crtc_state;
+   enum drm_mode_status mode_status;
+   struct drm_display_mode *mode;
+
+   if (!crtc || !encoder)
+   continue;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   continue;
+   if (!crtc_state->mode_changed && 
!crtc_state->connectors_changed)
+   continue;
+
+   mode = _state->mode;
+
+   mode_status = mode_valid_path(connector, encoder, crtc, mode);
+   if (mode_status != MODE_OK)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /**
  * drm_atomic_helper_check_modeset - validate state object for modeset changes
  * @dev: DRM device
@@ -466,13 +530,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
  * 2. _connector_helper_funcs.atomic_check to validate the connector state.
  * 3. If it's determined a modeset is needed then all connectors on the 
affected crtc
  *crtc are added and _connector_helper_funcs.atomic_check is run on 
them.
- * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
- * 5. _encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
+ * 4. _encoder_helper_funcs.mode_valid, _bridge_funcs.mode_valid and
+ *_crtc_helper_funcs.mode_valid are called on the affected components.
+ * 5. _bridge_funcs.mode_fixup is called on all encoder bridges.
+ * 6. _encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
  *This function is only called when the encoder will be part of a 
configured crtc,
  *it must not be used for implementing connector property validation.
  *If this function is NULL, _atomic_encoder_helper_funcs.mode_fixup is 
called
  *instead.
- * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc constraints.
+ * 7. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc 

[PATCH v7 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

intel_dp_aux_backlight driver should check for the
DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 6532e226db29..341bf2cb0c25 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -144,6 +144,7 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver

[Ong, Hean Loong]

On Tue, 2017-05-09 at 09:40 -0700, Eric Anholt wrote:
> "Ong, Hean Loong"  writes:
> 
> > 
> > On Mon, 2017-05-08 at 09:03 -0700, Eric Anholt wrote:
> > > 
> > > "Ong, Hean Loong"  writes:
> > > 
> > > > 
> > > > 
> > > > On Thu, 2017-05-04 at 10:11 -0700, Eric Anholt wrote:
> > > > > 
> > > > > 
> > > > > "Ong, Hean Loong"  writes:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2017-05-03 at 13:28 -0700, Eric Anholt wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > hean.loong@intel.com writes:
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Ong Hean Loong 
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > The new Intel Arria10 SOC FPGA devkit has a Display
> > > > > > > > Port IP
> > > > > > > > component 
> > > > > > > > which requires a new driver. This is a virtual driver
> > > > > > > > in
> > > > > > > > which
> > > > > > > > the
> > > > > > > > FGPA hardware would enable the Display Port based on
> > > > > > > > the
> > > > > > > > information
> > > > > > > > and data provided from the DRM frame buffer from the
> > > > > > > > OS.
> > > > > > > > Basically
> > > > > > > > all
> > > > > > > > all information with reagrds to resolution and bits per
> > > > > > > > pixel
> > > > > > > > are
> > > > > > > > pre-configured on the FPGA design and these information
> > > > > > > > are
> > > > > > > > fed
> > > > > > > > to
> > > > > > > > the driver via the device tree information as part of
> > > > > > > > the
> > > > > > > > hardware 
> > > > > > > > information.
> > > > > > > I started reviewing the code, but I want to make sure I
> > > > > > > understand
> > > > > > > what's going on:
> > > > > > > 
> > > > > > > This IP core isn't displaying contents from system memory
> > > > > > > on
> > > > > > > some
> > > > > > > sort
> > > > > > > of actual physical display, right?  It's a core that
> > > > > > > takes
> > > > > > > some
> > > > > > > input
> > > > > > > video stream (not described in the DT or in this driver)
> > > > > > > and
> > > > > > > stores
> > > > > > > it
> > > > > > > to memory?
> > > > > > If the IP Core you are referring to is some form of GPU
> > > > > > then in
> > > > > > this
> > > > > > case we are using the Intel FPGA Display Port Framebuffer
> > > > > > IP.
> > > > > > It
> > > > > > does
> > > > > > display contents streamed from the ARM/Linux system to the
> > > > > > Display
> > > > > > Port
> > > > > > of the physical Monitor.
> > > > > > 
> > > > > > Below a simple illustration of the system:
> > > > > > 
> > > > > > ARM/Linux --DMA-->Intel FPGA Display Port Framebuffer IP
> > > > > > |
> > > > > > |
> > > > > > Physical Connection
> > > > > > Display Port
> > > > > The "DMA" in this diagram is the frame reader IP, right?  The
> > > > > frame
> > > > > reader, as described in the spec, sounds approximately like a
> > > > > DRM
> > > > > plane,
> > > > > so if you have that in your system then that needs to be part
> > > > > of
> > > > > this
> > > > > DRM driver (otherwise you won't be putting the right things
> > > > > on
> > > > > the
> > > > > screen!).
> > > > Would the drm_simple_display_pipe_init be able to handle this ?
> > > > It
> > > > seems to be displaying the proper images on screen, based on my
> > > > current
> > > > changes. There were recommendations to use the
> > > > drm_simple_display_pipe_init instead of creating the CRTC and
> > > > planes
> > > > myself
> > > The docs I've read for the Frame Buffer IP don't fit into any
> > > current
> > > DRM component, since it's what we're currently calling a
> > > "writeback
> > > connector".
> > > 
> > While running my own test (since the intel-gpu-tools doesn't seems
> > applicable.) The drm_simple_display_pipe_init seems to be simple
> > enough
> > for displaying a matchbox console. The use case for this driver is
> > only
> > part of the enablemennt of the reference design board so that users
> > of
> > the Arria10 devkit can use this as base for their own designs.
> > 
> > > 
> > > I don't understand your system enough to answer.  You didn't
> > > answer
> > > if
> > > the "DMA" block you diagrammed was the frame reader IP (or maybe
> > > the
> > > frame reader IP comes after).  I also don't see how the frame
> > > buffer
> > > IP
> > > could possibly be connected directly to a physical display
> > > connector.
> > The FPGA FrameBuffer 2 soft IP reads the information provided to it
> > from the Linux Kernel via the platform device register provided in
> > the
> > DT. The Linux driver here allocates a chunk of coherent memory that
> > directly maps to the SDRAM. The FPGA soft IP would stream the
> > display
> > out to the Display Port based on the information that was written
> > to
> > the 

[PATCH v7 7/9] drm/i915: Restore brightness level in aux backlight driver

[Puthikorn Voravootivat]

Some panel will default to zero brightness when turning the
panel off and on again. This patch restores last brightness
level back when panel is turning back on.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 1c5459bc20ae..0b48851013cc 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -159,6 +159,7 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
 
set_aux_backlight_enable(intel_dp, true);
+   intel_dp_aux_set_backlight(connector, connector->panel.backlight.level);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Pandiyan, Dhinakaran]

On Wed, 2017-05-10 at 13:05 +0300, Jani Nikula wrote:
> On Wed, 10 May 2017, "Pandiyan, Dhinakaran"  
> wrote:
> > On Tue, 2017-05-09 at 16:39 -0700, Puthikorn Voravootivat wrote:
> >> > How is backlight enabled in this case?
> >> Using eDP BL_ENABLE pin
> >
> >
> > Sure, but I am not seeing how this falls back to one of the
> > [bxt,lpt]_enable_backlight() functions in intel_panel.c. Apologies if I
> > am missing something very obvious.
> >
> > If intel_dp_aux_init_backlight_funcs() returned -ENODEV, then one of the
> > platform specific PWM enable callbacks would be called. But in this
> > case, dp_aux_enable_backlight() just returns without doing anything.
> 
> The eDP BL_ENABLE pin (in the physical eDP connector) is controlled by
> the panel power sequencer, independent from the PWM control. See
> intel_edp_backlight_* functions in intel_dp.c.
> 
> BR,
> Jani.
> 
> 

Ah! Thanks, that makes sense. The naming is a bit confusing though. The
_enable_backlight() functions in intel_panel.c don't enable backlight
but enable PWM.  



> >
> >
> > -DK
> >> 
> >> 
> >> On Sat, May 6, 2017 at 1:59 AM, Pandiyan, Dhinakaran
> >>  wrote:
> >> On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat
> >> wrote:
> >> > There are some panel that
> >> > (1) does not support display backlight enable via AUX
> >> > (2) support display backlight adjustment via AUX
> >> > (3) support display backlight enable via eDP BL_ENABLE pin
> >> >
> >> > The current driver required that (1) must be support to
> >> enable (2).
> >> > This patch drops that requirement.
> >> >
> >> > Signed-off-by: Puthikorn Voravootivat 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> > index ad8560c5f689..5b83c9737644 100644
> >> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> > @@ -28,6 +28,10 @@ static void
> >> set_aux_backlight_enable(struct intel_dp *intel_dp, bool
> >> enable)
> >> >  {
> >> >   uint8_t reg_val = 0;
> >> >
> >> > +   /* Early return when display use other mechanism to
> >> enable backlight. */
> >> > + if (!(intel_dp->edp_dpcd[1] &
> >> DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> >> > + return;
> >> > +
> >> 
> >> How is backlight enabled in this case?
> >> 
> >> -DK
> >> 
> >> >   if (drm_dp_dpcd_readb(_dp->aux,
> >> DP_EDP_DISPLAY_CONTROL_REGISTER,
> >> > _val) < 0) {
> >> >   DRM_DEBUG_KMS("Failed to read DPCD register 0x
> >> %x\n",
> >> > @@ -164,7 +168,6 @@
> >> intel_dp_aux_display_control_capable(struct intel_connector
> >> *connector)
> >> >* the panel can support backlight control over the
> >> aux channel
> >> >*/
> >> >   if ((intel_dp->edp_dpcd[1] &
> >> DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
> >> > - (intel_dp->edp_dpcd[1] &
> >> DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >> >   (intel_dp->edp_dpcd[2] &
> >> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
> >> >   DRM_DEBUG_KMS("AUX Backlight Control
> >> Supported!\n");
> >> >   return true;
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> 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

Re: [Intel-gfx] [PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[Pandiyan, Dhinakaran]

On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> Add option to allow choosing how to adjust brightness if
> panel supports both PWM pin and AUX channel.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  8 +---
>  drivers/gpu/drm/i915/i915_params.h|  2 +-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 23 ++-
>  3 files changed, 24 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index b6a7e363d076..13cf3f1572ab 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
>   .huc_firmware_path = NULL,
>   .enable_dp_mst = true,
>   .inject_load_failure = 0,
> - .enable_dpcd_backlight = false,
> + .enable_dpcd_backlight = -1,
>   .enable_gvt = false,
>  };
>  
> @@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
>  module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, 
> uint, 0400);
>  MODULE_PARM_DESC(inject_load_failure,
>   "Force an error after a number of failure check points (0:disabled 
> (default), N:force failure at the Nth failure check point)");
> -module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
> 0600);
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
> 0600);
>  MODULE_PARM_DESC(enable_dpcd_backlight,
> - "Enable support for DPCD backlight control (default:false)");
> + "Enable support for DPCD backlight control "
> + "(-1:disable (default), 0:Use PWM pin if both supported, "
> + "1:Use DPCD if both supported");
>  
>  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
>  MODULE_PARM_DESC(enable_gvt,
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 34148cc8637c..ac02efce6e22 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -66,7 +66,7 @@
>   func(bool, verbose_state_checks); \
>   func(bool, nuclear_pageflip); \
>   func(bool, enable_dp_mst); \
> - func(bool, enable_dpcd_backlight); \
> + func(int, enable_dpcd_backlight); \
>   func(bool, enable_gvt)
>  
>  #define MEMBER(T, member) T member
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index c22712762957..e82f7cb9a7af 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -167,21 +167,34 @@ intel_dp_aux_display_control_capable(struct 
> intel_connector *connector)
>   /* Check the  eDP Display control capabilities registers to determine if
>* the panel can support backlight control over the aux channel
>*/
> - if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
> - !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> -   (intel_dp->edp_dpcd[2] & 
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
> + if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
>   DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
>   return true;
>   }
>   return false;
>  }
>  
> +static bool
> +intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
> +
> + /* Check the  eDP Display control capabilities registers to determine if
> +  * the panel can support backlight control via BL_PWM_DIM eDP pin
> +  */
> + return intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP;


This is not right. The bits in DPCD 0x702 don't mean anything if
DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP in 0x701 is not set.


-DK


> +}
> +
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> *intel_connector)
>  {
>   struct intel_panel *panel = _connector->panel;
>  
> - if (!i915.enable_dpcd_backlight)
> + if (i915.enable_dpcd_backlight == -1)
> + return -ENODEV;
> +
> + if (i915.enable_dpcd_backlight == 0 &&
> + intel_dp_pwm_pin_display_control_capable(intel_connector))
>   return -ENODEV;
>  
>   if (!intel_dp_aux_display_control_capable(intel_connector))

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

Re: [Intel-gfx] [PATCH v5 6/9] drm/i915: Support dynamic backlight via DPCD register

[Pandiyan, Dhinakaran]

On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> This patch enables dynamic backlight by default for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.


I read the link that you shared last time, should there be a switch for
a feature like this that can affect image quality? Should this be a
decision in the kernel with no provision to turn off/on? 


-DK

> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 39 
> ++-
>  1 file changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 5ef3ade7c40e..7d323af96636 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
> *connector, u32 level)
>   }
>  }
>  
> +/*
> + * Set minimum / maximum dynamic brightness percentage. This value is 
> expressed
> + * as the percentage of normal brightness in 5% increments.
> + */
> +static void
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> +   dbc, sizeof(dbc) < 0)) {
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + }
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t new_dpcd_buf = 0;
>   uint8_t edp_backlight_mode = 0;
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
> @@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   return;
>   }
>  
> + new_dpcd_buf = dpcd_buf;
>   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>  
>   switch (edp_backlight_mode) {
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> - if (drm_dp_dpcd_writeb(_dp->aux,
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
> - DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> - }
> + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>   break;
>  
>   /* Do nothing when it is already DPCD mode */
> @@ -130,6 +144,19 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   break;
>   }
>  
> + if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
> + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> + intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
> + DRM_DEBUG_KMS("Enable dynamic brightness.\n");
> + }
> +
> + if (new_dpcd_buf != dpcd_buf) {
> + if (drm_dp_dpcd_writeb(_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> + }
> + }
> +
>   set_aux_backlight_enable(intel_dp, true);
>  }
>  

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

[PATCH v7 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

[Puthikorn Voravootivat]

intel_dp_aux_enable_backlight() assumed that the register
BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
(DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.

This patch fixed that by handling all cases of that register.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 33 ++-
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 341bf2cb0c25..870c03fc0f3a 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,15 +97,36 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t edp_backlight_mode = 0;
 
set_aux_backlight_enable(intel_dp, true);
 
-   if ((drm_dp_dpcd_readb(_dp->aux,
-  DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
== 1) &&
-   ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
-DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
-   drm_dp_dpcd_writeb(_dp->aux, 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
-  (dpcd_buf | 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
+   if (drm_dp_dpcd_readb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
+   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+   return;
+   }
+
+   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+
+   switch (edp_backlight_mode) {
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   break;
+
+   /* Do nothing when it is already DPCD mode */
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
+   default:
+   break;
+   }
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH v6 8/9] drm: Add definition for eDP backlight frequency

[Pandiyan, Dhinakaran]

On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> This patch adds the following definition
> - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
>   register which only use bit 0:4
> - Base frequency (27 MHz) for backlight PWM frequency
>   generator.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  include/drm/drm_dp_helper.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7651a9..810b7d5d9f2b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -572,10 +572,12 @@
>  #define DP_EDP_PWMGEN_BIT_COUNT 0x724
>  #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
>  #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
> +# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (0x1f << 0)
>  
>  #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
>  
>  #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
> +# define DP_EDP_BACKLIGHT_FREQ_BASE 2700

I have seen frequency values expressed in kHz in most places within drm,
I think it's best to write this also in kHz to avoid confusion. With the
units addressed,
Reviewed-by: Dhinakaran Pandiyan 

>  
>  #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
>  #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b

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

[PATCH 4/5] amdgpu/cs: split out fence dependency checking

[Dave Airlie]

From: Dave Airlie 

This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.

Reviewed-by: Christian König 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb..df25b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -963,56 +963,65 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
 }
 
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p,
+   struct amdgpu_cs_chunk *chunk)
 {
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
-   int i, j, r;
-
-   for (i = 0; i < p->nchunks; ++i) {
-   struct drm_amdgpu_cs_chunk_dep *deps;
-   struct amdgpu_cs_chunk *chunk;
-   unsigned num_deps;
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_dep *deps;
 
-   chunk = >chunks[i];
+   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_dep);
 
-   if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
-   continue;
+   for (i = 0; i < num_deps; ++i) {
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct dma_fence *fence;
 
-   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
-   num_deps = chunk->length_dw * 4 /
-   sizeof(struct drm_amdgpu_cs_chunk_dep);
+   r = amdgpu_cs_get_ring(p->adev, deps[i].ip_type,
+  deps[i].ip_instance,
+  deps[i].ring, );
+   if (r)
+   return r;
 
-   for (j = 0; j < num_deps; ++j) {
-   struct amdgpu_ring *ring;
-   struct amdgpu_ctx *ctx;
-   struct dma_fence *fence;
+   ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+   if (ctx == NULL)
+   return -EINVAL;
 
-   r = amdgpu_cs_get_ring(adev, deps[j].ip_type,
-  deps[j].ip_instance,
-  deps[j].ring, );
+   fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+   if (IS_ERR(fence)) {
+   r = PTR_ERR(fence);
+   amdgpu_ctx_put(ctx);
+   return r;
+   } else if (fence) {
+   r = amdgpu_sync_fence(p->adev, >job->sync,
+ fence);
+   dma_fence_put(fence);
+   amdgpu_ctx_put(ctx);
if (r)
return r;
+   }
+   }
+   return 0;
+}
 
-   ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
-   if (ctx == NULL)
-   return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+   int i, r;
 
-   fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
-   if (IS_ERR(fence)) {
-   r = PTR_ERR(fence);
-   amdgpu_ctx_put(ctx);
-   return r;
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
 
-   } else if (fence) {
-   r = amdgpu_sync_fence(adev, >job->sync,
- fence);
-   dma_fence_put(fence);
-   amdgpu_ctx_put(ctx);
-   if (r)
-   return r;
-   }
+   chunk = >chunks[i];
+
+   if (chunk->chunk_id == AMDGPU_CHUNK_ID_DEPENDENCIES) {
+   r = amdgpu_process_fence_dep(p, chunk);
+   if (r)
+   return r;
}
}
 
-- 
2.9.3

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

[PATCH 3/5] drm/syncobj: add sync_file interaction.

[Dave Airlie]

From: Dave Airlie 

This interface allows importing the fence from a sync_file into
an existing drm sync object, or exporting the fence attached to
an existing drm sync object into a new sync file object.

This should only be used to interact with sync files where necessary.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_syncobj.c | 56 +++
 include/uapi/drm/drm.h|  6 +++--
 2 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 9a8c690..69ef20a 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_internal.h"
 #include 
@@ -290,6 +291,48 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
*file_private,
return 0;
 }
 
+int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
+  int fd, int handle)
+{
+   struct dma_fence *fence = sync_file_get_fence(fd);
+   if (!fence)
+   return -EINVAL;
+
+   return drm_syncobj_replace_fence(file_private, handle, fence);
+}
+
+int drm_syncobj_export_sync_file(struct drm_file *file_private,
+int handle, int *p_fd)
+{
+   int ret;
+   struct dma_fence *fence;
+   struct sync_file *sync_file;
+   int fd = get_unused_fd_flags(O_CLOEXEC);
+
+   if (fd < 0)
+   return fd;
+
+   ret = drm_syncobj_fence_get(file_private, handle, );
+   if (ret)
+   goto err_put_fd;
+
+   sync_file = sync_file_create(fence);
+   if (!sync_file) {
+   ret = -EINVAL;
+   goto err_fence_put;
+   }
+
+   fd_install(fd, sync_file->file);
+
+   dma_fence_put(fence);
+   *p_fd = fd;
+   return 0;
+err_fence_put:
+   dma_fence_put(fence);
+err_put_fd:
+   put_unused_fd(fd);
+   return ret;
+}
 /**
  * drm_syncobj_open - initalizes syncobj file-private structures at devnode 
open time
  * @dev: drm_device which is being opened by userspace
@@ -372,6 +415,12 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
 
+   if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
+   return drm_syncobj_export_sync_file(file_private, args->handle,
+   >fd);
+   else if (args->flags)
+   return -EINVAL;
+
return drm_syncobj_handle_to_fd(file_private, args->handle,
>fd);
 }
@@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
 
+   if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE)
+   return drm_syncobj_import_sync_file_fence(file_private,
+ args->fd,
+ args->handle);
+   else if (args->flags)
+   return -EINVAL;
+
return drm_syncobj_fd_to_handle(file_private, args->fd,
>handle);
 }
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index db9e35e..d0e05f4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -707,13 +707,15 @@ struct drm_syncobj_destroy {
__u32 pad;
 };
 
+#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE (1 << 0)
+#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE (1 << 0)
 struct drm_syncobj_handle {
__u32 handle;
/** Flags.. only applicable for handle->fd */
-   __u32 flags;
+   __u32 fd_flags;
 
__s32 fd;
-   __u32 pad;
+   __u32 flags;
 };
 
 /* timeout_ns is relative timeout in nanoseconds */
-- 
2.9.3

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

[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)

[Dave Airlie]

From: Dave Airlie 

This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.

Sync objects are managed via the drm syncobj ioctls.

The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.

This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.

In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.

NOTE: this interface addition needs a version bump to expose
it to userspace.

v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 81 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 include/uapi/drm/amdgpu_drm.h   |  6 +++
 3 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index df25b32..e86c832 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 
@@ -217,6 +218,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
break;
 
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
 
default:
@@ -1008,6 +1011,40 @@ static int amdgpu_process_fence_dep(struct 
amdgpu_cs_parser *p,
return 0;
 }
 
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+   int r;
+   struct dma_fence *fence;
+   r = drm_syncobj_fence_get(p->filp, handle, );
+   if (r)
+   return r;
+
+   r = amdgpu_sync_fence(p->adev, >job->sync, fence);
+   dma_fence_put(fence);
+
+   return r;
+}
+
+static int amdgpu_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
 static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
  struct amdgpu_cs_parser *p)
 {
@@ -1022,12 +1059,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device 
*adev,
r = amdgpu_process_fence_dep(p, chunk);
if (r)
return r;
+   } else if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_IN) {
+   r = amdgpu_process_syncobj_in_dep(p, chunk);
+   if (r)
+   return r;
}
}
 
return 0;
 }
 
+static int amdgpu_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = drm_syncobj_replace_fence(p->filp, deps[i].handle,
+ p->fence);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
+static int amdgpu_cs_post_dependencies(struct amdgpu_cs_parser *p)
+{
+   int i, r;
+
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
+
+   chunk = >chunks[i];
+
+   if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_OUT) {
+   r = amdgpu_process_syncobj_out_dep(p, chunk);
+   if (r)
+   return r;
+   }
+   }
+   return 0;
+}
+
 static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
union drm_amdgpu_cs *cs)
 {
@@ -1055,7 +1134,7 @@ static int 

[PATCH 2/5] drm/syncobj: add sync obj wait interface. (v2)

[Dave Airlie]

From: Dave Airlie 

This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

v2: accept relative timeout, pass remaining time back
to userspace.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_syncobj.c  | 139 -
 include/uapi/drm/drm.h |  12 
 4 files changed, 154 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 44ef903..a508ad9 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6da7adc..b142466 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -653,6 +653,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 835e987..9a8c690 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
 /*
  * Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -31,10 +33,13 @@
  * that contain an optional fence. The fence can be updated with a new
  * fence, or be NULL.
  *
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
  * syncobj's can be export to fd's and back, these fd's are opaque and
  * have no other use case, except passing the syncobj between processes.
  *
- * TODO: sync_file interactions, waiting
+ * TODO: sync_file interactions.
  *
  * Their primary use-case is to implement Vulkan fences and semaphores.
  *
@@ -383,3 +388,135 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
>handle);
 }
+
+static int drm_syncobj_wait_all_fences(struct drm_device *dev,
+  struct drm_file *file_private,
+  struct drm_syncobj_wait *wait,
+  uint32_t *handles)
+{
+   uint32_t i;
+   int ret = 0;
+   unsigned long timeout = nsecs_to_jiffies(wait->timeout_ns);
+
+   for (i = 0; i < wait->count_handles; i++) {
+   struct dma_fence *fence;
+
+   ret = drm_syncobj_fence_get(file_private, handles[i],
+   );
+   if (ret)
+   return ret;
+
+   if (!fence)
+   continue;
+
+   ret = dma_fence_wait_timeout(fence, true, timeout);
+
+   dma_fence_put(fence);
+   if (ret < 0)
+   return ret;
+   if (ret == 0)
+   break;
+   timeout = ret;
+   }
+
+   if (ret > 0)
+   wait->timeout_ns = jiffies_to_nsecs(ret);
+   wait->out_status = (ret > 0);
+   wait->first_signaled = 0;
+   return 0;
+}
+
+static int drm_syncobj_wait_any_fence(struct drm_device *dev,
+ struct drm_file *file_private,
+ struct drm_syncobj_wait *wait,
+ uint32_t *handles)
+{
+   unsigned long timeout = nsecs_to_jiffies(wait->timeout_ns);
+   struct dma_fence **array;
+   uint32_t i;
+   int ret;
+   uint32_t first = ~0;
+
+   /* Prepare the fence array */
+   array = kcalloc(wait->count_handles,
+   sizeof(struct dma_fence *), GFP_KERNEL);
+
+   if (array == NULL)
+   return -ENOMEM;
+
+   for (i = 0; i < wait->count_handles; i++) {
+   struct dma_fence *fence;
+
+   ret = drm_syncobj_fence_get(file_private, handles[i],
+  

drm syncobj - can we get some r-b/a-bs?

[Dave Airlie]

Okay I'm not convinced this is going to get any better out of tree,
I've polished what I can, and fixed up the last few comments from people,

I'd like to rebase on drm-misc probably at some point and send a pull
request for it.

This mostly just addresses things around naming that Chris pointed out.

Dave.

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

[PATCH 1/5] drm: introduce sync objects (v2)

[Dave Airlie]

From: Dave Airlie 

Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.

There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).

These objects can be converted to an opaque fd that can be
passes between processes.

v2: rename reference/unreference to put/get (Chris)
fix leaked reference (David Zhou)
drop mutex in favour of cmpxchg (Chris)
document drm_syncobj_fence_get
use ENOENT for syncobj lookup.

Signed-off-by: Dave Airlie 

fixup
---
 Documentation/gpu/drm-internals.rst |   3 +
 Documentation/gpu/drm-mm.rst|   6 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_fops.c  |   8 +
 drivers/gpu/drm/drm_internal.h  |  13 ++
 drivers/gpu/drm/drm_ioctl.c |  12 ++
 drivers/gpu/drm/drm_syncobj.c   | 385 
 include/drm/drmP.h  |   5 +
 include/drm/drm_drv.h   |   1 +
 include/drm/drm_syncobj.h   |  87 
 include/uapi/drm/drm.h  |  25 +++
 11 files changed, 546 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_syncobj.c
 create mode 100644 include/drm/drm_syncobj.h

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index e35920d..2ea3bce 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -98,6 +98,9 @@ DRIVER_ATOMIC
 implement appropriate obj->atomic_get_property() vfuncs for any
 modeset objects with driver specific properties.
 
+DRIVER_SYNCOBJ
+Driver support drm sync objects.
+
 Major, Minor and Patchlevel
 ~~~
 
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index f5760b1..28aebe8 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -483,3 +483,9 @@ DRM Cache Handling
 
 .. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+
+DRM Sync Objects
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+   :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 3ee9579..b5e565c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
-   drm_dumb_buffers.o drm_mode_config.o
+   drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index afdf5b1..9a61df2 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -219,6 +219,9 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, priv);
 
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_open(priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_init_file_private(>prime);
 
@@ -266,6 +269,8 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
 out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(>prime);
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(priv);
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, priv);
put_pid(priv->pid);
@@ -400,6 +405,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_property_destroy_user_blobs(dev, file_priv);
}
 
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(file_priv);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, file_priv);
 
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f37388c..44ef903 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -142,4 +142,17 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc 
*crtc)
 {
return 0;
 }
+
 #endif
+
+/* drm_syncobj.c */
+void drm_syncobj_open(struct drm_file *file_private);
+void drm_syncobj_release(struct drm_file *file_private);
+int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, void *data,
+  struct 

[Bug 188911] Function qxl_release_alloc() returns an improper value when the call to kmalloc() fails, resulting in bad memory access

[bugzilla-daemon]

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

bianpan (bianpan2...@ruc.edu.cn) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

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

[Bug 188911] Function qxl_release_alloc() returns an improper value when the call to kmalloc() fails, resulting in bad memory access

[bugzilla-daemon]

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

--- Comment #1 from bianpan (bianpan2...@ruc.edu.cn) ---
Created attachment 256435
  --> https://bugzilla.kernel.org/attachment.cgi?id=256435=edit
The patch fixes the bug

The patch has been merged into the latest version of the Linux kernel. So I
will close the bug.

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

[PATCH 1/4] drm/vc4: Adjust modes in DSI to work around the integer PLL divider.

[Eric Anholt]

BCM2835's PLLD_DSI1 divider doesn't give us many choices for our pixel
clocks, so to support panels on the Raspberry Pi we need to set a
higher pixel clock rate than requested and adjust the mode we program
to extend out the HFP so that the refresh rate matches.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 112 --
 1 file changed, 86 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index fb54a9d10360..62cb3b0d0345 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -519,7 +519,8 @@ struct vc4_dsi {
/* DSI channel for the panel we're connected to. */
u32 channel;
u32 lanes;
-   enum mipi_dsi_pixel_format format;
+   u32 format;
+   u32 divider;
u32 mode_flags;
 
/* Input clock from CPRMAN to the digital PHY, for the DSI
@@ -817,13 +818,67 @@ static void vc4_dsi_encoder_disable(struct drm_encoder 
*encoder)
pm_runtime_put(dev);
 }
 
+/* Extends the mode's blank intervals to handle BCM2835's integer-only
+ * DSI PLL divider.
+ *
+ * On 2835, PLLD is set to 2Ghz, and may not be changed by the display
+ * driver since most peripherals are hanging off of the PLLD_PER
+ * divider.  PLLD_DSI1, which drives our DSI bit clock (and therefore
+ * the pixel clock), only has an integer divider off of DSI.
+ *
+ * To get our panel mode to refresh at the expected 60Hz, we need to
+ * extend the horizontal blank time.  This means we drive a
+ * higher-than-expected clock rate to the panel, but that's what the
+ * firmware (which ) does too.
+ */
+static bool vc4_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   struct vc4_dsi_encoder *vc4_encoder = to_vc4_dsi_encoder(encoder);
+   struct vc4_dsi *dsi = vc4_encoder->dsi;
+   struct clk *phy_parent = clk_get_parent(dsi->pll_phy_clock);
+   unsigned long parent_rate = clk_get_rate(phy_parent);
+   unsigned long pixel_clock_hz = mode->clock * 1000;
+   unsigned long pll_clock = pixel_clock_hz * dsi->divider;
+   int divider;
+
+   /* Find what divider gets us a faster clock than the requested
+* pixel clock.
+*/
+   for (divider = 1; divider < 8; divider++) {
+   if (parent_rate / divider < pll_clock) {
+   divider--;
+   break;
+   }
+   }
+
+   /* Now that we've picked a PLL divider, calculate back to its
+* pixel clock.
+*/
+   pll_clock = parent_rate / divider;
+   pixel_clock_hz = pll_clock / dsi->divider;
+
+   /* Round up the clk_set_rate() request slightly, since
+* PLLD_DSI1 is an integer divider and its rate selection will
+* never round up.
+*/
+   adjusted_mode->clock = pixel_clock_hz / 1000 + 1;
+
+   /* Given the new pixel clock, adjust HFP to keep vrefresh the same. */
+   adjusted_mode->htotal = pixel_clock_hz / (mode->vrefresh * 
mode->vtotal);
+   adjusted_mode->hsync_end += adjusted_mode->htotal - mode->htotal;
+   adjusted_mode->hsync_start += adjusted_mode->htotal - mode->htotal;
+
+   return true;
+}
+
 static void vc4_dsi_encoder_enable(struct drm_encoder *encoder)
 {
-   struct drm_display_mode *mode = >crtc->mode;
+   struct drm_display_mode *mode = >crtc->state->adjusted_mode;
struct vc4_dsi_encoder *vc4_encoder = to_vc4_dsi_encoder(encoder);
struct vc4_dsi *dsi = vc4_encoder->dsi;
struct device *dev = >pdev->dev;
-   u32 format = 0, divider = 0;
bool debug_dump_regs = false;
unsigned long hs_clock;
u32 ui_ns;
@@ -845,26 +900,7 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
vc4_dsi_dump_regs(dsi);
}
 
-   switch (dsi->format) {
-   case MIPI_DSI_FMT_RGB888:
-   format = DSI_PFORMAT_RGB888;
-   divider = 24 / dsi->lanes;
-   break;
-   case MIPI_DSI_FMT_RGB666:
-   format = DSI_PFORMAT_RGB666;
-   divider = 24 / dsi->lanes;
-   break;
-   case MIPI_DSI_FMT_RGB666_PACKED:
-   format = DSI_PFORMAT_RGB666_PACKED;
-   divider = 18 / dsi->lanes;
-   break;
-   case MIPI_DSI_FMT_RGB565:
-   format = DSI_PFORMAT_RGB565;
-   divider = 16 / dsi->lanes;
-   break;
-   }
-
-   phy_clock = pixel_clock_hz * divider;
+   phy_clock = pixel_clock_hz * dsi->divider;
ret = clk_set_rate(dsi->pll_phy_clock, phy_clock);
if (ret) {
dev_err(>pdev->dev,
@@ -1049,8 +1085,9 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
 
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) 

[PATCH 3/4] drm/bridge: Add support for the Raspberry Pi 7" Touchscreen.

[Eric Anholt]

This driver communicates with the Atmel microcontroller for sequencing
the poweron of the TC358762 DSI-DPI bridge and controlling the
backlight PWM.

The following lines are required in config.txt, to keep the firmware
from trying to bash our I2C lines and steal the DSI interrupts:

disable_touchscreen=1
ignore_lcd=2
mask_gpu_interrupt1=0x1000

This means that the firmware won't power on the panel at boot time (no
rainbow) and the touchscreen input won't work.  A native input driver
for the touchscreen still needs to be written.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/bridge/Kconfig   |   9 +
 drivers/gpu/drm/bridge/Makefile  |   1 +
 drivers/gpu/drm/bridge/raspberrypi-touchscreen.c | 460 +++
 3 files changed, 470 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/raspberrypi-touchscreen.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index c4daca38743c..9adda62f45df 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -76,6 +76,15 @@ config DRM_SIL_SII8620
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.
 
+config DRM_RASPBERRYPI_TOUCHSCREEN_BRIDGE
+   tristate "Raspberry Pi 7-inch touchscreen bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Say Y here if you want to enable support for the Raspberry
+ Pi 7" Touchscreen.  To compile this driver as a module,
+ choose M here.
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 3fe2226ee2f2..6226ed41f4d1 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_RASPBERRYPI_TOUCHSCREEN_BRIDGE) += raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
diff --git a/drivers/gpu/drm/bridge/raspberrypi-touchscreen.c 
b/drivers/gpu/drm/bridge/raspberrypi-touchscreen.c
new file mode 100644
index ..b19b5a83f210
--- /dev/null
+++ b/drivers/gpu/drm/bridge/raspberrypi-touchscreen.c
@@ -0,0 +1,460 @@
+/*
+ * Copyright © 2016-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Portions of this file (derived from panel-simple.c) are:
+ *
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * Raspberry Pi 7" touchscreen panel bridge driver.
+ *
+ * The 7" touchscreen consists of a DPI LCD panel, a Toshiba
+ * TC358762XBG DSI-DPI bridge, and an I2C-connected Atmel ATTINY88-MUR
+ * controlling power management, the LCD PWM, and initial register
+ * setup of the Tohsiba.
+ *
+ * This driver controls the TC358762 and ATTINY88, bridging between
+ * the DSI host and the LCD panel.  The panel-simple driver has the
+ * actual panel.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I2C registers of the Atmel microcontroller. */
+enum REG_ADDR {
+   REG_ID = 0x80,
+   REG_PORTA, /* BIT(2) for horizontal flip, BIT(3) for vertical flip */
+   REG_PORTB,
+   REG_PORTC,
+   REG_PORTD,
+   REG_POWERON,
+   REG_PWM,
+   

[PATCH 4/4] drm/panel: Add the Raspberry Pi 7" touchscreen's panel.

[Eric Anholt]

The timings are those that the firmware defines as the baseline, which
will be modified by the bridge/host as necessary to get the clocking
to work.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/panel/panel-simple.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index c4566ce8fda7..5bd026cf432b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1530,6 +1530,33 @@ static const struct panel_desc qd43003c0_40 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode raspberrypi_7inch_mode = {
+   /* Modeline comes from the Raspberry Pi firmware, with HFP=1
+* plugged in and clock re-computed from that.
+*/
+   .clock = 25979400 / 1000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 1,
+   .hsync_end = 800 + 1 + 2,
+   .htotal = 800 + 1 + 2 + 46,
+   .vdisplay = 480,
+   .vsync_start = 480 + 7,
+   .vsync_end = 480 + 7 + 2,
+   .vtotal = 480 + 7 + 2 + 21,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc raspberrypi_7inch = {
+   .modes = _7inch_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct drm_display_mode samsung_lsn122dl01_c01_mode = {
.clock = 271560,
.hdisplay = 2560,
@@ -1996,6 +2023,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "qiaodian,qd43003c0-40",
.data = _40,
}, {
+   .compatible = "raspberrypi,7inch-touchscreen-panel",
+   .data = _7inch,
+   }, {
.compatible = "samsung,lsn122dl01-c01",
.data = _lsn122dl01_c01,
}, {
-- 
2.11.0

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

[PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Eric Anholt]

The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with
DSI->DPI bridge and touchscreen controller integrated, that connects
to the Raspberry Pi through its 15-pin "DSI" connector (some lines are
DSI, some lines are I2C).

This device is represented in the DT as three nodes (DSI device, I2C
device, panel).  Input will be left to a separate binding later, as it
will be a basic I2C client device.

Signed-off-by: Eric Anholt 
---
 .../raspberrypi,7inch-touchscreen-bridge.txt   | 68 ++
 .../panel/raspberrypi,7inch-touchscreen-panel.txt  |  7 +++
 2 files changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchscreen-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen-panel.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchscreen-bridge.txt
 
b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchscreen-bridge.txt
new file mode 100644
index ..a5669beaf68f
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchscreen-bridge.txt
@@ -0,0 +1,68 @@
+Official 7" (800x480) Raspberry Pi touchscreen panel's bridge.
+
+This DSI panel contains:
+
+- TC358762 DSI->DPI bridge
+- Atmel microcontroller on I2C for power sequencing the DSI bridge and
+  controlling backlight
+- Touchscreen controller on I2C for touch input
+
+and this covers the TC358762 bridge and Atmel microcontroller, while
+../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel.
+
+Required properties:
+- compatible:  Must be "raspberrypi,7inch-touchscreen-bridge"
+- raspberrypi,touchscreen-bridge:
+   Handle to the I2C device for Atmel microcontroller
+
+Example:
+
+dsi1: dsi@7e70 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   <...>
+
+   lcd-bridge@0 {
+   compatible = "raspberrypi,7inch-touchscreen-bridge";
+   reg = <0>;
+
+   raspberrypi,touchscreen-bridge = <_bridge>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   pitouchscreen_bridge_port: endpoint {
+   remote-endpoint = 
<_panel_port>;
+   };
+   };
+   };
+   };
+};
+
+i2c_dsi: i2c {
+   compatible = "i2c-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   gpios = < 28 0
+ 29 0>;
+
+   pitouchscreen_bridge: bridge@45 {
+   compatible = "raspberrypi,touchscreen-bridge-i2c";
+   reg = <0x45>;
+   };
+};
+
+lcd {
+   compatible = "raspberrypi,7inch-touchscreen-panel";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   pitouchscreen_panel_port: endpoint {
+   remote-endpoint = <_bridge_port>;
+   };
+   };
+   };
+};
diff --git 
a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen-panel.txt
 
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen-panel.txt
new file mode 100644
index ..1e84f97b3b20
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen-panel.txt
@@ -0,0 +1,7 @@
+Official 7" (800x480) Raspberry Pi touchscreen panel's panel.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible:  Must be "raspberrypi,7inch-touchscreen-panel"
-- 
2.11.0

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

[PATCH 0/4] Raspberry Pi Touchscreen bridge/panel drivers

[Eric Anholt]

Here's the rewrite of the Raspberry Pi display support to split out a
bridge driver representing the toshiba+atmel pair.  It depends on the
panel-bridge layer I've submitted.

The RPi DSI stack isn't completely working yet -- I've got some
flickery pixels on the display where it seems some color values are
unstable (on the default debian swirl desktop image, they're
particularly visible as pink sparkles near the edge of the swirls).
So far messing with clocks, not setting clocks at all, forcing the
firmware's DSI timings, and a bunch of other hacks haven't managed to
resolve it.  Still, I think this driver stack is useful to have, and I
assume that fixing this will be a small bugfix somewhere later.

Eric Anholt (4):
  drm/vc4: Adjust modes in DSI to work around the integer PLL divider.
  dt-bindings: Document the Raspberry Pi Touchscreen nodes.
  drm/bridge: Add support for the Raspberry Pi 7" Touchscreen.
  drm/panel: Add the Raspberry Pi 7" touchscreen's panel.

 .../raspberrypi,7inch-touchscreen-bridge.txt   |  68 +++
 .../panel/raspberrypi,7inch-touchscreen-panel.txt  |   7 +
 drivers/gpu/drm/bridge/Kconfig |   9 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/raspberrypi-touchscreen.c   | 460 +
 drivers/gpu/drm/panel/panel-simple.c   |  30 ++
 drivers/gpu/drm/vc4/vc4_dsi.c  | 112 +++--
 7 files changed, 661 insertions(+), 26 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchscreen-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen-panel.txt
 create mode 100644 drivers/gpu/drm/bridge/raspberrypi-touchscreen.c

-- 
2.11.0

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

Re: Requests for Proposal for hosting XDC 2018

[Manasi Navare]

Hi Daniel,

Is Call for Papers opened yet for XDC? When do they usually start accepting 
proposals?

Regards
Manasi


On Fri, May 12, 2017 at 12:08:45AM +0200, Daniel Vetter wrote:
> Hi all,
> 
> The X.org board is soliciting proposals to host XDC in 2017. By the usual
> rotation a location in Europe is preferred, but the board will also
> consider other locations, especially if there's an interesting co-location
> with another conference.
> 
> If you consider hosting XDC, we have assembled a wiki page with what's
> generally expected and needed:
> 
> https://www.x.org/wiki/Events/RFP/
> 
> If possible the board would like to decide on the next location at XDC
> 2017 in Mountain View, please submit your proposal with at least the key
> information about location, possible dates and estimated costs to
> bo...@foundation.x.org latest by 31th August. An early quick heads-up to
> the board if you consider hosting would also be good, in case we need to
> adjust the schedule a bit. Also earlier is better since in generally there
> will be a bit of Q with organizers.
> 
> And if you just have some questions about what organizing XDC entails,
> please feel free to chat with a previous organizers, or with someone from
> the board.
> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Unbreak HPD handling for r600+

[Lyude]

We end up reading the interrupt register for HPD5, and then writing it
to HPD6 which on systems without anything using HPD5 results in
permanently disabling hotplug on one of the display outputs after the
first time we acknowledge a hotplug interrupt from the GPU.

This code is really bad. But for now, let's just fix this. I will
hopefully have a large patch series to refactor all of this soon.

Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c   | 4 ++--
 drivers/gpu/drm/radeon/evergreen.c | 4 ++--
 drivers/gpu/drm/radeon/r600.c  | 2 +-
 drivers/gpu/drm/radeon/si.c| 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 53710dd..cfc917c 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7401,7 +7401,7 @@ static inline void cik_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.cik.disp_int_cont5 & DC_HPD6_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
@@ -7431,7 +7431,7 @@ static inline void cik_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.cik.disp_int_cont5 & DC_HPD6_RX_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_RX_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index d1b1e0c..c48d19e 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4933,7 +4933,7 @@ static void evergreen_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.evergreen.disp_int_cont5 & DC_HPD6_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
@@ -4964,7 +4964,7 @@ static void evergreen_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.evergreen.disp_int_cont5 & 
DC_HPD6_RX_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_RX_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0a08517..e06e2d8 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3988,7 +3988,7 @@ static void r600_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.r600.disp_int_cont2 & 
DC_HPD6_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 528e5a4..bfeb774 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6330,7 +6330,7 @@ static inline void si_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.evergreen.disp_int_cont5 & DC_HPD6_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
@@ -6361,7 +6361,7 @@ static inline void si_irq_ack(struct radeon_device *rdev)
WREG32(DC_HPD5_INT_CONTROL, tmp);
}
if (rdev->irq.stat_regs.evergreen.disp_int_cont5 & 
DC_HPD6_RX_INTERRUPT) {
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
+   tmp = RREG32(DC_HPD6_INT_CONTROL);
tmp |= DC_HPDx_RX_INT_ACK;
WREG32(DC_HPD6_INT_CONTROL, tmp);
}
-- 
2.9.3

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

Requests for Proposal for hosting XDC 2018

[Daniel Vetter]

Hi all,

The X.org board is soliciting proposals to host XDC in 2017. By the usual
rotation a location in Europe is preferred, but the board will also
consider other locations, especially if there's an interesting co-location
with another conference.

If you consider hosting XDC, we have assembled a wiki page with what's
generally expected and needed:

https://www.x.org/wiki/Events/RFP/

If possible the board would like to decide on the next location at XDC
2017 in Mountain View, please submit your proposal with at least the key
information about location, possible dates and estimated costs to
bo...@foundation.x.org latest by 31th August. An early quick heads-up to
the board if you consider hosting would also be good, in case we need to
adjust the schedule a bit. Also earlier is better since in generally there
will be a bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.

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

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #6 from Francesco Turco  ---
$ glxinfo | grep "renderer string"
couldn't open libtxc_dxtn.so, software DXTn compression/decompression
unavailable
i915_get_shader_param: Unknown cap 28.
i915_get_shader_param: Unknown cap 30.
i915_get_param: Unknown cap 49.
i915_get_param: Unknown cap 119.
i915_get_param: Unknown cap 49.
i915_get_shader_param: Unknown cap 28.
i915_get_shader_param: Unknown cap 30.
i915_get_param: Unknown cap 49.
i915_get_param: Unknown cap 119.
i915_get_param: Unknown cap 49.
i915_get_shader_param: Unknown cap 28.
i915_get_shader_param: Unknown cap 30.
i915_get_param: Unknown cap 49.
i915_get_param: Unknown cap 119.
i915_get_param: Unknown cap 49.
i915_get_shader_param: Unknown cap 28.
i915_get_shader_param: Unknown cap 30.
i915_get_param: Unknown cap 49.
i915_get_param: Unknown cap 119.
i915_get_param: Unknown cap 49.
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
i915_get_shader_param: Unknown cap 28.
i915_get_shader_param: Unknown cap 30.
i915_get_param: Unknown cap 49.
i915_get_param: Unknown cap 119.
i915_get_param: Unknown cap 49.
OpenGL renderer string: Gallium 0.4 on i915 (chipset: Q35)
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
i915_program_error: bad opcode 133
i915_program_error: bad opcode 121
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
i915_get_shader_param: Unknown cap 28.
i915_get_shader_param: Unknown cap 30.
i915_get_param: Unknown cap 49.
i915_get_param: Unknown cap 119.
i915_get_param: Unknown cap 49.

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Pavel Machek]

On Fri 2017-04-21 14:08:04, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > > While working on graphics support for virtual machines on ppc64 (which
> > > > exists in both little and big endian variants) I've figured the comments
> > > > for various drm fourcc formats in the header file don't match reality.
> > > > 
> > > > Comments says the RGB formats are little endian, but in practice they
> > > > are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
> > > > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
> > > > whenever the machine is little endian or big endian.  The users of this
> > > > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> > > > is native endian, not little endian.  Most userspace also operates on
> > > > native endian only.
> > > 
> > > I'm not a fan of "native". Native to what? "CPU" or "host" is what I'd
> > > call it.
> > 
> > native == whatever the cpu is using.
> > 
> > I personally find "native" more intuitive, but at the end of the day I
> > don't mind much.  If people prefer "host" over "native" I'll change it.
> 
> "native" to me feels more like "native to the GPU" since these things
> really are tied to the GPU not the CPU. That's also why I went with the
> explicit endianness originally so that the driver could properly declare
> what the GPU supports.

You can easily have more than one GPU in the system. Plus these are
used by cameras / frame grabbers, too. So anything else than CPU
endianness is badly defined.

(And I agree with the rest of the thread -- we should really be
explicit; fourcc should specify what format the image data are in, and
it should be possible to write fourcc + raw data into file and
transfer it between machines.)


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: [PATCH RFC v2 1/2] drm: Add optinal YCBCR_ENCODING property to drm_plane

[Laurent Pinchart]

Hi Jyri,

On Thursday 11 May 2017 17:30:01 Jyri Sarha wrote:
> On 05/05/17 16:03, Laurent Pinchart wrote:
> > On Friday 05 May 2017 15:11:06 Jyri Sarha wrote:
> >> On 05/05/17 12:07, Laurent Pinchart wrote:
> >>> On Thursday 04 May 2017 10:14:25 Jyri Sarha wrote:
>  Add a standard optinal property to control YCbCr conversion in DRM
>  planes. The property is stored to drm_plane object to allow different
>  set of supported conversion modes for different planes on the device.
>  
>  Signed-off-by: Jyri Sarha 
>  ---
>  
>   drivers/gpu/drm/drm_atomic.c |  5 
>   drivers/gpu/drm/drm_color_mgmt.c | 59 +++
>   drivers/gpu/drm/drm_plane.c  |  3 ++
>   include/drm/drm_color_mgmt.h | 14 ++
>   include/drm/drm_plane.h  |  6 
>   5 files changed, 87 insertions(+)
> >>> 
> >>> [snip]
> >>> 
>  diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>  b/drivers/gpu/drm/drm_color_mgmt.c index 533f3a3..245b14a 100644
>  --- a/drivers/gpu/drm/drm_color_mgmt.c
>  +++ b/drivers/gpu/drm/drm_color_mgmt.c
> >>> 
> >>> [snip]
> >>> 
>  @@ -85,6 +90,13 @@
>    * drm_mode_crtc_set_gamma_size(). Drivers which support both should
>    use
>    * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp
>    with the
>    * "GAMMA_LUT" property above.
>  + *
>  + * The _plane object's properties are:
>  + *
>  + * "YCBCR_ENCODING"
>  + *  Optional plane enum property to control YCbCr to RGB
>  + *  conversion. The driver provides a subset of standard
>  + *  enum values supported by the DRM plane.
>    */
> >>> 
> >>> As already mentioned by Hans Verkuil, I also recommend not mixing the
> >>> encoding and quantization in a single property. If you split them, I
> >>> would then drop the YCBCR_ prefix (or replace it by something more
> >>> generic) at least for the quantization property, as it would apply to
> >>> RGB as well. For the encoding property, we have support in V4L2 for a
> >>> two HSV encodings, so it could make sense to drop or replace the YCBCR_
> >>> prefix, but on the other hand I doubt we'll see any display hardware
> >>> with native support for HSV :-)
> >> 
> >> COLOR_ENCODING? Why not, the YCbCr could then be in the enum names.
> > 
> > Sounds good to me.
> 
> I am now implementing this. However, there is a logical challenge in
> putting the two suggestions together, splitting the encoding and range
> to separate properties, and changing the property names to generic
> COLOR_ENCODING and COLOR_RANGE.
> 
> In general COLOR_RANGE enum values are only defined within the selected
> COLOR_ENCODING. With the standard YCbCr encodings this is not a problem,
> since they all define a "full range" and a "limted range". But if we are
> preparing for some unknown color ecodings, I am not sure how likely it
> is that "full range" and "limited range" options make sense there.
> 
> I can implement the properties for currently known YCbCr color encodings
> either way, either as YCbCr specific properties, or as generic COLOR_*
> properties for all non RGB encodings. I am just not sure if defining the
> generic properties would make any sense now that we (or at least I) have
> no idea what the other non RGB encodings could be. What do you think?

I won't claim to know what quantization methods will make sense for non-YCbCr 
encodings in the future (or, for that matter, even for YCbCr encodings). We 
might even not need any new quantization method. However I don't think this is 
an argument to not standardize a quantization method property. We can start 
with an enumerated property with two values, clearly defined in the API 
documentation as applying to YCbCr only. If and when we'll need quantization 
methods for other encodings, we can just add values to that enumeration. I 
would have proposed to even reuse the enumerated values for a different 
purpose depending on the colour encoding, but as the DRM API exposes 
enumerated values as strings, we unfortunately can't do that.

-- 
Regards,

Laurent Pinchart

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

Re: Re: [Intel-gfx] GPU hang with kernel 4.10rc3

[Pavel Machek]

On Mon 2017-01-23 10:39:27, Juergen Gross wrote:
> On 13/01/17 15:41, Juergen Gross wrote:
> > On 12/01/17 10:21, Chris Wilson wrote:
> >> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> >>> On 11/01/17 18:08, Chris Wilson wrote:
>  On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> > With kernel 4.10rc3 running as Xen dm0 I get at each boot:
> >
> > [   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
> > [1431], reason: Hang on render ring, action: reset
> > [   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
> > gfx stack, including userspace.
> > [   49.213700] [drm] Please file a _new_ bug report on
> > bugs.freedesktop.org against DRI -> DRM/Intel
> > [   49.213700] [drm] drm/i915 developers can then reassign to the right
> > component if it's not a kernel issue.
> > [   49.213700] [drm] The gpu crash dump is required to analyze gpu
> > hangs, so please always attach it.
> > [   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
> > [   49.213755] drm/i915: Resetting chip after gpu hang
> > [   60.213769] drm/i915: Resetting chip after gpu hang
> > [   71.189737] drm/i915: Resetting chip after gpu hang
> > [   82.165747] drm/i915: Resetting chip after gpu hang
> > [   93.205727] drm/i915: Resetting chip after gpu hang
> >
> > The dump is attached.
> 
>  That's a nasty one. The first couple of pages of the batchbuffer appear
>  to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
>  may be a concurrent write by either the GPU or CPU, or we may have
>  incorrected mapped a set of pages. That it doesn't recovered suggests
>  that the corruption occurs frequently, probably on every request/batch.
> >>>
> >>> I hoped someone would have an idea already.
> >>
> >> Sorry, first report of something like this in a long time (that I can
> >> remember at least). And the problem is that it can be anything from a
> >> coherency to a concurrency issue, so no one patch springs to mind.
> >> Thankfully it appears to be kernel related.
> >> -Chris
> >>
> > 
> > Bisecting took longer than I thought, but I had to cherry pick some
> > patches and rebase one of them multiple times...
> > 
> > Finally I found the commit to blame: 920cf4194954ec ("drm/i915:
> > Introduce an internal allocator for disposable private objects")
> > 
> > In case you need me to produce some more data or test a patch
> > feel free to reach out.
> 
> Anything new for this severe regression?
> 
> Without a fix 4.10 will be unusable with Xen on a machine with i915
> graphics!

Did this get solved?

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

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
Francesco there can be two driver for your device. The following command will
show  which one.
$ glxinfo| grep "renderer string"

In either case - these drivers have hardly anyone looking at them, so a simple
test case, or a offending commit considering it's a regression, will be
appreciated.

-- 
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 101011] Shadow of Mordor crashes with mesa from 08.05.2017.

[bugzilla-daemon]

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

Bug ID: 101011
   Summary: Shadow of Mordor crashes with mesa from 08.05.2017.
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: nadro-li...@wp.pl
QA Contact: dri-devel@lists.freedesktop.org

Hello,

Today I installed mesa-git drivers from padoka ppa (drivers from 08.05.2017)
and I see instant crash in Shadow of Mordor after an intro movies (game menu
stage). When I reverted mesa packages to older packages from padoka ppa
(drivers from 02.05.2017) all works fine again.

My platform:
Gnome Ubuntu 17.04 x64
AMD Ryzen 5 1600X
16GB 3200MHz RAM
Radeon R9 380 2GB

BTW. I don't have any logs from terminal, because I don't know how to run this
game directly - no via Steam. When I just run Steam from terminal and SoM from
there I just have logs from Steam...

Best regards,
Patryk

-- 
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 v2 0/7] drm: asynchronous atomic plane update

[Gustavo Padovan]

2017-05-09 Ville Syrjälä :

> On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Hi,
> > 
> > Second take of Asynchronous Plane Updates over Atomic. Here I looked
> > to msm, vc4 and i915 to identify a common pattern to create atomic helpers
> > for async updates. So in patch 1 drm_atomic_async_check() and
> > drm_atomic_helper_async_commit() are introduced along with driver's plane 
> > hooks:
> > ->atomic_async_check() and ->atomic_async_commit().
> > 
> > For now we only support async update for one plane at a time. Also the async
> > update can't modify the CRTC so no modesets are allowed.
> > 
> > Then the other patches add support for it in the drivers. I did virtio 
> > mostly
> > for testing. i915 have been converted and I've been using it without any
> > problem. IGT tests seems to be fine, but there are somewhat random failures
> > with or without the async update changes. msm and vc4 are only 
> > compile-tested.
> > So I think this needs more testing
> > 
> > I started IGT changes to test the Atomic IOCTL with the new flag:
> > 
> > https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/
> 
> BTW I also realized recently that this is probably not going to work
> w.r.t. per-crtc out fences. I know we agrees earlier that the
> "return -1" trick would work, but now that I think about it again,
> I don't think it actually will work when combined with non-blocking
> commits since we can't decide whether to return -1 or a fence
> until the commit has actually been performed.

What we agreed wasn't that the 1st request was going to return the
out-fence and the subsequent requests modifying that request would
return -1. How does that change with non-blocking?

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

[radeon-alex:vega10-drop0509 1707/1987] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:518:10: note: in expansion of macro 'lower_32_bits'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git vega10-drop0509
head:   b97044091f42cad26368a402c31af13e1319c7ab
commit: 3488464228578f9ab9065246e1ec049a78ae0e53 [1707/1987] drm/amdgpu: Add 
Vega10 support for KFD
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 3488464228578f9ab9065246e1ec049a78ae0e53
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:23:0: warning: "pr_fmt" 
redefined
#define pr_fmt(fmt) "kfd2kgd: " fmt

   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/amd/amdgpu/../backport/backport.h:4,
from :0:
   include/linux/printk.h:261:0: note: this is the location of the previous 
definition
#define pr_fmt(fmt) fmt

   In file included from 
drivers/gpu/drm/amd/amdgpu/../backport/include/kcl/kcl_amdgpu.h:5:0,
from drivers/gpu/drm/amd/amdgpu/../backport/backport.h:5,
from :0:
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c: In function 
'kgd_hqd_load':
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:518:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 lower_32_bits((uint64_t)wptr));
   ^
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1741:53: note: in definition of macro 
'WREG32'
#define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 0)
^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:518:10: note: in expansion 
>> of macro 'lower_32_bits'
 lower_32_bits((uint64_t)wptr));
 ^
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:520:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 upper_32_bits((uint64_t)wptr));
   ^
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:1741:53: note: in definition of macro 
'WREG32'
#define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), 0)
^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:520:10: note: in expansion 
>> of macro 'upper_32_bits'
 upper_32_bits((uint64_t)wptr));
 ^

vim +/lower_32_bits +518 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c

   512  
   513  WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_LO),
   514 lower_32_bits(guessed_wptr));
   515  WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI),
   516 upper_32_bits(guessed_wptr));
   517  WREG32(SOC15_REG_OFFSET(GC, 0, 
mmCP_HQD_PQ_WPTR_POLL_ADDR),
 > 518 lower_32_bits((uint64_t)wptr));
   519  WREG32(SOC15_REG_OFFSET(GC, 0, 
mmCP_HQD_PQ_WPTR_POLL_ADDR_HI),
 > 520 upper_32_bits((uint64_t)wptr));
   521  WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1),
   522 get_queue_mask(pipe_id, queue_id));
   523  }

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


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

Re: [PATCH v2 6/7] drm/atmel-hlcdc: Drop custom encoder cleanup func.

[Boris Brezillon]

On Thu, 11 May 2017 11:31:27 -0700
Eric Anholt  wrote:

> drm_encoder_cleanup() finishes with memsetting it to 0, already.
> 
> Signed-off-by: Eric Anholt 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 65a3bd7a0c00..4b2cfbd0d43f 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -83,14 +83,8 @@ static const struct drm_encoder_helper_funcs 
> atmel_hlcdc_panel_encoder_helper_fu
>   .enable = atmel_hlcdc_rgb_encoder_enable,
>  };
>  
> -static void atmel_hlcdc_rgb_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> - memset(encoder, 0, sizeof(*encoder));
> -}
> -
>  static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
> - .destroy = atmel_hlcdc_rgb_encoder_destroy,
> + .destroy = drm_encoder_cleanup,
>  };
>  
>  static int atmel_hlcdc_panel_get_modes(struct drm_connector *connector)

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

Re: [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.

[Boris Brezillon]

Hi Eric,

On Thu, 11 May 2017 11:31:28 -0700
Eric Anholt  wrote:

> This cuts 135 lines of boilerplate, at the cost of losing the
> filtering of get_modes() using atmel_hlcdc_dc_mode_valid().  The
> atomic check will still check that we don't set an invalid mode,
> though.

Nice.

> 
> Signed-off-by: Eric Anholt 

Acked-by: Boris Brezillon 

A few comments below (no need to address them, those are just minor
things that can be fixed later on, or things I'm not comfortable
with but cannot be addressed easily).

> ---
> 
> This patch is just a proposal for atmel-hlcdc if you like it -- maybe
> you still want the filtering of get_modes().  I'm not sure from a
> userspace API perspective if we should really have the encoder (your
> CRTC's limits) filtering modes from a connector, but I'm also pretty
> sure it doesn't actually matter.

Actually I added this check because someone suggested it :-). I don't
think it's a real problem, and that should definitely be checked at the
CRTC level, not here.

> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 163 
> ++-
>  1 file changed, 14 insertions(+), 149 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 4b2cfbd0d43f..340ef962aa81 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -23,191 +23,56 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "atmel_hlcdc_dc.h"
>  
> -/**
> - * Atmel HLCDC RGB connector structure
> - *
> - * This structure stores RGB slave device information.
> - *
> - * @connector: DRM connector
> - * @encoder: DRM encoder
> - * @dc: pointer to the atmel_hlcdc_dc structure
> - * @panel: panel connected on the RGB output
> - */
> -struct atmel_hlcdc_rgb_output {
> - struct drm_connector connector;
> - struct drm_encoder encoder;
> - struct atmel_hlcdc_dc *dc;
> - struct drm_panel *panel;
> -};
> -
> -static inline struct atmel_hlcdc_rgb_output *
> -drm_connector_to_atmel_hlcdc_rgb_output(struct drm_connector *connector)
> -{
> - return container_of(connector, struct atmel_hlcdc_rgb_output,
> - connector);
> -}
> -
> -static inline struct atmel_hlcdc_rgb_output *
> -drm_encoder_to_atmel_hlcdc_rgb_output(struct drm_encoder *encoder)
> -{
> - return container_of(encoder, struct atmel_hlcdc_rgb_output, encoder);
> -}
> -
> -static void atmel_hlcdc_rgb_encoder_enable(struct drm_encoder *encoder)
> -{
> - struct atmel_hlcdc_rgb_output *rgb =
> - drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
> -
> - if (rgb->panel) {
> - drm_panel_prepare(rgb->panel);
> - drm_panel_enable(rgb->panel);
> - }
> -}
> -
> -static void atmel_hlcdc_rgb_encoder_disable(struct drm_encoder *encoder)
> -{
> - struct atmel_hlcdc_rgb_output *rgb =
> - drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
> -
> - if (rgb->panel) {
> - drm_panel_disable(rgb->panel);
> - drm_panel_unprepare(rgb->panel);
> - }
> -}
> -
> -static const struct drm_encoder_helper_funcs 
> atmel_hlcdc_panel_encoder_helper_funcs = {
> - .disable = atmel_hlcdc_rgb_encoder_disable,
> - .enable = atmel_hlcdc_rgb_encoder_enable,
> -};
> -
>  static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
>   .destroy = drm_encoder_cleanup,
>  };
>  
> -static int atmel_hlcdc_panel_get_modes(struct drm_connector *connector)
> -{
> - struct atmel_hlcdc_rgb_output *rgb =
> - drm_connector_to_atmel_hlcdc_rgb_output(connector);
> -
> - if (rgb->panel)
> - return rgb->panel->funcs->get_modes(rgb->panel);
> -
> - return 0;
> -}
> -
> -static int atmel_hlcdc_rgb_mode_valid(struct drm_connector *connector,
> -   struct drm_display_mode *mode)
> -{
> - struct atmel_hlcdc_rgb_output *rgb =
> - drm_connector_to_atmel_hlcdc_rgb_output(connector);
> -
> - return atmel_hlcdc_dc_mode_valid(rgb->dc, mode);
> -}
> -
> -static const struct drm_connector_helper_funcs 
> atmel_hlcdc_panel_connector_helper_funcs = {
> - .get_modes = atmel_hlcdc_panel_get_modes,
> - .mode_valid = atmel_hlcdc_rgb_mode_valid,
> -};
> -
> -static enum drm_connector_status
> -atmel_hlcdc_panel_connector_detect(struct drm_connector *connector, bool 
> force)
> -{
> - struct atmel_hlcdc_rgb_output *rgb =
> - drm_connector_to_atmel_hlcdc_rgb_output(connector);
> -
> - if (rgb->panel)
> - return connector_status_connected;
> -
> - return connector_status_disconnected;
> -}
> -
> -static void
> -atmel_hlcdc_panel_connector_destroy(struct drm_connector *connector)
> -{
> - struct atmel_hlcdc_rgb_output *rgb =
> - 

[PATCH 7/8] drm: remove unsafe drm_for_each_connector()

[Gustavo Padovan]

From: Gustavo Padovan 

After converting all users to drm_for_each_connector_iter() we no
longer need drm_for_each_connector() so we can go ahead and remove it.

Signed-off-by: Gustavo Padovan 
---
 include/drm/drm_connector.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4eeda12..ffb8ec1 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -989,21 +989,6 @@ void drm_mode_put_tile_group(struct drm_device *dev,
 struct drm_tile_group *tg);
 
 /**
- * drm_for_each_connector - iterate over all connectors
- * @connector: the loop cursor
- * @dev: the DRM device
- *
- * Iterate over all connectors of @dev.
- *
- * WARNING:
- *
- * This iterator is not safe against hotadd/removal of connectors and is
- * deprecated. Use drm_for_each_connector_iter() instead.
- */
-#define drm_for_each_connector(connector, dev) \
-   list_for_each_entry(connector, &(dev)->mode_config.connector_list, head)
-
-/**
  * struct drm_connector_list_iter - connector_list iterator
  *
  * This iterator tracks state needed to be able to walk the connector_list
-- 
2.9.3

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

[PATCH 4/8] drm/mediatek: use drm_for_each_connector_iter()

[Gustavo Padovan]

From: Gustavo Padovan 

Drop legacy drm_for_each_connector() in favor of the race-free
drm_for_each_connector_iter().

Cc: Philipp Zabel 
Signed-off-by: Gustavo Padovan 

---
only built-tested!
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 6b08774..6582e1f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -221,6 +221,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
struct drm_crtc *crtc = _crtc->base;
struct drm_connector *connector;
struct drm_encoder *encoder;
+   struct drm_connector_list_iter conn_iter;
unsigned int width, height, vrefresh, bpc = MTK_MAX_BPC;
int ret;
int i;
@@ -237,13 +238,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
if (encoder->crtc != crtc)
continue;
 
-   drm_for_each_connector(connector, crtc->dev) {
+   drm_connector_list_iter_begin(crtc->dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->encoder != encoder)
continue;
if (connector->display_info.bpc != 0 &&
bpc > connector->display_info.bpc)
bpc = connector->display_info.bpc;
}
+   drm_connector_list_iter_end(_iter);
}
 
ret = pm_runtime_get_sync(crtc->dev->dev);
-- 
2.9.3

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

[PATCH 6/8] drm/vc4: use drm_for_each_connector_iter()

[Gustavo Padovan]

From: Gustavo Padovan 

Drop legacy drm_for_each_connector() in favor of the race-free
drm_for_each_connector_iter().

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 

---
only built-tested!
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index d86c8cc..feee83a 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -359,12 +359,15 @@ static u32 vc4_get_fifo_full_level(u32 format)
 static struct drm_encoder *vc4_get_crtc_encoder(struct drm_crtc *crtc)
 {
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
-   drm_for_each_connector(connector, crtc->dev) {
+   drm_connector_list_iter_begin(crtc->dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->state->crtc == crtc) {
return connector->encoder;
}
}
+   drm_connector_list_iter_end(_iter);
 
return NULL;
 }
-- 
2.9.3

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

[PATCH 8/8] drm: todo: remove task about switch to drm_connector_list_iter

[Gustavo Padovan]

From: Gustavo Padovan 

This is now completed.

Signed-off-by: Gustavo Padovan 
---
 Documentation/gpu/todo.rst | 13 -
 1 file changed, 13 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 1bdb735..95a5170 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -177,19 +177,6 @@ following drivers still use ``struct_mutex``: ``msm``, 
``omapdrm`` and
 
 Contact: Daniel Vetter, respective driver maintainers
 
-Switch to drm_connector_list_iter for any connector_list walking
-
-
-Connectors can be hotplugged, and we now have a special list of helpers to walk
-the connector_list in a race-free fashion, without incurring deadlocks on
-mutexes and other fun stuff.
-
-Unfortunately most drivers are not converted yet. At least all those supporting
-DP MST hotplug should be converted, since for those drivers the difference
-matters. See drm_for_each_connector_iter() vs. drm_for_each_connector().
-
-Contact: Daniel Vetter
-
 Core refactorings
 =
 
-- 
2.9.3

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

[PATCH 5/8] drm/nouveau: use drm_for_each_connector_iter()

[Gustavo Padovan]

From: Gustavo Padovan 

Drop legacy drm_for_each_connector() in favor of the race-free
drm_for_each_connector_iter().

Cc: Ben Skeggs 
Signed-off-by: Gustavo Padovan 

---
only built-tested!
---
 drivers/gpu/drm/nouveau/nv50_display.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 0e58537..8790bdc 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -2871,17 +2871,20 @@ nv50_msto_enable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = NULL;
struct nv50_mstm *mstm = NULL;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
u8 proto, depth;
int slots;
bool r;
 
-   drm_for_each_connector(connector, encoder->dev) {
+   drm_connector_list_iter_begin(encoder->dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->state->best_encoder == >encoder) {
mstc = nv50_mstc(connector);
mstm = mstc->mstm;
break;
}
}
+   drm_connector_list_iter_end(_iter);
 
if (WARN_ON(!mstc))
return;
-- 
2.9.3

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

[PATCH 1/8] drm/exynos: use drm_for_each_connector_iter()

[Gustavo Padovan]

From: Gustavo Padovan 

Drop legacy drm_for_each_connector() in favor of the race-free
drm_for_each_connector_iter()

Cc: Inki Dae 
Cc: Joonyoung Shim 
Signed-off-by: Gustavo Padovan 

---
only built-tested!
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d3c4c..db6ef2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -177,12 +177,13 @@ static int exynos_drm_suspend(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
-   drm_modeset_lock_all(drm_dev);
-   drm_for_each_connector(connector, drm_dev) {
+   drm_connector_list_iter_begin(drm_dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
int old_dpms = connector->dpms;
 
if (connector->funcs->dpms)
@@ -191,7 +192,7 @@ static int exynos_drm_suspend(struct device *dev)
/* Set the old mode back to the connector for resume */
connector->dpms = old_dpms;
}
-   drm_modeset_unlock_all(drm_dev);
+   drm_connector_list_iter_end(_iter);
 
return 0;
 }
@@ -200,12 +201,13 @@ static int exynos_drm_resume(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
 
-   drm_modeset_lock_all(drm_dev);
-   drm_for_each_connector(connector, drm_dev) {
+   drm_connector_list_iter_begin(drm_dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->funcs->dpms) {
int dpms = connector->dpms;
 
@@ -213,7 +215,7 @@ static int exynos_drm_resume(struct device *dev)
connector->funcs->dpms(connector, dpms);
}
}
-   drm_modeset_unlock_all(drm_dev);
+   drm_connector_list_iter_end(_iter);
 
return 0;
 }
-- 
2.9.3

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

[PATCH 3/8] drm/i915: use drm_for_each_connector_iter()

[Gustavo Padovan]

From: Gustavo Padovan 

Drop legacy drm_for_each_connector() in favor of the race-free
drm_for_each_connector_iter().

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3617927..207f144 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11216,6 +11216,7 @@ static bool check_digital_port_conflicts(struct 
drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
unsigned int used_ports = 0;
unsigned int used_mst_ports = 0;
 
@@ -11224,7 +11225,8 @@ static bool check_digital_port_conflicts(struct 
drm_atomic_state *state)
 * list to detect the problem on ddi platforms
 * where there's just one encoder per digital port.
 */
-   drm_for_each_connector(connector, dev) {
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
struct drm_connector_state *connector_state;
struct intel_encoder *encoder;
 
@@ -11263,6 +11265,7 @@ static bool check_digital_port_conflicts(struct 
drm_atomic_state *state)
break;
}
}
+   drm_connector_list_iter_end(_iter);
 
/* can't mix MST and SST/HDMI on the same port */
if (used_ports & used_mst_ports)
-- 
2.9.3

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

[PATCH 2/8] drm/rockchip: use drm_for_each_connector_iter()

[Gustavo Padovan]

From: Gustavo Padovan 

Drop legacy drm_for_each_connector() in favor of the race-free
drm_for_each_connector_iter()

Cc: Mark Yao 
Signed-off-by: Gustavo Padovan 

---
only built-tested!
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 40a5e6e..4f042ab 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1118,16 +1118,16 @@ static void vop_crtc_destroy_state(struct drm_crtc 
*crtc,
 #ifdef CONFIG_DRM_ANALOGIX_DP
 static struct drm_connector *vop_get_edp_connector(struct vop *vop)
 {
-   struct drm_crtc *crtc = >crtc;
struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
 
-   mutex_lock(>dev->mode_config.mutex);
-   drm_for_each_connector(connector, crtc->dev)
+   drm_connector_list_iter_begin(vop->drm_dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
-   mutex_unlock(>dev->mode_config.mutex);
+   drm_connector_list_iter_end(_iter);
return connector;
}
-   mutex_unlock(>dev->mode_config.mutex);
+   drm_connector_list_iter_end(_iter);
 
return NULL;
 }
-- 
2.9.3

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

[PATCH 0/8] remove unsafe drm_for_each_connector()

[Gustavo Padovan]

From: Gustavo Padovan 

Hi all,

Something ligth in the middle of all my other tasks. I removed
drm_for_each_connector() in favor of drm_for_each_connector_iter().

The i915 patch was tested, but I only *built-tested* the others!

Gustavo

---
Gustavo Padovan (8):
  drm/exynos: use drm_for_each_connector_iter()
  drm/rockchip: use drm_for_each_connector_iter()
  drm/i915: use drm_for_each_connector_iter()
  drm/mediatek: use drm_for_each_connector_iter()
  drm/nouveau: use drm_for_each_connector_iter()
  drm/vc4: use drm_for_each_connector_iter()
  drm: remove unsafe drm_for_each_connector()
  drm: todo: remove task about switch to drm_connector_list_iter

 Documentation/gpu/todo.rst  | 13 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
 drivers/gpu/drm/i915/intel_display.c|  5 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  5 -
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 +-
 drivers/gpu/drm/vc4/vc4_crtc.c  |  5 -
 include/drm/drm_connector.h | 15 ---
 8 files changed, 29 insertions(+), 43 deletions(-)

-- 
2.9.3

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

[radeon-alex:vega10-drop0509 1381/1987] drivers/gpu/drm/radeon/radeon_kfd.c:1426:32: warning: cast to pointer from integer of different size

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git vega10-drop0509
head:   b97044091f42cad26368a402c31af13e1319c7ab
commit: 8e8443a9512d6794e1715bad20dad1fd2e6cd045 [1381/1987] radeon_kfd.c copied
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 8e8443a9512d6794e1715bad20dad1fd2e6cd045
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/radeon/radeon_kfd.c: In function 
'get_pdd_from_buffer_object':
   drivers/gpu/drm/radeon/radeon_kfd.c:219:22: error: 'struct radeon_bo' has no 
member named 'pdd'; did you mean 'pid'?
 return mem->data2.bo->pdd;
 ^~
   drivers/gpu/drm/radeon/radeon_kfd.c: In function 'open_graphic_handle':
   drivers/gpu/drm/radeon/radeon_kfd.c:516:34: error: passing argument 1 of 
'drm_gem_object_lookup' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle);
 ^~~~
   In file included from drivers/gpu/drm/radeon/radeon.h:77:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
   include/drm/drm_gem.h:241:24: note: expected 'struct drm_file *' but 
argument is of type 'struct drm_device *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 
handle);
   ^
   drivers/gpu/drm/radeon/radeon_kfd.c:516:46: warning: passing argument 2 of 
'drm_gem_object_lookup' makes integer from pointer without a cast 
[-Wint-conversion]
 gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle);
 ^~~~
   In file included from drivers/gpu/drm/radeon/radeon.h:77:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
   include/drm/drm_gem.h:241:24: note: expected 'u32 {aka unsigned int}' but 
argument is of type 'void *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 
handle);
   ^
   drivers/gpu/drm/radeon/radeon_kfd.c:516:12: error: too many arguments to 
function 'drm_gem_object_lookup'
 gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle);
   ^
   In file included from drivers/gpu/drm/radeon/radeon.h:77:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
   include/drm/drm_gem.h:241:24: note: declared here
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 
handle);
   ^
   drivers/gpu/drm/radeon/radeon_kfd.c: In function 'map_bo_to_gpuvm':
   drivers/gpu/drm/radeon/radeon_kfd.c:1271:9: error: too many arguments to 
function 'ttm_bo_wait'
  ret = ttm_bo_wait(>tbo, true, false, false);
^~~
   In file included from drivers/gpu/drm/radeon/radeon.h:71:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
   include/drm/ttm/ttm_bo_api.h:292:12: note: declared here
extern int ttm_bo_wait(struct ttm_buffer_object *bo,
   ^~~
   drivers/gpu/drm/radeon/radeon_kfd.c: In function 'write_config_static_mem':
   drivers/gpu/drm/radeon/radeon_kfd.c:1368:26: error: 
'SH_STATIC_MEM_CONFIG__SWIZZLE_ENABLE__SHIFT' undeclared (first use in this 
function)
 reg = swizzle_enable << SH_STATIC_MEM_CONFIG__SWIZZLE_ENABLE__SHIFT |
 ^~~
   drivers/gpu/drm/radeon/radeon_kfd.c:1368:26: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu/drm/radeon/radeon_kfd.c:1369:19: error: 
'SH_STATIC_MEM_CONFIG__ELEMENT_SIZE__SHIFT' undeclared (first use in this 
function)
  element_size << SH_STATIC_MEM_CONFIG__ELEMENT_SIZE__SHIFT |
  ^
   drivers/gpu/drm/radeon/radeon_kfd.c:1370:19: error: 
'SH_STATIC_MEM_CONFIG__INDEX_STRIDE__SHIFT' undeclared (first use in this 
function)
  index_stride << SH_STATIC_MEM_CONFIG__INDEX_STRIDE__SHIFT |
  ^
   drivers/gpu/drm/radeon/radeon_kfd.c:1371:19: error: 
'SH_STATIC_MEM_CONFIG__PRIVATE_MTYPE__SHIFT' undeclared (first use in this 
function)
  index_stride << SH_STATIC_MEM_CONFIG__PRIVATE_MTYPE__SHIFT;
  ^~
   In file included from drivers/gpu/drm/radeon/radeon_kfd.c:27:0:
   drivers/gpu/drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_scratch':
   drivers/gpu/drm/radeon/radeon_kfd.c:1382:9: error: 
'SH_HIDDEN_PRIVATE_BASE_VMID' undeclared (first use in this function)
 WREG32(SH_HIDDEN_PRIVATE_BASE_VMID, va);
^
   drivers/gpu/drm/radeon/radeon.h:2541:44: note: in definition of macro 
'WREG32'
#define WREG32(reg, v) 

[PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.

[Eric Anholt]

This cuts 135 lines of boilerplate, at the cost of losing the
filtering of get_modes() using atmel_hlcdc_dc_mode_valid().  The
atomic check will still check that we don't set an invalid mode,
though.

Signed-off-by: Eric Anholt 
---

This patch is just a proposal for atmel-hlcdc if you like it -- maybe
you still want the filtering of get_modes().  I'm not sure from a
userspace API perspective if we should really have the encoder (your
CRTC's limits) filtering modes from a connector, but I'm also pretty
sure it doesn't actually matter.

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 163 ++-
 1 file changed, 14 insertions(+), 149 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 4b2cfbd0d43f..340ef962aa81 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -23,191 +23,56 @@
 
 #include 
 #include 
+#include 
 
 #include "atmel_hlcdc_dc.h"
 
-/**
- * Atmel HLCDC RGB connector structure
- *
- * This structure stores RGB slave device information.
- *
- * @connector: DRM connector
- * @encoder: DRM encoder
- * @dc: pointer to the atmel_hlcdc_dc structure
- * @panel: panel connected on the RGB output
- */
-struct atmel_hlcdc_rgb_output {
-   struct drm_connector connector;
-   struct drm_encoder encoder;
-   struct atmel_hlcdc_dc *dc;
-   struct drm_panel *panel;
-};
-
-static inline struct atmel_hlcdc_rgb_output *
-drm_connector_to_atmel_hlcdc_rgb_output(struct drm_connector *connector)
-{
-   return container_of(connector, struct atmel_hlcdc_rgb_output,
-   connector);
-}
-
-static inline struct atmel_hlcdc_rgb_output *
-drm_encoder_to_atmel_hlcdc_rgb_output(struct drm_encoder *encoder)
-{
-   return container_of(encoder, struct atmel_hlcdc_rgb_output, encoder);
-}
-
-static void atmel_hlcdc_rgb_encoder_enable(struct drm_encoder *encoder)
-{
-   struct atmel_hlcdc_rgb_output *rgb =
-   drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
-
-   if (rgb->panel) {
-   drm_panel_prepare(rgb->panel);
-   drm_panel_enable(rgb->panel);
-   }
-}
-
-static void atmel_hlcdc_rgb_encoder_disable(struct drm_encoder *encoder)
-{
-   struct atmel_hlcdc_rgb_output *rgb =
-   drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
-
-   if (rgb->panel) {
-   drm_panel_disable(rgb->panel);
-   drm_panel_unprepare(rgb->panel);
-   }
-}
-
-static const struct drm_encoder_helper_funcs 
atmel_hlcdc_panel_encoder_helper_funcs = {
-   .disable = atmel_hlcdc_rgb_encoder_disable,
-   .enable = atmel_hlcdc_rgb_encoder_enable,
-};
-
 static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
-static int atmel_hlcdc_panel_get_modes(struct drm_connector *connector)
-{
-   struct atmel_hlcdc_rgb_output *rgb =
-   drm_connector_to_atmel_hlcdc_rgb_output(connector);
-
-   if (rgb->panel)
-   return rgb->panel->funcs->get_modes(rgb->panel);
-
-   return 0;
-}
-
-static int atmel_hlcdc_rgb_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
-   struct atmel_hlcdc_rgb_output *rgb =
-   drm_connector_to_atmel_hlcdc_rgb_output(connector);
-
-   return atmel_hlcdc_dc_mode_valid(rgb->dc, mode);
-}
-
-static const struct drm_connector_helper_funcs 
atmel_hlcdc_panel_connector_helper_funcs = {
-   .get_modes = atmel_hlcdc_panel_get_modes,
-   .mode_valid = atmel_hlcdc_rgb_mode_valid,
-};
-
-static enum drm_connector_status
-atmel_hlcdc_panel_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct atmel_hlcdc_rgb_output *rgb =
-   drm_connector_to_atmel_hlcdc_rgb_output(connector);
-
-   if (rgb->panel)
-   return connector_status_connected;
-
-   return connector_status_disconnected;
-}
-
-static void
-atmel_hlcdc_panel_connector_destroy(struct drm_connector *connector)
-{
-   struct atmel_hlcdc_rgb_output *rgb =
-   drm_connector_to_atmel_hlcdc_rgb_output(connector);
-
-   if (rgb->panel)
-   drm_panel_detach(rgb->panel);
-
-   drm_connector_cleanup(connector);
-}
-
-static const struct drm_connector_funcs atmel_hlcdc_panel_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .detect = atmel_hlcdc_panel_connector_detect,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = atmel_hlcdc_panel_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 int 

[PATCH v2 6/7] drm/atmel-hlcdc: Drop custom encoder cleanup func.

[Eric Anholt]

drm_encoder_cleanup() finishes with memsetting it to 0, already.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 65a3bd7a0c00..4b2cfbd0d43f 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -83,14 +83,8 @@ static const struct drm_encoder_helper_funcs 
atmel_hlcdc_panel_encoder_helper_fu
.enable = atmel_hlcdc_rgb_encoder_enable,
 };
 
-static void atmel_hlcdc_rgb_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-   memset(encoder, 0, sizeof(*encoder));
-}
-
 static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
-   .destroy = atmel_hlcdc_rgb_encoder_destroy,
+   .destroy = drm_encoder_cleanup,
 };
 
 static int atmel_hlcdc_panel_get_modes(struct drm_connector *connector)
-- 
2.11.0

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

[PATCH v2 5/7] drm/ltdc: Use the panel-bridge helper.

[Eric Anholt]

Another 100 lines of boilerplate gone.  Bridges aren't supported yet,
but will be trivial to add later.

Signed-off-by: Eric Anholt 
---

Also untested.

 drivers/gpu/drm/stm/ltdc.c | 128 +
 drivers/gpu/drm/stm/ltdc.h |   2 +-
 2 files changed, 13 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index a40418cda74a..41a1c5d68f5b 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -269,11 +269,6 @@ static inline struct ltdc_device *encoder_to_ltdc(struct 
drm_encoder *enc)
return (struct ltdc_device *)enc->dev->dev_private;
 }
 
-static inline struct ltdc_device *connector_to_ltdc(struct drm_connector *con)
-{
-   return (struct ltdc_device *)con->dev->dev_private;
-}
-
 static inline enum ltdc_pix_fmt to_ltdc_pixelformat(u32 drm_fmt)
 {
enum ltdc_pix_fmt pf;
@@ -815,22 +810,12 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct 
drm_crtc *crtc)
 
 static void ltdc_rgb_encoder_enable(struct drm_encoder *encoder)
 {
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_prepare(ldev->panel);
-   drm_panel_enable(ldev->panel);
 }
 
 static void ltdc_rgb_encoder_disable(struct drm_encoder *encoder)
 {
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_disable(ldev->panel);
-   drm_panel_unprepare(ldev->panel);
 }
 
 static const struct drm_encoder_helper_funcs ltdc_rgb_encoder_helper_funcs = {
@@ -863,82 +848,6 @@ static struct drm_encoder *ltdc_rgb_encoder_create(struct 
drm_device *ddev)
return encoder;
 }
 
-/*
- * DRM_CONNECTOR
- */
-
-static int ltdc_rgb_connector_get_modes(struct drm_connector *connector)
-{
-   struct drm_device *ddev = connector->dev;
-   struct ltdc_device *ldev = ddev->dev_private;
-   int ret = 0;
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (ldev->panel)
-   ret = drm_panel_get_modes(ldev->panel);
-
-   return ret < 0 ? 0 : ret;
-}
-
-static struct drm_connector_helper_funcs ltdc_rgb_connector_helper_funcs = {
-   .get_modes = ltdc_rgb_connector_get_modes,
-};
-
-static enum drm_connector_status
-ltdc_rgb_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct ltdc_device *ldev = connector_to_ltdc(connector);
-
-   return ldev->panel ? connector_status_connected :
-  connector_status_disconnected;
-}
-
-static void ltdc_rgb_connector_destroy(struct drm_connector *connector)
-{
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static const struct drm_connector_funcs ltdc_rgb_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .detect = ltdc_rgb_connector_detect,
-   .destroy = ltdc_rgb_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,
-};
-
-struct drm_connector *ltdc_rgb_connector_create(struct drm_device *ddev)
-{
-   struct drm_connector *connector;
-   int err;
-
-   connector = devm_kzalloc(ddev->dev, sizeof(*connector), GFP_KERNEL);
-   if (!connector) {
-   DRM_ERROR("Failed to allocate connector\n");
-   return NULL;
-   }
-
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
-
-   err = drm_connector_init(ddev, connector, _rgb_connector_funcs,
-DRM_MODE_CONNECTOR_DPI);
-   if (err) {
-   DRM_ERROR("Failed to initialize connector\n");
-   return NULL;
-   }
-
-   drm_connector_helper_add(connector, _rgb_connector_helper_funcs);
-
-   DRM_DEBUG_DRIVER("RGB connector:%d created\n", connector->base.id);
-
-   return connector;
-}
-
 static int ltdc_get_caps(struct drm_device *ddev)
 {
struct ltdc_device *ldev = ddev->dev_private;
@@ -972,7 +881,7 @@ static int ltdc_get_caps(struct drm_device *ddev)
return 0;
 }
 
-static struct drm_panel *ltdc_get_panel(struct drm_device *ddev)
+static struct drm_bridge *ltdc_get_bridge(struct drm_device *ddev)
 {
struct device *dev = ddev->dev;
struct device_node *np = dev->of_node;
@@ -1004,7 +913,10 @@ static struct drm_panel *ltdc_get_panel(struct drm_device 
*ddev)
}
}
 
-   return panel;
+   if (!panel)
+   return ERR_PTR(-ENODEV);
+
+   return drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
 }
 
 int ltdc_load(struct drm_device *ddev)
@@ -1014,7 +926,6 @@ int ltdc_load(struct drm_device *ddev)
struct device *dev = ddev->dev;
struct device_node *np = dev->of_node;
struct drm_encoder *encoder;
- 

[PATCH v2 2/7] drm/vc4: Switch DSI to the panel-bridge layer, and support bridges.

[Eric Anholt]

The newer version of the RPi panel driver is going to be a combination
of a bridge and a panel, but we should also support panels without a
bridge, so the panel-bridge layer lets us do that cleanly.

v2: Drop "dev" argument.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/vc4/Kconfig   |   2 +-
 drivers/gpu/drm/vc4/vc4_dsi.c | 154 ++
 2 files changed, 21 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index b16aefe4a8d3..4361bdcfd28a 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -7,7 +7,7 @@ config DRM_VC4
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-   select DRM_PANEL
+   select DRM_PANEL_BRIDGE
select SND_PCM
select SND_PCM_ELD
select SND_SOC_GENERIC_DMAENGINE_PCM
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index deba62008fd0..fb54a9d10360 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -503,8 +503,8 @@ struct vc4_dsi {
 
struct mipi_dsi_host dsi_host;
struct drm_encoder *encoder;
-   struct drm_connector *connector;
-   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   bool is_panel_bridge;
 
void __iomem *regs;
 
@@ -604,18 +604,6 @@ to_vc4_dsi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_dsi_encoder, base.base);
 }
 
-/* VC4 DSI connector KMS struct */
-struct vc4_dsi_connector {
-   struct drm_connector base;
-   struct vc4_dsi *dsi;
-};
-
-static inline struct vc4_dsi_connector *
-to_vc4_dsi_connector(struct drm_connector *connector)
-{
-   return container_of(connector, struct vc4_dsi_connector, base);
-}
-
 #define DSI_REG(reg) { reg, #reg }
 static const struct {
u32 reg;
@@ -723,79 +711,6 @@ int vc4_dsi_debugfs_regs(struct seq_file *m, void *unused)
 }
 #endif
 
-static enum drm_connector_status
-vc4_dsi_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct vc4_dsi_connector *vc4_connector =
-   to_vc4_dsi_connector(connector);
-   struct vc4_dsi *dsi = vc4_connector->dsi;
-
-   if (dsi->panel)
-   return connector_status_connected;
-   else
-   return connector_status_disconnected;
-}
-
-static void vc4_dsi_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static int vc4_dsi_connector_get_modes(struct drm_connector *connector)
-{
-   struct vc4_dsi_connector *vc4_connector =
-   to_vc4_dsi_connector(connector);
-   struct vc4_dsi *dsi = vc4_connector->dsi;
-
-   if (dsi->panel)
-   return drm_panel_get_modes(dsi->panel);
-
-   return 0;
-}
-
-static const struct drm_connector_funcs vc4_dsi_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .detect = vc4_dsi_connector_detect,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = vc4_dsi_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 const struct drm_connector_helper_funcs vc4_dsi_connector_helper_funcs 
= {
-   .get_modes = vc4_dsi_connector_get_modes,
-};
-
-static struct drm_connector *vc4_dsi_connector_init(struct drm_device *dev,
-   struct vc4_dsi *dsi)
-{
-   struct drm_connector *connector;
-   struct vc4_dsi_connector *dsi_connector;
-
-   dsi_connector = devm_kzalloc(dev->dev, sizeof(*dsi_connector),
-GFP_KERNEL);
-   if (!dsi_connector)
-   return ERR_PTR(-ENOMEM);
-
-   connector = _connector->base;
-
-   dsi_connector->dsi = dsi;
-
-   drm_connector_init(dev, connector, _dsi_connector_funcs,
-  DRM_MODE_CONNECTOR_DSI);
-   drm_connector_helper_add(connector, _dsi_connector_helper_funcs);
-
-   connector->polled = 0;
-   connector->interlace_allowed = 0;
-   connector->doublescan_allowed = 0;
-
-   drm_mode_connector_attach_encoder(connector, dsi->encoder);
-
-   return connector;
-}
-
 static void vc4_dsi_encoder_destroy(struct drm_encoder *encoder)
 {
drm_encoder_cleanup(encoder);
@@ -893,12 +808,8 @@ static void vc4_dsi_encoder_disable(struct drm_encoder 
*encoder)
struct vc4_dsi *dsi = vc4_encoder->dsi;
struct device *dev = >pdev->dev;
 
-   drm_panel_disable(dsi->panel);
-
vc4_dsi_ulps(dsi, true);
 
-   drm_panel_unprepare(dsi->panel);
-
clk_disable_unprepare(dsi->pll_phy_clock);

[PATCH v2 3/7] drm/vc4: Switch DPI to using the panel-bridge helper.

[Eric Anholt]

Another 100 lines of boilerplate gone, while allowing for bridges to
be connected in the display chain.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dpi.c | 164 --
 1 file changed, 30 insertions(+), 134 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c6d703903fd9..98532e2cd2b7 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -23,8 +23,10 @@
  */
 
 #include "drm_atomic_helper.h"
+#include "drm_bridge.h"
 #include "drm_crtc_helper.h"
 #include "drm_edid.h"
+#include "drm_of.h"
 #include "drm_panel.h"
 #include "linux/clk.h"
 #include "linux/component.h"
@@ -95,7 +97,8 @@ struct vc4_dpi {
 
struct drm_encoder *encoder;
struct drm_connector *connector;
-   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   bool is_panel_bridge;
 
void __iomem *regs;
 
@@ -118,24 +121,6 @@ to_vc4_dpi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_dpi_encoder, base.base);
 }
 
-/* VC4 DPI connector KMS struct */
-struct vc4_dpi_connector {
-   struct drm_connector base;
-   struct vc4_dpi *dpi;
-
-   /* Since the connector is attached to just the one encoder,
-* this is the reference to it so we can do the best_encoder()
-* hook.
-*/
-   struct drm_encoder *encoder;
-};
-
-static inline struct vc4_dpi_connector *
-to_vc4_dpi_connector(struct drm_connector *connector)
-{
-   return container_of(connector, struct vc4_dpi_connector, base);
-}
-
 #define DPI_REG(reg) { reg, #reg }
 static const struct {
u32 reg;
@@ -167,80 +152,6 @@ int vc4_dpi_debugfs_regs(struct seq_file *m, void *unused)
 }
 #endif
 
-static enum drm_connector_status
-vc4_dpi_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct vc4_dpi_connector *vc4_connector =
-   to_vc4_dpi_connector(connector);
-   struct vc4_dpi *dpi = vc4_connector->dpi;
-
-   if (dpi->panel)
-   return connector_status_connected;
-   else
-   return connector_status_disconnected;
-}
-
-static void vc4_dpi_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static int vc4_dpi_connector_get_modes(struct drm_connector *connector)
-{
-   struct vc4_dpi_connector *vc4_connector =
-   to_vc4_dpi_connector(connector);
-   struct vc4_dpi *dpi = vc4_connector->dpi;
-
-   if (dpi->panel)
-   return drm_panel_get_modes(dpi->panel);
-
-   return 0;
-}
-
-static const struct drm_connector_funcs vc4_dpi_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .detect = vc4_dpi_connector_detect,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = vc4_dpi_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 const struct drm_connector_helper_funcs vc4_dpi_connector_helper_funcs 
= {
-   .get_modes = vc4_dpi_connector_get_modes,
-};
-
-static struct drm_connector *vc4_dpi_connector_init(struct drm_device *dev,
-   struct vc4_dpi *dpi)
-{
-   struct drm_connector *connector = NULL;
-   struct vc4_dpi_connector *dpi_connector;
-
-   dpi_connector = devm_kzalloc(dev->dev, sizeof(*dpi_connector),
-GFP_KERNEL);
-   if (!dpi_connector)
-   return ERR_PTR(-ENOMEM);
-
-   connector = _connector->base;
-
-   dpi_connector->encoder = dpi->encoder;
-   dpi_connector->dpi = dpi;
-
-   drm_connector_init(dev, connector, _dpi_connector_funcs,
-  DRM_MODE_CONNECTOR_DPI);
-   drm_connector_helper_add(connector, _dpi_connector_helper_funcs);
-
-   connector->polled = 0;
-   connector->interlace_allowed = 0;
-   connector->doublescan_allowed = 0;
-
-   drm_mode_connector_attach_encoder(connector, dpi->encoder);
-
-   return connector;
-}
-
 static const struct drm_encoder_funcs vc4_dpi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
@@ -250,11 +161,7 @@ static void vc4_dpi_encoder_disable(struct drm_encoder 
*encoder)
struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
struct vc4_dpi *dpi = vc4_encoder->dpi;
 
-   drm_panel_disable(dpi->panel);
-
clk_disable_unprepare(dpi->pixel_clock);
-
-   drm_panel_unprepare(dpi->panel);
 }
 
 static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
@@ -265,12 +172,6 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
*encoder)
u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
int ret;
 
-   ret = 

[PATCH v2 1/7] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Eric Anholt]

Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel.  By wrapping the panel in a DRM
bridge, all of the connector code (including calls during encoder
enable/disable) goes away.

v2: Fix build with CONFIG_DRM=m, drop "dev" argument that should just
be the panel's dev, move kerneldoc up a level and document
_remove().

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |   6 ++
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/bridge/Kconfig|  11 +-
 drivers/gpu/drm/bridge/lvds-encoder.c | 157 ---
 drivers/gpu/drm/bridge/panel.c| 197 ++
 include/drm/drm_bridge.h  |   7 ++
 6 files changed, 238 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/panel.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index c075aadd7078..7c5e2549a58a 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -143,6 +143,12 @@ Bridge Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:
 
+Panel-Bridge Helper Reference
+-
+
+.. kernel-doc:: drivers/gpu/drm/bridge/panel.c
+   :export:
+
 .. _drm_panel_helper:
 
 Panel Helper Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index c156fecfb362..4cc9c02cc3f2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,6 +24,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+drm-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f6968d3b4b41..c4daca38743c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,6 +4,14 @@ config DRM_BRIDGE
help
  Bridge registration and lookup framework.
 
+config DRM_PANEL_BRIDGE
+   def_bool y
+   depends on DRM_BRIDGE
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   help
+ DRM bridge wrapper of DRM panels
+
 menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
 
@@ -27,8 +35,7 @@ config DRM_DUMB_VGA_DAC
 config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
-   select DRM_KMS_HELPER
-   select DRM_PANEL
+   select DRM_PANEL_BRIDGE
help
  Support for transparent parallel to LVDS encoders that don't require
  any configuration.
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index f1f67a279426..0903ba574f61 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -8,144 +8,18 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
 
 #include 
 
-struct lvds_encoder {
-   struct device *dev;
-
-   struct drm_bridge bridge;
-   struct drm_connector connector;
-   struct drm_panel *panel;
-};
-
-static inline struct lvds_encoder *
-drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
-{
-   return container_of(bridge, struct lvds_encoder, bridge);
-}
-
-static inline struct lvds_encoder *
-drm_connector_to_lvds_encoder(struct drm_connector *connector)
-{
-   return container_of(connector, struct lvds_encoder, connector);
-}
-
-static int lvds_connector_get_modes(struct drm_connector *connector)
-{
-   struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
-
-   return drm_panel_get_modes(lvds->panel);
-}
-
-static const struct drm_connector_helper_funcs lvds_connector_helper_funcs = {
-   .get_modes = lvds_connector_get_modes,
-};
-
-static const struct drm_connector_funcs lvds_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = drm_connector_cleanup,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static int lvds_encoder_attach(struct drm_bridge *bridge)
-{
-   struct lvds_encoder *lvds = drm_bridge_to_lvds_encoder(bridge);
-   struct drm_connector *connector = >connector;
-   int ret;
-
-   if (!bridge->encoder) {
-   DRM_ERROR("Missing encoder\n");
-   return -ENODEV;
-   }
-
-   drm_connector_helper_add(connector, _connector_helper_funcs);
-
-   ret = drm_connector_init(bridge->dev, connector, _connector_funcs,
-   

[PATCH v2 4/7] drm/mediatek: Use the panel-bridge helper.

[Eric Anholt]

Avoids a bunch of connector boilerplate.  Note that this causes panel
prepare() to be moved before mtk_dsi_poweron() and unprepare() to be
after poweroff().  I think this is the expected usage of the panel API
(enable should be when you do things that require the link to be
brought up), but there may be issues here.

Signed-off-by: Eric Anholt 
---

Note that I haven't tested this change, and am not committed to this
patch.  It's just an optional cleanup, if it works for you.

 drivers/gpu/drm/mediatek/mtk_dsi.c | 125 -
 1 file changed, 13 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 808b995a990f..764bd8b9c256 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -160,7 +160,6 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
-   struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *bridge;
struct phy *phy;
@@ -188,11 +187,6 @@ static inline struct mtk_dsi *encoder_to_dsi(struct 
drm_encoder *e)
return container_of(e, struct mtk_dsi, encoder);
 }
 
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
-   return container_of(c, struct mtk_dsi, conn);
-}
-
 static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
 {
return container_of(h, struct mtk_dsi, host);
@@ -603,16 +597,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
 
-   if (dsi->panel) {
-   if (drm_panel_prepare(dsi->panel)) {
-   DRM_ERROR("failed to prepare the panel\n");
-   goto err_disable_digital_clk;
-   }
-   }
-
return 0;
-err_disable_digital_clk:
-   clk_disable_unprepare(dsi->digital_clk);
 err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
 err_phy_power_off:
@@ -630,15 +615,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;
 
-   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
-   if (dsi->panel) {
-   if (drm_panel_unprepare(dsi->panel)) {
-   DRM_ERROR("failed to unprepare the panel\n");
-   return;
-   }
-   }
-   }
-
+   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -669,19 +646,9 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
 
mtk_dsi_start(dsi);
 
-   if (dsi->panel) {
-   if (drm_panel_enable(dsi->panel)) {
-   DRM_ERROR("failed to enable the panel\n");
-   goto err_dsi_power_off;
-   }
-   }
-
dsi->enabled = true;
 
return;
-err_dsi_power_off:
-   mtk_dsi_stop(dsi);
-   mtk_dsi_poweroff(dsi);
 }
 
 static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -689,13 +656,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
 
-   if (dsi->panel) {
-   if (drm_panel_disable(dsi->panel)) {
-   DRM_ERROR("failed to disable the panel\n");
-   return;
-   }
-   }
-
mtk_dsi_stop(dsi);
mtk_dsi_poweroff(dsi);
 
@@ -750,13 +710,6 @@ static void mtk_dsi_encoder_enable(struct drm_encoder 
*encoder)
mtk_output_dsi_enable(dsi);
 }
 
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
-   struct mtk_dsi *dsi = connector_to_dsi(connector);
-
-   return drm_panel_get_modes(dsi->panel);
-}
-
 static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
.mode_fixup = mtk_dsi_encoder_mode_fixup,
.mode_set = mtk_dsi_encoder_mode_set,
@@ -764,52 +717,7 @@ static const struct drm_encoder_helper_funcs 
mtk_dsi_encoder_helper_funcs = {
.enable = mtk_dsi_encoder_enable,
 };
 
-static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = drm_connector_cleanup,
-   .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 const struct drm_connector_helper_funcs
-   mtk_dsi_connector_helper_funcs = {
-   .get_modes = mtk_dsi_connector_get_modes,
-};
-
-static int mtk_dsi_create_connector(struct drm_device *drm, struct mtk_dsi 
*dsi)
-{
-   int ret;
-
-   ret = 

Re: [Intel-gfx] [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

[Daniel Vetter]

On Thu, May 11, 2017 at 12:57:20PM +0300, Jani Nikula wrote:
> Face the fact, there are Display Port sink and branch devices out there
> in the wild that don't follow the Display Port specifications, or they
> have bugs, or just otherwise require special treatment. Start a common
> quirk database the drivers can query based on OUI (with the option of
> expanding to device identification string and hardware/firmware
> revisions later). At least for now, we leave the workarounds for the
> drivers to implement as they see fit.
> 
> For starters, add a branch device that can't handle full 24-bit main
> link M and N attributes properly. Naturally, the workaround of reducing
> main link attributes for all devices ended up in regressions for other
> devices. So here we are.
> 
> Cc: Ville Syrjälä 
> Cc: Dhinakaran Pandiyan 
> Cc: Clint Taylor 
> Cc: Adam Jackson 
> Cc: Harry Wentland 
> Signed-off-by: Jani Nikula 

A few small bikesheds below. Ack in principle.
-Daniel

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 61 
> +
>  include/drm/drm_dp_helper.h |  7 +
>  2 files changed, 68 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 3e5f52110ea1..58b2ced33151 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1208,3 +1208,64 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_dp_stop_crc);
> +
> +/*
> + * Display Port sink and branch devices in the wild have a variety of bugs, 
> try
> + * to collect them here. The quirks are shared, but it's up to the drivers to
> + * implement workarounds for them.
> + */

I'd stash this in the kerneldoc for drm_dp_get_quirks().

> +
> +/*
> + * FIXME: Add support for device identification and hardware/firmware 
> revision.
> + */
> +struct dpcd_quirk {
> + u8 oui[3];
> + bool is_branch;
> + u32 quirks;
> +};
> +
> +#define OUI(first, second, third) { (first), (second), (third) }
> +
> +static const struct dpcd_quirk dpcd_quirk_list[] = {
> + /* Analogix 7737 needs reduced M and N at HBR2 link rates */
> + { OUI(0x00, 0x22, 0xb9), true, DP_DPCD_QUIRK_LIMITED_M_N },
> +};
> +
> +#undef OUI
> +
> +/**
> + * drm_dp_get_quirks() - get quirks for the sink/branch device
> + * @oui: pointer to len bytes of DPCD at 0x400 (sink) or 0x500 (branch)
> + * @len: 3-12 bytes of DPCD data
> + * @is_branch: true for branch devices, false for sink devices
> + *
> + * Get a bit mask of DPCD quirks for the sink/branch device. The quirk data 
> is
> + * shared but it's up to the drivers to act on the data.
> + *
> + * For now, only the OUI (first three bytes) is used, but this may be 
> extended
> + * to device identification string and hardware/firmware revisions later.
> + */
> +u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch)

Should we either base this on drm_dp_aux (so that this function would
query for quirks), or on struct drm_dp_link (which is kinda something
tegra and msm started to use to cache some sink properties)?

This is with an eye towards handling your FIXME, and maybe even converging
the dp helpers a bit more again.

Personally (aka my own bikeshed right now) I'm leaning towards struct
drm_dp_link and extending that.

> +{
> + const struct dpcd_quirk *quirk;
> + u32 quirks = 0;
> + int i;
> +
> + if (WARN_ON_ONCE(len < 3))
> + return 0;
> +
> + for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
> + quirk = _quirk_list[i];
> +
> + if (quirk->is_branch != is_branch)
> + continue;
> +
> + if (memcmp(quirk->oui, oui, 3) != 0)
> + continue;
> +
> + quirks |= quirk->quirks;
> + }
> +
> + return quirks;
> +}
> +EXPORT_SYMBOL(drm_dp_get_quirks);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index f7007e544f29..8abe9897fe59 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1079,4 +1079,11 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
>  int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
>  int drm_dp_stop_crc(struct drm_dp_aux *aux);
>  
> +/* Display Port sink and branch device quirks. */
> +
> +/* The sink is limited to small link M and N values. */
> +#define DP_DPCD_QUIRK_LIMITED_M_NBIT(0)

Bikeshed: I much prefer enums (with bitfields) than defines for internal
stuff, allows them to be nicely kernel-doc documented and linked. Which I
think would be good to do here, to spec out very precisely what exactly
the hack is that needs to be applied. LIMITED_M_N doesn't tell you
anything without looking at the i915 code.

> +
> +u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool 

[radeon-alex:vega10-drop0509 1379/1987] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:11: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'resource_s

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git vega10-drop0509
head:   b97044091f42cad26368a402c31af13e1319c7ab
commit: f0829a4c8f2abc5b12bfd7a4338b97864cfd2e47 [1379/1987] port in all files
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout f0829a4c8f2abc5b12bfd7a4338b97864cfd2e47
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function 
'amdgdu_amdkfd_restore_mem_worker':
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:193:22: error: 'struct amdgpu_bo' 
has no member named 'adev'
 adev = mem->data2.bo->adev;
 ^~
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function 'get_local_mem_info':
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:342:24: warning: left shift count 
>= width of type [-Wshift-count-overflow]
 address_mask = ~((1UL << 40) - 1);
   ^~
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/amd/amdgpu/../backport/backport.h:4,
from :0:
   include/linux/kern_levels.h:4:18: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type 'resource_size_t {aka 
unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^~~~
   include/linux/printk.h:277:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:352:3: note: in expansion of 
macro 'pr_err'
  pr_err("amdgpu: vram aperture is out of 40bit address base: 0x%llx limit 
0x%llx\n",
  ^~
   include/linux/kern_levels.h:4:18: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type 'resource_size_t {aka 
unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^~~~
   include/linux/printk.h:277:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:352:3: note: in expansion of 
macro 'pr_err'
  pr_err("amdgpu: vram aperture is out of 40bit address base: 0x%llx limit 
0x%llx\n",
  ^~
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/amd/amdgpu/../backport/backport.h:4,
from :0:
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:11: warning: format '%llx' 
>> expects argument of type 'long long unsigned int', but argument 3 has type 
>> 'resource_size_t {aka unsigned int}' [-Wformat=]
 pr_debug("amdgpu: address base: 0x%llx limit 0x%llx public 0x%llx private 
0x%llx\n",
  ^
   include/linux/printk.h:261:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
   include/linux/printk.h:309:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^~~~
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:2: note: in expansion of 
>> macro 'pr_debug'
 pr_debug("amdgpu: address base: 0x%llx limit 0x%llx public 0x%llx private 
0x%llx\n",
 ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:11: warning: format '%llx' 
expects argument of type 'long long unsigned int', but argument 4 has type 
'resource_size_t {aka unsigned int}' [-Wformat=]
 pr_debug("amdgpu: address base: 0x%llx limit 0x%llx public 0x%llx private 
0x%llx\n",
  ^
   include/linux/printk.h:261:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
   include/linux/printk.h:309:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^~~~
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:2: note: in expansion of 
>> macro 'pr_debug'
 pr_debug("amdgpu: address base: 0x%llx limit 0x%llx public 0x%llx private 
0x%llx\n",
 ^~~~
   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:361:6: error: 'amdgpu_powerplay' 

[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #21 from Alex Deucher  ---
Created attachment 131322
  --> https://bugs.freedesktop.org/attachment.cgi?id=131322=edit
possible fix 4/4

-- 
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 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher  ---
Created attachment 131321
  --> https://bugs.freedesktop.org/attachment.cgi?id=131321=edit
possible fix 3/4

-- 
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 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher  ---
Created attachment 131320
  --> https://bugs.freedesktop.org/attachment.cgi?id=131320=edit
possible fix 2/4

-- 
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 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher  ---
Created attachment 131319
  --> https://bugs.freedesktop.org/attachment.cgi?id=131319=edit
possible fix 1/4

Does this patch set help?

-- 
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 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

On 17-05-03 14:15:15, Liviu Dudau wrote:

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_mode_config.c |   7 +++
 drivers/gpu/drm/drm_plane.c   | 119 ++
 include/drm/drm_mode_config.h |   6 ++
 include/uapi/drm/drm_mode.h   |  26 +
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }

+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;
+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)


Why do you have to pass the format_modifiers again when you have 
plane->modifiers?
Or the reverse question: why do you need plane->modifiers when you are passing 
the
modifiers as parameters all the time?



I've dropped most of the parameters here and just used plane->*


+{
+   const struct drm_mode_config *config = >mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), formats, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < 

[Bug 101007] AMDgpu kernel BUG with 5 cards

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Christian König  ---
Yeah, I expected that it is something like that.

BTW: Any interest in giving my resizeable BAR patch set a try?

It allows the driver to make all of video memory accessible to the CPU, not
just the first 256MB.

Since you have a rather unusual system configuration a few results from your
board would be rather interesting to have.

-- 
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 101007] AMDgpu kernel BUG with 5 cards

[bugzilla-daemon]

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

--- Comment #3 from GSaraber  ---
Created attachment 131318
  --> https://bugs.freedesktop.org/attachment.cgi?id=131318=edit
lspci output

Here's the lspci -vvv output

-- 
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 101007] AMDgpu kernel BUG with 5 cards

[bugzilla-daemon]

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

GSaraber  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #2 from GSaraber  ---
Update:: There is a bios setting "Decode 4G" in advanced/Boot that needs to be
turned on, that stopped it from crashing, sorry for the wild goose chase.

-- 
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 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

[bugzilla-daemon]

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

--- Comment #17 from Andy Furniss  ---
Oh, OK, I don't know whether that's expected or not on an R9 390

-- 
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 99029] VCE VAAPI segfault using ffmpeg

[bugzilla-daemon]

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

--- Comment #6 from Andy Furniss  ---
(In reply to Martin Bednar from comment #4)
> The file is the OSS Elephant's dream movie : https://orange.blender.org/
> Purposely tested with this for easy sharing.
> Contained streams (ffmpeg -i ): 
> Stream #0:0: Video: msmpeg4v2 (MP42 / 0x3234504D), yuv420p, 1920x1080,
> 10002 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc
> Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side),
> fltp, 448 kb/s

I think ffmpeg will silently fall back to s/w decode with this file as it's not
normal h264.

If you don't specify a bitrate it seems ffmpeg will use cqp = 20 (which will
come out quite high bitrate on some content).

> -profile:v 77  : I tested values and in the end found one in ffmpeg sources.
> Are these values documented anywhere?

Not sure about ffmpeg, but they are standard numbers in the world of h264

> B-Frames : so basically VCE is useless in its B-Frame-less state?

I wouldn't go that far, for realtime encoding it is useful and libx264 with
realtime settings wouldn't use b-frames either (well depends on how much CPU
you have available in practice).
For example my card can do 2160p60 realtime in an artificial test - though in
practice for say, game/screen recording I would need hardware CSC which Windows
may have, but linux doesn't.

> I was hoping to create a tvheadend streaming server with live hw-accelerated
> transcoding, is this at all possible with AMD VCE cards?

If the input is progressive h.264 maybe - VCE doesn't encode interlaced which
could be an issue depending on what your local broadcasters use.

TV tends to be quite low bitrate anyway - if you are not reducing size then
re-encoding may not be the best way to go.

gstreamer can, for my dual instance VCE card, be faster than ffmpeg, on your
APU I don't know whether it would be.

gstreamer can use vaapi (I don't think a current mesa regression affects
transcoding). OMX can be used, but it's cqp only, with vaapi you can target
bitrates.

-- 
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 2/2] drm/i915: Detect USB-C specific dongles before reducing M and N

[Clint Taylor]

On 05/11/2017 02:57 AM, Jani Nikula wrote:

From: Clint Taylor 

The Analogix 7737 DP to HDMI converter requires reduced M and N values
when to operate correctly at HBR2. Detect this IC by its OUI value of
0x0022B9 via the DPCD quirk list.

v2 by Jani: Rebased on the DP quirk database

Fixes: 9a86cda07af2 ("drm/i915/dp: reduce link M/N parameters")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100755
Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 


Tested-by: Clinton Taylor 


Signed-off-by: Clint Taylor 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
  drivers/gpu/drm/i915/intel_display.c | 22 ++
  drivers/gpu/drm/i915/intel_dp.c  | 15 +++
  drivers/gpu/drm/i915/intel_dp_mst.c  |  4 +++-
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  5 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff3574a56812..d34412673d61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,7 +563,8 @@ struct intel_link_m_n {
  
  void intel_link_compute_m_n(int bpp, int nlanes,

int pixel_clock, int link_clock,
-   struct intel_link_m_n *m_n);
+   struct intel_link_m_n *m_n,
+   bool reduce_m_n);
  
  /* Interface history:

   *
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bf9020da8b80..46ac46ca976c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6116,7 +6116,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
pipe_config->fdi_lanes = lane;
  
  	intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,

-  link_bw, _config->fdi_m_n);
+  link_bw, _config->fdi_m_n, false);
  
  	ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);

if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
@@ -6292,7 +6292,8 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
  }
  
  static void compute_m_n(unsigned int m, unsigned int n,

-   uint32_t *ret_m, uint32_t *ret_n)
+   uint32_t *ret_m, uint32_t *ret_n,
+   bool reduce_m_n)
  {
/*
 * Reduce M/N as much as possible without loss in precision. Several DP
@@ -6300,9 +6301,11 @@ static void compute_m_n(unsigned int m, unsigned int n,
 * values. The passed in values are more likely to have the least
 * significant bits zero than M after rounding below, so do this first.
 */
-   while ((m & 1) == 0 && (n & 1) == 0) {
-   m >>= 1;
-   n >>= 1;
+   if (reduce_m_n) {
+   while ((m & 1) == 0 && (n & 1) == 0) {
+   m >>= 1;
+   n >>= 1;
+   }
}
  
  	*ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);

@@ -6313,16 +6316,19 @@ static void compute_m_n(unsigned int m, unsigned int n,
  void
  intel_link_compute_m_n(int bits_per_pixel, int nlanes,
   int pixel_clock, int link_clock,
-  struct intel_link_m_n *m_n)
+  struct intel_link_m_n *m_n,
+  bool reduce_m_n)
  {
m_n->tu = 64;
  
  	compute_m_n(bits_per_pixel * pixel_clock,

link_clock * nlanes * 8,
-   _n->gmch_m, _n->gmch_n);
+   _n->gmch_m, _n->gmch_n,
+   reduce_m_n);
  
  	compute_m_n(pixel_clock, link_clock,

-   _n->link_m, _n->link_n);
+   _n->link_m, _n->link_n,
+   reduce_m_n);
  }
  
  static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a6feb6a69bd..59f3dbb242a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1568,13 +1568,17 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
if (!__intel_dp_read_desc(intel_dp, desc))
return false;
  
+	intel_dp->quirks = drm_dp_get_quirks(desc->oui, sizeof(desc->oui),

+drm_dp_is_branch(intel_dp->dpcd));
+
dev_id_len = strnlen(desc->device_id, sizeof(desc->device_id));
-   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev 
%d.%d\n",
+   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev %d.%d 
quirks 0x%04x\n",
  

Re: [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

[Clint Taylor]

On 05/11/2017 02:57 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on OUI (with the option of
expanding to device identification string and hardware/firmware
revisions later). At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link M and N attributes properly. Naturally, the workaround of reducing
main link attributes for all devices ended up in regressions for other
devices. So here we are.

Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Clint Taylor 
Cc: Adam Jackson 
Cc: Harry Wentland 


Tested-by: Clinton Taylor 

Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/drm_dp_helper.c | 61 +
  include/drm/drm_dp_helper.h |  7 +
  2 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e5f52110ea1..58b2ced33151 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1208,3 +1208,64 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
return 0;
  }
  EXPORT_SYMBOL(drm_dp_stop_crc);
+
+/*
+ * Display Port sink and branch devices in the wild have a variety of bugs, try
+ * to collect them here. The quirks are shared, but it's up to the drivers to
+ * implement workarounds for them.
+ */
+
+/*
+ * FIXME: Add support for device identification and hardware/firmware revision.
+ */
+struct dpcd_quirk {
+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, DP_DPCD_QUIRK_LIMITED_M_N },
+};
+
+#undef OUI
+
+/**
+ * drm_dp_get_quirks() - get quirks for the sink/branch device
+ * @oui: pointer to len bytes of DPCD at 0x400 (sink) or 0x500 (branch)
+ * @len: 3-12 bytes of DPCD data
+ * @is_branch: true for branch devices, false for sink devices
+ *
+ * Get a bit mask of DPCD quirks for the sink/branch device. The quirk data is
+ * shared but it's up to the drivers to act on the data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   if (WARN_ON_ONCE(len < 3))
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, oui, 3) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+EXPORT_SYMBOL(drm_dp_get_quirks);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f7007e544f29..8abe9897fe59 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1079,4 +1079,11 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
  int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
  int drm_dp_stop_crc(struct drm_dp_aux *aux);
  
+/* Display Port sink and branch device quirks. */

+
+/* The sink is limited to small link M and N values. */
+#define DP_DPCD_QUIRK_LIMITED_M_N  BIT(0)
+
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch);
+
  #endif /* _DRM_DP_HELPER_H_ */


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

[Bug 100984] QupZilla crashes at startup after mesa upgrade

[bugzilla-daemon]

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

--- Comment #4 from Francesco Turco  ---
See also https://bugs.gentoo.org/show_bug.cgi?id=618206

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

Re: [PATCH v2 0/3] drm/amd/display: add HDMI Stereo 3D support

[Jeffrey Smith]

Note, the higher level pieces are not yet in place, for this to work
on X for instance.
I started to look at that a while back, only to realize the kernel
driver needed help first.

On Thu, May 11, 2017 at 10:33 AM, Jeffrey Smith  wrote:
> I took the work from https://patchwork.freedesktop.org/patch/27065/
> and cleaned it up. I've been meaning to take what I'd done and post it.
> Your question inspired me to take care of that and here is the result:
>   https://github.com/whydoubt/stereo-es2gears
>
> Also, Alastair Bridgewater pointed out to me that intel-gpu-tools has
> some testing modes, but I only messed with it a little.
>   https://github.com/tiagovignatti/intel-gpu-tools
>
> I have also played around with creating test patterns by extending
> https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c
> but that is some very raw stuff and probably not particularly helpful
> in the current state.
>
> On Wed, May 10, 2017 at 3:46 PM, Harry Wentland  
> wrote:
>> On 2017-05-08 12:35 PM, Jeff Smith wrote:
>>>
>>> Changes: I have broken one patch into three.
>>>
>>> Note: this only covers the display (not amdgpu) portion and does not
>>>   include the code to make it work over the card's DVI port.
>>>
>>> I only have one Stereo-3D-capable display to test this on, an LG TV from
>>> about 2014.  All 3 modes (side-by-side half, top-and-bottom, and
>>> frame-packing) appear to work as intended.
>>>
>>
>> Hi Jeff,
>>
>> how do you test this? Which app, etc, are you using? I've never tested
>> stereo 3D before on Linux but would really love to give this a quick spin
>> before pulling these patches. Everything that pops up on google points me to
>> the bino video player but that segfaults on Ubuntu 17.04 with any video.
>>
>> Harry
>>
>>
>>
>>> Jeff Smith (3):
>>>   drm/amd/display: translate drm's mode to display's stereo-3D timing
>>>   drm/amd/display: use stereo-3D-aware methods when calculating
>>> dimensions
>>>   drm/amd/display: enable stereo-3D modes/timings
>>>
>>>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 33
>>> +++---
>>>  .../display/dc/dce110/dce110_timing_generator.c|  4 ---
>>>  2 files changed, 23 insertions(+), 14 deletions(-)
>>>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101007] AMDgpu kernel BUG with 5 cards

[bugzilla-daemon]

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

--- Comment #1 from Christian König  ---
Please attach the output of "sudo lspci -".

-- 
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 101007] AMDgpu kernel BUG with 5 cards

[bugzilla-daemon]

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

Bug ID: 101007
   Summary: AMDgpu kernel BUG with 5 cards
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gsara...@rarcoa.com

Ubuntu server 17.04, amdgpu-pro-17.10-414273
Linux mining1 4.10.0-20-generic #22-Ubuntu SMP Thu Apr 20 09:22:42 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
Has 5 cards installed:
00:00.0 Host bridge: Intel Corporation Device 590f (rev 06)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 06)
00:01.1 PCI bridge: Intel Corporation Skylake PCIe Controller (x8) (rev 06)
00:14.0 USB controller: Intel Corporation 200 Series PCH USB 3.0 xHCI
Controller
00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1
00:1b.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #17
(rev f0)
00:1b.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #21
(rev f0)
00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #1
(rev f0)
00:1c.1 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #2
(rev f0)
00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5
(rev f0)
00:1c.6 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #7
(rev f0)
00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #9
(rev f0)
00:1f.0 ISA bridge: Intel Corporation 200 Series PCH LPC Controller (Z270)
00:1f.2 Memory controller: Intel Corporation 200 Series PCH PMC
00:1f.4 SMBus: Intel Corporation 200 Series PCH SMBus Controller
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Ellesmere [Radeon RX 470/480] (rev c7)
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf0
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Ellesmere [Radeon RX 470/480] (rev c7)
02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf0
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Ellesmere [Radeon RX 470/480] (rev c7)
04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf0
06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Ellesmere [Radeon RX 470/480] (rev c7)
06:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf0
08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Ellesmere [Radeon RX 470/480] (rev c7)
08:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf0

Causes kernel BUG on bootup:
[8.592737] amdgpu :08:00.0: GTT: 4096M 0x0001 -
0x0001
[8.598389] [ cut here ]
[8.601935] kernel BUG at
/build/linux-2NWldV/linux-4.10.0/arch/x86/mm/pat.c:539!
[8.605587] invalid opcode:  [#1] SMP
[8.609243] Modules linked in: hid_generic usbhid mxm_wmi crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd
glue_helper cryptd psmouse e1000e ptp pps_core amdkfd amd_iommu_v2 amdgpu(+)
i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
drm video wmi pinctrl_sunrisepoint pinctrl_intel i2c_hid hid fjes
[8.617618] CPU: 1 PID: 145 Comm: systemd-udevd Not tainted
4.10.0-20-generic #22-Ubuntu
[8.621935] Hardware name: System manufacturer System Product Name/PRIME
Z270-A, BIOS 0906 03/22/2017
[8.626312] task: 92630d3a2c00 task.stack: af7d410d
[8.630720] RIP: 0010:reserve_memtype+0x197/0x3d0
[8.635049] RSP: 0018:af7d410d3820 EFLAGS: 00010246
[8.639429] RAX:  RBX:  RCX:
af7d410d387c
[8.643902] RDX: 0001 RSI:  RDI:

[8.648401] RBP: af7d410d3860 R08:  R09:
04f3
[8.652927] R10: 92630ad67980 R11: 0001 R12:

[8.657479] R13: 0001 R14:  R15:
af7d410d38c4
[8.662076] FS:  7fb66305e8c0() GS:92631ed0()
knlGS:
[8.666777] CS:  0010 DS:  ES:  CR0: 80050033
[8.671518] CR2: 55d374b250f8 CR3: 00028c451000 CR4:
003406e0
[8.676355] Call Trace:
[8.681140]  io_reserve_memtype+0x59/0x130
[8.685876]  ? amdgpu_mm_rreg+0xd0/0xd0 [amdgpu]
[8.690513]  arch_io_reserve_memtype_wc+0x2f/0x50
[8.695080]  amdgpu_bo_init+0x20/0x90 [amdgpu]
[8.699560]  gmc_v8_0_sw_init+0x350/0x5c0 [amdgpu]
[8.704078]  amdgpu_device_init+0xb6b/0x1180 [amdgpu]
[8.708503]  ? kmalloc_order+0x18/0x40
[8.712905]  ? kmalloc_order_trace+0x24/0xa0
[8.717347]