[git pull] drm fixes for v4.17-rc3

[Dave Airlie]

Hi Linus,

Pretty run of the mill for this stage in the cycle.

i915:
- Black screen fixes
- Display w/a fix
- HDA codec interop fix
sun4i:
- tbsa711 tablet regression fix
qxl:
- Regression fixes due to changes in TTM
virtio:
- Fix wait event condition
msm:
- DSI display fixes
amdgpu:
- fix hang on Carrizo
- DP MST hang fixes
- irq handling deadlock in DC.
amdkfd:
- Fix Kconfig issue
- Clock retrieval fix
- Sparse fixes

Regards,
Dave.


The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc3

for you to fetch changes up to 24d9092c8b7de0a0f630adbe3504bef8d3a618af:

  Merge tag 'drm-intel-fixes-2018-04-26' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-04-27
14:08:47 +1000)


msm, i915, amdgpu, qxl, virtio-gpu, sun4i fixes


Abhay Kumar (1):
  drm/i915/audio: set minimum CD clock to twice the BCLK

Abhinav Kumar (3):
  drm/msm/dsi: check return value for video done waits
  drm/msm/dsi: check video mode engine status before waiting
  drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

Andres Rodriguez (1):
  drm/amdkfd: fix clock counter retrieval for node without GPU

Ben Hutchings (1):
  drm/msm: Fix possible null dereference on failure of get_pages()

Dave Airlie (5):
  Merge tag 'drm-amdkfd-fixes-2018-04-24' of
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-msm-fixes-2018-04-25' of
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2018-04-25' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2018-04-26' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Emil Velikov (1):
  drm/msm: don't deref error pointer in the msm_fbdev_create error path

Gerd Hoffmann (3):
  qxl: fix qxl_release_{map,unmap}
  qxl: keep separate release_bo pointer
  drm/virtio: fix vq wait_event condition

Harry Wentland (2):
  drm/amd/display: Disallow enabling CRTC without primary plane with FB
  drm/amd/display: Don't read EDID in atomic_check

Imre Deak (1):
  drm/i915: Enable display WA#1183 from its correct spot

Jerry (Fangzhi) Zuo (2):
  drm/amd/display: Update MST edid property every time
  drm/amd/display: Check dc_sink every time in MST hotplug

Jeykumar Sankaran (1):
  drm/msm: Add modifier to mdp_get_format arguments

José Roberto de Souza (1):
  drm/i915/fbdev: Enable late fbdev initial configuration

Mika Kuoppala (1):
  drm/i915: Use ktime on wait_for

Mikita Lipski (1):
  drm/amd/display: Fix deadlock when flushing irq

Nicolai Hähnle (1):
  drm/amdgpu: set COMPUTE_PGM_RSRC1 for SGPR/VGPR clearing shaders

Ondrej Jirman (1):
  Revert "drm/sun4i: add lvds mode_valid function"

Randy Dunlap (1):
  drm/amdkfd: fix build, select MMU_NOTIFIER

Sean Paul (1):
  drm/msm: Mark the crtc->state->event consumed

Stefan Agner (1):
  drm/msm/dsi: use correct enum in dsi_get_cmd_fmt

Ville Syrjälä (1):
  drm/edid: Reset more of the display info

Wei Yongjun (1):
  drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

kbuild test robot (1):
  drm/amdkfd: kfd_dev_is_large_bar() can be static

 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   7 +-
 drivers/gpu/drm/amd/amdkfd/Kconfig |   1 +
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  17 ++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  10 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  |   5 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  54 +-
 drivers/gpu/drm/drm_edid.c |  11 +--
 drivers/gpu/drm/i915/intel_cdclk.c |  16 ++-
 drivers/gpu/drm/i915/intel_drv.h   |   4 +-
 drivers/gpu/drm/i915/intel_fbdev.c |   2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c|  11 +--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c  |   1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  |   1 +
 drivers/gpu/drm/msm/disp/mdp_format.c  |   3 +-
 drivers/gpu/drm/msm/disp/mdp_kms.h |   2 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c |  16 ++-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 109 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 --
 drivers/gpu/drm/msm/msm_fb.c   |   3 +-
 drivers/gpu/drm/msm/msm_fbdev.c|  11 +--
 drivers/gpu/drm/msm/msm_gem.c  |  20 

[drm-intel:topic/core-for-CI 9/9] backtracetest.c:undefined reference to `save_stack_trace'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head:   1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects: 
capture stack traces at _init() time
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   kernel/backtracetest.o: In function `backtrace_regression_test':
>> backtracetest.c:(.text+0xd8): undefined reference to `save_stack_trace'
   mm/slub.o: In function `set_track':
   slub.c:(.text+0x12d2): undefined reference to `save_stack_trace'
   fs/btrfs/ref-verify.o: In function `btrfs_ref_tree_mod':
>> ref-verify.c:(.text+0x92e): undefined reference to `save_stack_trace'
   lib/debugobjects.o: In function `save_stack.isra.0':
   debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace'

---
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: [[RFC]DPU PATCH 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Rob Herring]

On Wed, Apr 25, 2018 at 08:46:13PM -0400, Rob Clark wrote:
> On Wed, Apr 25, 2018 at 7:45 PM, Stephen Boyd  wrote:
> > Quoting Sandeep Panda (2018-04-19 10:56:06)
> >> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
> >>
> >> Changes in v1:
> >>  - Rephrase the dt-binding descriptions to be more inline with existing
> >>bindings (Andrzej Hajda).
> >>  - Add missing dt-binding that are parsed by corresponding driver
> >>(Andrzej Hajda).
> >>
> >> Changes in v2:
> >>  - Removed edp panel specific dt-binding entries. Only keep bridge
> >>specific entries (Sean Paul).
> >>  - Remove custom-modes dt entry since its usage is removed from driver 
> >> also (Sean Paul).
> >>  - Remove is-pluggable dt entry since this will not be needed anymore 
> >> (Sean Paul).
> >>
> >> Changes in v3:
> >>  - Removed irq-gpio dt entry and instead populate is an interrupt
> >>property (Rob Herring).
> >
> > These changelogs usually go below the triple dash, but maybe drm is
> > different and wants them?
> 
> yeah, drm generally wants them in the commit msg rather than below the
> triple-dash, although I guess for bindings docs it should follow the
> rules for that tree.. I usually just fix up these sort of things as I
> apply patches, but not sure what other maintainers prefer

Well, these DPU patches aren't targeted for upstream so who cares.

Many patch revision changelogs I see are crap with statements like 
"implement changes requested by ??". But in this case, the changelog is 
really good.

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

Re: [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

[zhoucm1]

On 2018年04月26日 23:06, Michel Dänzer wrote:

From: Michel Dänzer 

When it's set, TTM tries to allocate huge pages if possible.

Do you mean original driver doesn't do this?
From the code, driver always try huge pages if 
CONFIG_TRANSPARENT_HUGEPAGE is enabled.


Regards,
David Zhou

  Drivers
which can take advantage of huge pages should set it.

Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.

Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 ++
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  8 +---
  include/drm/ttm/ttm_tt.h |  1 +
  4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dfd22db13fb1..e03e9e361e2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -988,7 +988,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_buffer_object *bo,
return NULL;
}
gtt->ttm.ttm.func = _backend_func;
-   if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
+   if (ttm_sg_tt_init(>ttm, bo, page_flags | 
TTM_PAGE_FLAG_TRANSHUGE)) {
kfree(gtt);
return NULL;
}
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index f0481b7b60c5..2ce91272b111 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -760,7 +760,7 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
  {
struct ttm_page_pool *pool = ttm_get_pool(flags, false, cstate);
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   struct ttm_page_pool *huge = ttm_get_pool(flags, true, cstate);
+   struct ttm_page_pool *huge = NULL;
  #endif
unsigned long irq_flags;
unsigned i;
@@ -780,7 +780,8 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
}
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

-   if (!(flags & TTM_PAGE_FLAG_DMA32)) {
+   if ((flags & (TTM_PAGE_FLAG_DMA32 | 
TTM_PAGE_FLAG_TRANSHUGE)) ==
+   TTM_PAGE_FLAG_TRANSHUGE) {
for (j = 0; j < HPAGE_PMD_NR; ++j)
if (p++ != pages[i + j])
break;
@@ -805,6 +806,8 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
  
  	i = 0;

  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   if (flags & TTM_PAGE_FLAG_TRANSHUGE)
+   huge = ttm_get_pool(flags, true, cstate);
if (huge) {
unsigned max_size, n2free;
  
@@ -877,7 +880,7 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,

  {
struct ttm_page_pool *pool = ttm_get_pool(flags, false, cstate);
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   struct ttm_page_pool *huge = ttm_get_pool(flags, true, cstate);
+   struct ttm_page_pool *huge = NULL;
  #endif
struct list_head plist;
struct page *p = NULL;
@@ -906,7 +909,8 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
  
  		i = 0;

  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   if (!(gfp_flags & GFP_DMA32)) {
+   if ((flags & (TTM_PAGE_FLAG_DMA32 | TTM_PAGE_FLAG_TRANSHUGE)) ==
+   TTM_PAGE_FLAG_TRANSHUGE) {
while (npages >= HPAGE_PMD_NR) {
gfp_t huge_flags = gfp_flags;
  
@@ -946,6 +950,8 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,

count = 0;
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

+   if (flags & TTM_PAGE_FLAG_TRANSHUGE)
+   huge = ttm_get_pool(flags, true, cstate);
if (huge && npages >= HPAGE_PMD_NR) {
INIT_LIST_HEAD();
ttm_page_pool_get_pages(huge, , flags, cstate,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 8a25d1974385..291b04213ec5 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
  
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE

-   if (ttm->page_flags & TTM_PAGE_FLAG_DMA32)
+   if ((ttm->page_flags & (TTM_PAGE_FLAG_DMA32 | TTM_PAGE_FLAG_TRANSHUGE))
+   != TTM_PAGE_FLAG_TRANSHUGE)
goto skip_huge;
  
  	pool = ttm_dma_find_pool(dev, type | IS_HUGE);

@@ -1035,7 +1036,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
  {
struct ttm_tt *ttm = _dma->ttm;
struct 

[radeon-alex:amd-staging-drm-next 31/33] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:490:66: sparse: incorrect type in assignment (different base types)

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   a11008ca87d737a3b1ffbe7f32af7d74d78a9aa8
commit: c4d9e2ed68bb9380ebd75916b28addcbc460c24f [31/33] drm/amd/powerplay: add 
smumgr support for VEGAM (v2)
reproduce:
# apt-get install sparse
git checkout c4d9e2ed68bb9380ebd75916b28addcbc460c24f
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:490:66: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] Voltage @@got  short [unsigned] 
>> [usertype] Voltage @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:490:66:
expected unsigned short [unsigned] [usertype] Voltage
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:490:66:got 
restricted __be16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:500:42: 
>> sparse: cast from restricted __be32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:518:66: 
sparse: incorrect type in assignment (different base types) @@expected 
unsigned short [unsigned] [usertype] Voltage @@got  short [unsigned] 
[usertype] Voltage @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:518:66:
expected unsigned short [unsigned] [usertype] Voltage
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:518:66:got 
restricted __be16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:586:9: sparse: 
>> incorrect type in assignment (different base types) @@expected unsigned 
>> int [unsigned] [usertype] CcPwrDynRm @@got ed int [unsigned] [usertype] 
>> CcPwrDynRm @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:586:9:
expected unsigned int [unsigned] [usertype] CcPwrDynRm
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:586:9:got 
restricted __be32 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:587:9: sparse: 
>> incorrect type in assignment (different base types) @@expected unsigned 
>> int [unsigned] [usertype] CcPwrDynRm1 @@got ed int [unsigned] [usertype] 
>> CcPwrDynRm1 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:587:9:
expected unsigned int [unsigned] [usertype] CcPwrDynRm1
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:587:9:got 
restricted __be32 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:588:9: sparse: 
>> incorrect type in assignment (different base types) @@expected unsigned 
>> short [unsigned] [usertype] VddcOffset @@got  short [unsigned] 
>> [usertype] VddcOffset @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:588:9:
expected unsigned short [unsigned] [usertype] VddcOffset
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:588:9:got 
restricted __be16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:617:51: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned int [unsigned] [usertype] DownThreshold @@got ed int [unsigned] 
>> [usertype] DownThreshold @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:617:51:
expected unsigned int [unsigned] [usertype] DownThreshold
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:617:51:got 
restricted __be32 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:618:49: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned int [unsigned] [usertype] UpThreshold @@got ed int [unsigned] 
>> [usertype] UpThreshold @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:618:49:
expected unsigned int [unsigned] [usertype] UpThreshold
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:618:49:got 
restricted __be32 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:722:25: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] fcw_pcc @@got  short [unsigned] 
>> [usertype] fcw_pcc @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:722:25:
expected unsigned short [unsigned] [usertype] fcw_pcc
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:722:25:got 
restricted __be16 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:723:25: 
>> sparse: incorrect type in assignment (different base types) @@expected 
>> unsigned short [unsigned] [usertype] fcw_trans_upper @@got  short 
>> [unsigned] [usertype] fcw_trans_upper @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:723:25:
expected unsigned short [unsigned] [usertype] fcw_trans_upper
   

[radeon-alex:amd-staging-drm-next 29/33] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:323:71: sparse: missing braces around initializer

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   a11008ca87d737a3b1ffbe7f32af7d74d78a9aa8
commit: 2493ccc491879761baffb7a66a7bbb86b3cff7ad [29/33] drm/amd/powerplay: 
update ppatomctrl.c (v2)
reproduce:
# apt-get install sparse
git checkout 2493ccc491879761baffb7a66a7bbb86b3cff7ad
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/ppatomctrl.c:55:66: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:84:48: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:106:42: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:119:36: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:157:49: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:182:53: sparse: 
incorrect type in assignment (different base types) @@expected unsigned int 
[unsigned] [usertype] ulTargetEngineClock @@got ed int [unsigned] 
[usertype] ulTargetEngineClock @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:182:53:
expected unsigned int [unsigned] [usertype] ulTargetEngineClock
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:182:53:got 
restricted __le32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:187:51: sparse: 
incorrect type in assignment (different base types) @@expected unsigned int 
[unsigned] [usertype] ulClock @@got ed int [unsigned] [usertype] ulClock @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:187:51:
expected unsigned int [unsigned] [usertype] ulClock
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:187:51:got 
restricted __le32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:222:29: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:234:27: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:257:33: sparse: 
incorrect type in assignment (different base types) @@expected unsigned int 
[unsigned] [usertype] ulClock @@got ed int [unsigned] [usertype] ulClock @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:257:33:
expected unsigned int [unsigned] [usertype] ulClock
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:257:33:got 
restricted __le32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:266:25: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:268:25: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:305:41: sparse: 
incorrect type in assignment (different base types) @@expected unsigned int 
[unsigned] [usertype] ulClock:24 @@got ed int [unsigned] [usertype] 
ulClock:24 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:305:41:
expected unsigned int [unsigned] [usertype] ulClock:24
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:305:41:got 
restricted __le32 [usertype] 
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:323:71: sparse: 
>> missing braces around initializer
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:326:41: sparse: 
incorrect type in assignment (different base types) @@expected unsigned int 
[unsigned] [usertype] ulClock:24 @@got ed int [unsigned] [usertype] 
ulClock:24 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:326:41:
expected unsigned int [unsigned] [usertype] ulClock:24
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:326:41:got 
restricted __le32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:337:25: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:339:25: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:341:25: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:356:32: sparse: 
incorrect type in assignment (different base types) @@expected unsigned int 
[unsigned] [usertype] ulClock:24 @@got ed int [unsigned] [usertype] 
ulClock:24 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:356:32:
expected unsigned int [unsigned] [usertype] ulClock:24
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:356:32:got 
restricted __le32 [usertype] 
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:364:40: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:379:40: sparse: 
incorrect type in assignment (different base types) @@expected 

[drm-intel:topic/core-for-CI 9/9] slub.c:undefined reference to `save_stack_trace'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head:   1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects: 
capture stack traces at _init() time
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   mm/slub.o: In function `set_track':
>> slub.c:(.text+0x12d2): undefined reference to `save_stack_trace'
   lib/debugobjects.o: In function `save_stack.isra.0':
>> debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace'

---
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] drm/bridge: tc358767: fix mode_valid's return type

[Laurent Pinchart]

Hi Luc,

Thank you for the patch.

On Tuesday, 24 April 2018 16:14:52 EEST Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
> 
> Fix this by using 'enum drm_mode_status' in the driver too.
> 
> Signed-off-by: Luc Van Oostenryck 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/tc358767.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c index 08ab7d6ae..0fd9cf275 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1102,7 +1102,7 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
> *bridge, return true;
>  }
> 
> -static int tc_connector_mode_valid(struct drm_connector *connector,
> +static enum drm_mode_status tc_connector_mode_valid(struct drm_connector
> *connector, struct drm_display_mode *mode)
>  {
>   /* DPI interface clock limitation: upto 154 MHz */

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

[Laurent Pinchart]

Hi Peter,

On Friday, 27 April 2018 02:09:14 EEST Peter Rosin wrote:
> On 2018-04-27 00:40, Laurent Pinchart wrote:
> > On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote:
> >> Hi!
> >> 
> >> It was noted by Russel King [1] that bridges (not using components)
> >> might disappear unexpectedly if the owner of the bridge was unbound.
> >> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
> >> came up with using device links to resolve the panel issue, which
> >> was also my (independent) reaction to the note from Russel.
> >> 
> >> This series builds up to the addition of that link in the last
> >> patch, but in my opinion the other 23 patches do have merit on their
> >> own.
> >> 
> >> The last patch needs testing, while the others look trivial. That
> >> said, I might have missed some subtlety.
> > 
> > I don't think this is the way to go. We have a real lifetime management
> > problem with bridges, and device links are just trying to hide the problem
> > under the carpet. They will further corner us by making a real fix much
> > more difficult to implement. I'll try to comment further in the next few
> > days on what I think a better solution would be, but in a nutshell I
> > believe that drm_bridge objects need to be refcounted, with a .release()
> > operation to free the bridge resources when the reference count drops to
> > zero. This shouldn't be difficult to implement and I'm willing to help.
> 
> Ok, sp 24/24 is dead, and maybe 23/24 too.

Not necessarily, maybe I'll get proven wrong :-) Let's discuss, but I first 
need some sleep.

> But how do you feel about dropping .of_node in favour of .owner? That gets
> rid of ugly #ifdefs...

I'll review that part and reply, I have nothing against it on principle at the 
moment. The more generic the code is, the better in my opinion. We just need 
to make sure that the OF node we're interested in will always be .owner-
>of_node in all cases.

> I also have the nagging feeling that .driver_private serves very little real
> purpose if there is a .owner so that you can do
> 
>   dev_get_drvdata(bridge->owner)
> 
> for the cases where the container_of macro is not appropriate.

I'll review that too, it's a good point.

-- 
Regards,

Laurent Pinchart



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

[Bug 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4

[bugzilla-daemon]

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

--- Comment #1 from erhar...@mailbox.org ---
Created attachment 139157
  --> https://bugs.freedesktop.org/attachment.cgi?id=139157=edit
journalctl -k (kernel 4.16.5)

-- 
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 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4

[bugzilla-daemon]

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

erhar...@mailbox.org changed:

   What|Removed |Added

Version|XOrg git|unspecified

-- 
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 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4

[bugzilla-daemon]

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

Bug ID: 106263
   Summary: amdgpu produces several stracktraces (Fiji, Bonaire)
at boot since kernel 4.16.4
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: erhar...@mailbox.org

Created attachment 139156
  --> https://bugs.freedesktop.org/attachment.cgi?id=139156=edit
kernel config 4.16.5

Getting these stracktraces at boot time since kernel 4.16.4. Last working was
4.16.3. On another machine I got similar issues since kernel 4.14.36 (last
working was 4.14.35 here). Booting is somewhat delayed (maybe other issues as
well?), but after a few minutes I get working console and X.

Apr 27 00:49:02 hakla03 kernel: WARNING: CPU: 2 PID: 148 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0xe4/0x120 [amdgpu]
Apr 27 00:49:02 hakla03 kernel: Modules linked in: ohci_pci(+) evdev
crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 crypto_simd cryptd
glue_helper amdgpu(+) r8169 k10temp mii chash i2c_algo_bit gpu_sched i2c_piix4
ohci_hcd ehci_pci drm_kms_helper ehci_hcd syscopyarea sysfillrect sysimgblt
fb_sys_fops ttm drm xhci_pci xhci_hcd drm_panel_orientation_quirks usbcore
usb_common shpchp video acpi_cpufreq button processor nct6775 hwmon_vid hwmon
Apr 27 00:49:02 hakla03 kernel: CPU: 2 PID: 148 Comm: systemd-udevd Not tainted
4.16.5-gentoo #2
Apr 27 00:49:02 hakla03 kernel: Hardware name: System manufacturer System
Product Name/A88X-PRO, BIOS 2603 03/10/2016
Apr 27 00:49:02 hakla03 kernel: RIP: 0010:generic_reg_update_ex+0xe4/0x120
[amdgpu]
Apr 27 00:49:02 hakla03 kernel: RSP: 0018:880420e33320 EFLAGS: 00010246
Apr 27 00:49:02 hakla03 kernel: RAX: 880420e8 RBX: 88042006f140
RCX: 
Apr 27 00:49:02 hakla03 kernel: RDX:  RSI: 
RDI: 88042c63ac00
Apr 27 00:49:02 hakla03 kernel: RBP: 880420e33388 R08: 
R09: 
Apr 27 00:49:02 hakla03 kernel: R10: 880420e333a0 R11: 0001
R12: 0001
Apr 27 00:49:02 hakla03 kernel: R13:  R14: 88042021e000
R15: 88041da1
Apr 27 00:49:02 hakla03 kernel: FS:  7fbfb3b21840()
GS:88043ed0() knlGS:
Apr 27 00:49:02 hakla03 kernel: CS:  0010 DS:  ES:  CR0:
80050033
Apr 27 00:49:02 hakla03 kernel: CR2: 7f8222b4af08 CR3: 000420e26000
CR4: 000406e0
Apr 27 00:49:02 hakla03 kernel: Call Trace:
Apr 27 00:49:02 hakla03 kernel: 
dce110_stream_encoder_update_hdmi_info_packets+0x374/0x590 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  apply_single_controller_ctx_to_hw+0x217/0x340
[amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? dce110_apply_ctx_to_hw+0x4c1/0x6d8 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? dc_commit_state+0x2ef/0x548 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? mod_freesync_set_user_enable+0x105/0x130
[amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? amdgpu_dm_atomic_commit_tail+0x353/0xdb0
[amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? amdgpu_bo_pin_restricted+0x1a8/0x288
[amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? dm_plane_helper_prepare_fb+0x16f/0x238
[amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? commit_tail+0x38/0x60 [drm_kms_helper]
Apr 27 00:49:02 hakla03 kernel:  ? drm_atomic_helper_commit+0xaf/0x120
[drm_kms_helper]
Apr 27 00:49:02 hakla03 kernel:  ? restore_fbdev_mode_atomic+0x1a8/0x200
[drm_kms_helper]
Apr 27 00:49:02 hakla03 kernel:  ?
drm_fb_helper_restore_fbdev_mode_unlocked+0x40/0x88 [drm_kms_helper]
Apr 27 00:49:02 hakla03 kernel:  ? drm_fb_helper_set_par+0x24/0x50
[drm_kms_helper]
Apr 27 00:49:02 hakla03 kernel:  ? fbcon_init+0x525/0x6b8
Apr 27 00:49:02 hakla03 kernel:  ? visual_init+0xcd/0x128
Apr 27 00:49:02 hakla03 kernel:  ? do_bind_con_driver+0x1ee/0x3e8
Apr 27 00:49:02 hakla03 kernel:  ? do_take_over_console+0x76/0x180
Apr 27 00:49:02 hakla03 kernel:  ? do_fbcon_takeover+0x52/0xa8
Apr 27 00:49:02 hakla03 kernel:  ? notifier_call_chain+0x41/0x60
Apr 27 00:49:02 hakla03 kernel:  ? blocking_notifier_call_chain+0x39/0x58
Apr 27 00:49:02 hakla03 kernel:  ? down+0xd/0x50
Apr 27 00:49:02 hakla03 kernel:  ? register_framebuffer+0x21d/0x2f8
Apr 27 00:49:02 hakla03 kernel:  ?
__drm_fb_helper_initial_config_and_unlock+0x209/0x3e0 [drm_kms_helper]
Apr 27 00:49:02 hakla03 kernel:  ? amdgpu_fbdev_init+0xba/0xf0 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? amdgpu_device_init+0xc88/0x1228 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? __alloc_pages_nodemask+0xcf/0x1b8
Apr 27 00:49:02 hakla03 kernel:  ? amdgpu_driver_load_kms+0x73/0x1c8 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? drm_dev_register+0x12d/0x1b8 [drm]
Apr 27 00:49:02 hakla03 kernel:  ? amdgpu_pci_probe+0xf4/0x180 [amdgpu]
Apr 27 00:49:02 hakla03 kernel:  ? 

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

[bugzilla-daemon]

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

--- Comment #5 from Francisco Pina Martins  ---
Created attachment 139154
  --> https://bugs.freedesktop.org/attachment.cgi?id=139154=edit
journaltcl log file with KASAN enabled in kernel

I have compiled a new kernel with KASAN module enabled.
However, I am not sure I am getting any KASAN related output in the logs
(attached).
Is there any boot option I should be passing it? Alternatively, can you point
me towards a good source of documentation on using KASAN (it is the first time
I am trying this).

-- 
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] dt-bindings: panel: lvds: Fix path to display timing bindings

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Wednesday, 25 April 2018 10:49:38 EEST Geert Uytterhoeven wrote:
> Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common
> panel properties")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> b/Documentation/devicetree/bindings/display/panel/panel-common.txt index
> 557fa765adcb9450..5d2519af4bb5ca5e 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> @@ -38,7 +38,7 @@ Display Timings
>require specific display timings. The panel-timing subnode expresses
> those timings as specified in the timing subnode section of the display
> timing bindings defined in
> -  Documentation/devicetree/bindings/display/display-timing.txt.
> +  Documentation/devicetree/bindings/display/panel/display-timing.txt.
> 
> 
>  Connectivity


-- 
Regards,

Laurent Pinchart



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

[Bug 106260] raven ridge (2400g) shows artifacts instead in xorg

[bugzilla-daemon]

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

--- Comment #3 from ojab  ---
DVI monitor is connected to HDMI port via HDMI->DVI adapter, if it matters.

-- 
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 00/24] device link, bridge supplier <-> drm device

[Laurent Pinchart]

Hi Peter,

Thank you for the patches.

On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote:
> Hi!
> 
> It was noted by Russel King [1] that bridges (not using components)
> might disappear unexpectedly if the owner of the bridge was unbound.
> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
> came up with using device links to resolve the panel issue, which
> was also my (independent) reaction to the note from Russel.
> 
> This series builds up to the addition of that link in the last
> patch, but in my opinion the other 23 patches do have merit on their
> own.
> 
> The last patch needs testing, while the others look trivial. That
> said, I might have missed some subtlety.

I don't think this is the way to go. We have a real lifetime management 
problem with bridges, and device links are just trying to hide the problem 
under the carpet. They will further corner us by making a real fix much more 
difficult to implement. I'll try to comment further in the next few days on 
what I think a better solution would be, but in a nutshell I believe that 
drm_bridge objects need to be refcounted, with a .release() operation to free 
the bridge resources when the reference count drops to zero. This shouldn't be 
difficult to implement and I'm willing to help.

> [1] https://lkml.org/lkml/2018/4/23/769
> [2] https://www.spinics.net/lists/dri-devel/msg174275.html
> 
> Peter Rosin (24):
>   drm/bridge: allow optionally specifying an .owner device
>   drm/bridge: adv7511: provide an .owner device
>   drm/bridge/analogix: core: specify the .owner of the bridge
>   drm/bridge: analogix-anx78xx: provide an .owner device
>   drm/bridge: vga-dac: provide an .owner device
>   drm/bridge: lvds-encoder: provide an .owner device
>   drm/bridge: megachips-stdp-ge-b850v3-fw: provide an .owner device
>   drm/bridge: nxp-ptn3460: provide an .owner device
>   drm/bridge: panel: provide an .owner device
>   drm/bridge: ps8622: provide an .owner device
>   drm/bridge: sii902x: provide an .owner device
>   drm/bridge: sii9234: provide an .owner device
>   drm/bridge: sii8620: provide an .owner device
>   drm/bridge: synopsys: provide an .owner device for the bridges
>   drm/bridge: tc358767: provide an .owner device
>   drm/bridge: ti-tfp410: provide an .owner device
>   drm/exynos: mic: provide an .owner device for the bridge
>   drm/mediatek: hdmi: provide an .owner device for the bridge
>   drm/msm: specify the .owner of the bridges
>   drm/rcar-du: lvds: provide an .owner device for the bridge
>   drm/sti: provide an .owner device for the bridges
>   drm/bridge: remove the .of_node member
>   drm/bridge: require the .owner to be filled in on drm_bridge_attach
>   drm/bridge: establish a link between the bridge supplier and consumer
> 
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  5 +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 +
>  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  2 +-
>  drivers/gpu/drm/bridge/lvds-encoder.c  |  2 +-
>  .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  2 +-
>  drivers/gpu/drm/bridge/nxp-ptn3460.c   |  2 +-
>  drivers/gpu/drm/bridge/panel.c |  4 +---
>  drivers/gpu/drm/bridge/parade-ps8622.c |  2 +-
>  drivers/gpu/drm/bridge/sii902x.c   |  2 +-
>  drivers/gpu/drm/bridge/sii9234.c   |  2 +-
>  drivers/gpu/drm/bridge/sil-sii8620.c   |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 +---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  |  4 +---
>  drivers/gpu/drm/bridge/tc358767.c  |  2 +-
>  drivers/gpu/drm/bridge/ti-tfp410.c |  2 +-
>  drivers/gpu/drm/drm_bridge.c   | 23 ++-
>  drivers/gpu/drm/exynos/exynos_drm_mic.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  2 +-
>  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  1 +
>  drivers/gpu/drm/msm/edp/edp_bridge.c   |  1 +
>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  1 +
>  drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +-
>  drivers/gpu/drm/sti/sti_dvo.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hda.c  |  1 +
>  drivers/gpu/drm/sti/sti_hdmi.c |  1 +
>  include/drm/drm_bridge.h   |  8 
>  27 files changed, 51 insertions(+), 33 deletions(-)


-- 
Regards,

Laurent Pinchart



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

[Bug 106260] raven ridge (2400g) shows artifacts instead in xorg

[bugzilla-daemon]

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

--- Comment #2 from ojab  ---
Created attachment 139151
  --> https://bugs.freedesktop.org/attachment.cgi?id=139151=edit
Xorg.log

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

[Bug 106260] raven ridge (2400g) shows artifacts instead in xorg

[bugzilla-daemon]

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

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

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

[Bug 106260] raven ridge (2400g) shows artifacts instead in xorg

[bugzilla-daemon]

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

Bug ID: 106260
   Summary: raven ridge (2400g) shows artifacts instead in xorg
   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: o...@ojab.ru
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 139149
  --> https://bugs.freedesktop.org/attachment.cgi?id=139149=edit
`DISPLAY=:0 mpv /some/film.mkv`

Raven ridge APU (2400g), no external GPU, linux-4.17-rc2, libdrm-2.4.91,
mesa-18.1.0-rc1, xorg-server-1.19.6, xf86-video-amdgpu-18.0.1.

Image in Xorg is completely unintelligible, see the attached file for the video
of mpv with some film playing.

-- 
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] gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe

[Laurent Pinchart]

Hi Jia-Ju,

Thank you for the patch.

On Wednesday, 11 April 2018 11:33:42 EEST Jia-Ju Bai wrote:
> adv7511_probe() is never called in atomic context.
> This function is only set as ".probe" in struct i2c_driver.
> 
> Despite never getting called from atomic context, adv7511_probe()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.

Nice work ! Is the tool open-source ?

> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b2431ae..2cf7fa1
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1054,7 +1054,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) }
> 
>   if (adv7511->gpio_pd) {
> - mdelay(5);
> + usleep_range(5000, 6000);
>   gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>   }

The patch looks good to me.

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] drm/bridge: adv7511: fix spelling of driver name in Kconfig

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Friday, 27 April 2018 00:36:44 EEST Peter Rosin wrote:
> Could perhaps prevent some confusion.
> 
> Signed-off-by: Peter Rosin 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/adv7511/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
> b/drivers/gpu/drm/bridge/adv7511/Kconfig index 592b9d2ec034..944e440c4fde
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
> @@ -1,5 +1,5 @@
>  config DRM_I2C_ADV7511
> - tristate "AV7511 encoder"
> + tristate "ADV7511 encoder"
>   depends on OF
>   select DRM_KMS_HELPER
>   select REGMAP_I2C


-- 
Regards,

Laurent Pinchart



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

[Bug 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #4 from Matt Corallo  ---
Oops, looks like we got our wires crossed on what has and hasn't been tested.
It only *may* be PAGE_SIZE related, but seems relevant 3d stuff was never
tested on PPC64LE with 4K pages, only 64K.

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #3 from Timothy Pearson  ---
(In reply to Timothy Pearson from comment #1)
> This also affects the WX7100, same symptoms.  Shows up as soon as an OpenGL
> application tries to use the accelerated graphics.  Kernel 4.16.

On our end Ureal Engine 4 would reliably trigger the problem.  A number of
other open source 3D applications worked without issues.

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #2 from Matt Corallo  ---
Oops, forgot to specify this is on a WX4100.

-- 
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 106259] [bisected] UVD hangs system on Vega10 linux-4.17

[bugzilla-daemon]

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

Bug ID: 106259
   Summary: [bisected] UVD hangs system on Vega10 linux-4.17
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lothmor...@gmail.com

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

Trying to play h264 encoded video with mpv --vo=opengl --hwdec=vdpau results in
frozen video and the system unresponsive to key/mouse input.  System freezes
roughly 1sec into videos, although audio often continues.  Bisected to the
following kernel commit:

2ee150cda7bdc766cf9baca3534f3a2c0b0e8357 is the first bad commit
commit 2ee150cda7bdc766cf9baca3534f3a2c0b0e8357
Author: Christian König 
Date:   Fri Jan 19 15:19:16 2018 +0100

drm/amdgpu: remove now superflous *_hdp operation

All HDP invalidation and most flush can now be replaced by the generic
ASIC function.

Signed-off-by: Christian König 
Acked-by: Chunming Zhou 
Signed-off-by: Alex Deucher 

:04 04 85ee277739bbce19d5dbaf1fb309983198180d0f
056ae126031efe507bea405931ce89864979ef2d M  drivers
-

I tested mesa (git-227b1af866) patched with "radeon/vcn: fix mpeg4 msg buffer
settings" by Boyuan Zang, but that didn't fix my problem.  I also tested
today's pull request for linux drm-fixes-4.17, but the issue is still present.

Software versions:
Linux 4.17.0-rc1 x86_64
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-rc1
libdrm: 2.4.91
libvdpau: 1.1.1
mpv: 0.27.2
ffmpeg: 3.4.2-r1

GPU hardware:
OpenGL renderer string: Radeon RX Vega (VEGA10, DRM 3.23.0, 4.16.0-rc4,
LLVM 6.0.0)
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Vega 10 XT [Radeon RX Vega 64] [1002:687f] (rev c3)

CPU hardware:
AMD Phenom(tm) II X4 955 Processor

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #1 from Timothy Pearson  ---
This also affects the WX7100, same symptoms.  Shows up as soon as an OpenGL
application tries to use the accelerated graphics.  Kernel 4.16.

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

Bug ID: 106258
   Summary: AMD Xorg start failes with non-4K page sizes
   Product: DRI
   Version: unspecified
  Hardware: PowerPC
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: freedesk...@bluematt.me

Have two nearly-identical boxes, both running Debian testing with a 4.16
kernel, only major difference is one is configured with a 4k page size, one
with Debian's default 64K page size (on PPC64LE). This results in a corrupted
output when running X (with a non-corrupt mouse overlayed on top) and the
following WARN in dmesg:

[   33.990146] WARNING: CPU: 8 PID: 1401 at
/build/linux-z743uR/linux-4.16/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c:326
amdgpu_sa_bo_new+0x630/0x6b0 [amdgpu]
[   33.990148] Modules linked in: ext4 crc16 mbcache jbd2 fscrypto amdgpu chash
evdev ast gpu_sched ttm snd_hda_codec_hdmi drm_kms_helper snd_hda_intel
ghash_generic snd_hda_codec gf128mul drm ctr snd_hda_core snd_hwdep cbc sg
snd_pcm vmx_crypto drm_panel_orientation_quirks syscopyarea ofpart snd_timer
sysfillrect ipmi_powernv sysimgblt snd powernv_flash ipmi_devintf fb_sys_fops
mtd ipmi_msghandler i2c_algo_bit opal_prd soundcore at24 ip_tables x_tables
autofs4 btrfs crc32c_generic xor zstd_decompress zstd_compress xxhash raid6_pq
ecb xts algif_skcipher af_alg hid_generic usbhid hid sd_mod dm_crypt dm_mod
xhci_pci xhci_hcd mpt3sas usbcore tg3 raid_class scsi_transport_sas libphy
usb_common
[   33.990187] CPU: 8 PID: 1401 Comm: gnome-shell Not tainted
4.16.0-trunk-powerpc64le #1 Debian 4.16-1~exp1
[   33.990189] NIP:  c0080e08bfe8 LR: c0080e0940d4 CTR:

[   33.990190] REGS: c00fac573260 TRAP: 0700   Not tainted 
(4.16.0-trunk-powerpc64le Debian 4.16-1~exp1)
[   33.990191] MSR:  90029033   CR: 24828848 
XER: 2004
[   33.990196] CFAR: c0080e08ba14 SOFTE: 0 
   GPR00: c0080e0940d4 c00fac5734e0 c0080e2e1c00
c00ff4673318 
   GPR04: c00feedc5a58 09fff138 0100
000ffacf 
   GPR08: 0010 0010 
c0080e246b98 
   GPR12: 8000 cfa85800 c00ff467
c00ff45067e0 
   GPR16: 000e69ff c00feedc5a58 fffe2000
ffef 
   GPR20: 09fff138 c00ff467 0100
 
   GPR24: 000e69ff 00104a00 c00ff4673318
00011600 
   GPR28: c00ff467  c00feedc5a58
09fff138 
[   33.990228] NIP [c0080e08bfe8] amdgpu_sa_bo_new+0x630/0x6b0 [amdgpu]
[   33.990244] LR [c0080e0940d4] amdgpu_ib_get+0x8c/0x120 [amdgpu]
[   33.990245] Call Trace:
[   33.990261] [c00fac5734e0] [c0080e08bae4]
amdgpu_sa_bo_new+0x12c/0x6b0 [amdgpu] (unreliable)
[   33.990278] [c00fac573740] [c0080e0940d4] amdgpu_ib_get+0x8c/0x120
[amdgpu]
[   33.990298] [c00fac5737c0] [c0080e176db8]
amdgpu_job_alloc_with_ib+0x90/0x110 [amdgpu]
[   33.990316] [c00fac573800] [c0080e090be8]
amdgpu_vm_bo_update_mapping+0x360/0x4b0 [amdgpu]
[   33.990332] [c00fac5738f0] [c0080e091084]
amdgpu_vm_bo_update+0x34c/0x710 [amdgpu]
[   33.990350] [c00fac573a00] [c0080e0768b0]
amdgpu_gem_va_ioctl+0x5f8/0x620 [amdgpu]
[   33.990356] [c00fac573b50] [c0080cd88f48]
drm_ioctl_kernel+0xa0/0x140 [drm]
[   33.990361] [c00fac573ba0] [c0080cd89424] drm_ioctl+0x1bc/0x4f0
[drm]
[   33.990376] [c00fac573cf0] [c0080e050078] amdgpu_drm_ioctl+0x70/0xd0
[amdgpu]
[   33.990379] [c00fac573d40] [c03dd8dc] do_vfs_ioctl+0xdc/0x8a0
[   33.990381] [c00fac573de0] [c03de164] SyS_ioctl+0xc4/0x130
[   33.990383] [c00fac573e30] [c000b8e0] system_call+0x58/0x6c
[   33.990384] Instruction dump:
[   33.990386] 7fc3f378 38210260 e8010010 81810008 ea21ff88 ea81ffa0 eac1ffb0
eb41ffd0 
[   33.990389] ebc1fff0 7c0803a6 7d908120 4e800020 <0fe0> 3bc0ffea 7fc3f378
38210260 
[   33.990393] ---[ end trace 59adbd4db83fa3b4 ]---
[   33.990397] amdgpu :01:00.0: failed to get a new IB (-22)
[   33.990501] amdgpu :01:00.0: failed to get a new IB (-22)
[   34.007673] amdgpu :01:00.0: failed to get a new IB (-22)

-- 
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 3/4] ARM: dma-mapping: Implement arch_iommu_detach_device()

[kbuild test robot]

Hi Thierry,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thierry-Reding/drm-nouveau-tegra-Detach-from-ARM-DMA-IOMMU-mapping/20180426-140854
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

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

   arch/arm/mm/dma-mapping.c: In function 'arch_iommu_detach_device':
>> arch/arm/mm/dma-mapping.c:2380:12: error: implicit declaration of function 
>> 'arm_get_dma_map_ops'; did you mean 'arm_get_iommu_dma_map_ops'? 
>> [-Werror=implicit-function-declaration]
 dma_ops = arm_get_dma_map_ops(dev->archdata.dma_coherent);
   ^~~
   arm_get_iommu_dma_map_ops
>> arch/arm/mm/dma-mapping.c:2380:10: warning: assignment makes pointer from 
>> integer without a cast [-Wint-conversion]
 dma_ops = arm_get_dma_map_ops(dev->archdata.dma_coherent);
 ^
   arch/arm/mm/dma-mapping.c: At top level:
>> arch/arm/mm/dma-mapping.c:2402:34: error: conflicting types for 
>> 'arm_get_dma_map_ops'
static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
 ^~~
   arch/arm/mm/dma-mapping.c:2380:12: note: previous implicit declaration of 
'arm_get_dma_map_ops' was here
 dma_ops = arm_get_dma_map_ops(dev->archdata.dma_coherent);
   ^~~
   cc1: some warnings being treated as errors

vim +2380 arch/arm/mm/dma-mapping.c

  2368  
  2369  void arch_iommu_detach_device(struct device *dev)
  2370  {
  2371  struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
  2372  const struct dma_map_ops *dma_ops;
  2373  
  2374  if (!mapping)
  2375  return;
  2376  
  2377  arm_iommu_release_mapping(mapping);
  2378  arm_iommu_detach_device(dev);
  2379  
> 2380  dma_ops = arm_get_dma_map_ops(dev->archdata.dma_coherent);
  2381  set_dma_ops(dev, dma_ops);
  2382  }
  2383  
  2384  #else
  2385  
  2386  static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
  2387  const struct iommu_ops *iommu)
  2388  {
  2389  return false;
  2390  }
  2391  
  2392  static void arm_teardown_iommu_dma_ops(struct device *dev) { }
  2393  
  2394  #define arm_get_iommu_dma_map_ops arm_get_dma_map_ops
  2395  
  2396  void arch_iommu_detach_device(struct device *dev)
  2397  {
  2398  }
  2399  
  2400  #endif  /* CONFIG_ARM_DMA_USE_IOMMU */
  2401  
> 2402  static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
  2403  {
  2404  return coherent ? _coherent_dma_ops : _dma_ops;
  2405  }
  2406  

---
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 07/17] drm: rcar-du: Add R8A77965 support

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 26 April 2018 19:53:36 EEST Kieran Bingham wrote:
> The R8A77965 (M3-N) SoC provides VGA, HDMI and LVDS output.
> 
> This platform is unusual in that the VGA is connected to DU3 leaving DU2
> unpopulated. This is reflected by the channel_mask accordingly.

I'd write s/VGA/DPAD/g (or s/VGA/RGB/g) as the DPAD output can be used for 
other purposes than VGA.

> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 29 +++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index d6ebc628fc22..4d195ff8c569
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -246,6 +246,34 @@ static const struct rcar_du_device_info
> rcar_du_r8a7796_info = { .dpll_ch =  BIT(1),
>  };
> 
> +static const struct rcar_du_device_info rcar_du_r8a77965_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> +   | RCAR_DU_FEATURE_EXT_CTRL_REGS
> +   | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .channel_mask = BIT(0) | BIT(1) | BIT(3),

Depending on what you think of my suggestions for patch 05/17, you might want 
to reverse the bit order here.

> + .routes = {
> + /*
> +  * R8A77965 has one RGB output, one LVDS output and one HDMI
> +  * output.
> +  */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(2),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_HDMI0] = {
> + .possible_crtcs = BIT(1),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),

I wonder whether it wouldn't be easier to read if we replaced possible_crtcs 
with possible_channels, as this structure describes the hardware and had its 
num_crtcs field replaced with a channel_mask. This would require converting 
the possible_channels field to a possible_crtcs field in 
rcar_du_modeset_init(), and I think that no change would be needed in 
rcar_du_group_setup_defr8() (but please double check). On the other hand, no 
code would be simplified, and rcar_du_modeset_init() would gain some 
additional complexity, so it might not be worth it.

Either way this patch looks good to me.

Reviewed-by: Laurent Pinchart 

> + .port = 2,
> + },
> + },
> + .num_lvds = 1,
> + .dpll_ch =  BIT(1),
> +};
> +
>  static const struct rcar_du_device_info rcar_du_r8a77970_info = {
>   .gen = 3,
>   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> @@ -277,6 +305,7 @@ static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77965", .data = _du_r8a77965_info },
>   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
>   { }
>  };

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 06/17] drm: rcar-du: Allow DU groups to work with hardware indexing

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 26 April 2018 19:53:35 EEST Kieran Bingham wrote:
> The group objects assume linear indexing, and more so always assume that
> channel 0 of any active group is used.
> 
> Now that the CRTC objects support non-linear indexing, adapt the groups
> to remove assumptions that channel 0 is utilised in each group by using
> the channel mask provided in the device structures.
> 
> Finally ensure that the RGB routing is determined from the index of the
> CRTC object (which represents the hardware DU channel index).
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_group.c | 14 +-
>  drivers/gpu/drm/rcar-du/rcar_du_group.h |  2 ++
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 -
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c index eead202c95c7..c52091fe02ba
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -46,9 +46,12 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32
> reg, u32 data)
> 
>  static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
>  {
> - u32 defr6 = DEFR6_CODE | DEFR6_ODPM02_DISP;
> + u32 defr6 = DEFR6_CODE;
> 
> - if (rgrp->num_crtcs > 1)
> + if (rgrp->channel_mask & BIT(0))
> + defr6 |= DEFR6_ODPM02_DISP;
> +
> + if (rgrp->channel_mask & BIT(1))
>   defr6 |= DEFR6_ODPM12_DISP;

So much cleaner with the channels mask, I like this.

>   rcar_du_group_write(rgrp, DEFR6, defr6);
> @@ -80,10 +83,11 @@ static void rcar_du_group_setup_defr8(struct
> rcar_du_group *rgrp) * On Gen3 VSPD routing can't be configured, but DPAD
> routing
>* needs to be set despite having a single option available.
>*/
> - u32 crtc = ffs(possible_crtcs) - 1;
> + unsigned int rgb_crtc = ffs(possible_crtcs) - 1;
> + struct rcar_du_crtc *crtc = >crtcs[rgb_crtc];
> 
> - if (crtc / 2 == rgrp->index)
> - defr8 |= DEFR8_DRGBS_DU(crtc);
> + if (crtc->index / 2 == rgrp->index)
> + defr8 |= DEFR8_DRGBS_DU(crtc->index);
>   }
> 
>   rcar_du_group_write(rgrp, DEFR8, defr8);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> b/drivers/gpu/drm/rcar-du/rcar_du_group.h index 5e3adc6b31b5..d29a68e006a7
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> @@ -25,6 +25,7 @@ struct rcar_du_device;
>   * @dev: the DU device
>   * @mmio_offset: registers offset in the device memory map
>   * @index: group index
> + * @channel_mask: bitmask of populated DU channels in this group
>   * @num_crtcs: number of CRTCs in this group (1 or 2)
>   * @use_count: number of users of the group (rcar_du_group_(get|put))
>   * @used_crtcs: number of CRTCs currently in use
> @@ -39,6 +40,7 @@ struct rcar_du_group {
>   unsigned int mmio_offset;
>   unsigned int index;
> 
> + unsigned int channel_mask;

Depending on how you like my suggestion in patch 05/17, this might be better 
called channels_mask.

>   unsigned int num_crtcs;
>   unsigned int use_count;
>   unsigned int used_crtcs;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 19a445fbc879..45fb554fd3c7
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -597,7 +597,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>   rgrp->dev = rcdu;
>   rgrp->mmio_offset = mmio_offsets[i];
>   rgrp->index = i;
> - rgrp->num_crtcs = min(rcdu->num_crtcs - 2 * i, 2U);
> + /* Extract the channel mask for this group only */

s/only/only./

> + rgrp->channel_mask = (rcdu->info->channel_mask >> (2 * i))
> +& GENMASK(1, 0);
> + rgrp->num_crtcs = hweight8(rgrp->channel_mask);

You could optimize this by computing it as

rgrp->num_crtcs = (rgrp->channel_mask >> 1)
| (rgrp->channel_mask & 1);

as you know that only two bits at most can be set. Up to you.

>   /*
>* If we have more than one CRTCs in this group pre-associate

With those small issues fixed,

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 05/17] drm: rcar-du: Split CRTC handling to support hardware indexing

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 26 April 2018 19:53:34 EEST Kieran Bingham wrote:
> The DU CRTC driver does not support distinguishing between a hardware
> index, and a software (CRTC) index in the event that a DU channel might
> not be populated by the hardware.
> 
> Support this by adapting the rcar_du_device_info structure to store a
> bitmask of available channels rather than a count of CRTCs. The count
> can then be obtained by determining the hamming weight of the bitmask.
> 
> This allows the rcar_du_crtc_create() function to distinguish between
> both index types, and non-populated DU channels will be skipped without
> leaving a gap in the software CRTC indexes.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 26 ++
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 20 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 17 -
>  5 files changed, 40 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 5a15dfd66343..36ce194c13b5
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -902,7 +902,8 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
>   * Initialization
>   */
> 
> -int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index)
> +int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int swindex,
> + unsigned int hwindex)
>  {
>   static const unsigned int mmio_offsets[] = {
>   DU0_REG_OFFSET, DU1_REG_OFFSET, DU2_REG_OFFSET, DU3_REG_OFFSET
> @@ -910,7 +911,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int index)
> 
>   struct rcar_du_device *rcdu = rgrp->dev;
>   struct platform_device *pdev = to_platform_device(rcdu->dev);
> - struct rcar_du_crtc *rcrtc = >crtcs[index];
> + struct rcar_du_crtc *rcrtc = >crtcs[swindex];
>   struct drm_crtc *crtc = >crtc;
>   struct drm_plane *primary;
>   unsigned int irqflags;
> @@ -922,7 +923,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int index)
> 
>   /* Get the CRTC clock and the optional external clock. */
>   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CRTC_IRQ_CLOCK)) {
> - sprintf(clk_name, "du.%u", index);
> + sprintf(clk_name, "du.%u", hwindex);
>   name = clk_name;
>   } else {
>   name = NULL;
> @@ -930,16 +931,16 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int index)
> 
>   rcrtc->clock = devm_clk_get(rcdu->dev, name);
>   if (IS_ERR(rcrtc->clock)) {
> - dev_err(rcdu->dev, "no clock for CRTC %u\n", index);
> + dev_err(rcdu->dev, "no clock for CRTC %u\n", swindex);

How about

dev_err(rcdu->dev, "no clock for DU channel %u\n", hwindex);

I think that would be clearer, because at this stage we're dealing with 
hardware resources, so matching the datasheet numbers seems better to me.

>   return PTR_ERR(rcrtc->clock);
>   }
> 
> - sprintf(clk_name, "dclkin.%u", index);
> + sprintf(clk_name, "dclkin.%u", hwindex);
>   clk = devm_clk_get(rcdu->dev, clk_name);
>   if (!IS_ERR(clk)) {
>   rcrtc->extclock = clk;
>   } else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
> - dev_info(rcdu->dev, "can't get external clock %u\n", index);
> + dev_info(rcdu->dev, "can't get external clock %u\n", hwindex);
>   return -EPROBE_DEFER;
>   }
> 
> @@ -948,13 +949,13 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int index) spin_lock_init(>vblank_lock);
> 
>   rcrtc->group = rgrp;
> - rcrtc->mmio_offset = mmio_offsets[index];
> - rcrtc->index = index;
> + rcrtc->mmio_offset = mmio_offsets[hwindex];
> + rcrtc->index = hwindex;
> 
>   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
>   primary = >vsp->planes[rcrtc->vsp_pipe].plane;
>   else
> - primary = >planes[index % 2].plane;
> + primary = >planes[hwindex % 2].plane;

This shouldn't make a difference because when RCAR_DU_FEATURE_VSP1_SOURCE 
isn't set we're running on Gen2, and don't need to deal with indices, but from 
a conceptual point of view, wouldn't the software index be better here ? 
Missing hardware channels won't be visible from userspace, so taking the first 
plane of the group as the primary plane would seem better to me.

>   ret = drm_crtc_init_with_planes(rcdu->ddev, crtc, primary, NULL,
>   rcdu->info->gen <= 2 ?
> @@ -970,7 +971,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int index)
> 
>   /* Register the interrupt handler. 

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #55 from i...@yahoo.com ---
(In reply to MirceaKitsune from comment #54)
> But there's a bizarre twist this time: When playing back the trace generated
> by Blender, my system will freeze at various points during the replay!
> Sometimes it freezes early, sometimes it freezes late, at other times I can
> replay the whole trace without getting a freeze at all.
> 
> This is very peculiar: The crash must be occurring beyond what apitrace is
> even capturing, likely something deep in the kernel or renderer which is
> only triggered when the conditions are just right. What do you make of this?

Well, this makes hardware issue a lot more probable.

Still, it is good that you have a trace that can trigger crashes.
Having an apitrace issuing same OpenGL commands eliminates a lot of variables. 

>From now on, you shell be using only this trace for your tests.

But first, you should try and setup `netconsole`.
I haven't used it myself so I can't give you any hints.
Still the documentation looks detailed. AFAIR you have it as module.

After you have it working, you can resume your experiments with environment
variables. And keep an eye on the kernel messages when a crash happens.

Few hints. If `MESA_NO_ASM=true` is set, then the other(MESA_NO_MMX=true ;
MESA_NO_3DNOW=true ; MESA_NO_SSE=true) have no effect.
And don't forget to test `export mesa_glthread=false` too.
Also try `export RADEON_THREAD=false` with the above.
Threading and concurrency just increase the random variables.

Your hope is to find something that always works, or some error that is always
present before crash.

You should also seriously consider testing the card on other OS or computer.
If that blender trace hangs on Windows, it definitely is not software issue.

Keep digging.

-- 
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 04/17] drm: rcar-du: Use the correct naming for ODPM fields in DEFR6

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 26 April 2018 19:53:33 EEST Kieran Bingham wrote:
> The naming of the fields for the ODPM signals in the DU extensional
> function control register 6 (DEFR6) is incorrect against the data sheets
> for both R-Car Gen2 and R-Car Gen3.
> 
> Rename the fields to match the datasheet.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

and taken in my tree.

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_group.c |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_regs.h  | 16 
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c index 2f37ea901873..eead202c95c7
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -46,10 +46,10 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32
> reg, u32 data)
> 
>  static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
>  {
> - u32 defr6 = DEFR6_CODE | DEFR6_ODPM12_DISP;
> + u32 defr6 = DEFR6_CODE | DEFR6_ODPM02_DISP;
> 
>   if (rgrp->num_crtcs > 1)
> - defr6 |= DEFR6_ODPM22_DISP;
> + defr6 |= DEFR6_ODPM12_DISP;
> 
>   rcar_du_group_write(rgrp, DEFR6, defr6);
>  }
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> b/drivers/gpu/drm/rcar-du/rcar_du_regs.h index d5bae99d3cfe..9dfd220ceda1
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_regs.h
> @@ -187,14 +187,14 @@
> 
>  #define DEFR60x000e8
>  #define DEFR6_CODE   (0x7778 << 16)
> -#define DEFR6_ODPM22_DSMR(0 << 10)
> -#define DEFR6_ODPM22_DISP(2 << 10)
> -#define DEFR6_ODPM22_CDE (3 << 10)
> -#define DEFR6_ODPM22_MASK(3 << 10)
> -#define DEFR6_ODPM12_DSMR(0 << 8)
> -#define DEFR6_ODPM12_DISP(2 << 8)
> -#define DEFR6_ODPM12_CDE (3 << 8)
> -#define DEFR6_ODPM12_MASK(3 << 8)
> +#define DEFR6_ODPM12_DSMR(0 << 10)
> +#define DEFR6_ODPM12_DISP(2 << 10)
> +#define DEFR6_ODPM12_CDE (3 << 10)
> +#define DEFR6_ODPM12_MASK(3 << 10)
> +#define DEFR6_ODPM02_DSMR(0 << 8)
> +#define DEFR6_ODPM02_DISP(2 << 8)
> +#define DEFR6_ODPM02_CDE (3 << 8)
> +#define DEFR6_ODPM02_MASK(3 << 8)
>  #define DEFR6_TCNE1  (1 << 6)
>  #define DEFR6_TCNE0  (1 << 4)
>  #define DEFR6_MLOS1  (1 << 2)

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 02/17] dt-bindings: display: renesas: du: Document the R8A77965 bindings

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 26 April 2018 19:57:32 EEST Kieran Bingham wrote:
> Ahem - this one seems to have lost it's commit message.
> 
> Apologies :)

Apart from that, this looks good to me.

Reviewed-by: Laurent Pinchart 

and applied to my tree with the commit message

Document the M3-N (r8a77965) SoC in the R-Car DU bindings

Let me know if you would like a different message.

> On 26/04/18 17:53, Kieran Bingham wrote:
> > Signed-off-by: Kieran Bingham 
> > ---
> > 
> >  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
> > a36a6e7ee54f..7c6854bd0a04 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> > 
> > @@ -13,6 +13,7 @@ Required Properties:
> >  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
> >  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
> >  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> > +- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
> >  - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> >  - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
> > 
> > @@ -59,6 +60,7 @@ corresponding to each DU output.
> > 
> >   R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  -
> >   R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS
> >   0
> >   R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 -
> > + R8A77965 (R-Car M3-N)  DPAD 0 HDMI 0 LVDS 0 -
> >   R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  -
> >   R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 -

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 01/17] dt-bindings: display: renesas: du: Increase indent in output table

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 26 April 2018 19:53:30 EEST Kieran Bingham wrote:
> The DU output table lists the port combinations for each supported DU
> type.  Newer models of R-Car Gen3 platforms have an increased string
> length.
> 
> Increase the table indentation in preparation for supporting new target
> types.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

and applied to my tree.

> ---
>  .../bindings/display/renesas,du.txt   | 26 +--
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> b/Documentation/devicetree/bindings/display/renesas,du.txt index
> c9cd17f99702..a36a6e7ee54f 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -47,20 +47,20 @@ bindings specified in
> Documentation/devicetree/bindings/graph.txt. The following table lists for
> each supported model the port number corresponding to each DU output.
> 
> -  Port0  Port1  Port2  Port3
> +Port0  Port1  Port2  Port3
>  ---
> -- - R8A7743 (RZ/G1M) DPAD 0 LVDS 0 -  - -
> R8A7745 (RZ/G1E) DPAD 0 DPAD 1 -  - -
> R8A7779 (R-Car H1)   DPAD 0 DPAD 1 -  - -
> R8A7790 (R-Car H2)   DPAD 0 LVDS 0 LVDS 1 - -
> R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 -  - -
> R8A7792 (R-Car V2H)  DPAD 0 DPAD 1 -  - -
> R8A7793 (R-Car M2-N) DPAD 0 LVDS 0 -  - -
> R8A7794 (R-Car E2)   DPAD 0 DPAD 1 -  - -
> R8A7795 (R-Car H3)   DPAD 0 HDMI 0 HDMI 1 LVDS 0 -
> R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - -
> R8A77970 (R-Car V3M) DPAD 0 LVDS 0 -  - -
> R8A77995 (R-Car D3)  DPAD 0 LVDS 0 LVDS 1 - +
> R8A7743 (RZ/G1M)   DPAD 0 LVDS 0 -  - +
> R8A7745 (RZ/G1E)   DPAD 0 DPAD 1 -  - +
> R8A7779 (R-Car H1) DPAD 0 DPAD 1 -  - +
> R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 - +
> R8A7791 (R-Car M2-W)   DPAD 0 LVDS 0 -  - +
> R8A7792 (R-Car V2H)DPAD 0 DPAD 1 -  - +
> R8A7793 (R-Car M2-N)   DPAD 0 LVDS 0 -  - +
> R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  - +
> R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
> + R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 - +
> R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  - +
> R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 -
> 
> 
>  Example: R8A7795 (R-Car H3) ES2.0 DU


-- 
Regards,

Laurent Pinchart



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

[Bug 106199] Cannot get back into DM after logoff (Linux 4.16.2+)

[bugzilla-daemon]

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

Konrad Wojtoń  changed:

   What|Removed |Added

 CC||kondzi...@gmail.com

--- Comment #3 from Konrad Wojtoń  ---
Created attachment 139145
  --> https://bugs.freedesktop.org/attachment.cgi?id=139145=edit
Xorg.0.log after crash

I have exactly the same blocky screen after logoff in SDDM with kernel 4.16.4
and RX 460. Xorg.0.log.amdgpu_logoff_crash contains xorg logs after crash.
Distro is gentoo, I have 3 screens connected to RX 460 - all get blocky screen.

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

Re: [PATCH 1/8] drm: bridge: Add support for static image formats

[Laurent Pinchart]

Hi Jacopo,

On Thursday, 26 April 2018 21:40:56 EEST jacopo mondi wrote:
> On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote:
> > On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote:
> >> Add support for storing image format information in DRM bridges with
> >> associated helper function.
> >> 
> >> This patch replicates for bridges what
> >> 'drm_display_info_set_bus_formats()'
> >> is for connectors.
> >> 
> >> Signed-off-by: Jacopo Mondi 
> >> ---
> >>  drivers/gpu/drm/drm_bridge.c | 30 ++
> >>  include/drm/drm_bridge.h |  8 
> >>  2 files changed, 38 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >> index 1638bfe..e2ad098 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -157,6 +157,36 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >>  }
> >>  
> >>  /**
> >> + * drm_bridge_set_bus_formats() - set bridge supported image formats
> >> + * @bridge: the bridge to set image formats in
> >> + * @formats: array of MEDIA_BUS_FMT\_ supported image formats
> > 
> > Why the \ (here and below) ?
> 
> mmm, I can't tell where I made that up from... Will change with
> MEDIA_BUS_FMT_*
> 
> >> + * @num_formats: number of elements in the @formats array
> >> + *
> >> + * Store a list of supported image formats in a bridge.
> >> + * See MEDIA_BUS_FMT_* definitions in
> >> include/uapi/linux/media-bus-format.h for
> >> + * a full list of available formats.
> >> + */
> >> +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32
> >> *formats,
> >> + unsigned int num_formats)
> >> +{
> >> +  u32 *fmts;
> >> +
> >> +  if (!formats || !num_formats)
> >> +  return -EINVAL;
> >> +
> >> +  fmts = kmemdup(formats, sizeof(*formats) * num_formats, GFP_KERNEL);
> > 
> > This memory will be leaked when the bridge is destroyed.
> 
> Right. I'm afraid this may open a pandora box, but, ehm, where is the
> bridge objects lifetime managed? The best I can think of is to use the
> resource managed version of kmemdup, associating that memory to
> the drm_device device object. That means the memory will be freed at
> DRM pipeline teardown time only if I'm not wrong. Can a bridge be
> destroyed before that?

The lifetime of the bridge is independent from the lifetime of the drm_device, 
so that won't work. It looks like we need to add a bridge cleanup operation 
:-/ You're right, it opens pandora's box.

My recommendation is to add a .release() operation to the bridge ops 
structure, and to implement a drm_bridge_cleanup() function that frees the 
bus_formats memory. Then, a drm_bridge_release() function can wrap the 
release() ops, and that should be called from the bridge driver .remove() 
handler. Or even butter, call the drm_bridge_release() function 
drm_bridge_put(), to pave the way for a reference-count-based implementation.

> >> +  if (!fmts)
> >> +  return -ENOMEM;
> >> +
> >> +  kfree(bridge->bus_formats);
> >> +  bridge->bus_formats = fmts;
> >> +  bridge->num_bus_formats = num_formats;
> >> +
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL(drm_bridge_set_bus_formats);
> >> +
> >> +/**
> >>   * DOC: bridge callbacks
> >>   *
> >>   * The _bridge_funcs ops are populated by the bridge driver. The
> >>   DRM
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index 3270fec..6b3648c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -258,6 +258,9 @@ struct drm_bridge_timings {
> >>   * @encoder: encoder to which this bridge is connected
> >>   * @next: the next bridge in the encoder chain
> >>   * @of_node: device node pointer to the bridge
> >> + * @bus_formats: wire image formats. Array of @num_bus_formats
> >> MEDIA_BUS_FMT\_
> >> + * elements
> >> + * @num_bus_formats: size of @bus_formats array
> >>   * @list: to keep track of all added bridges
> >>   * @timings: the timing specification for the bridge, if any (may
> >>   * be NULL)
> >> @@ -271,6 +274,9 @@ struct drm_bridge {
> >>  #ifdef CONFIG_OF
> >>struct device_node *of_node;
> >>  #endif
> >> +  const u32 *bus_formats;
> >> +  unsigned int num_bus_formats;
> >> +
> >>struct list_head list;
> >>const struct drm_bridge_timings *timings;
> >> 
> >> @@ -296,6 +302,8 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
> >>struct drm_display_mode *adjusted_mode);
> >>  void drm_bridge_pre_enable(struct drm_bridge *bridge);
> >>  void drm_bridge_enable(struct drm_bridge *bridge);
> >> +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32
> >> *fmts,
> >> + unsigned int num_fmts);
> >> 
> >>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,

-- 
Regards,

Laurent Pinchart



___
dri-devel mailing list

[PATCH v5] drm/panel: simple: Add TFC S9700RTWV43TR-01B 800x480 panel support

[Jyri Sarha]

Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
panel with resistive touch found on TI's AM335X-EVM.

Signed-off-by: Jyri Sarha 
Reviewed-by: Tomi Valkeinen 
cc: Thierry Reding 
---
Thanks Thierry, for reminding me about this!

Changes since v4:
- Add tfc to vendor-prefixes.txt

 .../display/panel/tfc,s9700rtwv43tr-01b.txt| 10 +
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 3 files changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt 
b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt
new file mode 100644
index 000..0b1cc71
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt
@@ -0,0 +1,10 @@
+TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with
+resistive touch
+
+The panel is found on TI AM335x-evm.
+
+Required properties:
+- compatible: should be "tfc,S9700RTWV43tr-01b"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 12e8b3e..4ec0d6b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -356,6 +356,7 @@ technexion  TechNexion
 technologicTechnologic Systems
 tempo  Tempo Semiconductor
 terasicTerasic Inc.
+tfcThree Five Corp
 thine  THine Electronics, Inc.
 ti Texas Instruments
 tianma Tianma Micro-electronics Co., Ltd.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab4..f2d96611 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1891,6 +1891,29 @@ static const struct panel_desc starry_kr122ea0sra = {
},
 };
 
+static const struct drm_display_mode tfc_s9700rtwv43tr_01b_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 39,
+   .hsync_end = 800 + 39 + 47,
+   .htotal = 800 + 39 + 47 + 39,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 2,
+   .vtotal = 480 + 13 + 2 + 29,
+   .vrefresh = 62,
+};
+
+static const struct panel_desc tfc_s9700rtwv43tr_01b = {
+   .modes = _s9700rtwv43tr_01b_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 155,
+   .height = 90,
+   },
+};
+
 static const struct display_timing tianma_tm070jdhg30_timing = {
.pixelclock = { 6260, 6820, 7810 },
.hactive = { 1280, 1280, 1280 },
@@ -2251,6 +2274,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "starry,kr122ea0sra",
.data = _kr122ea0sra,
}, {
+   .compatible = "tfc,s9700rtwv43tr-01b",
+   .data = _s9700rtwv43tr_01b,
+   }, {
.compatible = "tianma,tm070jdhg30",
.data = _tm070jdhg30,
}, {
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #10 from Harry Wentland  ---
No worries. Don't hesitate to open a new ticket if your warning/error log seems
to indicate amdgpu. I'd be happy to take a brief look.

Even if I won't have time to provide an immediate fix it will still allow me to
better understand what problems people have with our driver and where we might
need to spend more effort.

-- 
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 hwc 3/4] drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag

[Robert Foss]

This patch is:
Acked-by: Robert Foss 


On 04/26/2018 09:05 PM, John Stultz wrote:

The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is done in SurfaceFlinger, but in theory can
be more highly optimized for the hardware.

Unfortunately, due to these optimizations, the drm_hwcomposer's
pre-compositor becomes somewhat hardware specific (originally
targeting nvidia hardware, I believe).

So on some hardware, the gl precompositor may not actually
initialize due to hardware missing features, or the hardware
supporting different shader APIs.

Rather then try to rework the drm_hwcomposers precompositor
to be more generic, I instead suggest that when the
precompositor fails to initialize, we simply fall back to the
already more widely compatible client compositor in
SurfaceFlinger.

Thus, this patch cleans up some of the precompositor
initialization, which didn't handle failures well.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Reviewed-by: Rob Herring 
Signed-off-by: John Stultz 
---
  drmdisplaycompositor.cpp | 40 +---
  drmdisplaycompositor.h   |  3 +++
  2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e570923..40af3be 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -222,6 +222,13 @@ int DrmDisplayCompositor::Init(DrmResources *drm, int 
display) {
  return ret;
}
  
+  pre_compositor_.reset(new GLWorkerCompositor());

+  ret = pre_compositor_->Init();
+  if (ret) {
+ALOGE("Failed to initialize OpenGL compositor %d", ret);
+pre_compositor_.reset();
+  }
+
initialized_ = true;
return 0;
  }
@@ -294,14 +301,16 @@ int 
DrmDisplayCompositor::ApplySquash(DrmDisplayComposition *display_comp) {
}
  
std::vector  = display_comp->squash_regions();

-  ret = pre_compositor_->Composite(display_comp->layers().data(),
+  if (pre_compositor_) {
+ret = pre_compositor_->Composite(display_comp->layers().data(),
 regions.data(), regions.size(), 
fb.buffer(),
 display_comp->importer());
-  pre_compositor_->Finish();
+pre_compositor_->Finish();
  
-  if (ret) {

-ALOGE("Failed to squash layers");
-return ret;
+if (ret) {
+  ALOGE("Failed to squash layers");
+  return ret;
+}
}
  
ret = display_comp->CreateNextTimelineFence();

@@ -328,14 +337,16 @@ int DrmDisplayCompositor::ApplyPreComposite(
}
  
std::vector  = display_comp->pre_comp_regions();

-  ret = pre_compositor_->Composite(display_comp->layers().data(),
+  if (pre_compositor_) {
+ret = pre_compositor_->Composite(display_comp->layers().data(),
 regions.data(), regions.size(), 
fb.buffer(),
 display_comp->importer());
-  pre_compositor_->Finish();
+pre_compositor_->Finish();
  
-  if (ret) {

-ALOGE("Failed to pre-composite layers");
-return ret;
+if (ret) {
+  ALOGE("Failed to pre-composite layers");
+  return ret;
+}
}
  
ret = display_comp->CreateNextTimelineFence();

@@ -395,15 +406,6 @@ int 
DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
std::vector _comp_regions =
display_comp->pre_comp_regions();
  
-  if (!pre_compositor_) {

-pre_compositor_.reset(new GLWorkerCompositor());
-int ret = pre_compositor_->Init();
-if (ret) {
-  ALOGE("Failed to initialize OpenGL compositor %d", ret);
-  return ret;
-}
-  }
-
int squash_layer_index = -1;
if (squash_regions.size() > 0) {
  squash_framebuffer_index_ = (squash_framebuffer_index_ + 1) % 2;
diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
index f1965fb..ed6c5f9 100644
--- a/drmdisplaycompositor.h
+++ b/drmdisplaycompositor.h
@@ -98,6 +98,9 @@ class DrmDisplayCompositor {
  return _state_;
}
  
+  bool uses_GL() {

+return !!pre_compositor_;
+  }
   private:
struct ModeState {
  bool needs_modeset = false;


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

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #9 from Jon  ---
(In reply to Harry Wentland from comment #8)
> (In reply to Jon from comment #7)
> > (In reply to Harry Wentland from comment #6)
> > > Marking resolved as no longer an issue on recent mainline.
> > 
> > Which commit fixes this? I merged in agd5f/drm-fixes-4.17 into linus master:
> > Merge: 3be4aaf4e2d3 7ad35721e7d5
> > 
> 
> I believe it was this:
> 8acad1a18a78 drm/amd/display: Add regamma lut write mask to SOC base
> 
> 
> > I still see these crashes on every startup, with the following graphics 
> > card:
> > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> > Tonga XT / Amethyst XT [Radeon R9 380X / R9 M295X] (rev f1)
> > 
> 
> Are you seeing a crash or simply the error log described in this ticket?
I'm sorry, I think I've been mislead by the warning so I didn't actually go
through the stack properly on my recent boot. What I'm seeing now seem to be
the same warning line, however it shows a different stack and hence most likely
a different issue. And of course I was wrong to say crash, as nothing stops
after those warnings.

The crash I'm trying to debug is something completely different(every time I
lock screen, machine hangs at least keyboard/screen etc.), I'm just trying to
filter out the other warnings/errors I see to figure out what might be related.
Sorry for the disturbance :)
> 
> > regards

-- 
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 hwc 2/4] drm_hwcomposer: Use log/log.h instead of cutils/log.h

[Robert Foss]

This patch is:
Acked-by: Robert Foss 


On 04/26/2018 09:05 PM, John Stultz wrote:

When enabling Treble, Android builds are complaining about using
cutils/log.h so instead use log/log.h

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Signed-off-by: John Stultz 
---
  autolock.cpp| 2 +-
  drmcompositorworker.cpp | 2 +-
  drmconnector.cpp| 2 +-
  drmcrtc.cpp | 2 +-
  drmdisplaycomposition.cpp   | 2 +-
  drmdisplaycompositor.cpp| 2 +-
  drmeventlistener.cpp| 2 +-
  drmhwctwo.cpp   | 2 +-
  drmplane.cpp| 2 +-
  drmresources.cpp| 2 +-
  hwcomposer.cpp  | 2 +-
  hwcutils.cpp| 2 +-
  platform.cpp| 2 +-
  platformdrmgeneric.cpp  | 2 +-
  platformhisi.cpp| 2 +-
  virtualcompositorworker.cpp | 2 +-
  vsyncworker.cpp | 2 +-
  17 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/autolock.cpp b/autolock.cpp
index 1a2ded7..795a8c2 100644
--- a/autolock.cpp
+++ b/autolock.cpp
@@ -22,7 +22,7 @@
  #include 
  #include 
  
-#include 

+#include 
  
  namespace android {
  
diff --git a/drmcompositorworker.cpp b/drmcompositorworker.cpp

index a4e7fc9..695876d 100644
--- a/drmcompositorworker.cpp
+++ b/drmcompositorworker.cpp
@@ -22,7 +22,7 @@
  
  #include 
  
-#include 

+#include 
  #include 
  
  namespace android {

diff --git a/drmconnector.cpp b/drmconnector.cpp
index 145518f..10b96b5 100644
--- a/drmconnector.cpp
+++ b/drmconnector.cpp
@@ -22,7 +22,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  
  namespace android {

diff --git a/drmcrtc.cpp b/drmcrtc.cpp
index 1b354fe..4033269 100644
--- a/drmcrtc.cpp
+++ b/drmcrtc.cpp
@@ -22,7 +22,7 @@
  #include 
  #include 
  
-#include 

+#include 
  
  namespace android {
  
diff --git a/drmdisplaycomposition.cpp b/drmdisplaycomposition.cpp

index 66e67a4..24a8e9c 100644
--- a/drmdisplaycomposition.cpp
+++ b/drmdisplaycomposition.cpp
@@ -28,7 +28,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include 
  #include 
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e556e86..e570923 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -26,7 +26,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include 
  #include 
diff --git a/drmeventlistener.cpp b/drmeventlistener.cpp
index 5534182..9cdff81 100644
--- a/drmeventlistener.cpp
+++ b/drmeventlistener.cpp
@@ -24,7 +24,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include 
  #include 
diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index dfca1a6..8e00d71 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -26,7 +26,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include 
  #include 
diff --git a/drmplane.cpp b/drmplane.cpp
index 1f739ae..4449256 100644
--- a/drmplane.cpp
+++ b/drmplane.cpp
@@ -23,7 +23,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  
  namespace android {

diff --git a/drmresources.cpp b/drmresources.cpp
index 32dd376..ec6664c 100644
--- a/drmresources.cpp
+++ b/drmresources.cpp
@@ -30,7 +30,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  
  namespace android {

diff --git a/hwcomposer.cpp b/hwcomposer.cpp
index c0aafef..338e042 100644
--- a/hwcomposer.cpp
+++ b/hwcomposer.cpp
@@ -39,7 +39,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include 
  #include 
diff --git a/hwcutils.cpp b/hwcutils.cpp
index 53a7d82..715c93e 100644
--- a/hwcutils.cpp
+++ b/hwcutils.cpp
@@ -20,7 +20,7 @@
  #include "drmhwcomposer.h"
  #include "platform.h"
  
-#include 

+#include 
  
  namespace android {
  
diff --git a/platform.cpp b/platform.cpp

index 56ab37e..62b03a8 100644
--- a/platform.cpp
+++ b/platform.cpp
@@ -19,7 +19,7 @@
  #include "drmresources.h"
  #include "platform.h"
  
-#include 

+#include 
  
  namespace android {
  
diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp

index 2a6773c..8253967 100644
--- a/platformdrmgeneric.cpp
+++ b/platformdrmgeneric.cpp
@@ -24,7 +24,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include 
  #include 
diff --git a/platformhisi.cpp b/platformhisi.cpp
index 16c5e6f..3f5c319 100644
--- a/platformhisi.cpp
+++ b/platformhisi.cpp
@@ -27,7 +27,7 @@
  #include 
  #include 
  
-#include 

+#include 
  #include 
  #include "gralloc_priv.h"
  
diff --git a/virtualcompositorworker.cpp b/virtualcompositorworker.cpp

index 639dc86..b64b414 100644

Re: [PATCH hwc 1/4] drm_hwcomposer: Andorid.mk : Mark libdrmhwc_utils as vendor module

[Robert Foss]

This patch is:
Acked-by: Robert Foss 

On 04/26/2018 09:05 PM, John Stultz wrote:

From: Sumit Semwal 

To allow drm_hwcomposer to build with Treble, set
the libdrmhwc_utils library as a vendor module.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Signed-off-by: Sumit Semwal 
[jstultz: commit message tweaks]
Signed-off-by: John Stultz 
---
  Android.mk | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Android.mk b/Android.mk
index 1add286..a60d112 100644
--- a/Android.mk
+++ b/Android.mk
@@ -25,6 +25,7 @@ LOCAL_SRC_FILES := \
worker.cpp
  
  LOCAL_MODULE := libdrmhwc_utils

+LOCAL_VENDOR_MODULE := true
  
  include $(BUILD_STATIC_LIBRARY)
  


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

[PATCH] drm/dp: Rename the edp_sdp_header as dp_sdp_header

[Manasi Navare]

No functional changes in this patch.

The SDP Header is a generic header for secondary data packets for
both eDP and DP so call it dp_sdp_header. This header gets used for
different SDP types already defined.
Also header bytes 2 and 3 are secondary data packet specific header bytes.
So change the comment to indicate the same.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dp_helper.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 91c9bcd..2d55036 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -977,18 +977,18 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw);
 #define DP_SDP_VSC_EXT_CEA 0x21 /* DP 1.4 */
 /* 0x80+ CEA-861 infoframe types */
 
-struct edp_sdp_header {
+struct dp_sdp_header {
u8 HB0; /* Secondary Data Packet ID */
u8 HB1; /* Secondary Data Packet Type */
-   u8 HB2; /* 7:5 reserved, 4:0 revision number */
-   u8 HB3; /* 7:5 reserved, 4:0 number of valid data bytes */
+   u8 HB2; /* Secondary Data Packet Specific header, Byte 0 */
+   u8 HB3; /* Secondary Data packet Specific header, Byte 1 */
 } __packed;
 
 #define EDP_SDP_HEADER_REVISION_MASK   0x1F
 #define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
 
 struct edp_vsc_psr {
-   struct edp_sdp_header sdp_header;
+   struct dp_sdp_header sdp_header;
u8 DB0; /* Stereo Interface */
u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
-- 
2.7.4

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

[PATCH hwc 2/4] drm_hwcomposer: Use log/log.h instead of cutils/log.h

[John Stultz]

When enabling Treble, Android builds are complaining about using
cutils/log.h so instead use log/log.h

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Signed-off-by: John Stultz 
---
 autolock.cpp| 2 +-
 drmcompositorworker.cpp | 2 +-
 drmconnector.cpp| 2 +-
 drmcrtc.cpp | 2 +-
 drmdisplaycomposition.cpp   | 2 +-
 drmdisplaycompositor.cpp| 2 +-
 drmeventlistener.cpp| 2 +-
 drmhwctwo.cpp   | 2 +-
 drmplane.cpp| 2 +-
 drmresources.cpp| 2 +-
 hwcomposer.cpp  | 2 +-
 hwcutils.cpp| 2 +-
 platform.cpp| 2 +-
 platformdrmgeneric.cpp  | 2 +-
 platformhisi.cpp| 2 +-
 virtualcompositorworker.cpp | 2 +-
 vsyncworker.cpp | 2 +-
 17 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/autolock.cpp b/autolock.cpp
index 1a2ded7..795a8c2 100644
--- a/autolock.cpp
+++ b/autolock.cpp
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 namespace android {
 
diff --git a/drmcompositorworker.cpp b/drmcompositorworker.cpp
index a4e7fc9..695876d 100644
--- a/drmcompositorworker.cpp
+++ b/drmcompositorworker.cpp
@@ -22,7 +22,7 @@
 
 #include 
 
-#include 
+#include 
 #include 
 
 namespace android {
diff --git a/drmconnector.cpp b/drmconnector.cpp
index 145518f..10b96b5 100644
--- a/drmconnector.cpp
+++ b/drmconnector.cpp
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 namespace android {
diff --git a/drmcrtc.cpp b/drmcrtc.cpp
index 1b354fe..4033269 100644
--- a/drmcrtc.cpp
+++ b/drmcrtc.cpp
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 namespace android {
 
diff --git a/drmdisplaycomposition.cpp b/drmdisplaycomposition.cpp
index 66e67a4..24a8e9c 100644
--- a/drmdisplaycomposition.cpp
+++ b/drmdisplaycomposition.cpp
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e556e86..e570923 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -26,7 +26,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drmeventlistener.cpp b/drmeventlistener.cpp
index 5534182..9cdff81 100644
--- a/drmeventlistener.cpp
+++ b/drmeventlistener.cpp
@@ -24,7 +24,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index dfca1a6..8e00d71 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -26,7 +26,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drmplane.cpp b/drmplane.cpp
index 1f739ae..4449256 100644
--- a/drmplane.cpp
+++ b/drmplane.cpp
@@ -23,7 +23,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 namespace android {
diff --git a/drmresources.cpp b/drmresources.cpp
index 32dd376..ec6664c 100644
--- a/drmresources.cpp
+++ b/drmresources.cpp
@@ -30,7 +30,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 namespace android {
diff --git a/hwcomposer.cpp b/hwcomposer.cpp
index c0aafef..338e042 100644
--- a/hwcomposer.cpp
+++ b/hwcomposer.cpp
@@ -39,7 +39,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/hwcutils.cpp b/hwcutils.cpp
index 53a7d82..715c93e 100644
--- a/hwcutils.cpp
+++ b/hwcutils.cpp
@@ -20,7 +20,7 @@
 #include "drmhwcomposer.h"
 #include "platform.h"
 
-#include 
+#include 
 
 namespace android {
 
diff --git a/platform.cpp b/platform.cpp
index 56ab37e..62b03a8 100644
--- a/platform.cpp
+++ b/platform.cpp
@@ -19,7 +19,7 @@
 #include "drmresources.h"
 #include "platform.h"
 
-#include 
+#include 
 
 namespace android {
 
diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
index 2a6773c..8253967 100644
--- a/platformdrmgeneric.cpp
+++ b/platformdrmgeneric.cpp
@@ -24,7 +24,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/platformhisi.cpp b/platformhisi.cpp
index 16c5e6f..3f5c319 100644
--- a/platformhisi.cpp
+++ b/platformhisi.cpp
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include "gralloc_priv.h"
 
diff --git a/virtualcompositorworker.cpp b/virtualcompositorworker.cpp
index 639dc86..b64b414 100644
--- a/virtualcompositorworker.cpp
+++ b/virtualcompositorworker.cpp
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/vsyncworker.cpp b/vsyncworker.cpp
index 3bfe4be..d431d2e 100644
--- 

[PATCH hwc 4/4] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

[John Stultz]

If the gl precompositor isn't being used, we cannot accept
every layer as a device composited layer.

Thus this patch adds some extra logic in the validate function
to fall back to client side compositing if the gl precompositor
did not initialize properly.

This does force everything to a single plane even if we have
a few available, but a deeper rework of the validate step
planning is needed before we can reliably make use of them.

Credit to Rob Herring, who's single plane patch was what this
was originally based on.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Reviewed-by: Rob Herring 
Signed-off-by: John Stultz 
---
v2:
* Dropped misguided attempt to trivially allocate layers to planes
---
 drmhwctwo.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index 8e00d71..ede75e0 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -695,6 +695,13 @@ HWC2::Error 
DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
 layer.set_validated_type(HWC2::Composition::Client);
 ++*num_types;
 break;
+  case HWC2::Composition::Device:
+if (!compositor_.uses_GL()) {
+  layer.set_validated_type(HWC2::Composition::Client);
+  ++*num_types;
+  break;
+}
+   /* fall through */
   default:
 layer.set_validated_type(layer.sf_type());
 break;
-- 
2.7.4

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

[PATCH hwc 1/4] drm_hwcomposer: Andorid.mk : Mark libdrmhwc_utils as vendor module

[John Stultz]

From: Sumit Semwal 

To allow drm_hwcomposer to build with Treble, set
the libdrmhwc_utils library as a vendor module.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Signed-off-by: Sumit Semwal 
[jstultz: commit message tweaks]
Signed-off-by: John Stultz 
---
 Android.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Android.mk b/Android.mk
index 1add286..a60d112 100644
--- a/Android.mk
+++ b/Android.mk
@@ -25,6 +25,7 @@ LOCAL_SRC_FILES := \
worker.cpp
 
 LOCAL_MODULE := libdrmhwc_utils
+LOCAL_VENDOR_MODULE := true
 
 include $(BUILD_STATIC_LIBRARY)
 
-- 
2.7.4

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

[PATCH hwc 3/4] drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag

[John Stultz]

The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is done in SurfaceFlinger, but in theory can
be more highly optimized for the hardware.

Unfortunately, due to these optimizations, the drm_hwcomposer's
pre-compositor becomes somewhat hardware specific (originally
targeting nvidia hardware, I believe).

So on some hardware, the gl precompositor may not actually
initialize due to hardware missing features, or the hardware
supporting different shader APIs.

Rather then try to rework the drm_hwcomposers precompositor
to be more generic, I instead suggest that when the
precompositor fails to initialize, we simply fall back to the
already more widely compatible client compositor in
SurfaceFlinger.

Thus, this patch cleans up some of the precompositor
initialization, which didn't handle failures well.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Reviewed-by: Rob Herring 
Signed-off-by: John Stultz 
---
 drmdisplaycompositor.cpp | 40 +---
 drmdisplaycompositor.h   |  3 +++
 2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e570923..40af3be 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -222,6 +222,13 @@ int DrmDisplayCompositor::Init(DrmResources *drm, int 
display) {
 return ret;
   }
 
+  pre_compositor_.reset(new GLWorkerCompositor());
+  ret = pre_compositor_->Init();
+  if (ret) {
+ALOGE("Failed to initialize OpenGL compositor %d", ret);
+pre_compositor_.reset();
+  }
+
   initialized_ = true;
   return 0;
 }
@@ -294,14 +301,16 @@ int 
DrmDisplayCompositor::ApplySquash(DrmDisplayComposition *display_comp) {
   }
 
   std::vector  = display_comp->squash_regions();
-  ret = pre_compositor_->Composite(display_comp->layers().data(),
+  if (pre_compositor_) {
+ret = pre_compositor_->Composite(display_comp->layers().data(),
regions.data(), regions.size(), fb.buffer(),
display_comp->importer());
-  pre_compositor_->Finish();
+pre_compositor_->Finish();
 
-  if (ret) {
-ALOGE("Failed to squash layers");
-return ret;
+if (ret) {
+  ALOGE("Failed to squash layers");
+  return ret;
+}
   }
 
   ret = display_comp->CreateNextTimelineFence();
@@ -328,14 +337,16 @@ int DrmDisplayCompositor::ApplyPreComposite(
   }
 
   std::vector  = 
display_comp->pre_comp_regions();
-  ret = pre_compositor_->Composite(display_comp->layers().data(),
+  if (pre_compositor_) {
+ret = pre_compositor_->Composite(display_comp->layers().data(),
regions.data(), regions.size(), fb.buffer(),
display_comp->importer());
-  pre_compositor_->Finish();
+pre_compositor_->Finish();
 
-  if (ret) {
-ALOGE("Failed to pre-composite layers");
-return ret;
+if (ret) {
+  ALOGE("Failed to pre-composite layers");
+  return ret;
+}
   }
 
   ret = display_comp->CreateNextTimelineFence();
@@ -395,15 +406,6 @@ int 
DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
   std::vector _comp_regions =
   display_comp->pre_comp_regions();
 
-  if (!pre_compositor_) {
-pre_compositor_.reset(new GLWorkerCompositor());
-int ret = pre_compositor_->Init();
-if (ret) {
-  ALOGE("Failed to initialize OpenGL compositor %d", ret);
-  return ret;
-}
-  }
-
   int squash_layer_index = -1;
   if (squash_regions.size() > 0) {
 squash_framebuffer_index_ = (squash_framebuffer_index_ + 1) % 2;
diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
index f1965fb..ed6c5f9 100644
--- a/drmdisplaycompositor.h
+++ b/drmdisplaycompositor.h
@@ -98,6 +98,9 @@ class DrmDisplayCompositor {
 return _state_;
   }
 
+  bool uses_GL() {
+return !!pre_compositor_;
+  }
  private:
   struct ModeState {
 bool needs_modeset = false;
-- 
2.7.4

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

Re: [PATCH 1/8] drm: bridge: Add support for static image formats

[jacopo mondi]

Hi Peter,

On Sun, Apr 22, 2018 at 10:02:23PM +0200, Peter Rosin wrote:
> On 2018-04-19 11:31, Jacopo Mondi wrote:
> > Add support for storing image format information in DRM bridges with
> > associated helper function.
> >
> > This patch replicates for bridges what 'drm_display_info_set_bus_formats()'
> > is for connectors.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/gpu/drm/drm_bridge.c | 30 ++
> >  include/drm/drm_bridge.h |  8 
> >  2 files changed, 38 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 1638bfe..e2ad098 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -157,6 +157,36 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >  }
> >
> >  /**
> > + * drm_bridge_set_bus_formats() - set bridge supported image formats
> > + * @bridge: the bridge to set image formats in
> > + * @formats: array of MEDIA_BUS_FMT\_ supported image formats
> > + * @num_formats: number of elements in the @formats array
> > + *
> > + * Store a list of supported image formats in a bridge.
> > + * See MEDIA_BUS_FMT_* definitions in 
> > include/uapi/linux/media-bus-format.h for
> > + * a full list of available formats.
> > + */
> > +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32 
> > *formats,
> > +  unsigned int num_formats)
> > +{
> > +   u32 *fmts;
> > +
> > +   if (!formats || !num_formats)
> > +   return -EINVAL;
>
> I see no compelling reason to forbid restoring the number of reported
> input formats to zero? I can't think of a use right now of course, but it
> seems a bit odd all the same.

It is, you're right. Will fix in v2 and will allow bridges to just
restore formats to 0 (as it is done for drm_connectors, by the way)

Thanks
   j
>
> Cheers,
> Peter
>
> > +
> > +   fmts = kmemdup(formats, sizeof(*formats) * num_formats, GFP_KERNEL);
> > +   if (!fmts)
> > +   return -ENOMEM;
> > +
> > +   kfree(bridge->bus_formats);
> > +   bridge->bus_formats = fmts;
> > +   bridge->num_bus_formats = num_formats;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_bridge_set_bus_formats);
> > +
> > +/**
> >   * DOC: bridge callbacks
> >   *
> >   * The _bridge_funcs ops are populated by the bridge driver. The DRM
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index 3270fec..6b3648c 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -258,6 +258,9 @@ struct drm_bridge_timings {
> >   * @encoder: encoder to which this bridge is connected
> >   * @next: the next bridge in the encoder chain
> >   * @of_node: device node pointer to the bridge
> > + * @bus_formats: wire image formats. Array of @num_bus_formats 
> > MEDIA_BUS_FMT\_
> > + * elements
> > + * @num_bus_formats: size of @bus_formats array
> >   * @list: to keep track of all added bridges
> >   * @timings: the timing specification for the bridge, if any (may
> >   * be NULL)
> > @@ -271,6 +274,9 @@ struct drm_bridge {
> >  #ifdef CONFIG_OF
> > struct device_node *of_node;
> >  #endif
> > +   const u32 *bus_formats;
> > +   unsigned int num_bus_formats;
> > +
> > struct list_head list;
> > const struct drm_bridge_timings *timings;
> >
> > @@ -296,6 +302,8 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
> > struct drm_display_mode *adjusted_mode);
> >  void drm_bridge_pre_enable(struct drm_bridge *bridge);
> >  void drm_bridge_enable(struct drm_bridge *bridge);
> > +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32 *fmts,
> > +  unsigned int num_fmts);
> >
> >  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >
>


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

Re: [PATCH 1/8] drm: bridge: Add support for static image formats

[jacopo mondi]

Hi Laurent,

On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote:
> > Add support for storing image format information in DRM bridges with
> > associated helper function.
> >
> > This patch replicates for bridges what 'drm_display_info_set_bus_formats()'
> > is for connectors.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/gpu/drm/drm_bridge.c | 30 ++
> >  include/drm/drm_bridge.h |  8 
> >  2 files changed, 38 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 1638bfe..e2ad098 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -157,6 +157,36 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >  }
> >
> >  /**
> > + * drm_bridge_set_bus_formats() - set bridge supported image formats
> > + * @bridge: the bridge to set image formats in
> > + * @formats: array of MEDIA_BUS_FMT\_ supported image formats
>
> Why the \ (here and below) ?

mmm, I can't tell where I made that up from... Will change with
MEDIA_BUS_FMT_*

>
> > + * @num_formats: number of elements in the @formats array
> > + *
> > + * Store a list of supported image formats in a bridge.
> > + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h
> > for
> > + * a full list of available formats.
> > + */
> > +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32
> > *formats,
> > +  unsigned int num_formats)
> > +{
> > +   u32 *fmts;
> > +
> > +   if (!formats || !num_formats)
> > +   return -EINVAL;
> > +
> > +   fmts = kmemdup(formats, sizeof(*formats) * num_formats, GFP_KERNEL);
>
> This memory will be leaked when the bridge is destroyed.

Right. I'm afraid this may open a pandora box, but, ehm, where is the
bridge objects lifetime managed? The best I can think of is to use the
resource managed version of kmemdup, associating that memory to
the drm_device device object. That means the memory will be freed at
DRM pipeline teardown time only if I'm not wrong. Can a bridge be
destroyed before that?

Thanks
   j

>
> > +   if (!fmts)
> > +   return -ENOMEM;
> > +
> > +   kfree(bridge->bus_formats);
> > +   bridge->bus_formats = fmts;
> > +   bridge->num_bus_formats = num_formats;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_bridge_set_bus_formats);
> > +
> > +/**
> >   * DOC: bridge callbacks
> >   *
> >   * The _bridge_funcs ops are populated by the bridge driver. The DRM
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index 3270fec..6b3648c 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -258,6 +258,9 @@ struct drm_bridge_timings {
> >   * @encoder: encoder to which this bridge is connected
> >   * @next: the next bridge in the encoder chain
> >   * @of_node: device node pointer to the bridge
> > + * @bus_formats: wire image formats. Array of @num_bus_formats
> > MEDIA_BUS_FMT\_
> > + * elements
> > + * @num_bus_formats: size of @bus_formats array
> >   * @list: to keep track of all added bridges
> >   * @timings: the timing specification for the bridge, if any (may
> >   * be NULL)
> > @@ -271,6 +274,9 @@ struct drm_bridge {
> >  #ifdef CONFIG_OF
> > struct device_node *of_node;
> >  #endif
> > +   const u32 *bus_formats;
> > +   unsigned int num_bus_formats;
> > +
> > struct list_head list;
> > const struct drm_bridge_timings *timings;
> >
> > @@ -296,6 +302,8 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
> > struct drm_display_mode *adjusted_mode);
> >  void drm_bridge_pre_enable(struct drm_bridge *bridge);
> >  void drm_bridge_enable(struct drm_bridge *bridge);
> > +int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32 *fmts,
> > +  unsigned int num_fmts);
> >
> >  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>


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

Re: [PATCH] drm/amd/display: Remove erroneous if statement in gamma set

[Harry Wentland]

On 2018-04-26 10:46 AM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li" 
> 
> The lines were removed as part of the original change. They may have
> been missed during merge.
> 
> This is a fixup to:
> 
> committ 265083076187e619aa9176aeb05ad630013429b4
> Author: Leo (Sunpeng) Li 
> Date:   Fri Feb 2 10:18:56 2018 -0500
> 
> drm/amd/display: Hookup color management functions

Missing SOB?

With that fixed this is
Reviewed-by: Harry Wentland 

I would like Kevin to take a look before merging first. It looks like this line 
was unintentionally left when merging to amd-mainline-dkms-4.15 but would like 
to confirm that's the case.

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index b7265f6..0d4a133 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2206,11 +2206,9 @@ static int fill_plane_attributes(struct amdgpu_device 
> *adev,
>  
>   dc_plane_state->in_transfer_func = input_tf;
>  
> - /* In case of gamma set, update gamma value */
>  #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0) || \
>   defined(OS_NAME_RHEL_7_3) || \
>   defined(OS_NAME_RHEL_7_4_5)
> - if (crtc_state->gamma_lut)
>   /*
>* Always set input transfer function, since plane state is refreshed
>* every time.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

--- Comment #10 from Harry Wentland  ---
Thanks for reporting, testing, and quick feedback. It's greatly 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

[radeon-alex:drm-next-4.18-wip 259/261] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1369:9: warning: missing braces around initializer

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head:   92fb37464bd2b759d74f33c3b90a27575601745d
commit: b5f9f0f4bd3b061c10899d66a9d8d7d8e7e6bbd0 [259/261] drm/amd/powerplay: 
add smumgr support for VEGAM (v2)
config: i386-randconfig-a0-201816 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout b5f9f0f4bd3b061c10899d66a9d8d7d8e7e6bbd0
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: In function 
'vegam_program_memory_timing_parameters':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1369:9: 
>> warning: missing braces around initializer [-Wmissing-braces]
 struct SMU75_Discrete_MCArbDramTimingTable arb_regs = {0};
^
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1369:9: 
warning: (near initialization for 'arb_regs.entries') [-Wmissing-braces]

vim +1369 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c

  1364  
  1365  static int vegam_program_memory_timing_parameters(struct pp_hwmgr 
*hwmgr)
  1366  {
  1367  struct smu7_hwmgr *hw_data = (struct smu7_hwmgr 
*)(hwmgr->backend);
  1368  struct vegam_smumgr *smu_data = (struct vegam_smumgr 
*)(hwmgr->smu_backend);
> 1369  struct SMU75_Discrete_MCArbDramTimingTable arb_regs = {0};
  1370  uint32_t i, j;
  1371  int result = 0;
  1372  
  1373  for (i = 0; i < hw_data->dpm_table.sclk_table.count; i++) {
  1374  for (j = 0; j < hw_data->dpm_table.mclk_table.count; 
j++) {
  1375  result = 
vegam_populate_memory_timing_parameters(hwmgr,
  1376  
hw_data->dpm_table.sclk_table.dpm_levels[i].value,
  1377  
hw_data->dpm_table.mclk_table.dpm_levels[j].value,
  1378  _regs.entries[i][j]);
  1379  if (result)
  1380  return result;
  1381  }
  1382  }
  1383  
  1384  result = smu7_copy_bytes_to_smc(
  1385  hwmgr,
  1386  smu_data->smu7_data.arb_table_start,
  1387  (uint8_t *)_regs,
  1388  sizeof(SMU75_Discrete_MCArbDramTimingTable),
  1389  SMC_RAM_END);
  1390  return result;
  1391  }
  1392  

---
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 02/17] dt-bindings: display: renesas: du: Document the R8A77965 bindings

[Kieran Bingham]

Ahem - this one seems to have lost it's commit message.

Apologies :)

--
Kieran


On 26/04/18 17:53, Kieran Bingham wrote:
> Signed-off-by: Kieran Bingham 
> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
> b/Documentation/devicetree/bindings/display/renesas,du.txt
> index a36a6e7ee54f..7c6854bd0a04 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -13,6 +13,7 @@ Required Properties:
>  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
>  - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
>  - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
>  
> @@ -59,6 +60,7 @@ corresponding to each DU output.
>   R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  -
>   R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
>   R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 -
> + R8A77965 (R-Car M3-N)  DPAD 0 HDMI 0 LVDS 0 -
>   R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  -
>   R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 -
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/17] dt-bindings: display: renesas: du: Document the R8A77965 bindings

[Kieran Bingham]

Signed-off-by: Kieran Bingham 
---
 Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index a36a6e7ee54f..7c6854bd0a04 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -13,6 +13,7 @@ Required Properties:
 - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
+- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
 - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
 - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
 
@@ -59,6 +60,7 @@ corresponding to each DU output.
  R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  -
  R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
  R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 -
+ R8A77965 (R-Car M3-N)  DPAD 0 HDMI 0 LVDS 0 -
  R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  -
  R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 -
 
-- 
2.17.0

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

[PATCH 06/17] drm: rcar-du: Allow DU groups to work with hardware indexing

[Kieran Bingham]

The group objects assume linear indexing, and more so always assume that
channel 0 of any active group is used.

Now that the CRTC objects support non-linear indexing, adapt the groups
to remove assumptions that channel 0 is utilised in each group by using
the channel mask provided in the device structures.

Finally ensure that the RGB routing is determined from the index of the
CRTC object (which represents the hardware DU channel index).

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 14 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.h |  2 ++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 -
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index eead202c95c7..c52091fe02ba 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -46,9 +46,12 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32 
reg, u32 data)
 
 static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
 {
-   u32 defr6 = DEFR6_CODE | DEFR6_ODPM02_DISP;
+   u32 defr6 = DEFR6_CODE;
 
-   if (rgrp->num_crtcs > 1)
+   if (rgrp->channel_mask & BIT(0))
+   defr6 |= DEFR6_ODPM02_DISP;
+
+   if (rgrp->channel_mask & BIT(1))
defr6 |= DEFR6_ODPM12_DISP;
 
rcar_du_group_write(rgrp, DEFR6, defr6);
@@ -80,10 +83,11 @@ static void rcar_du_group_setup_defr8(struct rcar_du_group 
*rgrp)
 * On Gen3 VSPD routing can't be configured, but DPAD routing
 * needs to be set despite having a single option available.
 */
-   u32 crtc = ffs(possible_crtcs) - 1;
+   unsigned int rgb_crtc = ffs(possible_crtcs) - 1;
+   struct rcar_du_crtc *crtc = >crtcs[rgb_crtc];
 
-   if (crtc / 2 == rgrp->index)
-   defr8 |= DEFR8_DRGBS_DU(crtc);
+   if (crtc->index / 2 == rgrp->index)
+   defr8 |= DEFR8_DRGBS_DU(crtc->index);
}
 
rcar_du_group_write(rgrp, DEFR8, defr8);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h 
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index 5e3adc6b31b5..d29a68e006a7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
@@ -25,6 +25,7 @@ struct rcar_du_device;
  * @dev: the DU device
  * @mmio_offset: registers offset in the device memory map
  * @index: group index
+ * @channel_mask: bitmask of populated DU channels in this group
  * @num_crtcs: number of CRTCs in this group (1 or 2)
  * @use_count: number of users of the group (rcar_du_group_(get|put))
  * @used_crtcs: number of CRTCs currently in use
@@ -39,6 +40,7 @@ struct rcar_du_group {
unsigned int mmio_offset;
unsigned int index;
 
+   unsigned int channel_mask;
unsigned int num_crtcs;
unsigned int use_count;
unsigned int used_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 19a445fbc879..45fb554fd3c7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -597,7 +597,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
rgrp->dev = rcdu;
rgrp->mmio_offset = mmio_offsets[i];
rgrp->index = i;
-   rgrp->num_crtcs = min(rcdu->num_crtcs - 2 * i, 2U);
+   /* Extract the channel mask for this group only */
+   rgrp->channel_mask = (rcdu->info->channel_mask >> (2 * i))
+  & GENMASK(1, 0);
+   rgrp->num_crtcs = hweight8(rgrp->channel_mask);
 
/*
 * If we have more than one CRTCs in this group pre-associate
-- 
2.17.0

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

[PATCH 07/17] drm: rcar-du: Add R8A77965 support

[Kieran Bingham]

The R8A77965 (M3-N) SoC provides VGA, HDMI and LVDS output.

This platform is unusual in that the VGA is connected to DU3 leaving DU2
unpopulated. This is reflected by the channel_mask accordingly.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index d6ebc628fc22..4d195ff8c569 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -246,6 +246,34 @@ static const struct rcar_du_device_info 
rcar_du_r8a7796_info = {
.dpll_ch =  BIT(1),
 };
 
+static const struct rcar_du_device_info rcar_du_r8a77965_info = {
+   .gen = 3,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+   .channel_mask = BIT(0) | BIT(1) | BIT(3),
+   .routes = {
+   /*
+* R8A77965 has one RGB output, one LVDS output and one HDMI
+* output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(2),
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_HDMI0] = {
+   .possible_crtcs = BIT(1),
+   .port = 1,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .port = 2,
+   },
+   },
+   .num_lvds = 1,
+   .dpll_ch =  BIT(1),
+};
+
 static const struct rcar_du_device_info rcar_du_r8a77970_info = {
.gen = 3,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
@@ -277,6 +305,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
{ .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
{ .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
+   { .compatible = "renesas,du-r8a77965", .data = _du_r8a77965_info },
{ .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
{ }
 };
-- 
2.17.0

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

[PATCH 04/17] drm: rcar-du: Use the correct naming for ODPM fields in DEFR6

[Kieran Bingham]

The naming of the fields for the ODPM signals in the DU extensional
function control register 6 (DEFR6) is incorrect against the data sheets
for both R-Car Gen2 and R-Car Gen3.

Rename the fields to match the datasheet.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_group.c |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_regs.h  | 16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 2f37ea901873..eead202c95c7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -46,10 +46,10 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32 
reg, u32 data)
 
 static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
 {
-   u32 defr6 = DEFR6_CODE | DEFR6_ODPM12_DISP;
+   u32 defr6 = DEFR6_CODE | DEFR6_ODPM02_DISP;
 
if (rgrp->num_crtcs > 1)
-   defr6 |= DEFR6_ODPM22_DISP;
+   defr6 |= DEFR6_ODPM12_DISP;
 
rcar_du_group_write(rgrp, DEFR6, defr6);
 }
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_regs.h 
b/drivers/gpu/drm/rcar-du/rcar_du_regs.h
index d5bae99d3cfe..9dfd220ceda1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_regs.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_regs.h
@@ -187,14 +187,14 @@
 
 #define DEFR6  0x000e8
 #define DEFR6_CODE (0x7778 << 16)
-#define DEFR6_ODPM22_DSMR  (0 << 10)
-#define DEFR6_ODPM22_DISP  (2 << 10)
-#define DEFR6_ODPM22_CDE   (3 << 10)
-#define DEFR6_ODPM22_MASK  (3 << 10)
-#define DEFR6_ODPM12_DSMR  (0 << 8)
-#define DEFR6_ODPM12_DISP  (2 << 8)
-#define DEFR6_ODPM12_CDE   (3 << 8)
-#define DEFR6_ODPM12_MASK  (3 << 8)
+#define DEFR6_ODPM12_DSMR  (0 << 10)
+#define DEFR6_ODPM12_DISP  (2 << 10)
+#define DEFR6_ODPM12_CDE   (3 << 10)
+#define DEFR6_ODPM12_MASK  (3 << 10)
+#define DEFR6_ODPM02_DSMR  (0 << 8)
+#define DEFR6_ODPM02_DISP  (2 << 8)
+#define DEFR6_ODPM02_CDE   (3 << 8)
+#define DEFR6_ODPM02_MASK  (3 << 8)
 #define DEFR6_TCNE1(1 << 6)
 #define DEFR6_TCNE0(1 << 4)
 #define DEFR6_MLOS1(1 << 2)
-- 
2.17.0

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

[PATCH 05/17] drm: rcar-du: Split CRTC handling to support hardware indexing

[Kieran Bingham]

The DU CRTC driver does not support distinguishing between a hardware
index, and a software (CRTC) index in the event that a DU channel might
not be populated by the hardware.

Support this by adapting the rcar_du_device_info structure to store a
bitmask of available channels rather than a count of CRTCs. The count
can then be obtained by determining the hamming weight of the bitmask.

This allows the rcar_du_crtc_create() function to distinguish between
both index types, and non-populated DU channels will be skipped without
leaving a gap in the software CRTC indexes.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 26 ++
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 20 ++--
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 17 -
 5 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5a15dfd66343..36ce194c13b5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -902,7 +902,8 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
  * Initialization
  */
 
-int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index)
+int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int swindex,
+   unsigned int hwindex)
 {
static const unsigned int mmio_offsets[] = {
DU0_REG_OFFSET, DU1_REG_OFFSET, DU2_REG_OFFSET, DU3_REG_OFFSET
@@ -910,7 +911,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
 
struct rcar_du_device *rcdu = rgrp->dev;
struct platform_device *pdev = to_platform_device(rcdu->dev);
-   struct rcar_du_crtc *rcrtc = >crtcs[index];
+   struct rcar_du_crtc *rcrtc = >crtcs[swindex];
struct drm_crtc *crtc = >crtc;
struct drm_plane *primary;
unsigned int irqflags;
@@ -922,7 +923,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
 
/* Get the CRTC clock and the optional external clock. */
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CRTC_IRQ_CLOCK)) {
-   sprintf(clk_name, "du.%u", index);
+   sprintf(clk_name, "du.%u", hwindex);
name = clk_name;
} else {
name = NULL;
@@ -930,16 +931,16 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
 
rcrtc->clock = devm_clk_get(rcdu->dev, name);
if (IS_ERR(rcrtc->clock)) {
-   dev_err(rcdu->dev, "no clock for CRTC %u\n", index);
+   dev_err(rcdu->dev, "no clock for CRTC %u\n", swindex);
return PTR_ERR(rcrtc->clock);
}
 
-   sprintf(clk_name, "dclkin.%u", index);
+   sprintf(clk_name, "dclkin.%u", hwindex);
clk = devm_clk_get(rcdu->dev, clk_name);
if (!IS_ERR(clk)) {
rcrtc->extclock = clk;
} else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
-   dev_info(rcdu->dev, "can't get external clock %u\n", index);
+   dev_info(rcdu->dev, "can't get external clock %u\n", hwindex);
return -EPROBE_DEFER;
}
 
@@ -948,13 +949,13 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
spin_lock_init(>vblank_lock);
 
rcrtc->group = rgrp;
-   rcrtc->mmio_offset = mmio_offsets[index];
-   rcrtc->index = index;
+   rcrtc->mmio_offset = mmio_offsets[hwindex];
+   rcrtc->index = hwindex;
 
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
primary = >vsp->planes[rcrtc->vsp_pipe].plane;
else
-   primary = >planes[index % 2].plane;
+   primary = >planes[hwindex % 2].plane;
 
ret = drm_crtc_init_with_planes(rcdu->ddev, crtc, primary, NULL,
rcdu->info->gen <= 2 ?
@@ -970,7 +971,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
 
/* Register the interrupt handler. */
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_CRTC_IRQ_CLOCK)) {
-   irq = platform_get_irq(pdev, index);
+   /* The IRQ's are associated with the CRTC (sw)index */
+   irq = platform_get_irq(pdev, swindex);
irqflags = 0;
} else {
irq = platform_get_irq(pdev, 0);
@@ -978,7 +980,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
}
 
if (irq < 0) {
-   dev_err(rcdu->dev, "no IRQ for CRTC %u\n", index);
+   dev_err(rcdu->dev, "no IRQ for CRTC %u\n", swindex);
return irq;
}
 
@@ -986,7 +988,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
   dev_name(rcdu->dev), 

[PATCH 01/17] dt-bindings: display: renesas: du: Increase indent in output table

[Kieran Bingham]

The DU output table lists the port combinations for each supported DU
type.  Newer models of R-Car Gen3 platforms have an increased string
length.

Increase the table indentation in preparation for supporting new target
types.

Signed-off-by: Kieran Bingham 
---
 .../bindings/display/renesas,du.txt   | 26 +--
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index c9cd17f99702..a36a6e7ee54f 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -47,20 +47,20 @@ bindings specified in 
Documentation/devicetree/bindings/graph.txt.
 The following table lists for each supported model the port number
 corresponding to each DU output.
 
-  Port0  Port1  Port2  Port3
+Port0  Port1  Port2  Port3
 -
- R8A7743 (RZ/G1M) DPAD 0 LVDS 0 -  -
- R8A7745 (RZ/G1E) DPAD 0 DPAD 1 -  -
- R8A7779 (R-Car H1)   DPAD 0 DPAD 1 -  -
- R8A7790 (R-Car H2)   DPAD 0 LVDS 0 LVDS 1 -
- R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 -  -
- R8A7792 (R-Car V2H)  DPAD 0 DPAD 1 -  -
- R8A7793 (R-Car M2-N) DPAD 0 LVDS 0 -  -
- R8A7794 (R-Car E2)   DPAD 0 DPAD 1 -  -
- R8A7795 (R-Car H3)   DPAD 0 HDMI 0 HDMI 1 LVDS 0
- R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
- R8A77970 (R-Car V3M) DPAD 0 LVDS 0 -  -
- R8A77995 (R-Car D3)  DPAD 0 LVDS 0 LVDS 1 -
+ R8A7743 (RZ/G1M)   DPAD 0 LVDS 0 -  -
+ R8A7745 (RZ/G1E)   DPAD 0 DPAD 1 -  -
+ R8A7779 (R-Car H1) DPAD 0 DPAD 1 -  -
+ R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 -
+ R8A7791 (R-Car M2-W)   DPAD 0 LVDS 0 -  -
+ R8A7792 (R-Car V2H)DPAD 0 DPAD 1 -  -
+ R8A7793 (R-Car M2-N)   DPAD 0 LVDS 0 -  -
+ R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  -
+ R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
+ R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 -
+ R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  -
+ R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 -
 
 
 Example: R8A7795 (R-Car H3) ES2.0 DU
-- 
2.17.0

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

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

Joel Sass  changed:

   What|Removed |Added

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

--- Comment #9 from Joel Sass  ---
I can confirm the patch fixed the issue. I installed drm-next-4.17 from
git://people.freedesktop.org/~agd5f/linux and the problem is solved.

Good work, and thanks!

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

[radeon-alex:drm-next-4.18-wip 257/261] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:323:2: warning: missing braces around initializer

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head:   92fb37464bd2b759d74f33c3b90a27575601745d
commit: 414643871e4c144d7a7a41d14d889fe32089f0e0 [257/261] drm/amd/powerplay: 
update ppatomctrl.c (v2)
config: i386-randconfig-a0-201816 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 414643871e4c144d7a7a41d14d889fe32089f0e0
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c: In function 
'atomctrl_get_memory_pll_dividers_ai':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:323:2: warning: 
>> missing braces around initializer [-Wmissing-braces]
 COMPUTE_MEMORY_CLOCK_PARAM_PARAMETERS_V2_3 mpll_parameters = {0};
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:323:2: warning: 
(near initialization for 'mpll_parameters.ulClock') [-Wmissing-braces]

vim +323 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c

   317  
   318  int atomctrl_get_memory_pll_dividers_ai(struct pp_hwmgr *hwmgr,
   319  uint32_t clock_value,
   320  
pp_atomctrl_memory_clock_param_ai *mpll_param)
   321  {
   322  struct amdgpu_device *adev = hwmgr->adev;
 > 323  COMPUTE_MEMORY_CLOCK_PARAM_PARAMETERS_V2_3 mpll_parameters = 
 > {0};
   324  int result;
   325  
   326  mpll_parameters.ulClock.ulClock = cpu_to_le32(clock_value);
   327  
   328  result = amdgpu_atom_execute_table(adev->mode_info.atom_context,
   329  GetIndexIntoMasterTable(COMMAND, 
ComputeMemoryClockParam),
   330  (uint32_t *)_parameters);
   331  
   332  /* VEGAM's mpll takes sometime to finish computing */
   333  udelay(10);
   334  
   335  if (!result) {
   336  mpll_param->ulMclk_fcw_int =
   337  le16_to_cpu(mpll_parameters.usMclk_fcw_int);
   338  mpll_param->ulMclk_fcw_frac =
   339  le16_to_cpu(mpll_parameters.usMclk_fcw_frac);
   340  mpll_param->ulClock =
   341  le32_to_cpu(mpll_parameters.ulClock.ulClock);
   342  mpll_param->ulPostDiv = 
mpll_parameters.ulClock.ucPostDiv;
   343  }
   344  
   345  return result;
   346  }
   347  

---
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 v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Doug Anderson]

Hi,

On Thu, Apr 26, 2018 at 5:05 AM, Thierry Reding
 wrote:
> If you've got an EDID you should be relying on the EDID to provide the
> timings. No need to have any timings in the DT in that case.

The problem that's specifically trying to be solved by Sean's series
is when we have to use timings other than the one suggested by the
EDID.  Specifically:

* On many Rockchip SoCs there is only one "extra" PLL available.  This
extra PLL can only be used by one of the two displays (eDP for
internal panel or HDMI/DP for external display).  The other display
has to use one of the "shared" PLLs in the system.  These PLLs have
their rate set at boot and aren't changed.

* In order to provide maximum flexibility to connect external
displays, we always want the "extra" PLL dedicated to the external
display port.  Then we can make lots of pixel clocks.

* We work with device and display manufacturers to figure out a pixel
clock that is achievable with the shared PLLs and that has valid
timings.  This is the the pixel clock that was used when testing EMI,
etc.  It is the one that should be used.

* Panel manufacturers agreed that this pixel clock was good to use,
but we didn't get an updated EDID that suggested this mode.  It's my
understanding that panels were already available and it didn't really
make sense to program in an EDID to work around a certain board.



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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #54 from MirceaKitsune  ---
I have some very interesting results from today: As instructed, I used the
latest version of apitrace. I cloned it straight from its Github repository and
compiled it myself, then ran Xonotic through it.

https://github.com/apitrace/apitrace

Same thing: The trace always ends several seconds before the moment of the
freeze and prints an "end of file" warning in the console.

Then I decided to do something different: I ran Blender 3D through apitrace,
loading up the scene that triggered this same lockup last time. I used various
features and went into several modes which I remembered were responsible.
Eventually I got the exact same freeze as I do with Xonotic. I rebooted and
played back the Blender trace. Same story as with Xonotic: It cuts a few
seconds earlier and complains about EoF.

But there's a bizarre twist this time: When playing back the trace generated by
Blender, my system will freeze at various points during the replay! Sometimes
it freezes early, sometimes it freezes late, at other times I can replay the
whole trace without getting a freeze at all.

This is very peculiar: The crash must be occurring beyond what apitrace is even
capturing, likely something deep in the kernel or renderer which is only
triggered when the conditions are just right. What do you make of this?

-- 
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/bridge: cdns: Mark runtime PM operations as maybe unused

[Thierry Reding]

On Thu, Apr 26, 2018 at 04:21:04PM +0200, Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:53PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Building the driver in a configuration with !PM currently causes a
> > warning about these operations being unused. Mark them as such to shut
> > up the compiler.
> > 
> > Signed-off-by: Thierry Reding 
> 
> I'd so love if we could use LTO (or at least link time garbage collection
> of functions/heap allocations) instead of tons of #ifdef (even in macros)
> and __maybe_unused.

I had discussed this with Arnd Bergmann a long time ago and neither of
us could figure out a way to make that work in this case, so we agreed
that __maybe_unused was the preferred way forward until somebody would
figure out a better way.

> Patch looks fine itself.
> 
> Reviewed-by: Daniel Vetter 

Thanks, applied to drm-misc-next.

Thierry


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

Re: [PATCH v4 6/8] drm/panel: Add Ilitek ILI9881c panel driver

[Thierry Reding]

On Wed, Apr 04, 2018 at 11:57:14AM +0200, Maxime Ripard wrote:
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
> based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
> after the other Ilitek controller drivers.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/panel/Kconfig |   9 +-
>  drivers/gpu/drm/panel/Makefile|   1 +-
>  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 489 +++-
>  3 files changed, 499 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 25682ff3449a..6020c30a33b3 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -46,6 +46,15 @@ config DRM_PANEL_ILITEK_IL9322
> Say Y here if you want to enable support for Ilitek IL9322
> QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
>  
> +config DRM_PANEL_ILITEK_ILI9881C
> + tristate "Ilitek ILI9881C-based panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y if you want to enable support for panels based on the
> +   Ilitek ILI9881c controller.
> +
>  config DRM_PANEL_INNOLUX_P079ZCA
>   tristate "Innolux P079ZCA panel"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f26efc11d746..5ccaaa9d13af 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
>  obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> +obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
> b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> new file mode 100644
> index ..8992a6431c30
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> @@ -0,0 +1,489 @@
> +// SPDX-License-Identifier: GPL-2.0+

This isn't a valid SPDX license specifier. The module license is GPL v2,
so the corresponding specifier would be: GPL-2.0-only.

> +/*
> + * Copyright (C) 2017, Free Electrons

-2018?

> + * Author: Maxime Ripard 

No need for this, it's already in MODULE_AUTHOR.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct ili9881c {
> + struct drm_panelpanel;
> + struct mipi_dsi_device  *dsi;
> +
> + struct backlight_device *backlight;
> + struct gpio_desc*power;
> + struct gpio_desc*reset;
> +};
> +
> +enum ili9881c_op {
> + ILI9881C_SWITCH_PAGE,
> + ILI9881C_COMMAND,
> +};
> +
> +struct ili9881c_instr {
> + enum ili9881c_opop;
> +
> + union arg {
> + struct cmd {
> + u8  cmd;
> + u8  data;
> + } cmd;
> + u8  page;
> + } arg;
> +};
> +
> +#define ILI9881C_SWITCH_PAGE_INSTR(_page)\
> + {   \
> + .op = ILI9881C_SWITCH_PAGE, \
> + .arg = {\
> + .page = (_page),\
> + },  \
> + }
> +
> +#define ILI9881C_COMMAND_INSTR(_cmd, _data)  \
> + {   \
> + .op = ILI9881C_COMMAND, \
> + .arg = {\
> + .cmd = {\
> + .cmd = (_cmd),  \
> + .data = (_data),\
> + },  \
> + },  \
> + }
> +
> +static struct ili9881c_instr ili9881c_init[] = {

These are never modified, so they could be const, right?

> + ILI9881C_SWITCH_PAGE_INSTR(3),
> + ILI9881C_COMMAND_INSTR(0x01, 0x00),
> + ILI9881C_COMMAND_INSTR(0x02, 0x00),
> + ILI9881C_COMMAND_INSTR(0x03, 0x73),
> + ILI9881C_COMMAND_INSTR(0x04, 0x03),
> + ILI9881C_COMMAND_INSTR(0x05, 0x00),
> + ILI9881C_COMMAND_INSTR(0x06, 0x06),
> + ILI9881C_COMMAND_INSTR(0x07, 0x06),
> + ILI9881C_COMMAND_INSTR(0x08, 0x00),
> + ILI9881C_COMMAND_INSTR(0x09, 0x18),
> + ILI9881C_COMMAND_INSTR(0x0a, 0x04),
> + ILI9881C_COMMAND_INSTR(0x0b, 0x00),
> +   

[PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

[Michel Dänzer]

From: Michel Dänzer 

When it's set, TTM tries to allocate huge pages if possible. Drivers
which can take advantage of huge pages should set it.

Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.

Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 ++
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  8 +---
 include/drm/ttm/ttm_tt.h |  1 +
 4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dfd22db13fb1..e03e9e361e2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -988,7 +988,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_buffer_object *bo,
return NULL;
}
gtt->ttm.ttm.func = _backend_func;
-   if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
+   if (ttm_sg_tt_init(>ttm, bo, page_flags | 
TTM_PAGE_FLAG_TRANSHUGE)) {
kfree(gtt);
return NULL;
}
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index f0481b7b60c5..2ce91272b111 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -760,7 +760,7 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, false, cstate);
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   struct ttm_page_pool *huge = ttm_get_pool(flags, true, cstate);
+   struct ttm_page_pool *huge = NULL;
 #endif
unsigned long irq_flags;
unsigned i;
@@ -780,7 +780,8 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
}
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   if (!(flags & TTM_PAGE_FLAG_DMA32)) {
+   if ((flags & (TTM_PAGE_FLAG_DMA32 | 
TTM_PAGE_FLAG_TRANSHUGE)) ==
+   TTM_PAGE_FLAG_TRANSHUGE) {
for (j = 0; j < HPAGE_PMD_NR; ++j)
if (p++ != pages[i + j])
break;
@@ -805,6 +806,8 @@ static void ttm_put_pages(struct page **pages, unsigned 
npages, int flags,
 
i = 0;
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   if (flags & TTM_PAGE_FLAG_TRANSHUGE)
+   huge = ttm_get_pool(flags, true, cstate);
if (huge) {
unsigned max_size, n2free;
 
@@ -877,7 +880,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 {
struct ttm_page_pool *pool = ttm_get_pool(flags, false, cstate);
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   struct ttm_page_pool *huge = ttm_get_pool(flags, true, cstate);
+   struct ttm_page_pool *huge = NULL;
 #endif
struct list_head plist;
struct page *p = NULL;
@@ -906,7 +909,8 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 
i = 0;
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   if (!(gfp_flags & GFP_DMA32)) {
+   if ((flags & (TTM_PAGE_FLAG_DMA32 | TTM_PAGE_FLAG_TRANSHUGE)) ==
+   TTM_PAGE_FLAG_TRANSHUGE) {
while (npages >= HPAGE_PMD_NR) {
gfp_t huge_flags = gfp_flags;
 
@@ -946,6 +950,8 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
count = 0;
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   if (flags & TTM_PAGE_FLAG_TRANSHUGE)
+   huge = ttm_get_pool(flags, true, cstate);
if (huge && npages >= HPAGE_PMD_NR) {
INIT_LIST_HEAD();
ttm_page_pool_get_pages(huge, , flags, cstate,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 8a25d1974385..291b04213ec5 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   if (ttm->page_flags & TTM_PAGE_FLAG_DMA32)
+   if ((ttm->page_flags & (TTM_PAGE_FLAG_DMA32 | TTM_PAGE_FLAG_TRANSHUGE))
+   != TTM_PAGE_FLAG_TRANSHUGE)
goto skip_huge;
 
pool = ttm_dma_find_pool(dev, type | IS_HUGE);
@@ -1035,7 +1036,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
 {
struct ttm_tt *ttm = _dma->ttm;
struct ttm_mem_global *mem_glob = ttm->bdev->glob->mem_glob;
-   struct dma_pool *pool;
+   struct dma_pool *pool = NULL;
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = 

[PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages

[Michel Dänzer]

From: Michel Dänzer 

GFP_TRANSHUGE tries very hard to allocate huge pages, which can result
in long delays with high memory pressure. I have observed firefox
freezing for up to around a minute due to this while restic was taking
a full system backup.

Since we don't really need huge pages, use GFP_TRANSHUGE_LIGHT |
__GFP_NORETRY instead, in order to fail quickly when there are no huge
pages available.

Set __GFP_KSWAPD_RECLAIM as well, in order for huge pages to be freed
up in the background if necessary.

With these changes, I'm no longer seeing freezes during a restic backup.

Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 ++-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2ce91272b111..6794f15461d9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -914,7 +914,8 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
while (npages >= HPAGE_PMD_NR) {
gfp_t huge_flags = gfp_flags;
 
-   huge_flags |= GFP_TRANSHUGE;
+   huge_flags |= GFP_TRANSHUGE_LIGHT | 
__GFP_NORETRY |
+   __GFP_KSWAPD_RECLAIM;
huge_flags &= ~__GFP_MOVABLE;
huge_flags &= ~__GFP_COMP;
p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
@@ -1033,11 +1034,15 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
  GFP_USER | GFP_DMA32, "uc dma", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_huge,
- GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
+ (GFP_TRANSHUGE_LIGHT | __GFP_NORETRY |
+  __GFP_KSWAPD_RECLAIM) &
+ ~(__GFP_MOVABLE | __GFP_COMP),
  "wc huge", order);
 
ttm_page_pool_init_locked(&_manager->uc_pool_huge,
- GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
+ (GFP_TRANSHUGE_LIGHT | __GFP_NORETRY |
+  __GFP_KSWAPD_RECLAIM) &
+ ~(__GFP_MOVABLE | __GFP_COMP)
  , "uc huge", order);
 
_manager->options.max_size = max_pages;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 291b04213ec5..5a551158c289 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -910,7 +910,8 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt 
*ttm_dma, bool huge)
gfp_flags |= __GFP_ZERO;
 
if (huge) {
-   gfp_flags |= GFP_TRANSHUGE;
+   gfp_flags |= GFP_TRANSHUGE_LIGHT | __GFP_NORETRY |
+   __GFP_KSWAPD_RECLAIM;
gfp_flags &= ~__GFP_MOVABLE;
gfp_flags &= ~__GFP_COMP;
}
-- 
2.17.0

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

Re: [PATCH 2/2] drm/panel: rm67191: Add support for new bus formats

[Thierry Reding]

On Tue, Apr 03, 2018 at 01:30:01PM +0300, Robert Chiras wrote:
> From: Mirela Rabulea 
> 
> Do not hardcode pixel_format to 0x77 but calculate it from dsi->format.
> Report all the supported bus formats in get_modes:
> MEDIA_BUS_FMT_RGB888_1X24
> MEDIA_BUS_FMT_RGB666_1X18
> MEDIA_BUS_FMT_RGB565_1X16
> Change pixelclock from 120 to 132 MHz, or 16 bpp formats will not work.
> 
> Signed-off-by: Mirela Rabulea 
> ---
>  drivers/gpu/drm/panel/panel-raydium-rm67191.c | 33 
> +++
>  1 file changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c 
> b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> index 07b0bd4..6331fef 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -178,6 +178,12 @@ static const cmd_set_table manufacturer_cmd_set[] = {
>   {0x51, 0x04},
>  };
>  
> +static const u32 rad_bus_formats[] = {
> + MEDIA_BUS_FMT_RGB888_1X24,
> + MEDIA_BUS_FMT_RGB666_1X18,
> + MEDIA_BUS_FMT_RGB565_1X16,
> +};
> +
>  struct rad_panel {
>   struct drm_panel base;
>   struct mipi_dsi_device *dsi;
> @@ -215,11 +221,27 @@ static int rad_panel_push_cmd_list(struct 
> mipi_dsi_device *dsi)
>   return ret;
>  };
>  
> +static int color_format_from_dsi_format(enum mipi_dsi_pixel_format format)
> +{
> + switch (format) {
> + case MIPI_DSI_FMT_RGB565:
> + return 0x55;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + return 0x66;
> + case MIPI_DSI_FMT_RGB888:
> + return 0x77;
> + default:
> + return 0x77; /* for backward compatibility */
> + }
> +};
> +
>  static int rad_panel_prepare(struct drm_panel *panel)
>  {
>   struct rad_panel *rad = to_rad_panel(panel);
>   struct mipi_dsi_device *dsi = rad->dsi;
>   struct device *dev = >dev;
> + int color_format = color_format_from_dsi_format(dsi->format);
>   int ret;
>  
>   if (rad->prepared)
> @@ -276,8 +298,10 @@ static int rad_panel_prepare(struct drm_panel *panel)
>   DRM_DEV_ERROR(dev, "Failed to set tear scanline (%d)\n", ret);
>   goto fail;
>   }
> - /* Set pixel format to RGB888 */
> - ret = mipi_dsi_dcs_set_pixel_format(dsi, 0x77);
> + /* Set pixel format */
> + ret = mipi_dsi_dcs_set_pixel_format(dsi, color_format);
> + DRM_DEV_DEBUG_DRIVER(dev, "Interface color format set to 0x%x\n",
> + color_format);
>   if (ret < 0) {
>   DRM_DEV_ERROR(dev, "Failed to set pixel format (%d)\n", ret);
>   goto fail;
> @@ -393,7 +417,6 @@ static int rad_panel_get_modes(struct drm_panel *panel)
>   struct device *dev = >dsi->dev;
>   struct drm_connector *connector = panel->connector;
>   struct drm_display_mode *mode;
> - u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>   u32 *bus_flags = >display_info.bus_flags;
>   int ret;
>  
> @@ -420,7 +443,7 @@ static int rad_panel_get_modes(struct drm_panel *panel)
>   *bus_flags |= DRM_BUS_FLAG_PIXDATA_POSEDGE;
>  
>   ret = drm_display_info_set_bus_formats(>display_info,
> -_format, 1);
> + rad_bus_formats, ARRAY_SIZE(rad_bus_formats));
>   if (ret)
>   return ret;
>  
> @@ -492,7 +515,7 @@ static const struct drm_panel_funcs rad_panel_funcs = {
>   * to 132MHz (60Hz refresh rate)
>   */
>  static const struct display_timing rad_default_timing = {
> - .pixelclock = { 6600, 12000, 13200 },
> + .pixelclock = { 6600, 13200, 13200 },

This seems like a fix that should be squashed into patch 1.

Thierry


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

Re: [PATCH] drm-misc.rst: Document commit rights

[Lukas Wunner]

On Thu, Apr 26, 2018 at 04:25:57PM +0200, Daniel Vetter wrote:
> This is the exact same text as proposed for igt:
> 
> https://patchwork.kernel.org/patch/10339739/
> 
> With one minor change: Both regular contributions to the kernel
> overall and to userspace graphics counts. We've gained a few
> committers in the past who are coming from arm-soc platform work and
> similar areas, to upstream drm drivers for their platform.

FWIW,
Acked-by: Lukas Wunner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/panel: Add Raydium RM67191 DSI Panel

[Thierry Reding]

On Tue, Apr 03, 2018 at 01:30:00PM +0300, Robert Chiras wrote:
> Add support for the OLED display based on MIPI-DSI protocol from Raydium:
> RM67191.
> 
> Signed-off-by: Robert Chiras 
> ---
>  .../bindings/display/panel/raydium,rm67191.txt |  55 ++
>  drivers/gpu/drm/panel/Kconfig  |   9 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-raydium-rm67191.c  | 645 
> +
>  4 files changed, 710 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-raydium-rm67191.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt 
> b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> new file mode 100644
> index 000..18a57de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> @@ -0,0 +1,55 @@
> +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
> +
> +Required properties:
> +- compatible:"raydium,rm67191"
> +- reg:   virtual channel for MIPI-DSI protocol
> + must be <0>
> +- dsi-lanes: number of DSI lanes to be used
> + must be <3> or <4>
> +- port:  input port node with endpoint definition as
> + defined in Documentation/devicetree/bindings/graph.txt;
> + the input port should be connected to a MIPI-DSI device
> + driver
> +
> +Optional properties:
> +- reset-gpio:a GPIO spec for the RST_B GPIO pin
> +- display-timings:   timings for the connected panel according to [1]
> +- pinctrl-0  phandle to the pin settings for the reset pin
> +- panel-width-mm:physical panel width [mm]
> +- panel-height-mm:   physical panel height [mm]
> +
> +[1]: Documentation/devicetree/bindings/display/display-timing.txt
> +
> +Example:
> +
> + panel@0 {
> + compatible = "raydium,rm67191";
> + reg = <0>;
> + pinctrl-0 = <_mipi_dsi_0_1_en>;
> + reset-gpio = < 7 GPIO_ACTIVE_HIGH>;
> + dsi-lanes = <4>;
> + panel-width-mm = <68>;
> + panel-height-mm = <121>;
> + display-timings {
> + timing {
> + clock-frequency = <13200>;
> + hactive = <1080>;
> + vactive = <1920>;
> + hback-porch = <11>;
> + hfront-porch = <4>;
> + vback-porch = <48>;
> + vfront-porch = <20>;
> + hsync-len = <5>;
> + vsync-len = <12>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <0>;
> + pixelclk-active = <0>;
> + };
> + };

This shouldn't be necessary. You already have the timings in your
driver, why the extra work of getting it from DT?

> + port {
> + panel1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };

Please split device tree bindings patches off into a separate patch and
make sure you Cc the devicet...@vger.kernel.org mailing list so that
they can be reviewed by the respective maintainers.

Also make sure that you put maintainers on To: or at least Cc: so that
they have a better chance of seeing your patch and don't have to go
find them.

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6ba4031..769cba7 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -158,4 +158,13 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>  
> +config DRM_PANEL_RAYDIUM_RM67191
> + tristate "Raydium RM67191 FHD panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for Raydium RM67191 FHD
> +   (1080x1920) DSI panel.
> +

These should be sorted alphabetically.

>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 6d251eb..838d5c6 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += 
> panel-seiko-43wvf1g.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> 

[PATCH] drm/amd/display: Remove erroneous if statement in gamma set

[sunpeng.li]

From: "Leo (Sunpeng) Li" 

The lines were removed as part of the original change. They may have
been missed during merge.

This is a fixup to:

committ 265083076187e619aa9176aeb05ad630013429b4
Author: Leo (Sunpeng) Li 
Date:   Fri Feb 2 10:18:56 2018 -0500

drm/amd/display: Hookup color management functions
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b7265f6..0d4a133 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2206,11 +2206,9 @@ static int fill_plane_attributes(struct amdgpu_device 
*adev,
 
dc_plane_state->in_transfer_func = input_tf;
 
-   /* In case of gamma set, update gamma value */
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0) || \
defined(OS_NAME_RHEL_7_3) || \
defined(OS_NAME_RHEL_7_4_5)
-   if (crtc_state->gamma_lut)
/*
 * Always set input transfer function, since plane state is refreshed
 * every time.
-- 
2.7.4

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

Re: [PATCH] drm-misc.rst: Document commit rights

[Daniel Vetter]

On Thu, Apr 26, 2018 at 4:25 PM, Daniel Vetter  wrote:
> This is the exact same text as proposed for igt:
>
> https://patchwork.kernel.org/patch/10339739/
>
> With one minor change: Both regular contributions to the kernel
> overall and to userspace graphics counts. We've gained a few
> committers in the past who are coming from arm-soc platform work and
> similar areas, to upstream drm drivers for their platform.
>
> For simplicity I've kept the same massive Cc: list.
>
> Cc: Alex Deucher 
> Cc: Arkadiusz Hiler 
> Cc: Ben Widawsky 
> Cc: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Acked-by: Gustavo Padovan 
> Cc: Gustavo Padovan 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Keith Packard 
> Cc: Kenneth Graunke 
> Cc: Kristian H. Kristensen 
> Acked-by: Maarten Lankhorst 
> Cc: Maarten Lankhorst 
> Cc: Petri Latvala 
> Cc: Rodrigo Vivi 
> Acked-by: Sean Paul 
> Cc: Sean Paul 
> Cc: Keith Packard 
> Signed-off-by: Daniel Vetter 

So after pushing this patch accidentally instead of the dim bugfix I
also forgot to cc dim-tools when sending it out.

Really not the best day today ...
-Daniel
> ---
>  drm-misc.rst | 48 
>  1 file changed, 48 insertions(+)
>
> diff --git a/drm-misc.rst b/drm-misc.rst
> index 187a4df07ad4..21cbaefda9aa 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -174,6 +174,54 @@ Maintainers mostly provide services to keep drm-misc 
> running smoothly:
>  * Take the blame when something goes wrong. Maintainers interface and 
> represent
>the entire group of committers to the wider kernel community.
>
> +Commit Rights
> +=
> +
> +Commit rights will be granted to anyone who requests them and fulfills the
> +below criteria:
> +
> +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple
> +  spelling fixes and whitespace adjustment) patches that have been merged
> +  already.
> +
> +- Are actively participating on discussions about their work (on the mailing
> +  list or IRC). This should not be interpreted as a requirement to review 
> other
> +  peoples patches but just make sure that patch submission isn't one-way
> +  communication. Cross-review is still highly encouraged.
> +
> +- Will be regularly contributing further patches. This includes regular
> +  contributors to other parts of the linux kernel or the open source graphics
> +  stack who only do the oddball rare patch within drm-misc itself.
> +
> +- Agrees to use their commit rights in accordance with the documented merge
> +  criteria, tools, and processes.
> +
> +Apply for an account (and any other account change requests) through
> +
> +https://www.freedesktop.org/wiki/AccountRequests/
> +
> +and please ping the maintainers if your request is stuck.
> +
> +Committers are encouraged to request their commit rights get removed when 
> they
> +no longer contribute to the project. Commit rights will be reinstated when 
> they
> +come back to the project.
> +
> +Maintainers and committers should encourage contributors to request commit
> +rights, especially junior contributors tend to underestimate their skills.
> +
> +Code of Conduct
> +===
> +
> +Please be aware the fd.o Code of Conduct also applies to drm-misc:
> +
> +https://www.freedesktop.org/wiki/CodeOfConduct/
> +
> +See the MAINTAINERS file for contact details of the drm-misc maintainers.
> +
> +Abuse of commit rights, like engaging in commit fights or willfully pushing
> +patches that violate the documented merge criteria, will also be handled 
> through
> +the Code of Conduct enforcement process.
> +
>  Tooling
>  ===
>
> --
> 2.17.0
>



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

[PATCH] drm-misc.rst: Document commit rights

[Daniel Vetter]

This is the exact same text as proposed for igt:

https://patchwork.kernel.org/patch/10339739/

With one minor change: Both regular contributions to the kernel
overall and to userspace graphics counts. We've gained a few
committers in the past who are coming from arm-soc platform work and
similar areas, to upstream drm drivers for their platform.

For simplicity I've kept the same massive Cc: list.

Cc: Alex Deucher 
Cc: Arkadiusz Hiler 
Cc: Ben Widawsky 
Cc: Daniel Stone 
Cc: Dave Airlie 
Cc: Eric Anholt 
Acked-by: Gustavo Padovan 
Cc: Gustavo Padovan 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Keith Packard 
Cc: Kenneth Graunke 
Cc: Kristian H. Kristensen 
Acked-by: Maarten Lankhorst 
Cc: Maarten Lankhorst 
Cc: Petri Latvala 
Cc: Rodrigo Vivi 
Acked-by: Sean Paul 
Cc: Sean Paul 
Cc: Keith Packard 
Signed-off-by: Daniel Vetter 
---
 drm-misc.rst | 48 
 1 file changed, 48 insertions(+)

diff --git a/drm-misc.rst b/drm-misc.rst
index 187a4df07ad4..21cbaefda9aa 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -174,6 +174,54 @@ Maintainers mostly provide services to keep drm-misc 
running smoothly:
 * Take the blame when something goes wrong. Maintainers interface and represent
   the entire group of committers to the wider kernel community.
 
+Commit Rights
+=
+
+Commit rights will be granted to anyone who requests them and fulfills the
+below criteria:
+
+- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple
+  spelling fixes and whitespace adjustment) patches that have been merged
+  already.
+
+- Are actively participating on discussions about their work (on the mailing
+  list or IRC). This should not be interpreted as a requirement to review other
+  peoples patches but just make sure that patch submission isn't one-way
+  communication. Cross-review is still highly encouraged.
+
+- Will be regularly contributing further patches. This includes regular
+  contributors to other parts of the linux kernel or the open source graphics
+  stack who only do the oddball rare patch within drm-misc itself.
+
+- Agrees to use their commit rights in accordance with the documented merge
+  criteria, tools, and processes.
+
+Apply for an account (and any other account change requests) through
+
+https://www.freedesktop.org/wiki/AccountRequests/
+
+and please ping the maintainers if your request is stuck.
+
+Committers are encouraged to request their commit rights get removed when they
+no longer contribute to the project. Commit rights will be reinstated when they
+come back to the project.
+
+Maintainers and committers should encourage contributors to request commit
+rights, especially junior contributors tend to underestimate their skills.
+
+Code of Conduct
+===
+
+Please be aware the fd.o Code of Conduct also applies to drm-misc:
+
+https://www.freedesktop.org/wiki/CodeOfConduct/
+
+See the MAINTAINERS file for contact details of the drm-misc maintainers.
+
+Abuse of commit rights, like engaging in commit fights or willfully pushing
+patches that violate the documented merge criteria, will also be handled 
through
+the Code of Conduct enforcement process.
+
 Tooling
 ===
 
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH v11 06/11] drm: Add DRM client cap for aspect-ratio

[Ville Syrjälä]

On Mon, Apr 23, 2018 at 01:11:25PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> > 
> > 
> > On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> > >> From: Ankit Nautiyal 
> > >>
> > >> To enable aspect-ratio support in DRM, blindly exposing the aspect
> > >> ratio information along with mode, can break things in existing
> > >> user-spaces which have no intention or support to use this aspect
> > >> ratio information.
> > >>
> > >> To avoid this, a new drm client cap is required to enable a
> > >> user-space to advertise if it supports modes with aspect-ratio. Based
> > >> on this cap value, the kernel will take a call on exposing the aspect
> > >> ratio info in modes or not.
> > >>
> > >> This patch adds the client cap for aspect-ratio.
> > >>
> > >> Cc: Ville Syrjala 
> > >> Cc: Shashank Sharma 
> > >> Signed-off-by: Ankit Nautiyal 
> > >>
> > >> V3: rebase
> > >> V4: As suggested by Marteen Lankhorst modified the commit message
> > >>  explaining the need to use the DRM cap for aspect-ratio. Also,
> > >>  tweaked the comment lines in the code for better understanding and
> > >>  clarity, as recommended by Shashank Sharma.
> > >> V5: rebase
> > >> V6: rebase
> > >> V7: rebase
> > >> V8: rebase
> > >> V9: rebase
> > >> V10: added comment explaining that no userspace breaks on aspect-ratio
> > >>   mode bits.
> > >>
> > >> Reviewed-by: Shashank Sharma 
> > >> ---
> > >>   drivers/gpu/drm/drm_ioctl.c | 9 +
> > >>   include/drm/drm_file.h  | 8 
> > >>   include/uapi/drm/drm.h  | 7 +++
> > >>   3 files changed, 24 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > >> index af78291..39c8eab 100644
> > >> --- a/drivers/gpu/drm/drm_ioctl.c
> > >> +++ b/drivers/gpu/drm/drm_ioctl.c
> > >> @@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void 
> > >> *data, struct drm_file *file_priv)
> > >>  file_priv->atomic = req->value;
> > >>  file_priv->universal_planes = req->value;
> > >>  break;
> > >> +case DRM_CLIENT_CAP_ASPECT_RATIO:
> > >> +if (req->value > 1)
> > >> +return -EINVAL;
> > >> +/*
> > >> + * No Atomic userspace blows up on aspect ratio mode bits. 
> > >> Checked in
> > >> + * wayland/weston, xserver, and hardware-composer modeset paths.
> > >> + */
> > > Bogus indentation.
> > 
> > Thanks to point that out, will fix this.
> > 
> > > Also where's the aspect_ratio_allowed handling for the atomic cap?
> > > Or did we decide against it after all?
> > 
> > As discussed, aspect ratio is handled in the atomic modeset path, where 
> > in the modeset requests with aspect-ratios
> > are rejected, if the aspect-ratio cap not set.
> 
> That is not what we discussed on irc. What Daniel was suggesting is
> always enabling the aspect ratio cap for atomic clients, just as we
> already enable the univerals planes cap for atomic clients.

And to make sure we're on the same page finally

@@ -320,14 +320,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
case DRM_CLIENT_CAP_ATOMIC:
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
return -EINVAL;
if (req->value > 1)
return -EINVAL;
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
+   file_priv->aspect_ratio_allowed = req->value;
break;
default:
return -EINVAL;
}
 
return 0;
 }

is what we're talking about here.

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

Re: [PATCH] drm/bridge: cdns: Mark runtime PM operations as maybe unused

[Daniel Vetter]

On Thu, Apr 26, 2018 at 03:58:53PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Building the driver in a configuration with !PM currently causes a
> warning about these operations being unused. Mark them as such to shut
> up the compiler.
> 
> Signed-off-by: Thierry Reding 

I'd so love if we could use LTO (or at least link time garbage collection
of functions/heap allocations) instead of tons of #ifdef (even in macros)
and __maybe_unused.

Patch looks fine itself.

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/bridge/cdns-dsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index c255fc3e1be5..f2d43f24acfb 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -1337,7 +1337,7 @@ static const struct mipi_dsi_host_ops cdns_dsi_ops = {
>   .transfer = cdns_dsi_transfer,
>  };
>  
> -static int cdns_dsi_resume(struct device *dev)
> +static int __maybe_unused cdns_dsi_resume(struct device *dev)
>  {
>   struct cdns_dsi *dsi = dev_get_drvdata(dev);
>  
> @@ -1350,7 +1350,7 @@ static int cdns_dsi_resume(struct device *dev)
>   return 0;
>  }
>  
> -static int cdns_dsi_suspend(struct device *dev)
> +static int __maybe_unused cdns_dsi_suspend(struct device *dev)
>  {
>   struct cdns_dsi *dsi = dev_get_drvdata(dev);
>  
> -- 
> 2.17.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rect: Fix drm_rect_rotation_inv() docs

[Ville Syrjala]

From: Ville Syrjälä 

An overeager sed has corrupted the drm_rect_rotation_inv()
documentation. Fix it up.

Looks like it wasn't entirely correct before the sed fail
either. We were missing _rect_ from the function names, which
also explains why the sed hit these by accident.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_rect.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 9817c1445ba9..a3783ecea297 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -373,8 +373,8 @@ EXPORT_SYMBOL(drm_rect_rotate);
  * them when doing a rotatation and its inverse.
  * That is, if you do ::
  *
- * DRM_MODE_PROP_ROTATE(, width, height, rotation);
- * DRM_MODE_ROTATE_inv(, width, height, rotation);
+ * drm_rect_rotate(, width, height, rotation);
+ * drm_rect_rotate_inv(, width, height, rotation);
  *
  * you will always get back the original rectangle.
  */
-- 
2.16.1

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

Re: [PATCH v4] drm/panel: simple: Add TFC S9700RTWV43TR-01B 800x480 panel support

[Thierry Reding]

On Mon, Mar 12, 2018 at 11:33:45PM +0200, Jyri Sarha wrote:
> Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
> panel with resistive touch found on TI's AM335X-EVM.
> 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Tomi Valkeinen 
> cc: Thierry Reding 
> ---
>  .../display/panel/tfc,s9700rtwv43tr-01b.txt| 10 +
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt

Oh, you might want to Cc this to devicet...@vger.kernel.org and Rob
Herring (or any of the other bindings reviewers) for an Acked-by on
the DT bindings.

Thierry


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

Re: [PATCH v4] drm/panel: simple: Add TFC S9700RTWV43TR-01B 800x480 panel support

[Thierry Reding]

On Mon, Mar 12, 2018 at 11:33:45PM +0200, Jyri Sarha wrote:
> Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
> panel with resistive touch found on TI's AM335X-EVM.
> 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Tomi Valkeinen 
> cc: Thierry Reding 
> ---
>  .../display/panel/tfc,s9700rtwv43tr-01b.txt| 10 +
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt

Documentation/devicetree/bindings/vendor-prefixes.txt does not contain
an entry for "tfc". Please send a patch for that.

Other than that this look good to me.

Thierry


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

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[Thierry Reding]

On Wed, Mar 14, 2018 at 05:12:14PM +0800, Lin Huang wrote:
> From: huang lin 
> 
> Refactor Innolux P079ZCA panel driver, let it support
> multi panel.
> 
> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2

When you send out a revised set of these patches, please drop the
Change-Id: line from the commit message. It is useless for upstream.

Thierry


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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #16 from Joel Sass  ---
Created attachment 139134
  --> https://bugs.freedesktop.org/attachment.cgi?id=139134=edit
Here's the kernel .config I used for making the kernel

Key changes:

I added AMDGPU module, checked all 4 boxes. Looks like amdgpu.dc switch is
gone, assuming that's intentional.

I also checked the optimization for Intel Core 2/Xeon processors kernel
checkbox instead of generic x86

-- 
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 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #15 from Joel Sass  ---
Created attachment 139132
  --> https://bugs.freedesktop.org/attachment.cgi?id=139132=edit
This is the dmesg from an ssh session after attaching a monitor to my MST hub

root@nope:~/errors# uname -a
Linux nope 4.16.0-rc7+ #2 SMP Thu Apr 26 08:45:00 EDT 2018 x86_64 x86_64 x86_64
GNU/Linux

Kernel git acquired here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.17

Key message from dmesg:

[  526.900234] Call Trace:
[  526.900280]  dm_dp_mst_get_modes+0xce/0x120 [amdgpu]
[  526.900288]  drm_helper_probe_single_connector_modes+0x199/0x6c0
[drm_kms_helper]
[  526.900294]  ? jbd2_journal_stop+0xf3/0x3e0
[  526.900297]  ? __ext4_journal_stop+0x37/0xa0
[  526.900309]  drm_mode_getconnector+0x2c4/0x300 [drm]
[  526.900314]  ? _cond_resched+0x16/0x40
[  526.900324]  ? drm_mode_connector_property_set_ioctl+0x60/0x60 [drm]
[  526.900333]  drm_ioctl_kernel+0x67/0xb0 [drm]
[  526.900342]  drm_ioctl+0x2a9/0x350 [drm]
[  526.900352]  ? drm_mode_connector_property_set_ioctl+0x60/0x60 [drm]
[  526.900381]  amdgpu_drm_ioctl+0x46/0x80 [amdgpu]
[  526.900385]  do_vfs_ioctl+0xa2/0x5f0
[  526.900389]  ? vfs_write+0x162/0x1a0
[  526.900391]  SyS_ioctl+0x74/0x80
[  526.900395]  do_syscall_64+0x60/0x110
[  526.900399]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

-- 
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/rect: Handle rounding errors in drm_rect_clip_scaled

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_rect.c | 65 +++---
>  1 file changed, 47 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index b179c7c73cc5..71b6b7f5d58f 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -50,6 +50,24 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct 
> drm_rect *r2)
>  }
>  EXPORT_SYMBOL(drm_rect_intersect);
>  
> +static int drm_calc_scale(int src, int dst)
> +{
> + int scale = 0;
> +
> + if (WARN_ON(src < 0 || dst < 0))
> + return -EINVAL;
> +
> + if (dst == 0)
> + return 0;
> +
> + if (src > (dst << 16))
> + return DIV_ROUND_UP(src, dst);
> + else
> + scale = src / dst;
> +
> + return scale;
> +}
> +
>  /**
>   * drm_rect_clip_scaled - perform a scaled clip operation
>   * @src: source window rectangle
> @@ -71,49 +89,60 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct 
> drm_rect *dst,
>  {
>   int diff;
>  
> + /*
> +  * When scale is near 0x1 rounding errors may cause the scaling
> +  * factor to the other side. Some hardware may support
> +  * upsampling, but not downsampling, and that would break when
> +  * rounding.
> +  */
> +#define FIXUP(oldscale, fn, m, second) do { \
> + if (oldscale != 1 << 16) { \
> + int newscale = drm_calc_scale(fn(src), fn(dst)); \
> + \
> + if (newscale < 0) \
> + return false; \
> + \
> + if ((oldscale < 0x1) != (newscale < 0x1)) { \
> + if (!second) \
> + src->m##1 = src->m##2 - ((fn(dst) - diff) << 
> 16); \
> + else \
> + src->m##2 = src->m##1 + ((fn(dst) - diff) << 
> 16); \

This is starting to get very messy. Also are we sure the x2/y2 can't
go past the initial value here?

It's starting to feel like we should do the clip with the rounding the
orher way, which should guarantee we never flip between up and down
scaling by accident. And then just do a post-clip check for final scale
factor with the pessimistic rounding direction to make sure we stay
within the limits.

> + } \
> + } \
> + } while (0)
> +
>   diff = clip->x1 - dst->x1;
>   if (diff > 0) {
>   int64_t tmp = src->x1 + (int64_t) diff * hscale;
>   src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 0);
>   }
> +
>   diff = clip->y1 - dst->y1;
>   if (diff > 0) {
>   int64_t tmp = src->y1 + (int64_t) diff * vscale;
>   src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 0);
>   }
> +
>   diff = dst->x2 - clip->x2;
>   if (diff > 0) {
>   int64_t tmp = src->x2 - (int64_t) diff * hscale;
>   src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 1);
>   }
>   diff = dst->y2 - clip->y2;
>   if (diff > 0) {
>   int64_t tmp = src->y2 - (int64_t) diff * vscale;
>   src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 1);
>   }
> +#undef FIXUP
>  
>   return drm_rect_intersect(dst, clip);
>  }
>  EXPORT_SYMBOL(drm_rect_clip_scaled);
>  
> -static int drm_calc_scale(int src, int dst)
> -{
> - int scale = 0;
> -
> - if (WARN_ON(src < 0 || dst < 0))
> - return -EINVAL;
> -
> - if (dst == 0)
> - return 0;
> -
> - if (src > (dst << 16))
> - return DIV_ROUND_UP(src, dst);
> - else
> - scale = src / dst;
> -
> - return scale;
> -}
> -
>  /**
>   * drm_rect_calc_hscale - calculate the horizontal scaling factor
>   * @src: source window rectangle
> -- 
> 2.17.0

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

[PATCH] drm/bridge: cdns: Mark runtime PM operations as maybe unused

[Thierry Reding]

From: Thierry Reding 

Building the driver in a configuration with !PM currently causes a
warning about these operations being unused. Mark them as such to shut
up the compiler.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/bridge/cdns-dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index c255fc3e1be5..f2d43f24acfb 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -1337,7 +1337,7 @@ static const struct mipi_dsi_host_ops cdns_dsi_ops = {
.transfer = cdns_dsi_transfer,
 };
 
-static int cdns_dsi_resume(struct device *dev)
+static int __maybe_unused cdns_dsi_resume(struct device *dev)
 {
struct cdns_dsi *dsi = dev_get_drvdata(dev);
 
@@ -1350,7 +1350,7 @@ static int cdns_dsi_resume(struct device *dev)
return 0;
 }
 
-static int cdns_dsi_suspend(struct device *dev)
+static int __maybe_unused cdns_dsi_suspend(struct device *dev)
 {
struct cdns_dsi *dsi = dev_get_drvdata(dev);
 
-- 
2.17.0

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

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

[bugzilla-daemon]

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

--- Comment #14 from Joel Sass  ---
Alex, I just rebooted to this kernel after building. This problem still exists,
but it's not a hard freeze!

I'll attach the dmesg showing the error.

-- 
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 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default

[bugzilla-daemon]

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

Joel Sass  changed:

   What|Removed |Added

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

--- Comment #16 from Joel Sass  ---
Whoops. Changing to resolved/fixed.

-- 
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 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default

[bugzilla-daemon]

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

--- Comment #15 from Joel Sass  ---
This bug has been fixed in this branch: h

https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.17

brightness appears as normal after building the kernel from git.

Good job, and thanks.

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

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

[bugzilla-daemon]

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

--- Comment #8 from Harry Wentland  ---
(In reply to Jon from comment #7)
> (In reply to Harry Wentland from comment #6)
> > Marking resolved as no longer an issue on recent mainline.
> 
> Which commit fixes this? I merged in agd5f/drm-fixes-4.17 into linus master:
> Merge: 3be4aaf4e2d3 7ad35721e7d5
> 

I believe it was this:
8acad1a18a78 drm/amd/display: Add regamma lut write mask to SOC base


> I still see these crashes on every startup, with the following graphics card:
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Tonga XT / Amethyst XT [Radeon R9 380X / R9 M295X] (rev f1)
> 

Are you seeing a crash or simply the error log described in this ticket?

> regards

-- 
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: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Daniel Vetter]

On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
 wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > > It's been a while since we introduced drm_dev{get/put} functions
>> > > to replace reference/unreference in drm subsystem for the
>> > > consistency purpose. So, with this patch, let's just replace
>> > > all current use cases of drm_dev_unref() with drm_dev_put and remove
>> > > the function itself.
>> > >
>> > > Coccinelle was used for mass-patching.
>> > >
>> > > Signed-off-by: Vaishali Thakkar 
>> >
>> > Thanks for doing this. Unfortunately drm moves pretty fast, so already a
>> > conflict when I tried to apply this. Some drivers are also in their own
>> > trees, so this might lead to more fun :-/
>> >
>> > Can you pls split it up per-driver (just the directories under
>> > drivers/gpu/drm/ is enough)? Final patch to remove the function might then
>> > get stalled a bit ofc.
>>
>> I requested a single patch instead of splitting it per driver, you might want
>> to blame me for that.
>>
>
> Doesn't splitting the change per driver break bisectability unless there
> is a guarantee that the change in include/drm/drm_drv.h is applied after
> all the driver trees have been merged?

That's why I said the final patch will likely take a bit longer to get
merged, since we have to wait until all the trees converge again. But
since I have conflicts already looks like we can't take the shortcut
:-(
-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

Re: [PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series

[Rob Herring]

On Tue, Apr 24, 2018 at 3:32 AM, Türk, Jan  wrote:
>> -Ursprüngliche Nachricht-
>> Von: Shawn Guo Gesendet: Montag, 23. April 2018 10:45
>> Re: [PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series
>>
>> On Fri, Apr 20, 2018 at 02:50:52PM +0200, jan.tu...@emtrion.com wrote:
>> > From: Jan Tuerk 
>> >
>> > This patch adds support for the emtrion GmbH emCON-MX6 modules.
>> > They are available with imx.6 Solo, Dual-Lite, Dual and Quad equipped
>> > with Memory from 512MB to 2GB (configured by U-Boot).
>> >
>> > Our default developer-Kit ships with the Avari baseboard and the EDT
>> > ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
>> >
>> > The devicetree is split into the common part providing all module
>> > components and the basic support for all SoC versions
>> > (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
>> > Finally the support for the avari baseboard in the developer-kit
>> > configuration is provided by the emcon-avari dts files.
>> >
>> > Signed-off-by: Jan Tuerk 
>> > ---
>> >  Documentation/devicetree/bindings/arm/emtrion.txt |  13 +
>>
>> It's better to have a separate patch for bindings doc, which needs to be
>> acknowledged by DT maintainers.
>
> I can change that, but nobody complained in the first 2 revisions of the 
> patch.

Well, sometimes I forget to mention what is step 1 in
Documentation/devicetree/bindings/submitting-patches.txt.

> Also I though having the documentation is required for merging new bindings?

Yes, so binding patches come first (step 3).

>> >  arch/arm/boot/dts/Makefile|   2 +
>> >  arch/arm/boot/dts/imx6dl-emcon-avari.dts  | 224 ++
>> >  arch/arm/boot/dts/imx6dl-emcon.dtsi   |  27 +
>> >  arch/arm/boot/dts/imx6q-emcon-avari.dts   | 224 ++
>> >  arch/arm/boot/dts/imx6q-emcon.dtsi|  27 +
>> >  arch/arm/boot/dts/imx6qdl-emcon.dtsi  | 838
>> ++
>> >  7 files changed, 1355 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
>> >  create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
>> >  create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
>> >  create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
>> >  create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
>> >  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

[...]

>> > +   };
>> > +
>> > +   boardID: pca8754a@3a {
>>
>> Please find a more generic node name for it.
>
> you mean boardID@3a?

No. "gpio@3a" as it is a gpio controller.

> This chip identifies the baseboard type for the bootloader.
>
>>
>> > +   compatible = "nxp,pca8574";
>> > +   reg = <0x3a>;
>> > +   gpio-controller;
>> > +   #gpio-cells = <1>;
>> > +   };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm/rect: Handle rounding errors in drm_rect_clip_scaled

[Daniel Vetter]

On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
> 
> Signed-off-by: Maarten Lankhorst 

I think this and the previous patch are perfect candidates for in-kernel
selftests. Can I volunteer you to get those started for the kms side? We
already have a drm_mm selftest, but I think splitting things a bit might
be useful.

Or we rename that one and just stuff all the kms tests in there, dunno.
-Daniel

> ---
>  drivers/gpu/drm/drm_rect.c | 65 +++---
>  1 file changed, 47 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index b179c7c73cc5..71b6b7f5d58f 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -50,6 +50,24 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct 
> drm_rect *r2)
>  }
>  EXPORT_SYMBOL(drm_rect_intersect);
>  
> +static int drm_calc_scale(int src, int dst)
> +{
> + int scale = 0;
> +
> + if (WARN_ON(src < 0 || dst < 0))
> + return -EINVAL;
> +
> + if (dst == 0)
> + return 0;
> +
> + if (src > (dst << 16))
> + return DIV_ROUND_UP(src, dst);
> + else
> + scale = src / dst;
> +
> + return scale;
> +}
> +
>  /**
>   * drm_rect_clip_scaled - perform a scaled clip operation
>   * @src: source window rectangle
> @@ -71,49 +89,60 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct 
> drm_rect *dst,
>  {
>   int diff;
>  
> + /*
> +  * When scale is near 0x1 rounding errors may cause the scaling
> +  * factor to the other side. Some hardware may support
> +  * upsampling, but not downsampling, and that would break when
> +  * rounding.
> +  */
> +#define FIXUP(oldscale, fn, m, second) do { \
> + if (oldscale != 1 << 16) { \
> + int newscale = drm_calc_scale(fn(src), fn(dst)); \
> + \
> + if (newscale < 0) \
> + return false; \
> + \
> + if ((oldscale < 0x1) != (newscale < 0x1)) { \
> + if (!second) \
> + src->m##1 = src->m##2 - ((fn(dst) - diff) << 
> 16); \
> + else \
> + src->m##2 = src->m##1 + ((fn(dst) - diff) << 
> 16); \
> + } \
> + } \
> + } while (0)
> +
>   diff = clip->x1 - dst->x1;
>   if (diff > 0) {
>   int64_t tmp = src->x1 + (int64_t) diff * hscale;
>   src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 0);
>   }
> +
>   diff = clip->y1 - dst->y1;
>   if (diff > 0) {
>   int64_t tmp = src->y1 + (int64_t) diff * vscale;
>   src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 0);
>   }
> +
>   diff = dst->x2 - clip->x2;
>   if (diff > 0) {
>   int64_t tmp = src->x2 - (int64_t) diff * hscale;
>   src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 1);
>   }
>   diff = dst->y2 - clip->y2;
>   if (diff > 0) {
>   int64_t tmp = src->y2 - (int64_t) diff * vscale;
>   src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 1);
>   }
> +#undef FIXUP
>  
>   return drm_rect_intersect(dst, clip);
>  }
>  EXPORT_SYMBOL(drm_rect_clip_scaled);
>  
> -static int drm_calc_scale(int src, int dst)
> -{
> - int scale = 0;
> -
> - if (WARN_ON(src < 0 || dst < 0))
> - return -EINVAL;
> -
> - if (dst == 0)
> - return 0;
> -
> - if (src > (dst << 16))
> - return DIV_ROUND_UP(src, dst);
> - else
> - scale = src / dst;
> -
> - return scale;
> -}
> -
>  /**
>   * drm_rect_calc_hscale - calculate the horizontal scaling factor
>   * @src: source window rectangle
> -- 
> 2.17.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH/RFC 1/4] drm: Add colorkey properties

[Ville Syrjälä]

On Sun, Dec 17, 2017 at 02:17:21AM +0200, Laurent Pinchart wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent, or gain a
> programmable alpha value.
> 
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds four properties
> related to color keying named colorkey.min, colorkey.max, colorkey.alpha
> and colorkey.mode. Additional properties can be defined by drivers to
> expose device-specific features.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_atomic.c |  16 +++
>  drivers/gpu/drm/drm_blend.c  | 108 
> +++
>  include/drm/drm_blend.h  |   4 ++
>  include/drm/drm_plane.h  |  28 ++-
>  4 files changed, 155 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 37445d50816a..4f57ec25e04d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -756,6 +756,14 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
>   state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.value_property) {
> + state->colorkey.value = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -815,6 +823,14 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
>   *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.value_property) {
> + *val = state->colorkey.value;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 2e5e089dd912..79da7d8a22e2 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -98,6 +98,10 @@
>   *   planes. Without this property the primary plane is always below the 
> cursor
>   *   plane, and ordering between all other planes is undefined.
>   *
> + * - Color keying is set up with drm_plane_create_colorkey_properties(). It 
> adds
> + *   support for replacing a range of colors with a transparent color in the
> + *   plane.
> + *
>   * Note that all the property extensions described here apply either to the
>   * plane or the CRTC (e.g. for the background color, which currently is not
>   * exposed and assumed to be black).
> @@ -405,3 +409,107 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_normalize_zpos);
> +
> +/**
> + * drm_plane_create_colorkey_properties - create colorkey properties
> + * @plane: drm plane
> + * @modes: array of supported color keying modes
> + * @num_modes: number of modes in the modes array
> + * @replace: if true create the colorkey.replacement property
> + *
> + * This function creates the generic color keying properties and attach them 
> to
> + * the plane to enable color keying control for blending operations.
> + *
> + * Color keying is controlled through four properties:
> + *
> + * colorkey.mode:
> + *   The mode is an enumerated property that controls how color keying
> + *   operates. Modes are driver-specific, except for a "disabled" mode that
> + *   disables color keying and is guaranteed to exist if color keying is
> + *   supported.

I don't see why we need driver specific modes. It should be possible to
come up with some standard modes. I suppose a simple src vs. dst doesn't
suffice, but if we combine that with a bit more information it should be
good enough? Eg. i915 would expose something like src-min-max and
dst-value-mask.

> + *
> + * colorkey.min, colorkey.max:
> + *   Those two properties 

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

[Thierry Reding]

On Thu, Apr 26, 2018 at 03:59:04PM +0300, Mikko Perttunen wrote:
> On 26.04.2018 15:41, Thierry Reding wrote:
> > On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote:
> > > On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote:
> > > > From: Thierry Reding 
> > > > 
> > > > Depending on the kernel configuration, early ARM architecture setup code
> > > > may have attached the GPU to a DMA/IOMMU mapping that transparently uses
> > > > the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
> > > > backed buffers (a special bit in the GPU's MMU page tables indicates the
> > > > memory path to take: via the SMMU or directly to the memory controller).
> > > > Transparently backing DMA memory with an IOMMU prevents Nouveau from
> > > > properly handling such memory accesses and causes memory access faults.
> > > > 
> > > > As a side-note: buffers other than those allocated in instance memory
> > > > don't need to be physically contiguous from the GPU's perspective since
> > > > the GPU can map them into contiguous buffers using its own MMU. Mapping
> > > > these buffers through the IOMMU is unnecessary and will even lead to
> > > > performance degradation because of the additional translation.
> > > > 
> > > > Signed-off-by: Thierry Reding 
> > > > ---
> > > > I had already sent this out independently to fix a regression that was
> > > > introduced in v4.16, but then Christoph pointed out that it should've
> > > > been sent to a wider audience and should use a core API rather than
> > > > calling into architecture code directly.
> > > > 
> > > > I've added it to this series for easier reference and to show the need
> > > > for the new API.
> > > 
> > > This is good stuff, I am struggling with something similar on ARM64. One
> > > problem that I wasn't able to fully solve cleanly was that for arm-smmu
> > > the SMMU HW resources are not released until the domain itself is 
> > > destroyed
> > > and I never quite figured out a way to swap the default domain cleanly.
> > > 
> > > This is a problem for the MSM GPU because not only do we run our own 
> > > IOMMU as
> > > you do we also have a hardware dependency to use context bank 0 to
> > > asynchronously switch the pagetable during rendering.
> > > 
> > > I'm not sure if this is a problem you have encountered.
> > 
> > I don't think I have. Recent chips have similar capabilities, but they
> > don't have the restriction to a context bank, as far as I understand.
> > Adding Mikko who's had more exposure to this.
> 
> IIRC the only way I've gotten Host1x to work on Tegra186 with IOMMU enabled
> is doing the equivalent of this patch (or actually using the DMA API, which
> may be possible but has some potential issues).
> 
> As you said, we don't have a limitation regarding the context bank or
> similar - Host1x handles context switching by changing the sent stream ID on
> the fly (which is quite difficult to deal with from kernel point of view as
> well), and the actual GPU has its own MMU.

One instance where we still need the system MMU for GPU is to implement
support for big pages, which is required in order to do compression and
better performance in some other use-cases. I don't think we'll need
anything fancy like context switching in that case, though, because we
would use the SMMU exclusively to make sparse allocations look
contiguous to the GPU, so all of the per-process protection would still
be achieved via the GPU MMU.

Thierry


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

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

[Mikko Perttunen]

On 26.04.2018 15:41, Thierry Reding wrote:

On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote:

On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote:

From: Thierry Reding 

Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the memory controller).
Transparently backing DMA memory with an IOMMU prevents Nouveau from
properly handling such memory accesses and causes memory access faults.

As a side-note: buffers other than those allocated in instance memory
don't need to be physically contiguous from the GPU's perspective since
the GPU can map them into contiguous buffers using its own MMU. Mapping
these buffers through the IOMMU is unnecessary and will even lead to
performance degradation because of the additional translation.

Signed-off-by: Thierry Reding 
---
I had already sent this out independently to fix a regression that was
introduced in v4.16, but then Christoph pointed out that it should've
been sent to a wider audience and should use a core API rather than
calling into architecture code directly.

I've added it to this series for easier reference and to show the need
for the new API.


This is good stuff, I am struggling with something similar on ARM64. One
problem that I wasn't able to fully solve cleanly was that for arm-smmu
the SMMU HW resources are not released until the domain itself is destroyed
and I never quite figured out a way to swap the default domain cleanly.

This is a problem for the MSM GPU because not only do we run our own IOMMU as
you do we also have a hardware dependency to use context bank 0 to
asynchronously switch the pagetable during rendering.

I'm not sure if this is a problem you have encountered.


I don't think I have. Recent chips have similar capabilities, but they
don't have the restriction to a context bank, as far as I understand.
Adding Mikko who's had more exposure to this.


IIRC the only way I've gotten Host1x to work on Tegra186 with IOMMU 
enabled is doing the equivalent of this patch (or actually using the DMA 
API, which may be possible but has some potential issues).


As you said, we don't have a limitation regarding the context bank or 
similar - Host1x handles context switching by changing the sent stream 
ID on the fly (which is quite difficult to deal with from kernel point 
of view as well), and the actual GPU has its own MMU.


Thanks,
Mikko




In any event, this code
gets us a little bit further down the path and at least there is somebody else
out there in the cold dark world that understands my pain. :)


This doesn't actually fix anything on 64-bit ARM, and oddly enough I
haven't run into this issue myself on 64-bit ARM either. I think the
reason is that I haven't tested Nouveau on Tegra186 yet, which is the
first SoC which has an ARM SMMU. On prior 64-bit ARM chips we've used
the custom Tegra SMMU and that driver simply forbids creating any DMA
domains, so it will allow only explicit usage of the IOMMU API. There
is code in the generic DMA/IOMMU integration layer to not use the DMA
API with non-DMA IOMMU domains, but that's not true on 32-bit ARM,
unfortunately. It's entirely possible that Tegra186 will show exactly
the same problem that you are describing.

We do use the IOMMU API explicitly in the Tegra DRM driver as well,
and that is something that I've tested on Tegra186 and that I know to
be working. However, the reason why it works there is that the IOMMU
group will contain multiple display controllers, which will again
trigger a special case that will prevent the DMA/IOMMU integration
from setting up a DMA domain for use with those devices.


For your interest, here was my half-hearted attempt to avoid creating DMA
domains in the first place based on a blacklist to try to spur a bit of
discussion: https://patchwork.freedesktop.org/series/41573/


This looks very interesting and simple, but I can imagine that it will
see significant pushback from the ARM SMMU maintainers (if not complete
silence), because it adds SoC-specific knowledge to an otherwise fully
generic driver. Having the GPU driver explicitly detach from the IOMMU
domain sounds like a better option, but I don't see how that would help
with the context bank issue that you're seeing.

One other possibility that I can imagine is to add something to struct
device that could be used by arch_setup_dma_ops() to not attach any of
the IOMMU-backed DMA operations to the device. Unfortunately that code
is called before the driver's ->probe() implementation is called, so a
driver doesn't have an opportunity to set it. Something like
of_dma_configure() could still set that up, perhaps based on some DT
property, though I can already hear 

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Vaishali Thakkar]

On Thu, Apr 26, 2018 at 6:15 PM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > It's been a while since we introduced drm_dev{get/put} functions
>> > to replace reference/unreference in drm subsystem for the
>> > consistency purpose. So, with this patch, let's just replace
>> > all current use cases of drm_dev_unref() with drm_dev_put and remove
>> > the function itself.
>> >
>> > Coccinelle was used for mass-patching.
>> >
>> > Signed-off-by: Vaishali Thakkar 
>>
>> Thanks for doing this. Unfortunately drm moves pretty fast, so already a
>> conflict when I tried to apply this. Some drivers are also in their own
>> trees, so this might lead to more fun :-/
>>
>> Can you pls split it up per-driver (just the directories under
>> drivers/gpu/drm/ is enough)? Final patch to remove the function might then
>> get stalled a bit ofc.
>
> I requested a single patch instead of splitting it per driver, you might want
> to blame me for that.
>
>> Also can you pls update ./scripts/coccinelle/api/drm-get-put.cocci and
>> remove that spatch hunk in the final patch, since we no longer need it?
>
> How about just rerunning the coccinelle patch when it's time to apply this ?
> There's precedent for performing such automated changes, and it would ensure
> that no driver is left out.

I was planning to send patches to remove all remaining reference/unreference
functions by the weekend [as there aren't much remaining now and I see that
new drivers keeps adding them instead of new API]. So, wanted to delete whole
cocci file after that. I thought of dividing a patch per function because
Laurent requested to send a single patch for all files.

But if we are going to split it per driver under gpu/drm, would it work if per
driver patch contains all function cases? Also, would you be fine with taking a
patch for removal of coccinelle file via your tree? Then I can include that in
the same patchset as well.

Thanks!

>> > ---
>> >
>> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
>> >  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
>> >  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
>> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
>> >  drivers/gpu/drm/drm_drv.c  | 13 -
>> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
>> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
>> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
>> >  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
>> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
>> >  drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
>> >  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
>> >  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
>> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
>> >  drivers/gpu/drm/msm/msm_drv.c  |  8 
>> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
>> >  drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
>> >  drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
>> >  drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
>> >  drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
>> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
>> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
>> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
>> >  drivers/gpu/drm/sti/sti_drv.c  |  8 
>> >  drivers/gpu/drm/stm/drv.c  |  4 ++--
>> >  drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
>> >  drivers/gpu/drm/tegra/drm.c|  4 ++--
>> >  drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
>> >  drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
>> >  drivers/gpu/drm/udl/udl_drv.c  |  2 +-
>> >  drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
>> >  drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
>> >  drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
>> >  drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
>> >  include/drm/drm_drv.h  |  1 -
>> >  41 files changed, 73 insertions(+), 87 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>



-- 
Vaishali

[radeon-alex:amd-mainline-dkms-4.15 1231/1759] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2183 fill_plane_attributes() warn: if statement not indented

[Dan Carpenter]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head:   9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 265083076187e619aa9176aeb05ad630013429b4 [1231/1759] drm/amd/display: 
Hookup color management functions

smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2183 
fill_plane_attributes() warn: if statement not indented

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout 265083076187e619aa9176aeb05ad630013429b4
vim +2183 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c

e7b07ceef Harry Wentland   2017-08-10  2143  
3ee6b26b7 Alex Deucher 2017-10-10  2144  static int 
fill_plane_attributes(struct amdgpu_device *adev,
3be5262e3 Harry Wentland   2017-07-27  2145  struct 
dc_plane_state *dc_plane_state,
e7b07ceef Harry Wentland   2017-08-10  2146  struct 
drm_plane_state *plane_state,
ab8968728 Michel Dänzer2017-10-26  2147  struct 
drm_crtc_state *crtc_state)
e7b07ceef Harry Wentland   2017-08-10  2148  {
e7b07ceef Harry Wentland   2017-08-10  2149 const struct amdgpu_framebuffer 
*amdgpu_fb =
e7b07ceef Harry Wentland   2017-08-10  2150 
to_amdgpu_framebuffer(plane_state->fb);
25b138493 Roger He 2018-02-26  2151  #if LINUX_VERSION_CODE >= 
KERNEL_VERSION(4, 6, 0) || \
25b138493 Roger He 2018-02-26  2152 defined(OS_NAME_RHEL_7_3) || \
25b138493 Roger He 2018-02-26  2153 defined(OS_NAME_RHEL_7_4_5)
e7b07ceef Harry Wentland   2017-08-10  2154 const struct drm_crtc *crtc = 
plane_state->crtc;
30b13a59d Junwei Zhang 2018-02-08  2155  #else
30b13a59d Junwei Zhang 2018-02-08  2156 struct drm_crtc *crtc = 
plane_state->crtc;
30b13a59d Junwei Zhang 2018-02-08  2157  #endif
e7b07ceef Harry Wentland   2017-08-10  2158 struct dc_transfer_func 
*input_tf;
e7b07ceef Harry Wentland   2017-08-10  2159 int ret = 0;
e7b07ceef Harry Wentland   2017-08-10  2160  
3be5262e3 Harry Wentland   2017-07-27  2161 if 
(!fill_rects_from_plane_state(plane_state, dc_plane_state))
e7b07ceef Harry Wentland   2017-08-10  2162 return -EINVAL;
e7b07ceef Harry Wentland   2017-08-10  2163  
e7b07ceef Harry Wentland   2017-08-10  2164 ret = 
fill_plane_attributes_from_fb(
e7b07ceef Harry Wentland   2017-08-10  2165 crtc->dev->dev_private,
3be5262e3 Harry Wentland   2017-07-27  2166 dc_plane_state,
ab8968728 Michel Dänzer2017-10-26  2167 amdgpu_fb);
e7b07ceef Harry Wentland   2017-08-10  2168  
e7b07ceef Harry Wentland   2017-08-10  2169 if (ret)
e7b07ceef Harry Wentland   2017-08-10  2170 return ret;
e7b07ceef Harry Wentland   2017-08-10  2171  
e7b07ceef Harry Wentland   2017-08-10  2172 input_tf = 
dc_create_transfer_func();
e7b07ceef Harry Wentland   2017-08-10  2173  
e7b07ceef Harry Wentland   2017-08-10  2174 if (input_tf == NULL)
e7b07ceef Harry Wentland   2017-08-10  2175 return -ENOMEM;
e7b07ceef Harry Wentland   2017-08-10  2176  
3be5262e3 Harry Wentland   2017-07-27  2177 
dc_plane_state->in_transfer_func = input_tf;
e7b07ceef Harry Wentland   2017-08-10  2178  
e7b07ceef Harry Wentland   2017-08-10  2179 /* In case of gamma set, update 
gamma value */
25b138493 Roger He 2018-02-26  2180  #if LINUX_VERSION_CODE >= 
KERNEL_VERSION(4, 6, 0) || \
25b138493 Roger He 2018-02-26  2181 defined(OS_NAME_RHEL_7_3) || \
25b138493 Roger He 2018-02-26  2182 defined(OS_NAME_RHEL_7_4_5)
e7b07ceef Harry Wentland   2017-08-10 @2183 if (crtc_state->gamma_lut)
265083076 Leo (Sunpeng  Li 2018-02-02  2184)/*
265083076 Leo (Sunpeng  Li 2018-02-02  2185) * Always set input transfer 
function, since plane state is refreshed
265083076 Leo (Sunpeng  Li 2018-02-02  2186) * every time.
265083076 Leo (Sunpeng  Li 2018-02-02  2187) */
265083076 Leo (Sunpeng  Li 2018-02-02  2188)ret = 
amdgpu_dm_set_degamma_lut(crtc_state, dc_plane_state);

It should be indented and I would normally use curly braces around the
whole thing as well for readability.

3f4b5749a Junwei Zhang 2018-02-07  2189  #else
3f4b5749a Junwei Zhang 2018-02-07  2190 if (crtc->mode.private_flags & 
AMDGPU_CRTC_MODE_PRIVATE_FLAGS_GAMMASET) {
3f4b5749a Junwei Zhang 2018-02-07  2191 
fill_gamma_from_crtc(crtc, dc_plane_state);
3f4b5749a Junwei Zhang 2018-02-07  2192 /* reset trigger of 
gamma */
3f4b5749a Junwei Zhang 2018-02-07  2193 
crtc->mode.private_flags &=
3f4b5749a Junwei Zhang 2018-02-07  2194 
~AMDGPU_CRTC_MODE_PRIVATE_FLAGS_GAMMASET;
3f4b5749a Junwei Zhang 2018-02-07  2195 }
3f4b5749a Junwei Zhang 2018-02-07  2196  #endif
e7b07ceef Harry Wentland   2017-08-10  2197  
e7b07ceef Harry Wentland   2017-08-10  2198 return ret;
e7b07ceef Harry 

Re: [PATCH v4 0/2] drm/panel: Add device link in drm_panel_attach()

[Thierry Reding]

On Thu, Apr 26, 2018 at 11:06:58AM +0300, Jyri Sarha wrote:
> I guess the first patch should be mergable. With the second, maybe it
> is better to wait until we have a full solution including the bridges
> too. What should I do to get the first patch merged?

I don't see a reason why patch 2 can't be applied as-is right now. The
bridges can always be fixed in a separate patch.

Applied both of these to drm-misc-next, thanks.

Thierry


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

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Laurent Pinchart]

Hi Daniel,

On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> > It's been a while since we introduced drm_dev{get/put} functions
> > to replace reference/unreference in drm subsystem for the
> > consistency purpose. So, with this patch, let's just replace
> > all current use cases of drm_dev_unref() with drm_dev_put and remove
> > the function itself.
> > 
> > Coccinelle was used for mass-patching.
> > 
> > Signed-off-by: Vaishali Thakkar 
> 
> Thanks for doing this. Unfortunately drm moves pretty fast, so already a
> conflict when I tried to apply this. Some drivers are also in their own
> trees, so this might lead to more fun :-/
> 
> Can you pls split it up per-driver (just the directories under
> drivers/gpu/drm/ is enough)? Final patch to remove the function might then
> get stalled a bit ofc.

I requested a single patch instead of splitting it per driver, you might want 
to blame me for that.

> Also can you pls update ./scripts/coccinelle/api/drm-get-put.cocci and
> remove that spatch hunk in the final patch, since we no longer need it?

How about just rerunning the coccinelle patch when it's time to apply this ? 
There's precedent for performing such automated changes, and it would ensure 
that no driver is left out.

> > ---
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
> >  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
> >  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
> >  drivers/gpu/drm/drm_drv.c  | 13 -
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
> >  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
> >  drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
> >  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
> >  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
> >  drivers/gpu/drm/msm/msm_drv.c  |  8 
> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
> >  drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
> >  drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
> >  drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
> >  drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
> >  drivers/gpu/drm/sti/sti_drv.c  |  8 
> >  drivers/gpu/drm/stm/drv.c  |  4 ++--
> >  drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
> >  drivers/gpu/drm/tegra/drm.c|  4 ++--
> >  drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
> >  drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
> >  drivers/gpu/drm/udl/udl_drv.c  |  2 +-
> >  drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
> >  drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
> >  drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
> >  drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
> >  include/drm/drm_drv.h  |  1 -
> >  41 files changed, 73 insertions(+), 87 deletions(-)

-- 
Regards,

Laurent Pinchart



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

RE: [PATCH] drm: Don't pass the index to drm_property_add_enum()

[Lisovskiy, Stanislav]

Reviewed-by: Stanislav Lisovskiy 

Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of 
Lisovskiy, Stanislav [stanislav.lisovs...@intel.com]
Sent: Monday, April 23, 2018 4:59 PM
To: Ville Syrjala; dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org; intel-...@lists.freedesktop.org; Ben Skeggs
Subject: Re: [Intel-gfx] [PATCH] drm: Don't pass the index to 
drm_property_add_enum()

Acked-by: Stanislav Lisovskiy 

Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>


From: Ville Syrjala [ville.syrj...@linux.intel.com]
Sent: Friday, March 16, 2018 9:04 PM
To: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs; 
nouv...@lists.freedesktop.org
Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum()

From: Ville Syrjälä 

drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.

Cc: Patrik Jakobsson 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c   |  6 +++---
 drivers/gpu/drm/drm_property.c| 27 +--
 drivers/gpu/drm/gma500/cdv_device.c   |  4 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +---
 include/drm/drm_property.h|  2 +-
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..dfc8ca1e9413 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
goto nomem;

for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property, i,
+   drm_property_add_enum(dev->mode_config.tv_mode_property,
  i, modes[i]);

dev->mode_config.tv_brightness_property =
@@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_property *scaling_mode_property;
-   int i, j = 0;
+   int i;
const unsigned valid_scaling_mode_mask =
(1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;

@@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
if (!(BIT(i) & scaling_mode_mask))
continue;

-   ret = drm_property_add_enum(scaling_mode_property, j++,
+   ret = drm_property_add_enum(scaling_mode_property,
drm_scaling_mode_enum_list[i].type,
drm_scaling_mode_enum_list[i].name);

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 8f4672daac7f..1f8031e30f53 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev,
return NULL;

for (i = 0; i < num_values; i++) {
-   ret = drm_property_add_enum(property, i,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret, index = 0;
+   int i, ret;
int num_values = hweight64(supported_bits);

flags |= DRM_MODE_PROP_BITMASK;
@@ -221,14 +221,9 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
if (!(supported_bits & (1ULL << props[i].type)))
continue;

-   if (WARN_ON(index >= num_values)) {
-   drm_property_destroy(dev, property);
-   return NULL;
-   }
-
-   ret = drm_property_add_enum(property, index++,
- 

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

[Thierry Reding]

On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote:
> On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > Depending on the kernel configuration, early ARM architecture setup code
> > may have attached the GPU to a DMA/IOMMU mapping that transparently uses
> > the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
> > backed buffers (a special bit in the GPU's MMU page tables indicates the
> > memory path to take: via the SMMU or directly to the memory controller).
> > Transparently backing DMA memory with an IOMMU prevents Nouveau from
> > properly handling such memory accesses and causes memory access faults.
> > 
> > As a side-note: buffers other than those allocated in instance memory
> > don't need to be physically contiguous from the GPU's perspective since
> > the GPU can map them into contiguous buffers using its own MMU. Mapping
> > these buffers through the IOMMU is unnecessary and will even lead to
> > performance degradation because of the additional translation.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> > I had already sent this out independently to fix a regression that was
> > introduced in v4.16, but then Christoph pointed out that it should've
> > been sent to a wider audience and should use a core API rather than
> > calling into architecture code directly.
> > 
> > I've added it to this series for easier reference and to show the need
> > for the new API.
> 
> This is good stuff, I am struggling with something similar on ARM64. One
> problem that I wasn't able to fully solve cleanly was that for arm-smmu 
> the SMMU HW resources are not released until the domain itself is destroyed
> and I never quite figured out a way to swap the default domain cleanly.
> 
> This is a problem for the MSM GPU because not only do we run our own IOMMU as
> you do we also have a hardware dependency to use context bank 0 to
> asynchronously switch the pagetable during rendering.
> 
> I'm not sure if this is a problem you have encountered.

I don't think I have. Recent chips have similar capabilities, but they
don't have the restriction to a context bank, as far as I understand.
Adding Mikko who's had more exposure to this.

> In any event, this code
> gets us a little bit further down the path and at least there is somebody else
> out there in the cold dark world that understands my pain. :)

This doesn't actually fix anything on 64-bit ARM, and oddly enough I
haven't run into this issue myself on 64-bit ARM either. I think the
reason is that I haven't tested Nouveau on Tegra186 yet, which is the
first SoC which has an ARM SMMU. On prior 64-bit ARM chips we've used
the custom Tegra SMMU and that driver simply forbids creating any DMA
domains, so it will allow only explicit usage of the IOMMU API. There
is code in the generic DMA/IOMMU integration layer to not use the DMA
API with non-DMA IOMMU domains, but that's not true on 32-bit ARM,
unfortunately. It's entirely possible that Tegra186 will show exactly
the same problem that you are describing.

We do use the IOMMU API explicitly in the Tegra DRM driver as well,
and that is something that I've tested on Tegra186 and that I know to
be working. However, the reason why it works there is that the IOMMU
group will contain multiple display controllers, which will again
trigger a special case that will prevent the DMA/IOMMU integration
from setting up a DMA domain for use with those devices.

> For your interest, here was my half-hearted attempt to avoid creating DMA
> domains in the first place based on a blacklist to try to spur a bit of
> discussion: https://patchwork.freedesktop.org/series/41573/

This looks very interesting and simple, but I can imagine that it will
see significant pushback from the ARM SMMU maintainers (if not complete
silence), because it adds SoC-specific knowledge to an otherwise fully
generic driver. Having the GPU driver explicitly detach from the IOMMU
domain sounds like a better option, but I don't see how that would help
with the context bank issue that you're seeing.

One other possibility that I can imagine is to add something to struct
device that could be used by arch_setup_dma_ops() to not attach any of
the IOMMU-backed DMA operations to the device. Unfortunately that code
is called before the driver's ->probe() implementation is called, so a
driver doesn't have an opportunity to set it. Something like
of_dma_configure() could still set that up, perhaps based on some DT
property, though I can already hear the NAK from DT maintainers because
this is, after all, policy, not hardware description.

The last solution that I can think of that might allow us to do this is
to add a flag to struct device_driver (bool explicit_iommu?) that will
be used by the DMA/IOMMU setup code to decide whether or not to attach
to the IOMMU automatically.

Though, again, I'm not sure that would actually solve your bank problem.