Re: [Intel-gfx] [PATCH] drm/debugfs: Fix framebuffer debugfs file init

[Dave Airlie]

On 14 November 2017 at 09:12, Noralf Trønnes  wrote:
> The introduction of: drm/framebuffer: Add framebuffer debugfs file
> broke vgem. That patch assumed that all drivers had initialized the
> dev->mode_config.fb_lock mutex which happens in drm_mode_config_init().
> vgem doesn't need to call drm_mode_config_init().
>
> Fix this by only creating the framebuffer debugfs file for modesetting
> drivers.
>
> Fixes: 45d58b40292b ("drm/framebuffer: Add framebuffer debugfs file")
> Suggested-by: Chris Wilson 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Dave Airlie 

Can someone pushed this to drm-misc, I think it's blocking the intel CI ppl.

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

[PATCH] drm/tilcdc: uninitialized variable in tilcdc_get_overlay()

[Dan Carpenter]

The code seems to assume that of_fdt_unflatten_tree() sets "overlay" to
NULL on error but actually it could be uninitialized.

Fixes: 4e7221580223 ("drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for 
ti,tilcdc,slave binding support")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index d2b9e5f04724..a8a70b36f0ff 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -144,7 +144,7 @@ static struct device_node * __init 
tilcdc_get_overlay(struct kfree_table *kft)
const int size = __dtb_tilcdc_slave_compat_end -
__dtb_tilcdc_slave_compat_begin;
static void *overlay_data;
-   struct device_node *overlay;
+   struct device_node *overlay = NULL;
 
if (!size) {
pr_warn("%s: No overlay data\n", __func__);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] OMAPFB: prevent buffer underflow in omapfb_parse_vram_param()

[Dan Carpenter]

We cap the upper bound of "fbnum" but we also need to check for
negatives or make the type unsigned.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c 
b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index 1d7c012f09db..e08e5664e330 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -1477,7 +1477,7 @@ static int omapfb_alloc_fbmem_display(struct fb_info 
*fbi, unsigned long size,
 static int omapfb_parse_vram_param(const char *param, int max_entries,
unsigned long *sizes, unsigned long *paddrs)
 {
-   int fbnum;
+   unsigned int fbnum;
unsigned long size;
unsigned long paddr = 0;
char *p, *start;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] exynos-drm-next

[Dave Airlie]

On 26 October 2017 at 11:37, Inki Dae  wrote:
> Hi Dave,
>
>Improving Exynos DRM HDMI and Mixer drivers and also adding
>HDMI audio support.
>
>Please kindly let me know if there is any problem.
>
>Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
>such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request
>git pull one more time after review.

Hi Inki,

I dropped the ball a bit here, I do think the second pull with IPP is
probably a bit late,
I think I'd like more assurance that the UAPI for IPP is to be used in
some upstream
shipping project (forks of mpv not withstanding, unless this fork
ships in some distro
or product).

I unfortunately forgot to pull this one, I've rectified that and it is
now in drm-next.

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

Re: drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline

[Archit Taneja]

On 11/14/2017 02:33 AM, Eric Anholt wrote:

Lothar Waßmann  writes:


Hi,

On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:

Lothar Waßmann  writes:


Hi,

drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
dysfunctional due to:
|commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
|Author: Eric Anholt 
|Date:   Fri Jun 2 13:25:14 2017 -0700
|
|drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

Also, there is no in-kernel user of this driver, so that it obviously
doesn't get tested in any way. There is only one dts file (r8a7779-marzen.dts)
that instantiates this driver, but it has an incomplete OF graph. The missing
link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
the kernel source.

Should the driver be removed or moved to staging, until it is properly
fixed?


I can't see any behavior change about the DT handling in that commit,
and I didn't intend for there to be any.  Could you help me understand
what went wrong?


With the offending commit applied, the lvds-encoder driver is being
attached to the device associated with the lcd-panel driver's of_node
(panel-simple in my case) rather than the lvds-encoder's of_node.


Anyone have any thoughts on best handling this?  Slip another bridge in
attached to this of_node that chains to panel-bridge's bridge, or just
have a panel-bridge entrypoint for what node to register the bridge on?


I think slipping in another bridge seems to make more sense. When we converted
to panel-bridge, we didn't create a bridge entity for the lvds-encoder itself,
we just created the panel-bridge's bridge, which anyway is more a glue-layer
for drm_panel than a real bridge entity.

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

[Laurent Pinchart]

Hi Liviu,

On Monday, 13 November 2017 13:53:14 EET Liviu Dudau wrote:
> On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote:
> > When the DU sources its frames from a VSP, it performs no memory access
> > and thus has no requirements on imported dma-buf memory types. In
> > particular the DU could import a physically non-contiguous buffer that
> > would later be mapped contiguously through the VSP IOMMU.
> > 
> > This use case isn't supported at the moment as the GEM CMA helpers will
> > reject any non-contiguous buffer, and the DU isn't connected to an IOMMU
> > that can make the buffer contiguous for DMA. Fix this by implementing a
> > custom .gem_prime_import_sg_table() operation that accepts all imported
> > dma-buf regardless of the number of scatterlist entries.
> 
> This patch raises the question of why use CMA at all if you can accept
> any kind of buffers.

Both the DU and VSP require DMA contiguous memory. On R-Car Gen2 the DU 
performs DMA, and thus uses the GEM CMA helpers. On Gen3 it delegates DMA to 
the external VSP composer, and still uses the GEM CMA helpers to ensure that 
memory will be DMA contiguous for the VSP. The problem arises when physically 
non-contiguous dma-buf buffers are imported, they can be mapped contiguously 
to the VSP (assuming an IOMMU is present) but not to the DU (as there's no 
IOMMU).

The situation is particularly messy due to the fact that I have one VSP 
instance per CRTC, each connected to its own IOMMU channel. The driver thus 
doesn't know when allocating GEM objects to which struct device they need to 
be mapped. The DRM helpers don't support delayed mapping of memory. I'd like 
to know whether that's something I should fix properly (which would likely 
involve major reworking of the helpers) or hack around it in the DU driver.

> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 ++
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
> >  3 files changed, 47 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 48c166f925a3..d999231f98c7
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = {
> > .gem_prime_import   = drm_gem_prime_import,
> > .gem_prime_export   = drm_gem_prime_export,
> > .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> > -   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> > +   .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table,
> > .gem_prime_vmap = drm_gem_cma_prime_vmap,
> > .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> > .gem_prime_mmap = drm_gem_cma_prime_mmap,
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 566d1a948c8f..2dd0c2ba047d
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c

[snip]

> > +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct
> > drm_device *dev,
> > +   struct dma_buf_attachment *attach,
> > +   struct sg_table *sgt)
> > +{
> > +   struct rcar_du_device *rcdu = dev->dev_private;
> > +   struct drm_gem_cma_object *cma_obj;
> > +   struct drm_gem_object *gem_obj;
> > +   int ret;
> > +
> > +   if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
> > +   return drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> > +
> > +   /* Create a CMA GEM buffer. */
> > +   cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> > +   if (!cma_obj)
> > +   return ERR_PTR(-ENOMEM);
> > +   gem_obj = _obj->base;
> > +
> > +   ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size);
> > +   if (ret)
> > +   goto error;
> > +
> > +   ret = drm_gem_create_mmap_offset(gem_obj);
> > +   if (ret) {
> > +   drm_gem_object_release(gem_obj);
> > +   goto error;
> > +   }
> > +
> > +   cma_obj->paddr = 0;
> 
> This is going to break drm_gem_cma_describe() if you are using it

As far as I can tell drm_gem_cma_describe() will just print paddr = 0, it 
won't crash.

> plus the rcar_du_plane_setup_scanout() unless I'm missing something besides
> familiarity with the RCAR driver code :)

rcar_du_plane_setup_scanout() is only called when !rcar_du_has(rcdu, 
RCAR_DU_FEATURE_VSP1_SOURCE) (that is on Gen3 hardware, or on Gen2 when I 
artificially disable all DMA from the DU and use external composers to emulate 
Gen3 behaviour for testing purpose), in which case this function calls 
drm_gem_cma_prime_import_sg_table().

> This function looks very similar to what I tried to do for mali-dp to
> allow the import of contiguous DMA buffers that have 

Re: [PATCH 2/2] drm/ttm: optimize ttm_mem_evict_first v4

[Chunming Zhou]

On 2017年11月13日 17:54, Christian König wrote:

Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.

v2: rebase and we still need to remove/add the BO from/to the LRU.
v3: fix remove/add one more time, cleanup the logic a bit
v4: we should still check if the eviction is valuable

Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 54 +++-
  1 file changed, 33 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 691646c0f8d3..7b1525d39ea8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -738,47 +738,57 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,
  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
  
  static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

-   uint32_t mem_type,
-   const struct ttm_place *place,
-   bool interruptible,
-   bool no_wait_gpu)
+  struct reservation_object *resv,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  bool interruptible,
+  bool no_wait_gpu)
  {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
-   struct ttm_buffer_object *bo;
-   int ret = -EBUSY;
+   struct ttm_buffer_object *bo = NULL;
+   bool locked = false;
unsigned i;
+   int ret;
  
  	spin_lock(>lru_lock);

for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
-   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
-   if (ret)
-   continue;
+   if (bo->resv == resv) {
+   if (list_empty(>ddestroy))
+   continue;
Do you have further patches for enabling eviction and swapout for 
allocation?


Regards,
David Zhou

+
+   } else {
+   locked = reservation_object_trylock(bo->resv);
+   if (!locked)
+   continue;
+   }
  
  			if (place && !bdev->driver->eviction_valuable(bo,

  place)) {
-   reservation_object_unlock(bo->resv);
-   ret = -EBUSY;
+   if (locked)
+   reservation_object_unlock(bo->resv);
continue;
}
-
break;
}
  
-		if (!ret)

+   if (>lru != >lru[i])
break;
+   else
+   bo = NULL;
}
  
-	if (ret) {

+   if (!bo) {
spin_unlock(>lru_lock);
-   return ret;
+   return -EBUSY;
}
  
  	kref_get(>list_kref);
  
  	if (!list_empty(>ddestroy)) {

-   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu,
+ locked);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
}
@@ -786,10 +796,11 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
ttm_bo_del_from_lru(bo);
spin_unlock(>lru_lock);
  
-	BUG_ON(ret != 0);

-
ret = ttm_bo_evict(bo, interruptible, no_wait_gpu);
-   ttm_bo_unreserve(bo);
+   if (locked)
+   ttm_bo_unreserve(bo);
+   else
+   ttm_bo_add_to_lru(bo);
  
  	kref_put(>list_kref, ttm_bo_release_list);

return ret;
@@ -853,7 +864,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place,
+   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place,
  interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1356,7 +1367,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(>lru[i])) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, 
false);
+   ret = ttm_mem_evict_first(bdev, NULL, mem_type, NULL,
+ false, false);
 

[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 1/16] drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:9: error: implicit declaration of function 'ttm_populate_and_map_pages'; did you mean 'vmem

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git 
upstream-4.14-drm-next-amd-dc-staging-chrome
head:   4448b9a68413462529d018050cd246bc33957bd6
commit: a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 [1/16] FORKLIFT: amd: copy amd 
folder as is from dave airlie tree
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-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 a9aa2210cd8aadeea91c845a0a05510d2a91ffa6
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: the radeon-alex/upstream-4.14-drm-next-amd-dc-staging-chrome HEAD 
4448b9a68413462529d018050cd246bc33957bd6 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_populate':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:9: error: implicit declaration 
>> of function 'ttm_populate_and_map_pages'; did you mean 
>> 'vmemmap_populate_basepages'? [-Werror=implicit-function-declaration]
 return ttm_populate_and_map_pages(adev->dev, >ttm);
^~
vmemmap_populate_basepages
   drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_unpopulate':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:995:2: error: implicit declaration 
>> of function 'ttm_unmap_and_unpopulate_pages'; did you mean 
>> 'ttm_dma_unpopulate'? [-Werror=implicit-function-declaration]
 ttm_unmap_and_unpopulate_pages(adev->dev, >ttm);
 ^~
 ttm_dma_unpopulate
   cc1: some warnings being treated as errors
--
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 
'amdgpu_gem_object_open':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: error: 
>> 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function); 
>> did you mean 'AMDGPU_GEM_CREATE_VRAM_CLEARED'?
 if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID &&
  ^
  AMDGPU_GEM_CREATE_VRAM_CLEARED
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 
'amdgpu_gem_create_ioctl':
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:215:9: error: 
'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function); 
did you mean 'AMDGPU_GEM_CREATE_VRAM_CLEARED'?
AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
^
AMDGPU_GEM_CREATE_VRAM_CLEARED
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_op_ioctl':
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:718:21: error: 
'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function); 
did you mean 'AMDGPU_GEM_CREATE_VRAM_CLEARED'?
  if (robj->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
^
AMDGPU_GEM_CREATE_VRAM_CLEARED
--
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c: In function 
'amdgpu_cs_fence_to_handle_ioctl':
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1348:47: error: dereferencing 
pointer to incomplete type 'union drm_amdgpu_fence_to_handle'
 fence = amdgpu_cs_get_fence(adev, filp, >in.fence);
  ^~
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: error: 
'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ' undeclared (first use in this function); 
did you mean 'AMDGPU_FENCE_FLAG_INT'?
 case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
  ^~
  AMDGPU_FENCE_FLAG_INT
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1354:7: error: implicit declaration 
>> of function 'drm_syncobj_create'; did you mean 'drm_syncobj_free'? 
>> [-Werror=implicit-function-declaration]
  r = drm_syncobj_create(, 0, fence);
  ^~
  drm_syncobj_free
>> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1358:7: error: implicit declaration 
>> of function 'drm_syncobj_get_handle'; did you mean 'drm_syncobj_get'? 
>> [-Werror=implicit-function-declaration]
  r = drm_syncobj_get_handle(filp, syncobj, >out.handle);
  ^~
  drm_syncobj_get
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1362:7: error: 
'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD' undeclared (first use in this 
function); did you mean 'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ'?
 case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD:
  ^
  AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ
>> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1367:7: error: implicit declaration 
>> of 

[Bug 103726] GPU crashes freezing the system and weird rendering issues on CAYMAN

[bugzilla-daemon]

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

Bug ID: 103726
   Summary: GPU crashes freezing the system and weird rendering
issues on CAYMAN
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: v10la...@myway.de
QA Contact: dri-devel@lists.freedesktop.org

I'm not really sure how to describe this bug. It is so random, sometimes I'm
not sure if exists as nothing happens in weeks, then it happenes all 10
minutes. I'm hunting this bug for so long, can't tell if a year or two or even
more.

Some (if not all?) games are triggering weird behavior on a Radeon HD 6950.
What happens is the screen changing to green with some check pattern (sorry for
having no picture but screenshoting is impossible and I never had a camera at
hand). Before the driver was able to do a GPU reset (now you get how old this
bug is) it was staying there but with modern kernels the drivers seems to try a
reset (monitor flickering for a moment) after some time and then all I get is a
black screen (not no-signal, a black image) at that time the only way to
recover the PC is by pressing the reset button.

Now since a few days I'm playing Dead Island and it seems to be a good trigger
for the bug ("good" means the game seems to trigger it in between a few seconds
and 6 hours of gameplay. Make sure to have a lot of freetime if you try to
recreate) so I decided to try to hunt it again. For that I started the game
with R600_DEBUG=nosb,nohyperz and played for around 3 hours before I got bored.
Then I switched back to the desktop and noticed that everything got broken:
Flickering and/or invisible windows, hanging menue, the complete desktop
hanging and so on (I tried to take a video but it's corrupted: [ffmpeg/demuxer]
mov,mp4,m4a,3gp,3g2,mj2: moov atom not found) ).

When the desktio corruted there's nothing in the logs except
kernel: radeon_dp_aux_transfer_native: 32 callbacks suppressed
but that should be harmless, shouldn't it?

When the green screen comes there#s also nothing in the logs, but that's most
likely because the system froze before it could flush it to disc as the logs
are incomlete im that case.

This bug might or might not be the same as
https://bugs.freedesktop.org/show_bug.cgi?id=92555 - I really can't tell but if
it's the same: Could it be a regresion introduced by splitting r600 and
radeonsi?

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

Re: [PATCH 1/2] drm/vc4: Account for interrupts in flight

[Eric Anholt]

Stefan Schake  writes:

> Synchronously disable the IRQ to make the following cancel_work_sync
> invocation effective.
>
> An interrupt in flight could enqueue further overflow mem work. As we
> free the binner BO immediately following vc4_irq_uninstall this caused
> a NULL pointer dereference in the work callback vc4_overflow_mem_work.
>
> Link: https://github.com/anholt/linux/issues/114
> Signed-off-by: Stefan Schake 
> Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")

Reviewed and applied this one.  Thanks!


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

[Bug 101978] [bisected] war thunder performance reduced by ~28%

[bugzilla-daemon]

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

--- Comment #7 from higu...@gmx.net ---
>Also, there are amdgpu kernel driver changes lined up for 4.14 that might help.

Updates to 4.14 and i fail to see any improvement, sclk is still low,
performance is still very low for what this card is capable. Or is there any
new setting that i have to enable/change to get a possible improvement

-- 
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:upstream-4.14-drm-next-amd-dc-staging-chrome 1/16] drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:2: error: implicit declaration of function 'ttm_populate_and_map_pages'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git 
upstream-4.14-drm-next-amd-dc-staging-chrome
head:   4448b9a68413462529d018050cd246bc33957bd6
commit: a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 [1/16] FORKLIFT: amd: copy amd 
folder as is from dave airlie tree
config: x86_64-randconfig-g0-11140757 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout a9aa2210cd8aadeea91c845a0a05510d2a91ffa6
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the radeon-alex/upstream-4.14-drm-next-amd-dc-staging-chrome HEAD 
4448b9a68413462529d018050cd246bc33957bd6 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_populate':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:2: error: implicit declaration 
>> of function 'ttm_populate_and_map_pages' 
>> [-Werror=implicit-function-declaration]
 return ttm_populate_and_map_pages(adev->dev, >ttm);
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 
'amdgpu_ttm_tt_unpopulate':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:995:2: error: implicit declaration 
>> of function 'ttm_unmap_and_unpopulate_pages' 
>> [-Werror=implicit-function-declaration]
 ttm_unmap_and_unpopulate_pages(adev->dev, >ttm);
 ^
   cc1: some warnings being treated as errors
--
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 
'amdgpu_gem_object_open':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: error: 
>> 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function)
 if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID &&
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 
'amdgpu_gem_create_ioctl':
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:215:9: error: 
'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function)
AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
^
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_op_ioctl':
   drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:718:21: error: 
'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function)
  if (robj->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
^
--
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c: In function 
'amdgpu_cs_fence_to_handle_ioctl':
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1348:47: error: dereferencing 
pointer to incomplete type
 fence = amdgpu_cs_get_fence(adev, filp, >in.fence);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1352:14: error: dereferencing 
pointer to incomplete type
 switch (info->in.what) {
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: error: 
'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ' undeclared (first use in this function)
 case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1354:3: error: implicit declaration 
>> of function 'drm_syncobj_create' [-Werror=implicit-function-declaration]
  r = drm_syncobj_create(, 0, fence);
  ^
>> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1358:3: error: implicit declaration 
>> of function 'drm_syncobj_get_handle' [-Werror=implicit-function-declaration]
  r = drm_syncobj_get_handle(filp, syncobj, >out.handle);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1358:50: error: dereferencing 
pointer to incomplete type
  r = drm_syncobj_get_handle(filp, syncobj, >out.handle);
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1362:7: error: 
'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD' undeclared (first use in this function)
 case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD:
  ^
>> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1367:3: error: implicit declaration 
>> of function 'drm_syncobj_get_fd' [-Werror=implicit-function-declaration]
  r = drm_syncobj_get_fd(syncobj, (int*)>out.handle);
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1367:46: error: dereferencing 
pointer to incomplete type
  r = drm_syncobj_get_fd(syncobj, (int*)>out.handle);
 ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1371:7: error: 
'AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD' undeclared (first use in this 
function)
 case AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD:
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1386:7: error: dereferencing pointer 
to incomplete type
  info->out.handle = fd;
  ^
   drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1392:1: warning: control reaches end 
of non-void function [-Wreturn-type]
}
^
   cc1: 

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

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

Matthew Treinish  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #20 from Matthew Treinish  ---
Ok, I built a kernel from Alex's amd-staging-drm-next tree
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next the head
of the tree was:

eee12cc2150b932ee52ccf89de611a7ba030eb90  drm/amdgpu/virt: remove redundant
variable pf2vf_ver

and I confirmed that dc is loaded by checking for: [   10.330032] [drm] Display
Core initialized!
in dmesg. But the problem still persists. Although instead of 4 segments in
each corner like before, there are only 2 now.

I've attached the dmesg output (grepped for drm) and I can provide any
additional debug information needed. Just let me know and I'll gladly do what I
can to help.

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

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

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

Matthew Treinish  changed:

   What|Removed |Added

 Attachment #129571|0   |1
is obsolete||
 Attachment #129575|0   |1
is obsolete||

--- Comment #19 from Matthew Treinish  ---
Created attachment 135442
  --> https://bugs.freedesktop.org/attachment.cgi?id=135442=edit
dmesg output (grepped for 'drm') from kernel running eee12cc2150b

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

Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled

[Eric Anholt]

Stefan Schake  writes:

> The overflow mem work callback vc4_overflow_mem_work reenables its
> associated interrupt upon completion. To ensure all interrupts are disabled
> when we return from vc4_irq_uninstall, we need to disable it again if
> cancel_work_sync indicated pending work.

Is there a reason we need the interrupts disabled at the V3D level while
we have the IRQ disabled at the irqchip level?  Once we re-enable at the
irqchip, we immediately V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS) anyway.


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/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Inki Dae]

2017년 11월 13일 23:28에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
> 
> On 2017-11-13 02:24, Inki Dae wrote:
>> Hi Marek,
>>
>> 2017년 11월 10일 16:35에 Marek Szyprowski 이(가) 쓴 글:
>>> Dear Inki,
>>>
>>> On 2017-11-10 04:04, Inki Dae wrote:
 2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep
 What if user disabled CMA support? In this case, it guarantees also to 
 allocate physically contiguous memory?
 I think it depends on CMA support so wouldn't be true.
>>> dma_alloc_attrs() always guarantees the contiguity of the allocated memory
>>> in DMA address space. When NOIOMMU is available, this mean that the 
>>> allocated
>>> buffer is contiguous in the physical memory. When CMA is disabled,
>>> dma_alloc_attrs() uses alloc_pages() allocator. The drawback of 
>>> alloc_pages()
>>> is that it easily fails if physical memory is fragmented and it cannot
>>> allocate memory larger than MAX_ORDER (4MiB in case of ARM32bit).
>> You are right. Without IOMMU suppot alloc_pages always tryies to allocate 
>> contiguous memory,
>> order = get_order(size);
>> page = alloc_pages(..., order);
>> if (!page)
>> return NULL;
>> ...
> 
> Right
> 
 Real problem I think is that user don't know whether the gem buffer 
 allocated with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer.
 So user can request a page flip with NONCONTIG buffer to kernel which 
 doesn't support IOMMU.

 And another is that user may want to use NONCONTIG buffer for another 
 purpose, not scanout.
 So if we enforce on using CONTIG buffer on kernel without IOMMU support, 
 then it wouldn't be really what user intended.
>>> When IOMMU support is disabled, ANY buffer allocated with dma_alloc_attrs()
>>> will be contiguous, so I see no point propagating incorrect flag for it.
>>>
>>> The only way to create a NONCONTIG buffer with IOMMU disabled is to import
>>> it from other driver and this path is already handled correctly.
>>>
 My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can 
 allocate a buffer with a different allocation type - CONTIG or NONCONTIG - 
 according to IOMMU support.
 And any page flip request with NONCONTIG buffer to kernel without IOMMU 
 support should fail and it has to return a error with a proper error 
 message.
>>> I don't think that we need it. With the proposed patch the same userspace 
>>> will
>>> work fine in both cases IOMMU enabled and disabled, even if it allocate GEM
>>> with NONCONTIG flag. We can assume that CONTIG is a special case of 
>>> NONCONTIG
>>> then.
>> The problem is really not whether user space will work fine or not but is 
>> that this may be not what user space wanted.
>> I.e., user space expects the allocated buffer is NONCONTIG buffer because 
>> user space requested NONCONTIG buffer but kernel internally, this is changed 
>> to CONTIG buffer.
> 
> What's the problem when kernel allocated contiguous buffer but user
> requested non-contiguous? Contiguous is a subclass of non-contiguous
> in general. There is no driver nor scenario which will not work because
> of such change (any code for handing n-segments should be fine with only
> 1 segment). In some conditions, by luck, kernel might allocate
> a contiguous buffer even with IOMMU enabled. When we know that the
> buffer is contiguous, then flag it as such.

I'd like to say what I experienced before here. I'd ever modified in-house 
kernel with similar issue that with IOMMU sometimes page fault happended. So 
tempararily I always made gem allocation request from user space to allocate 
CONTIG buffer and it worked well without page fault. Several days ago, a 
Platform guy reported one issue that gem allocation request failed even through 
it has free memory enough. The issus was as you guess fragementation issue and 
I talked to him memory fragmentation happended.

However, that guy didn't understand why memory fragementation happended because 
he definitely requested NONCONTIG buffer allocation. Thus, if I provided a some 
hit - gem allocation way is changed to CONTIG due to some reason - to user 
space then he could understand the fragmentation issue without contacting me. 
This patch could fix the X Server issue but the X Server never know that the 
allocated buffer is contiguous because you changed the allocation type witout 
user's knowledge. 

Thanks,
Inki Dae

> 
>> So you could provide some information - maybe warning message?? - to user 
>> space the buffer type is changed to CONTIG buffer due to NO IOMMU support.
> 
> I don't think this needs a warning. I just think that when we know that
> the allocated buffer IS contiguous there is no point flagging it as
> non-contiguous and fail a few calls later although the driver allocated

[Bug 103700] Displayport link status failed on resume from suspend on eDP on RX580 with Asus GL702ZC

[bugzilla-daemon]

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

--- Comment #2 from dwagner  ---
This bug could be the same as
https://bugs.freedesktop.org/show_bug.cgi?id=103277 - but since I have only one
display connected to the GPU - which stays off after resume (and then the
system crashes so no other way to look at dmesg output) - I had no chance to
see error messages like the ones you reported.

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

[PATCH] drm/debugfs: Fix framebuffer debugfs file init

[Noralf Trønnes]

The introduction of: drm/framebuffer: Add framebuffer debugfs file
broke vgem. That patch assumed that all drivers had initialized the
dev->mode_config.fb_lock mutex which happens in drm_mode_config_init().
vgem doesn't need to call drm_mode_config_init().

Fix this by only creating the framebuffer debugfs file for modesetting
drivers.

Fixes: 45d58b40292b ("drm/framebuffer: Add framebuffer debugfs file")
Suggested-by: Chris Wilson 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_debugfs.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 550f29de6c1f..b2482818fee8 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -158,10 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int 
minor_id,
}
}
 
-   ret = drm_framebuffer_debugfs_init(minor);
-   if (ret) {
-   DRM_ERROR("Failed to create framebuffer debugfs file\n");
-   return ret;
+   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+   ret = drm_framebuffer_debugfs_init(minor);
+   if (ret) {
+   DRM_ERROR("Failed to create framebuffer debugfs 
file\n");
+   return ret;
+   }
}
 
if (dev->driver->debugfs_init) {
-- 
2.14.2

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

Re: [PATCH] drm/tilcdc: Remove obsolete "ti, tilcdc, slave" dts binding support

[Rob Herring]

On Mon, Nov 13, 2017 at 6:42 AM, Jyri Sarha  wrote:
> This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the
> obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based
> binding - that is widely used in other drm driver too - has been
> supported since Linux v4.2. Maintaining the the backwards dts
> conversion code in 0the DRM_TILCDC_SLAVE_COMPAT has become a nuisance
> for the device/of development so the we decided to drop it after Linux
> v4.14, the 2017 LTS.
>
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/Kconfig |  11 -
>  drivers/gpu/drm/tilcdc/Makefile|   3 -
>  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 269 
> -
>  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 ---
>  drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h   |  25 ---
>  5 files changed, 380 deletions(-)
>  delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
>  delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h

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

[Bug 103630] [regression] Hacker Evolution(1,2,3) crash on startup

[bugzilla-daemon]

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

--- Comment #3 from cosiek...@o2.pl ---
Computer Information:
Manufacturer:  Unknown
Model:  Unknown
Form Factor: Desktop
No Touch Input Detected

Processor Information:
CPU Vendor:  GenuineIntel
CPU Brand:  Intel(R) Core(TM)2 CPU T5500  @ 1.66GHz
CPU Family:  0x6
CPU Model:  0xf
CPU Stepping:  0x6
CPU Type:  0x0
Speed:  1667 Mhz
2 logical processors
2 physical processors
HyperThreading:  Unsupported
FCMOV:  Supported
SSE2:  Supported
SSE3:  Supported
SSSE3:  Supported
SSE4a:  Unsupported
SSE41:  Unsupported
SSE42:  Unsupported
AES:  Unsupported
AVX:  Unsupported
CMPXCHG16B:  Supported
LAHF/SAHF:  Supported
PrefetchW:  Unsupported

Operating System Version:
"Manjaro Linux" (64 bit)
Kernel Name:  Linux
Kernel Version:  4.9.61-3-MANJARO
X Server Vendor:  The X.Org Foundation
X Server Release:  11905000
X Window Manager:  Xfwm4
Steam Runtime Version:  

Video Card:
Driver:  X.Org R300 Project ATI RC410
Driver Version:  2.1 Mesa 17.2.4
OpenGL Version: 2.1
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 59 Hz
VendorID:  0x1002
DeviceID:  0x5a62
Revision Not Detected
Number of Monitors:  1
Number of Logical Video Cards:  1
Primary Display Resolution:  1280 x 800
Desktop Resolution: 1280 x 800
Primary Display Size: 13,03" x 8,15" (15,35" diag)
33,1cm x 20,7cm (39,0cm diag)
Primary VRAM Not Detected

Sound card:
Audio device: Realtek ALC861-VD

Memory:
RAM:  1877 Mb

Miscellaneous:
UI Language:  English
LANG:  pl_PL.utf8
Total Hard Disk Space Available:  54060 Mb
Largest Free Hard Disk Block:  41979 Mb
VR Headset: None detected

Recent Failure Reports:

-- 
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 v5 04/12] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

Den 13.11.2017 23.17, skrev Chris Wilson:

Quoting Noralf Trønnes (2017-11-13 22:12:06)

Den 13.11.2017 22.33, skrev Chris Wilson:

Quoting Noralf Trønnes (2017-11-13 19:54:43)

Den 11.11.2017 19.55, skrev Chris Wilson:

Quoting Noralf Trønnes (2017-11-07 19:13:40)

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

This isn't too hot for non-modesetting drm drivers.

Just to be clear; this is currently on fire in i915's CI. As
framebuffer-info is installed for vgem and vgem hasn't initialised any
of the data structs being inspected...

Ok, so I have broken vgem :-(

drm_framebuffer_info() takes dev->mode_config.fb_lock which hasn't been
initialized because vgem doesn't call drm_mode_config_init().
drm_mode_config_init() in addition to initializing various thing also
calls drm_mode_create_standard_properties().

Can we call drm_mode_config_init() in vgem or is this a no-go because of
the properties? Do you see a solution to this?

My quick fix idea was a drm_core_check_feature(dev, DRIVER_MODESET)
around the drm_framebuffer_debugfs_init().


Ah, yes, thank you!
That sounds like a good idea. I will create a patch.

Noralf.

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

[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 4/16] drivers/gpu//drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of 'ttm_populate_and_map_pages'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git 
upstream-4.14-drm-next-amd-dc-staging-chrome
head:   4448b9a68413462529d018050cd246bc33957bd6
commit: ed285b98008b667978d7faf348a22000b8a1c6b9 [4/16] drm/ttm: Add helper 
functions to populate/map in one call (v2)
config: i386-randconfig-s0-201746 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout ed285b98008b667978d7faf348a22000b8a1c6b9
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of 
>> 'ttm_populate_and_map_pages'
int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
^~
   In file included from drivers/gpu//drm/ttm/ttm_page_alloc.c:49:0:
   include/drm/ttm/ttm_page_alloc.h:120:19: note: previous definition of 
'ttm_populate_and_map_pages' was here
static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
  ^~
>> drivers/gpu//drm/ttm/ttm_page_alloc.c:950:6: error: redefinition of 
>> 'ttm_unmap_and_unpopulate_pages'
void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt 
*tt)
 ^~
   In file included from drivers/gpu//drm/ttm/ttm_page_alloc.c:49:0:
   include/drm/ttm/ttm_page_alloc.h:125:20: note: previous definition of 
'ttm_unmap_and_unpopulate_pages' was here
static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, 
struct ttm_dma_tt *tt)
   ^~

vim +/ttm_populate_and_map_pages +923 drivers/gpu//drm/ttm/ttm_page_alloc.c

   922  
 > 923  int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt 
 > *tt)
   924  {
   925  unsigned i;
   926  int r;
   927  
   928  r = ttm_pool_populate(>ttm);
   929  if (r)
   930  return r;
   931  
   932  for (i = 0; i < tt->ttm.num_pages; i++) {
   933  tt->dma_address[i] = dma_map_page(dev, tt->ttm.pages[i],
   9340, PAGE_SIZE,
   935DMA_BIDIRECTIONAL);
   936  if (dma_mapping_error(dev, tt->dma_address[i])) {
   937  while (i--) {
   938  dma_unmap_page(dev, tt->dma_address[i],
   939 PAGE_SIZE, 
DMA_BIDIRECTIONAL);
   940  tt->dma_address[i] = 0;
   941  }
   942  ttm_pool_unpopulate(>ttm);
   943  return -EFAULT;
   944  }
   945  }
   946  return 0;
   947  }
   948  EXPORT_SYMBOL(ttm_populate_and_map_pages);
   949  
 > 950  void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
 > ttm_dma_tt *tt)
   951  {
   952  unsigned i;
   953  
   954  for (i = 0; i < tt->ttm.num_pages; i++) {
   955  if (tt->dma_address[i]) {
   956  dma_unmap_page(dev, tt->dma_address[i],
   957 PAGE_SIZE, DMA_BIDIRECTIONAL);
   958  }
   959  }
   960  ttm_pool_unpopulate(>ttm);
   961  }
   962  EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
   963  

---
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 v5 04/12] drm/framebuffer: Add framebuffer debugfs file

[Chris Wilson]

Quoting Noralf Trønnes (2017-11-13 22:12:06)
> 
> Den 13.11.2017 22.33, skrev Chris Wilson:
> > Quoting Noralf Trønnes (2017-11-13 19:54:43)
> >> Den 11.11.2017 19.55, skrev Chris Wilson:
> >>> Quoting Noralf Trønnes (2017-11-07 19:13:40)
>  Add debugfs file that dumps info about the framebuffers and its planes.
>  Also dump info about any connected gem object(s).
> >>> This isn't too hot for non-modesetting drm drivers.
> > Just to be clear; this is currently on fire in i915's CI. As
> > framebuffer-info is installed for vgem and vgem hasn't initialised any
> > of the data structs being inspected...
> 
> Ok, so I have broken vgem :-(
> 
> drm_framebuffer_info() takes dev->mode_config.fb_lock which hasn't been
> initialized because vgem doesn't call drm_mode_config_init().
> drm_mode_config_init() in addition to initializing various thing also
> calls drm_mode_create_standard_properties().
> 
> Can we call drm_mode_config_init() in vgem or is this a no-go because of
> the properties? Do you see a solution to this?

My quick fix idea was a drm_core_check_feature(dev, DRIVER_MODESET)
around the drm_framebuffer_debugfs_init().
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

Den 13.11.2017 22.33, skrev Chris Wilson:

Quoting Noralf Trønnes (2017-11-13 19:54:43)

Den 11.11.2017 19.55, skrev Chris Wilson:

Quoting Noralf Trønnes (2017-11-07 19:13:40)

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

This isn't too hot for non-modesetting drm drivers.

Just to be clear; this is currently on fire in i915's CI. As
framebuffer-info is installed for vgem and vgem hasn't initialised any
of the data structs being inspected...


Ok, so I have broken vgem :-(

drm_framebuffer_info() takes dev->mode_config.fb_lock which hasn't been
initialized because vgem doesn't call drm_mode_config_init().
drm_mode_config_init() in addition to initializing various thing also
calls drm_mode_create_standard_properties().

Can we call drm_mode_config_init() in vgem or is this a no-go because of
the properties? Do you see a solution to this?

Sorry about the fallout.

Noralf.

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

[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 3/16] drivers/staging//vboxvideo/vbox_mode.c:380:10: error: too few arguments to function 'drm_encoder_find'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git 
upstream-4.14-drm-next-amd-dc-staging-chrome
head:   4448b9a68413462529d018050cd246bc33957bd6
commit: 74667d0b87be12956d9266ae54757db7adf6d1e6 [3/16] drm: Pass struct 
drm_file * to __drm_mode_object_find [v2]
config: i386-randconfig-s0-201746 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 74667d0b87be12956d9266ae54757db7adf6d1e6
# save the attached .config to linux build tree
make ARCH=i386 

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

   drivers/staging//vboxvideo/vbox_mode.c: In function 
'vbox_best_single_encoder':
>> drivers/staging//vboxvideo/vbox_mode.c:380:43: warning: passing argument 2 
>> of 'drm_encoder_find' makes pointer from integer without a cast 
>> [-Wint-conversion]
  return drm_encoder_find(connector->dev, enc_id);
  ^~
   In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_crtc_helper.h:43,
from drivers/staging//vboxvideo/vbox_mode.c:35:
   include/drm/drm_encoder.h:216:35: note: expected 'struct drm_file *' but 
argument is of type 'int'
static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev,
  ^~~~
>> drivers/staging//vboxvideo/vbox_mode.c:380:10: error: too few arguments to 
>> function 'drm_encoder_find'
  return drm_encoder_find(connector->dev, enc_id);
 ^~~~
   In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_crtc_helper.h:43,
from drivers/staging//vboxvideo/vbox_mode.c:35:
   include/drm/drm_encoder.h:216:35: note: declared here
static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev,
  ^~~~

vim +/drm_encoder_find +380 drivers/staging//vboxvideo/vbox_mode.c

dd55d44f4 Hans de Goede 2017-07-06  372  
dd55d44f4 Hans de Goede 2017-07-06  373  static struct drm_encoder 
*vbox_best_single_encoder(struct drm_connector
dd55d44f4 Hans de Goede 2017-07-06  374 
*connector)
dd55d44f4 Hans de Goede 2017-07-06  375  {
dd55d44f4 Hans de Goede 2017-07-06  376 int enc_id = 
connector->encoder_ids[0];
dd55d44f4 Hans de Goede 2017-07-06  377  
dd55d44f4 Hans de Goede 2017-07-06  378 /* pick the encoder ids */
dd55d44f4 Hans de Goede 2017-07-06  379 if (enc_id)
dd55d44f4 Hans de Goede 2017-07-06 @380 return 
drm_encoder_find(connector->dev, enc_id);
dd55d44f4 Hans de Goede 2017-07-06  381  
dd55d44f4 Hans de Goede 2017-07-06  382 return NULL;
dd55d44f4 Hans de Goede 2017-07-06  383  }
dd55d44f4 Hans de Goede 2017-07-06  384  

:: The code at line 380 was first introduced by commit
:: dd55d44f408419278c00887bfcb2261d0caae350 staging: vboxvideo: Add 
vboxvideo to drivers/staging

:: TO: Hans de Goede 
:: CC: Greg Kroah-Hartman 

---
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 v5 04/12] drm/framebuffer: Add framebuffer debugfs file

[Chris Wilson]

Quoting Noralf Trønnes (2017-11-13 19:54:43)
> 
> Den 11.11.2017 19.55, skrev Chris Wilson:
> > Quoting Noralf Trønnes (2017-11-07 19:13:40)
> >> Add debugfs file that dumps info about the framebuffers and its planes.
> >> Also dump info about any connected gem object(s).
> > This isn't too hot for non-modesetting drm drivers.

Just to be clear; this is currently on fire in i915's CI. As
framebuffer-info is installed for vgem and vgem hasn't initialised any
of the data structs being inspected...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

[bugzilla-daemon]

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

--- Comment #2 from jan@gmx.de ---
I also have this problem. Is there a way to force/override Z_ORDER to LATE_Z,
at best per application, so that I can try whether this has any effect?
If not: what other way is there to test it? I am willing to e.g. patch, compile
and test some code if somebody tells me what to do, no promise when I'll find
the time for that though.

-- 
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/atomic-helper: Calculate normalized zpos values

[Ville Syrjälä]

On Mon, Nov 13, 2017 at 09:56:19PM +0100, Thierry Reding wrote:
> On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> > > will automatically calculate the normalized zpos values, but it won't
> > > currently do so. Modify the atomic helpers to behave as documented.
> > 
> > NAK
> > 
> > See commit  38d868e41c4b ("drm: Don't force all planes to be added to
> > the state due to zpos")
> 
> Thanks, that's interesting background. It's a little unfortunate that
> I'll have to go and add a custom ->atomic_check() just because of this.

IIRC I did propose having two variants in the helper, but Daniel didn't
like that. Of course that might not scale too well if more variants
would become necessary, so I do understand the desire to avoid many
helper variants.

> This is something in general that's been bugging me. How are we supposed
> to keep all of the custom ->atomic_check() implementations in sync with
> the atomic helpers? It looks to me like most drivers will at some point
> copy the atomic helper to their driver and then make driver-specific
> changes to them. But then when one of the helpers gets updated, the same
> changes are usually not propagated to the drivers that originally copied
> from the helpers.
> 
> One way I've seen used (and have used myself) occasionally is for the
> driver-specific implementations to "subclass" the helpers by calling the
> helper first and then calling the driver-specific bits. That helps a lot
> but will obviously not work if ordering is important.
> 
> Any ideas on how we can improve that? Other than periodically checking
> the git log for the helpers and updating drivers? I suppose if one were
> to closely follow the mailing list one might notice early on, and maybe
> speak up and have the changes applied to the drivers in the same patch
> as the helpers. But I don't think that's going to work for every driver.

Yeah, I guess keeping a close eye on or periodically checking for
changes is the best one can do.

Of course people shouldn't be breaking other drivers with their changes
to the helper. So if something gets added there that's really needed in
the open coded implementations as well, the patch author should at least
attempt to make those changes and make sure all relevant driver
maintainers are aware part of the process. That won't magically land
you new features though, unless the people implementing those are
feeling extra generous.

And I guess nothing beats regular and thorough testing if you're
concerned about other people breaking your stuff.

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

Re: drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline

[Eric Anholt]

Lothar Waßmann  writes:

> Hi,
>
> On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
>> Lothar Waßmann  writes:
>> 
>> > Hi,
>> >
>> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
>> > dysfunctional due to:
>> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
>> > |Author: Eric Anholt 
>> > |Date:   Fri Jun 2 13:25:14 2017 -0700
>> > |
>> > |drm/bridge: Refactor out the panel wrapper from the lvds-encoder 
>> > bridge.
>> >
>> > Also, there is no in-kernel user of this driver, so that it obviously
>> > doesn't get tested in any way. There is only one dts file 
>> > (r8a7779-marzen.dts)
>> > that instantiates this driver, but it has an incomplete OF graph. The 
>> > missing
>> > link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
>> > r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
>> > the kernel source.
>> >
>> > Should the driver be removed or moved to staging, until it is properly
>> > fixed?
>> 
>> I can't see any behavior change about the DT handling in that commit,
>> and I didn't intend for there to be any.  Could you help me understand
>> what went wrong?
>>
> With the offending commit applied, the lvds-encoder driver is being
> attached to the device associated with the lcd-panel driver's of_node
> (panel-simple in my case) rather than the lvds-encoder's of_node.

Anyone have any thoughts on best handling this?  Slip another bridge in
attached to this of_node that chains to panel-bridge's bridge, or just
have a panel-bridge entrypoint for what node to register the bridge on?


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

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #12 from Alex Deucher  ---
Can you verify that the Linux pci subsystem is properly calling the ACPI _PR3
method on your platform?  The workaround just uses the legacy AMD ACPI
interface.  It appears pci is not calling _PR3 properly for some reason on your
platform.

-- 
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/atomic-helper: Calculate normalized zpos values

[Thierry Reding]

On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> > will automatically calculate the normalized zpos values, but it won't
> > currently do so. Modify the atomic helpers to behave as documented.
> 
> NAK
> 
> See commit  38d868e41c4b ("drm: Don't force all planes to be added to
> the state due to zpos")

Thanks, that's interesting background. It's a little unfortunate that
I'll have to go and add a custom ->atomic_check() just because of this.

This is something in general that's been bugging me. How are we supposed
to keep all of the custom ->atomic_check() implementations in sync with
the atomic helpers? It looks to me like most drivers will at some point
copy the atomic helper to their driver and then make driver-specific
changes to them. But then when one of the helpers gets updated, the same
changes are usually not propagated to the drivers that originally copied
from the helpers.

One way I've seen used (and have used myself) occasionally is for the
driver-specific implementations to "subclass" the helpers by calling the
helper first and then calling the driver-specific bits. That helps a lot
but will obviously not work if ordering is important.

Any ideas on how we can improve that? Other than periodically checking
the git log for the helpers and updating drivers? I suppose if one were
to closely follow the mailing list one might notice early on, and maybe
speak up and have the changes applied to the drivers in the same patch
as the helpers. But I don't think that's going to work for every driver.

Thierry


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

[Bug 197851] Resume from suspend sometimes results in black screen on Radeon R5

[bugzilla-daemon]

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

--- Comment #2 from Tyler McLean (sonarsoundapplicati...@gmail.com) ---
Created attachment 260643
  --> https://bugzilla.kernel.org/attachment.cgi?id=260643=edit
Output from dmesg on a clean restart

Attached the dmesg output. Can't get Xorg though as I'm running a Wayland
environment

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

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #11 from higu...@gmx.net ---
just tested kernel 4.14.0 (without the above patch) and it still fails

i will apply the patch again, as a workaround

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

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

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   eee12cc2150b932ee52ccf89de611a7ba030eb90
commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [2749/2876] ASoC: AMD: enable 
ACP3x drivers build
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.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 0bd599b1f523598c05f13a4a562884e82a378c2c
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All errors (new ones prefixed by >>):

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

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

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

Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

Den 11.11.2017 19.55, skrev Chris Wilson:

Quoting Noralf Trønnes (2017-11-07 19:13:40)

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

This isn't too hot for non-modesetting drm drivers.

And isn't this growing a midlayer? Calling to the drivers instead of the
drivers controlling and calling helpers for the common stuff.


I really can't say, but Daniel asked me to do it like this:
https://lists.freedesktop.org/archives/dri-devel/2017-October/155245.html

Noralf.

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

Re: linux-next: manual merge of the devicetree tree with the drm tree

[Jyri Sarha]

On 11/13/17 20:43, Frank Rowand wrote:
> Hi Jyri,
> 
> On 11/13/17 07:40, Jyri Sarha wrote:
>> On 11/13/17 07:58, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown  wrote:
 Today's linux-next merge of the devicetree tree got a conflict in:

   drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c

 between commit:

   44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting")

 from the drm tree and commit:

   f948d6d8b792bb ("of: overlay: avoid race condition between applying 
 multiple overlays")

 from the devicetree tree.

 I fixed it up (see below) and can carry the fix as necessary. This
 is now fixed as far as linux-next is concerned, but any non trivial
 conflicts should be mentioned to your upstream maintainer when your tree
 is submitted for merging.  You may also want to consider cooperating
 with the maintainer of the conflicting tree to minimise any particularly
 complex conflicts.

 diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 index 482299a6f3b0,54025af534d4..
 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc
return NULL;
}
   
 -  ret = of_resolve_phandles(overlay);
 -  if (ret) {
 -  pr_err("%s: Failed to resolve phandles: %d\n", __func__, ret);
 -  return NULL;
 -  }
  - of_node_set_flag(overlay, OF_DETACHED);
 --
return overlay;
   }
   
>>> Just a reminder that this conflict still exists.
>>>
>> After some consideration, I think we can drop the dts backward
>> compatibility code from drm/tilcdc. It seems that it is causing a lot of
>> trouble and I do not even know if anybody uses it anymore. Here is a
>> patch for dropping it:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html
>>
>> I did not plan to merge it before v4.16, but if this is a bigger problem
>> I can push is right now for v4.15.
>>
>> Best regards,
>> Jyri
>>
> The dropping patch is much appreciated.
> 
> It would make life easier for me if the patch gets into v4.15-rc.

Dave, Daniel? Would you take this late addition to v4.15 still, if I
would send a pull request now?

The patch is pretty much orthogonal to the rest of drm as it is only
dealing with device tree stuff.

Best regards,
Jyri

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

[drm-intel:drm-intel-next-queued 6/6] drivers/gpu/drm/i915/intel_device_info.c:345: undefined reference to `__udivdi3'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   dab91783338bd3dd42638f89b5f7e34c57773207
commit: dab91783338bd3dd42638f89b5f7e34c57773207 [6/6] drm/i915: expose command 
stream timestamp frequency to userspace
config: i386-randconfig-s0-201746 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout dab91783338bd3dd42638f89b5f7e34c57773207
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_device_info.o: In function 
`read_reference_ts_freq':
>> drivers/gpu/drm/i915/intel_device_info.c:345: undefined reference to 
>> `__udivdi3'

vim +345 drivers/gpu/drm/i915/intel_device_info.c

   331  
   332  static u64 read_reference_ts_freq(struct drm_i915_private *dev_priv)
   333  {
   334  u32 ts_override = I915_READ(GEN9_TIMESTAMP_OVERRIDE);
   335  u64 base_freq, frac_freq;
   336  
   337  base_freq = ((ts_override & 
GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_MASK) >>
   338   GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_SHIFT) 
+ 1;
   339  base_freq *= 100;
   340  
   341  frac_freq = ((ts_override &
   342
GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK) >>
   343   
GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT);
   344  if (frac_freq != 0)
 > 345  frac_freq = 100 / (frac_freq + 1);
   346  
   347  return base_freq + frac_freq;
   348  }
   349  

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


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

[PULL] drm-misc-fixes

[Sean Paul]

Hi Dave,
Here's the previous PR plus the rockchip fix that snuck in.


drm-misc-fixes-2017-11-13:
Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
- rockchip: Convert psr spinlock to mutex (Emil)

Cc: Emil Renner Berthing 
Cc: Gerd Hoffmann 

Cheers, Sean


The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9:

  Linux 4.14-rc5 (2017-10-15 21:01:12 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-11-13

for you to fetch changes up to 44419ce7d77e03692ed8fe799688d8dc43f9266e:

  drm/rockchip: analogix_dp: Use mutex rather than spinlock (2017-11-13 
10:29:23 +0800)


Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
- rockchip: Convert psr spinlock to mutex (Emil)

Cc: Emil Renner Berthing 
Cc: Gerd Hoffmann 


Emil Renner Berthing (1):
  drm/rockchip: analogix_dp: Use mutex rather than spinlock

Gerd Hoffmann (2):
  drm/qxl: replace QXL_INFO with DRM_DEBUG_DRIVER
  qxl: alloc & use shadow for dumb buffers

 drivers/gpu/drm/qxl/qxl_cmd.c   | 22 ++-
 drivers/gpu/drm/qxl/qxl_display.c   | 49 +++--
 drivers/gpu/drm/qxl/qxl_drv.h   | 28 ++
 drivers/gpu/drm/qxl/qxl_dumb.c  |  1 +
 drivers/gpu/drm/qxl/qxl_fb.c| 13 +++
 drivers/gpu/drm/qxl/qxl_release.c   |  5 +--
 drivers/gpu/drm/qxl/qxl_ttm.c   |  4 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 +++
 8 files changed, 77 insertions(+), 59 deletions(-)

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

Re: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver

[Alex Deucher]

On Mon, Nov 13, 2017 at 9:40 AM, Chen, Horace  wrote:
> Reivewed-by: Horace Chen 

Applied.  thanks!

Alex

>
> -Original Message-
> From: Liu, Monk
> Sent: Monday, November 13, 2017 11:43 AM
> To: Chen, Horace ; Colin King 
> ; Deucher, Alexander ; 
> Koenig, Christian ; David Airlie 
> ; Yu, Xiangliang ; 
> amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver
> Importance: High
>
> + Horace
>
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: 2017年11月11日 19:51
> To: Deucher, Alexander ; Koenig, Christian 
> ; David Airlie ; Liu, Monk 
> ; Yu, Xiangliang ; 
> amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver
>
> From: Colin Ian King 
>
> Variable pf2vf_ver is assigned but never read, it is redundant and hence can 
> be removed.
>
> Cleans up clang warning:
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:310:3: warning: Value stored to 
> 'pf2vf_ver' is never read
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 6738df836a70..b1cc179512fa 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -296,7 +296,6 @@ int amdgpu_virt_fw_reserve_get_checksum(void *obj,
>
>  void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev)  {
> -   uint32_t pf2vf_ver = 0;
> uint32_t pf2vf_size = 0;
> uint32_t checksum = 0;
> uint32_t checkval;
> @@ -309,7 +308,6 @@ void amdgpu_virt_init_data_exchange(struct amdgpu_device 
> *adev)
> adev->virt.fw_reserve.p_pf2vf =
> (struct amdgim_pf2vf_info_header *)(
> adev->fw_vram_usage.va + AMDGIM_DATAEXCHANGE_OFFSET);
> -   pf2vf_ver = adev->virt.fw_reserve.p_pf2vf->version;
> AMDGPU_FW_VRAM_PF2VF_READ(adev, header.size, _size);
> AMDGPU_FW_VRAM_PF2VF_READ(adev, checksum, );
>
> --
> 2.14.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Ville Syrjälä]

On Mon, Nov 13, 2017 at 06:30:47PM +, Jose Abreu wrote:
> 
> 
> On 13-11-2017 17:04, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > If the user mode would specify an aspect ratio other than 4:3 or 16:9
> > we now silently ignore it. Maybe a better apporoach is to return an
> > error? Let's try that.
> >
> > Also we must be careful that we don't try to send illegal picture
> > aspect in the infoframe as it's only capable of signalling none,
> > 4:3, and 16:9. Currently we're sending these bogus infoframes
> > whenever the cea mode specifies some other aspect ratio.
> >
> >
> 
> Yes, this is a bug. Following my input from the previous patch I
> think you should also check for HDMI_PICTURE_ASPECT_RESERVED or

RESERVED > 16_9

> user a helper to check that. I'm also wondering if this should go
> to stable since the vics with aspect ratio > 16:9 were
> introduced. We are indeed corrupting the AVI infoframe.

Possibly. Just need to be careful we don't end up making a bigger mess
in stable. I has some concerns about the ordering of these patches, but
I guess that was between this patch and the next patch that starts to
reject the illegal aspect ratios in the infoframe code. So just
backporting this one alone (or both patches) should be fine.

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

Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Ville Syrjälä]

On Mon, Nov 13, 2017 at 06:13:37PM +, Jose Abreu wrote:
> Hi Ville,
> 
> On 13-11-2017 17:04, Ville Syrjala wrote:
> >  
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > +
> >
> 
> Maybe "if (to_match->picture_aspect_ratio !=
> HDMI_PICTURE_ASPECT_NONE && to_match->picture_aspect_ratio !=
> HDMI_PICTURE_ASPECT_RESERVED)"?
> 
> Or some kind of helper to validate the aspect ratio from userspace?

We can't currently get an aspect ratio from userspace. Well we had
it but I reverted it due to regressions. When we add it back it will
obviously need to be validated, just like any other information we
get from userspace.

Hmm. Except we don't even validate the current mode flags/type
at all. Fail.

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

Re: [PATCH 08/10] video/hdmi: Reject illegal picture aspect ratios

[Jose Abreu]

On 13-11-2017 17:04, Ville Syrjala wrote:
> From: Ville Syrjälä 
>
> AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
> ratios. Return an error if the user asked for something different.
>
> Cc: Shashank Sharma 
> Cc: "Lin, Jia" 
> Cc: Akashdeep Sharma 
> Cc: Jim Bride 
> Cc: Jose Abreu 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Thierry Reding 
> Cc: Hans Verkuil 
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jose Abreu 

Best Regards,
Jose Miguel Abreu

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

Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Jose Abreu]

On 13-11-2017 17:04, Ville Syrjala wrote:
> From: Ville Syrjälä 
>
> If the user mode would specify an aspect ratio other than 4:3 or 16:9
> we now silently ignore it. Maybe a better apporoach is to return an
> error? Let's try that.
>
> Also we must be careful that we don't try to send illegal picture
> aspect in the infoframe as it's only capable of signalling none,
> 4:3, and 16:9. Currently we're sending these bogus infoframes
> whenever the cea mode specifies some other aspect ratio.
>
>

Yes, this is a bug. Following my input from the previous patch I
think you should also check for HDMI_PICTURE_ASPECT_RESERVED or
user a helper to check that. I'm also wondering if this should go
to stable since the vics with aspect ratio > 16:9 were
introduced. We are indeed corrupting the AVI infoframe.

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

[drm-intel:drm-intel-next-queued 6/6] intel_device_info.c:undefined reference to `__udivdi3'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   dab91783338bd3dd42638f89b5f7e34c57773207
commit: dab91783338bd3dd42638f89b5f7e34c57773207 [6/6] drm/i915: expose command 
stream timestamp frequency to userspace
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout dab91783338bd3dd42638f89b5f7e34c57773207
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_device_info.o: In function 
`read_reference_ts_freq':
>> intel_device_info.c:(.text+0x4b): undefined reference to `__udivdi3'

---
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 06/10] drm/edid: Fix cea mode aspect ratio handling

[Jose Abreu]

Hi Ville,

On 13-11-2017 17:04, Ville Syrjala wrote:
>  
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
>

Maybe "if (to_match->picture_aspect_ratio !=
HDMI_PICTURE_ASPECT_NONE && to_match->picture_aspect_ratio !=
HDMI_PICTURE_ASPECT_RESERVED)"?

Or some kind of helper to validate the aspect ratio from userspace?

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

Re: Regression in Linux next-20171113 with fbdev timer conversion

[Bartlomiej Zolnierkiewicz]

On Monday, November 13, 2017 09:07:14 AM Tony Lindgren wrote:
> Hi,

Hi Tony,

> Looks like next-20171113 now has a NULL pointe dereference with commit
> 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()").
> 
> See the error below, any ideas?

Should be fixed by:

https://marc.info/?l=linux-fbdev=151056635200583=2

> Regards,
> 
> Tony
> 
> 8< --
> Unable to handle kernel NULL pointer dereference at virtual address 0214
> pgd = edfe4000
> [0214] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> ...
> CPU: 1 PID: 920 Comm: openrc-run.sh Not tainted 4.14.0-next-20171113+ #1911
> Hardware name: Generic OMAP4 (Flattened Device Tree)
> task: ed922000 task.stack: edc2
> PC is at _test_and_set_bit+0x20/0x48
> LR is at queue_work_on+0x28/0x74
> pc : []lr : []psr: 6193
> sp : edc21e38  ip :   fp : c0d09168
> r10: edb686bc  r9 : 0001  r8 : c0544e4c
> r7 : ee80f000  r6 : 0002  r5 : 0214  r4 : 2113
> r3 : 0001  r2 : 0001  r1 : 0214  r0 : 
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 10c5387d  Table: adfe404a  DAC: 0051
> Process openrc-run.sh (pid: 920, stack limit = 0xedc20218)
> Stack: (0xedc21e38 to 0xedc22000)
> 1e20:   edb686bc edb686bc
> 1e40: c0dc8588 0100 c0544e4c c0544e6c c0dc7239 c01cc78c 0001 
> 1e60: c01cc6d0    0001 c1505b74 c124c5f8 
> 1e80: c0adfb54  c0544e4c edb686bc c0544e4c ef6b3700 edc2 edc21ed8
> 1ea0: c0dc8588 c0d09168 edb686bc c01ccbbc 8fee 0001 edc21ed8 c0d05d00
> 1ec0: ef6b3700 c0d0957c 0100 c0dc8128 0282 c01ccd94  c0d4675c
> 1ee0: 6113 c0dc7132 c0d09168 c019f718 e000  c0d03084 edc2
> 1f00: 0001 c0dc7132 c0d09168 c0101714 c0d8821c c0dc720a 0002 000a
> 1f20: 8fee 0040 0001 0002  e000  c0d0957c
> 1f40:  0001 ee80d400 fa240100 c0d09854 c013fa6c c0c79160 c01adf54
> 1f60: fa24010c 03eb 03ff  edc21fb0 c0d88738 fa240100 c0101574
> 1f80: 0006 fa241100 edc2 b6f2e9bc 2010  10c5387d 10c5387d
> 1fa0: 005169a0 00517240 005169a0 c088d6b4 005280ea 005280eb  005f
> 1fc0: 005280e4 004f9511 00517830   005169a0 00517240 005169a0
> 1fe0: 0001 bed595c0 bed595e0 b6f2e9bc 2010   
> [] (_test_and_set_bit) from [] (queue_work_on+0x28/0x74)
> [] (queue_work_on) from [] 
> (cursor_timer_handler+0x20/0x44)
> [] (cursor_timer_handler) from [] 
> (call_timer_fn+0xbc/0x408)
> [] (call_timer_fn) from [] (expire_timers+0xe4/0x220)
> [] (expire_timers) from [] (run_timer_softirq+0x9c/0x1a4)
> [] (run_timer_softirq) from [] (__do_softirq+0x13c/0x5b8)
> [] (__do_softirq) from [] (irq_exit+0x14c/0x1a8)
> [] (irq_exit) from [] (__handle_domain_irq+0x6c/0xe0)
> [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x58/0xb8)
> [] (gic_handle_irq) from [] (__irq_usr+0x54/0x80)
> Exception stack(0xedc21fb0 to 0xedc21ff8)
> 1fa0: 005280ea 005280eb  005f
> 1fc0: 005280e4 004f9511 00517830   005169a0 00517240 005169a0
> 1fe0: 0001 bed595c0 bed595e0 b6f2e9bc 2010 
> Code: e1a002a0 e0811100 e1a03312 ee070fba (e1912f9f)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH] fbcon: Initialize ops->info early

[Bartlomiej Zolnierkiewicz]

On Monday, November 13, 2017 10:45:46 AM Thierry Reding wrote:
> From: Thierry Reding 
> 
> During console takeover, which happens for all DRM/KMS setups using the
> fbdev helpers, fbcon_startup() is called before fbcon_init() and as a
> result con2fb_acquire_newinfo() will not be called (info->fbcon_par was
> set to non-NULL in fbcon_startup()) to assign ops->info.
> 
> This causes the cursor_timer_handler() to unreference a NULL pointer.
> 
> Avoid this by unconditionally assigning ops->info during fbcon_startup()
> so that it will be available early, but keep the additional assignment
> in con2fb_acquire_newinfo() to support console remapping at runtime.
> 
> Cc: Kees Cook 
> Signed-off-by: Thierry Reding 

Patch queued for 4.15, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

[PATCH 10/10] video/hdmi: Pass buffer size to infoframe unpack functions

[Ville Syrjala]

From: Ville Syrjälä 

To make sure the infoframe unpack functions don't end up examining
stack garbage or oopsing, let's pass in the size of the buffer.

Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
 drivers/media/i2c/adv7511.c  |  2 +-
 drivers/media/i2c/adv7604.c  |  2 +-
 drivers/media/i2c/adv7842.c  |  2 +-
 drivers/media/i2c/tc358743.c |  2 +-
 drivers/video/hdmi.c | 51 
 include/linux/hdmi.h |  2 +-
 6 files changed, 42 insertions(+), 19 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 2817bafc67bf..dec09c18ea34 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -562,7 +562,7 @@ static void log_infoframe(struct v4l2_subdev *sd, const 
struct adv7511_cfg_read_
buffer[3] = 0;
buffer[3] = hdmi_infoframe_checksum(buffer, len + 4);
 
-   if (hdmi_infoframe_unpack(, buffer) < 0) {
+   if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__, 
cri->desc);
return;
}
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index f289b8aca1da..8500438af0d3 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2429,7 +2429,7 @@ static int adv76xx_read_infoframe(struct v4l2_subdev *sd, 
int index,
buffer[i + 3] = infoframe_read(sd,
   adv76xx_cri[index].payload_addr + i);
 
-   if (hdmi_infoframe_unpack(frame, buffer) < 0) {
+   if (hdmi_infoframe_unpack(frame, buffer, sizeof(buffer)) < 0) {
v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
 adv76xx_cri[index].desc);
return -ENOENT;
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 65f34e7e146f..fd5d5e84dcbf 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2576,7 +2576,7 @@ static void log_infoframe(struct v4l2_subdev *sd, struct 
adv7842_cfg_read_infofr
for (i = 0; i < len; i++)
buffer[i + 3] = infoframe_read(sd, cri->payload_addr + i);
 
-   if (hdmi_infoframe_unpack(, buffer) < 0) {
+   if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__, 
cri->desc);
return;
}
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index e6f5c363ccab..f6a5ebffd9c6 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -453,7 +453,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
 
i2c_rd(sd, PK_AVI_0HEAD, buffer, HDMI_INFOFRAME_SIZE(AVI));
 
-   if (hdmi_infoframe_unpack(, buffer) < 0) {
+   if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
v4l2_err(sd, "%s: unpack of AVI infoframe failed\n", __func__);
return;
}
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 65b915ea4936..b5d491014b0b 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1005,8 +1005,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
 
 /**
  * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe
- * @buffer: source buffer
  * @frame: HDMI AVI infoframe
+ * @buffer: source buffer
+ * @size: size of buffer
  *
  * Unpacks the information contained in binary @buffer into a structured
  * @frame of the HDMI Auxiliary Video (AVI) information frame.
@@ -1016,11 +1017,14 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
  * Returns 0 on success or a negative error code on failure.
  */
 static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame,
-const void *buffer)
+const void *buffer, size_t size)
 {
const u8 *ptr = buffer;
int ret;
 
+   if (size < HDMI_INFOFRAME_SIZE(AVI))
+   return -EINVAL;
+
if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
ptr[1] != 2 ||
ptr[2] != HDMI_AVI_INFOFRAME_SIZE)
@@ -1068,8 +1072,9 @@ static int hdmi_avi_infoframe_unpack(struct 
hdmi_avi_infoframe *frame,
 
 /**
  * hdmi_spd_infoframe_unpack() - unpack binary buffer to a HDMI SPD infoframe
- * @buffer: source buffer
  * @frame: HDMI SPD infoframe
+ * @buffer: source buffer
+ * @size: size of buffer
  *
  * Unpacks the information contained in binary @buffer into a structured
  * @frame of the HDMI Source Product Description (SPD) information frame.
@@ -1079,11 +1084,14 @@ static int hdmi_avi_infoframe_unpack(struct 
hdmi_avi_infoframe *frame,
  * Returns 0 on success or a negative error code on failure.
  */
 static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe 

[PATCH 08/10] video/hdmi: Reject illegal picture aspect ratios

[Ville Syrjala]

From: Ville Syrjälä 

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
 drivers/video/hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 111a0ab6280a..38716eb50408 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
*frame, void *buffer,
if (size < length)
return -ENOSPC;
 
+   if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+   return -EINVAL;
+
memset(buffer, 0, size);
 
ptr[0] = frame->type;
-- 
2.13.6

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

[PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Ville Syrjala]

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00aa98f3e55d..bafb3ee4ea97 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
 {
+   enum hdmi_picture_aspect picture_aspect;
int err;
 
if (!frame || !mode)
@@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
 
+   /*
+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
 
-- 
2.13.6

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

[PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Ville Syrjala]

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7220b8f9a7e8..00aa98f3e55d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2956,7 +2964,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3003,6 +3011,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3020,7 +3029,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3037,6 +3046,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3052,7 +3062,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
   

[PATCH 09/10] video/hdmi: Constify 'buffer' to the unpack functions

[Ville Syrjala]

From: Ville Syrjälä 

The unpack functions just read from the passed in buffer,
so make it const.

Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
 drivers/video/hdmi.c | 23 ---
 include/linux/hdmi.h |  3 ++-
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 38716eb50408..65b915ea4936 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -31,7 +31,7 @@
 
 #define hdmi_log(fmt, ...) dev_printk(level, dev, fmt, ##__VA_ARGS__)
 
-static u8 hdmi_infoframe_checksum(u8 *ptr, size_t size)
+static u8 hdmi_infoframe_checksum(const u8 *ptr, size_t size)
 {
u8 csum = 0;
size_t i;
@@ -1016,9 +1016,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
  * Returns 0 on success or a negative error code on failure.
  */
 static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame,
-void *buffer)
+const void *buffer)
 {
-   u8 *ptr = buffer;
+   const u8 *ptr = buffer;
int ret;
 
if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
@@ -1079,9 +1079,9 @@ static int hdmi_avi_infoframe_unpack(struct 
hdmi_avi_infoframe *frame,
  * Returns 0 on success or a negative error code on failure.
  */
 static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame,
-void *buffer)
+const void *buffer)
 {
-   u8 *ptr = buffer;
+   const u8 *ptr = buffer;
int ret;
 
if (ptr[0] != HDMI_INFOFRAME_TYPE_SPD ||
@@ -1117,9 +1117,9 @@ static int hdmi_spd_infoframe_unpack(struct 
hdmi_spd_infoframe *frame,
  * Returns 0 on success or a negative error code on failure.
  */
 static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame,
-  void *buffer)
+  const void *buffer)
 {
-   u8 *ptr = buffer;
+   const u8 *ptr = buffer;
int ret;
 
if (ptr[0] != HDMI_INFOFRAME_TYPE_AUDIO ||
@@ -1163,9 +1163,9 @@ static int hdmi_audio_infoframe_unpack(struct 
hdmi_audio_infoframe *frame,
  */
 static int
 hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame,
-void *buffer)
+const void *buffer)
 {
-   u8 *ptr = buffer;
+   const u8 *ptr = buffer;
size_t length;
int ret;
u8 hdmi_video_format;
@@ -1234,10 +1234,11 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
  *
  * Returns 0 on success or a negative error code on failure.
  */
-int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
+int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
+ const void *buffer)
 {
int ret;
-   u8 *ptr = buffer;
+   const u8 *ptr = buffer;
 
switch (ptr[0]) {
case HDMI_INFOFRAME_TYPE_AVI:
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index d271ff23984f..d3816170c062 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -332,7 +332,8 @@ union hdmi_infoframe {
 
 ssize_t
 hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size);
-int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer);
+int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
+ const void *buffer);
 void hdmi_infoframe_log(const char *level, struct device *dev,
union hdmi_infoframe *frame);
 
-- 
2.13.6

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

[PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Ville Syrjala]

From: Ville Syrjälä 

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.

v2: Fix the getting has_hdmi_infoframe from display_info
Always fail constructing the infoframe if the display
possibly can't handle it

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
 drivers/gpu/drm/drm_edid.c| 34 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
 drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
 drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
 drivers/gpu/drm/zte/zx_hdmi.c |  1 +
 include/drm/drm_connector.h   |  5 +
 include/drm/drm_edid.h|  1 +
 12 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704d0a8a..4417276ba02e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge,
union hdmi_infoframe frm;
u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
 
+   /* FIXME: We need the connector here */
drm_hdmi_vendor_infoframe_from_display_mode(
-   , adjusted_mode);
+   , NULL, adjusted_mode);
vic = frm.vendor.hdmi.vic;
if (vic >= ARRAY_SIZE(mhl_vic))
vic = 0;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a64ce7112288..b172139502d6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1437,7 +1437,9 @@ static void hdmi_config_vendor_specific_infoframe(struct 
dw_hdmi *hdmi,
u8 buffer[10];
ssize_t err;
 
-   err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);
+   err = drm_hdmi_vendor_infoframe_from_display_mode(,
+ >connector,
+ mode);
if (err < 0)
/*
 * Going into that statement does not means vendor infoframe
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..9ada0ccf50df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3393,6 +3393,7 @@ static int
 do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
   const u8 *video_db, u8 video_len)
 {
+   struct drm_display_info *info = >display_info;
int modes = 0, offset = 0, i, multi_present = 0, multi_len;
u8 vic_len, hdmi_3d_len = 0;
u16 mask;
@@ -3520,6 +3521,8 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, const 
u8 *db, u8 len,
}
 
 out:
+   if (modes > 0)
+   info->has_hdmi_infoframe = true;
return modes;
 }
 
@@ -4243,6 +4246,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
 
+   display->has_hdmi_infoframe = true;
+
if (hf_vsdb[6] & 0x80) {
hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
@@ -4416,6 +4421,7 @@ static void drm_add_display_info(struct drm_connector 
*connector,
info->cea_rev = 0;
info->max_tmds_clock = 0;
info->dvi_dual = false;
+   info->has_hdmi_infoframe = false;
 
if (edid->revision < 3)
return;
@@ -4903,6 +4909,7 @@ 

[PATCH 03/10] drm/modes: Introduce drm_mode_match()

[Ville Syrjala]

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a33844..8128dbb098be 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return 

[PATCH 05/10] drm/edid: Fix up edid_cea_modes[] formatting

[Ville Syrjala]

From: Ville Syrjälä 

Fix up a bunch of bad indentation and insconsistent comments
in edid_cea_modes[].

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

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b575c4b5a313..7220b8f9a7e8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -685,43 +685,43 @@ static const struct drm_display_mode edid_cea_modes[] = {
{ DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
   2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
-   DRM_MODE_FLAG_INTERLACE),
+  DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 6 - 720(1440)x480i@60Hz */
{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
   801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
+  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
/* 7 - 720(1440)x480i@60Hz */
{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
   801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
+  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 8 - 720(1440)x240@60Hz */
{ DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
   801, 858, 0, 240, 244, 247, 262, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_DBLCLK),
+  DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
/* 9 - 720(1440)x240@60Hz */
{ DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
   801, 858, 0, 240, 244, 247, 262, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_DBLCLK),
+  DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 10 - 2880x480i@60Hz */
{ DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
   3204, 3432, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_INTERLACE),
+  DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
/* 11 - 2880x480i@60Hz */
{ DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
   3204, 3432, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_INTERLACE),
+  DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 12 - 2880x240@60Hz */
{ DRM_MODE("2880x240", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
@@ -767,43 +767,43 @@ static const struct drm_display_mode edid_cea_modes[] = {
{ DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
   2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
-   DRM_MODE_FLAG_INTERLACE),
+  DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 21 - 720(1440)x576i@50Hz */
{ DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
   795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
+  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
/* 22 - 720(1440)x576i@50Hz */
{ DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
   795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
+  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 23 - 720(1440)x288@50Hz */
{ DRM_MODE("720x288", DRM_MODE_TYPE_DRIVER, 

[PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Ville Syrjala]

From: Ville Syrjälä 

HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.

v2: Handle unpack() as well
Pull the length calculation into a helper

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Reviewed-by: Andrzej Hajda  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/video/hdmi.c | 51 +++
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
hdmi_vendor_infoframe *frame)
 }
 EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
 
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe 
*frame)
+{
+   /* for side by side (half) we also need to provide 3D_Ext_Data */
+   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+   return 6;
+   else if (frame->vic != 0 || frame->s3d_struct != 
HDMI_3D_STRUCTURE_INVALID)
+   return 5;
+   else
+   return 4;
+}
+
 /**
  * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
buffer
  * @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
 
-   /* empty info frame */
-   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
-   return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
 
-   /* for side by side (half) we also need to provide 3D_Ext_Data */
-   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
-   frame->length = 6;
-   else
-   frame->length = 5;
+   frame->length = hdmi_vendor_infoframe_length(frame);
 
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
 
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
ptr[5] = 0x0c;
ptr[6] = 0x00;
 
-   if (frame->vic) {
-   ptr[7] = 0x1 << 5;  /* video format */
-   ptr[8] = frame->vic;
-   } else {
+   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5;  /* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+   } else if (frame->vic) {
+   ptr[7] = 0x1 << 5;  /* video format */
+   ptr[8] = frame->vic;
+   } else {
+   ptr[7] = 0x0 << 5;  /* video format */
}
 
hdmi_infoframe_set_checksum(buffer, length);
@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
 
if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
ptr[1] != 1 ||
-   (ptr[2] != 5 && ptr[2] != 6))
+   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
 
length = ptr[2];
@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
 
hvf->length = length;
 
-   if (hdmi_video_format == 0x1) {
-   hvf->vic = ptr[4];
-   } else if (hdmi_video_format == 0x2) {
+   if (hdmi_video_format == 0x2) {
+   if (length != 5 && length != 6)
+   return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
-   if (length == 6)
-   hvf->s3d_ext_data = ptr[5] >> 4;
-   else
+   if (length != 6)
return -EINVAL;
+   hvf->s3d_ext_data = ptr[5] >> 4;
}
+   } else if (hdmi_video_format == 0x1) {
+   if (length != 5)
+   return -EINVAL;
+   hvf->vic = ptr[4];
+   } else {
+   if (length != 4)
+   return -EINVAL;
}
 
return 0;
-- 
2.13.6

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

[PATCH 04/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Ville Syrjala]

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9ada0ccf50df..b575c4b5a313 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3020,7 +3020,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.13.6

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

[PATCH 00/10] drm/edid: Infoframe cleanups and fixes

[Ville Syrjala]

From: Ville Syrjälä 

This series tries to fix some issues with HDMI infoframes. In particular
we can currently send a bogus picture aspect ratio in the infoframe. I
included stuff to to make the infoframe unpakc more robust, evne though
we don't (yet) use it in drm. Additionally I included my earlier "empty"
HDMI infoframe support.

I have further work piled up on top which allows us to precompuet the
infoframes during the atomic check phase. But the series would have
become rather big, so I wanted to post these fixes and cleanups first.

Entire series (with the infoframe precompute) is available here:
git://github.com/vsyrjala/linux.git infoframe_precompute

Cc: Akashdeep Sharma 
Cc: Andrzej Hajda 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Hans Verkuil 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Laurent Pinchart 
Cc: "Lin, Jia" 
Cc: linux-me...@vger.kernel.org
Cc: Sean Paul 
Cc: Shashank Sharma 
Cc: Thierry Reding 

Ville Syrjälä (10):
  video/hdmi: Allow "empty" HDMI infoframes
  drm/edid: Allow HDMI infoframe without VIC or S3D
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix up edid_cea_modes[] formatting
  drm/edid: Fix cea mode aspect ratio handling
  drm/edid: Don't send bogus aspect ratios in AVI infoframes
  video/hdmi: Reject illegal picture aspect ratios
  video/hdmi: Constify 'buffer' to the unpack functions
  video/hdmi: Pass buffer size to infoframe unpack functions

 drivers/gpu/drm/bridge/sil-sii8620.c  |   3 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   4 +-
 drivers/gpu/drm/drm_edid.c| 159 +++---
 drivers/gpu/drm/drm_modes.c   | 134 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   2 +-
 drivers/gpu/drm/i915/intel_hdmi.c |  14 +--
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |   3 +-
 drivers/gpu/drm/nouveau/nv50_display.c|   3 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |   1 +
 drivers/gpu/drm/sti/sti_hdmi.c|   4 +-
 drivers/gpu/drm/zte/zx_hdmi.c |   1 +
 drivers/media/i2c/adv7511.c   |   2 +-
 drivers/media/i2c/adv7604.c   |   2 +-
 drivers/media/i2c/adv7842.c   |   2 +-
 drivers/media/i2c/tc358743.c  |   2 +-
 drivers/video/hdmi.c  | 118 ++
 include/drm/drm_connector.h   |   5 +
 include/drm/drm_edid.h|   1 +
 include/drm/drm_modes.h   |   9 ++
 include/linux/hdmi.h  |   3 +-
 20 files changed, 326 insertions(+), 146 deletions(-)

-- 
2.13.6

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

[PATCH libdrm v2] amdgpu: Add memory over allocation test.

[Andrey Grodzovsky]

Allocates 1 TB of memory. Test is disabled by default
since it's triggers OOM killer.

v2:
FIx the test to only alloc the BO and assert if return value
not equal to -ENOMEM and remove test disable on start.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/bo_tests.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 4545196..53e76c1 100644
--- a/tests/amdgpu/bo_tests.c
+++ b/tests/amdgpu/bo_tests.c
@@ -47,6 +47,7 @@ static void amdgpu_bo_export_import(void);
 static void amdgpu_bo_metadata(void);
 static void amdgpu_bo_map_unmap(void);
 static void amdgpu_memory_alloc(void);
+static void amdgpu_mem_fail_alloc(void);
 
 CU_TestInfo bo_tests[] = {
{ "Export/Import",  amdgpu_bo_export_import },
@@ -55,6 +56,7 @@ CU_TestInfo bo_tests[] = {
 #endif
{ "CPU map/unmap",  amdgpu_bo_map_unmap },
{ "Memory alloc Test",  amdgpu_memory_alloc },
+   { "Memory fail alloc Test",  amdgpu_mem_fail_alloc },
CU_TEST_INFO_NULL,
 };
 
@@ -244,3 +246,25 @@ static void amdgpu_memory_alloc(void)
r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
CU_ASSERT_EQUAL(r, 0);
 }
+
+static void amdgpu_mem_fail_alloc(void)
+{
+   amdgpu_bo_handle bo;
+   int r;
+   struct amdgpu_bo_alloc_request req = {0};
+   amdgpu_bo_handle buf_handle;
+
+   /* Test impossible mem allocation, 1TB */
+   req.alloc_size = 0xE8D4A51000;
+   req.phys_alignment = 4096;
+   req.preferred_heap = AMDGPU_GEM_DOMAIN_VRAM;
+   req.flags = AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
+
+   r = amdgpu_bo_alloc(device_handle, , _handle);
+   CU_ASSERT_EQUAL(r, -ENOMEM);
+
+   if (!r) {
+   r = amdgpu_bo_free(bo);
+   CU_ASSERT_EQUAL(r, 0);
+   }
+}
-- 
2.7.4

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

Re: [PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors

[Oded Gabbay]

On Mon, Nov 13, 2017 at 2:35 AM, Dmitry V. Levin  wrote:
> Consistently use types provided by  via 
> to fix the following linux/kfd_ioctl.h userspace compilation errors:
>
> /usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t'
>   uint64_t va_addr; /* to KFD */
> /usr/include/linux/kfd_ioctl.h:237:2: error: unknown type name 'uint32_t'
>   uint32_t gpu_id; /* to KFD */
> /usr/include/linux/kfd_ioctl.h:238:2: error: unknown type name 'uint32_t'
>   uint32_t pad;
> /usr/include/linux/kfd_ioctl.h:243:2: error: unknown type name 'uint64_t'
>   uint64_t tile_config_ptr;
> /usr/include/linux/kfd_ioctl.h:245:2: error: unknown type name 'uint64_t'
>   uint64_t macro_tile_config_ptr;
> /usr/include/linux/kfd_ioctl.h:249:2: error: unknown type name 'uint32_t'
>   uint32_t num_tile_configs;
> /usr/include/linux/kfd_ioctl.h:253:2: error: unknown type name 'uint32_t'
>   uint32_t num_macro_tile_configs;
> /usr/include/linux/kfd_ioctl.h:255:2: error: unknown type name 'uint32_t'
>   uint32_t gpu_id;  /* to KFD */
> /usr/include/linux/kfd_ioctl.h:256:2: error: unknown type name 'uint32_t'
>   uint32_t gb_addr_config; /* from KFD */
> /usr/include/linux/kfd_ioctl.h:257:2: error: unknown type name 'uint32_t'
>   uint32_t num_banks;  /* from KFD */
> /usr/include/linux/kfd_ioctl.h:258:2: error: unknown type name 'uint32_t'
>   uint32_t num_ranks;  /* from KFD */
>
> Fixes: 6a1c9510694fe ("drm/amdkfd: Adding new IOCTL for scratch memory v2")
> Fixes: 5d71dbc3a5886 ("drm/amdkfd: Implement image tiling mode support v2")
> Signed-off-by: Dmitry V. Levin 
> ---
>  include/uapi/linux/kfd_ioctl.h | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
> index 26283fefdf5f..f7015aa12347 100644
> --- a/include/uapi/linux/kfd_ioctl.h
> +++ b/include/uapi/linux/kfd_ioctl.h
> @@ -233,29 +233,29 @@ struct kfd_ioctl_wait_events_args {
>  };
>
>  struct kfd_ioctl_set_scratch_backing_va_args {
> -   uint64_t va_addr;   /* to KFD */
> -   uint32_t gpu_id;/* to KFD */
> -   uint32_t pad;
> +   __u64 va_addr;  /* to KFD */
> +   __u32 gpu_id;   /* to KFD */
> +   __u32 pad;
>  };
>
>  struct kfd_ioctl_get_tile_config_args {
> /* to KFD: pointer to tile array */
> -   uint64_t tile_config_ptr;
> +   __u64 tile_config_ptr;
> /* to KFD: pointer to macro tile array */
> -   uint64_t macro_tile_config_ptr;
> +   __u64 macro_tile_config_ptr;
> /* to KFD: array size allocated by user mode
>  * from KFD: array size filled by kernel
>  */
> -   uint32_t num_tile_configs;
> +   __u32 num_tile_configs;
> /* to KFD: array size allocated by user mode
>  * from KFD: array size filled by kernel
>  */
> -   uint32_t num_macro_tile_configs;
> +   __u32 num_macro_tile_configs;
>
> -   uint32_t gpu_id;/* to KFD */
> -   uint32_t gb_addr_config;/* from KFD */
> -   uint32_t num_banks; /* from KFD */
> -   uint32_t num_ranks; /* from KFD */
> +   __u32 gpu_id;   /* to KFD */
> +   __u32 gb_addr_config;   /* from KFD */
> +   __u32 num_banks;/* from KFD */
> +   __u32 num_ranks;/* from KFD */
> /* struct size can be extended later if needed
>  * without breaking ABI compatibility
>  */
> --
> ldv

Thanks!
Applied to -fixes
Oded
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

[Oded Gabbay]

On Sat, Nov 11, 2017 at 8:16 AM, Randy Dunlap  wrote:
> From: Randy Dunlap 
>
> Fix GP fault caused by dev_info() reference to a struct device*
> after the device has been freed (use after free).
> kfd_chardev_exit() frees the device so 'kfd_device' should not
> be used after calling kfd_chardev_exit().
>
> To reproduce, just load the module and then unload it.
> Note that %RAX contains repeated 0x6b, which is use-after-free
> poisoning.
>
> [  946.645809] calling  kfd_module_init+0x0/0x1000 [amdkfd] @ 5785
> [  946.646025] CRAT table not found
> [  946.646027] Finished initializing topology ret=0
> [  946.646050] kfd kfd: Initialized module
> [  946.646058] initcall kfd_module_init+0x0/0x1000 [amdkfd] returned 0 after 
> 233 usecs
> [  947.650189] general protection fault:  [#1] PREEMPT SMP
> [  947.650192] Modules linked in: amdkfd(-) amd_iommu_v2 dw_hdmi cec rc_core 
> mxm_wmi ttm dln2 gpio_max730x tps65218 lp3943 mcb crc4 fpga_mgr fpga_bridge 
> fmc fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common 
> xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 
> nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT 
> iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
> nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack 
> libcrc32c ip6table_filter ip6_tables x_tables coretemp hwmon intel_rapl 
> x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm irqbypass 
> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc 
> aesni_intel uvcvideo videobuf2_vmalloc aes_x86_64 videobuf2_memops 
> hid_generic videobuf2_v4l2
> [  947.650224]  crypto_simd snd_hda_codec_hdmi videobuf2_core usbmouse 
> videodev snd_hda_codec_realtek glue_helper usbhid media hid 
> snd_hda_codec_generic snd_hda_intel arc4 snd_hda_codec cryptd iwldvm 
> sdhci_pci snd_hda_core sdhci mmc_core mac80211 snd_hwdep iTCO_wdt snd_pcm 
> iTCO_vendor_support xhci_pci intel_cstate xhci_hcd i915 snd_seq 
> snd_seq_device ehci_pci snd_timer toshiba_acpi ehci_hcd snd usbcore iwlwifi 
> sparse_keymap e1000e cfg80211 input_leds ptp wmi sr_mod intel_uncore mei_me 
> lpc_ich led_class cdrom usb_common pps_core mei joydev intel_rapl_perf 
> mousedev evdev industrialio toshiba_bluetooth shpchp mac_hid rfkill soundcore 
> serio_raw pcspkr toshiba_haps battery video thermal ac button sg autofs4 
> [last unloaded: radeon]
> [  947.650259] CPU: 3 PID: 5791 Comm: rmmod Not tainted 4.14.0-rc8 #4
> [  947.650260] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version 
> 4.10   01/08/2013
> [  947.650262] task: 97144a3f2840 task.stack: a51e409c4000
> [  947.650266] RIP: 0010:__dev_printk+0x29/0x90
> [  947.650267] RSP: 0018:a51e409c7e48 EFLAGS: 00010202
> [  947.650269] RAX: 6b6b6b6b6b6b6b6b RBX: 97a579c3 RCX: 
> 000100140013
> [  947.650270] RDX: a51e409c7e78 RSI: 97139e360558 RDI: 
> 97a579c3
> [  947.650271] RBP: a51e409c7e68 R08: 6b6b6b6b6b6b6b6b R09: 
> a51e409c7e78
> [  947.650272] R10: 9714465c44b8 R11: 9714465c55e8 R12: 
> 7fff874111f7
> [  947.650273] R13: 0800 R14: 006231c0 R15: 
> 00623010
> [  947.650275] FS:  7fe8a109d700() GS:97144fac() 
> knlGS:
> [  947.650276] CS:  0010 DS:  ES:  CR0: 80050033
> [  947.650277] CR2: 0062cc88 CR3: 00013fd43005 CR4: 
> 000606e0
> [  947.650279] Call Trace:
> [  947.650283]  ? kobject_cleanup+0x75/0x170
> [  947.650284]  _dev_info+0x57/0x60
> [  947.650288]  ? kfree+0xf5/0x140
> [  947.650295]  kfd_module_exit+0x37/0x39 [amdkfd]
> [  947.650299]  SyS_delete_module+0x14d/0x260
> [  947.650302]  ? exit_to_usermode_loop+0x60/0x87
> [  947.650305]  entry_SYSCALL_64_fastpath+0x1e/0xa9
> [  947.650307] RIP: 0033:0x7fe8a0beff97
> [  947.650308] RSP: 002b:7fff8740ffc8 EFLAGS: 0202 ORIG_RAX: 
> 00b0
> [  947.650310] RAX: ffda RBX: 0003 RCX: 
> 7fe8a0beff97
> [  947.650311] RDX: 7fe8a0c56920 RSI: 0800 RDI: 
> 00623228
> [  947.650312] RBP: 006231c0 R08: 7fe8a0ea3f20 R09: 
> 7fff8740ef41
> [  947.650313] R10: 2ef31b7d R11: 0202 R12: 
> 7fff8740efc0
> [  947.650314] R13:  R14: 006231c0 R15: 
> 00623010
> [  947.650316] Code: 00 00 55 49 89 d1 48 89 e5 53 48 89 fb 48 83 ec 18 48 85 
> f6 74 5f 4c 8b 46 50 4d 85 c0 74 2b 48 8b 86 88 00 00 00 48 85 c0 74 25 <48> 
> 8b 08 0f be 7b 01 48 c7 c2 96 0a aa 97 31 c0 83 ef 30 e8 7f
> [  947.650339] RIP: __dev_printk+0x29/0x90 RSP: a51e409c7e48
> [  947.650388] ---[ end trace c41965e147ae98ae ]---
>
> Signed-off-by: Randy Dunlap 
> Cc: Oded Gabbay 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_module.c |3 ++-
>  1 file changed, 2 

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Andrey Grodzovsky]

On 11/13/2017 10:27 AM, Christian König wrote:

Am 13.11.2017 um 15:57 schrieb Andrey Grodzovsky:

On 11/13/2017 07:39 AM, Christian König wrote:


Am 13.11.2017 um 12:32 schrieb Michel Dänzer:

On 12/11/17 10:35 AM, Christian König wrote:

A few comments on the code:


+/* Validate bo size is bit bigger then the request domain */
+static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
*adev,
+  unsigned long size, u32 domain)

Drop the inline keyword and the second _bo_ in the name here.


+{
+struct ttm_mem_type_manager *man = NULL;
+
+if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
+man = >mman.bdev.man[TTM_PL_VRAM];
+
+if (man && size < (man->size << PAGE_SHIFT))

Drop the extra check that man is not NULL. We get the pointer to an
array element, that can't be NULL.


+return true;

Mhm, domain is a bitmask of allowed domains.

So we should check all valid domains if the size fit, not just the 
first

one.

Assuming VRAM <-> system migration of BOs larger than the GTT domain
works, I'd say we should only require that the BO can fit in any of 
the

allowed domains. Otherwise it must also always fit in GTT.
Good point, and yes VRAM <-> system migration of BOs larger than the 
GTT domain works now.


I can agree on that VRAM should probably be optional, otherwise we 
can't allocate anything large when the driver uses only very low 
amounts of stolen VRAM on APUs.


But I think when userspace requests VRAM and GTT at the same time we 
still should be able to fall back to GTT.


Attached V2 patch, I still don't understand why I experience the 
SIGSEV in the tester when the check fails and the IOCTLs will return 
ENOMEM




Reviewed-by: Christian König  for this one, 
but please use git send-email to send out patches.


I will update the libdrm test to correctly handle mem failure, it 
segfaults at the moment.


Sounds like it just tries to use the BO for VM or CPU mapping while 
the underlying function has failed (or we have another bug somewhere).


Yes, the segfault is because I am using gpu_mem_alloc which continues 
executing after amdgpu_bo_alloc failed, the segfault is in amdgpu_bo_va_op.




Please commit the kernel patch and leave me a note so that I can push 
the libdrm patches. 


Areyou gonna push patches 1-3 from the original series and then I need 
to resend patch 4 to fix the segfault ?



BTW: Do you have the link where you request an account at hand? I want 
to ping the admins once more.


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

Thanks,
Andrey



Regards,
Christian.




Thanks,
Andey


Regards,
Christian.






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

[PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent mfd node was also prematurely freed.

Note that the nodes returned from the two calls to of_parse_phandle()
are also leaking, but fixing that is a bit more involved as pointers to
node fields are being stored for later use.

Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
Cc: stable  # 3.10
Cc: Guennadi Liakhovetski 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/as3711_bl.c | 35 +--
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/as3711_bl.c 
b/drivers/video/backlight/as3711_bl.c
index 734a9158946b..21ce56053c88 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -262,15 +262,16 @@ static int as3711_bl_register(struct platform_device 
*pdev,
 static int as3711_backlight_parse_dt(struct device *dev)
 {
struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
-   struct device_node *bl =
-   of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
+   struct device_node *bl, *fb;
int ret;
 
+   bl = of_get_child_by_name(dev->parent->of_node, "backlight");
if (!bl) {
dev_dbg(dev, "backlight node not found\n");
return -ENODEV;
}
 
+   /* FIXME: need to drop reference to returned node */
fb = of_parse_phandle(bl, "su1-dev", 0);
if (fb) {
pdata->su1_fb = fb->full_name;
@@ -279,9 +280,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su1_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
-   return ret;
+   goto err_put_bl;
}
 
+   /* FIXME: need to drop reference to returned node */
fb = of_parse_phandle(bl, "su2-dev", 0);
if (fb) {
int count = 0;
@@ -292,7 +294,7 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su2_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
-   return ret;
+   goto err_put_bl;
 
if (of_find_property(bl, "su2-feedback-voltage", NULL)) {
pdata->su2_feedback = AS3711_SU2_VOLTAGE;
@@ -314,8 +316,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
count++;
}
-   if (count != 1)
-   return -EINVAL;
+   if (count != 1) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
 
count = 0;
if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
@@ -334,8 +338,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_fbprot = AS3711_SU2_GPIO4;
count++;
}
-   if (count != 1)
-   return -EINVAL;
+   if (count != 1) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
 
count = 0;
if (of_find_property(bl, "su2-auto-curr1", NULL)) {
@@ -355,11 +361,20 @@ static int as3711_backlight_parse_dt(struct device *dev)
 * At least one su2-auto-curr* must be specified iff
 * AS3711_SU2_CURR_AUTO is used
 */
-   if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
-   return -EINVAL;
+   if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
}
 
+   of_node_put(bl);
+
return 0;
+
+err_put_bl:
+   of_node_put(bl);
+
+   return ret;
 }
 
 static int as3711_backlight_probe(struct platform_device *pdev)
-- 
2.15.0

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

[PATCH 3/3] backlight: tps65217_bl: fix device-tree node lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

This would only cause trouble if the child node is missing while there
is an unrelated node named "backlight" elsewhere in the tree.

Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
Cc: stable  # 3.7
Cc: Matthias Kaehlcke 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/tps65217_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index 380917c86276..762e3feed097 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -184,11 +184,11 @@ static struct tps65217_bl_pdata *
 tps65217_bl_parse_dt(struct platform_device *pdev)
 {
struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
-   struct device_node *node = of_node_get(tps->dev->of_node);
+   struct device_node *node;
struct tps65217_bl_pdata *pdata, *err;
u32 val;
 
-   node = of_find_node_by_name(node, "backlight");
+   node = of_get_child_by_name(tps->dev->of_node, "backlight");
if (!node)
return ERR_PTR(-ENODEV);
 
-- 
2.15.0

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

[PATCH] video: fbdev: atmel_lcdfb: fix display-timings lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent display node was also prematurely
freed.

Note that the display and timings node references are never put after a
successful dt-initialisation so the nodes would leak on later probe
deferrals and on driver unbind.

Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
Cc: stable  # 3.13
Cc: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Johan Hovold 
---
 drivers/video/fbdev/atmel_lcdfb.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index e06358da4b99..3dee267d7c75 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1119,7 +1119,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
goto put_display_node;
}
 
-   timings_np = of_find_node_by_name(display_np, "display-timings");
+   timings_np = of_get_child_by_name(display_np, "display-timings");
if (!timings_np) {
dev_err(dev, "failed to find display-timings node\n");
ret = -ENODEV;
@@ -1140,6 +1140,12 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
fb_add_videomode(_vm, >modelist);
}
 
+   /*
+* FIXME: Make sure we are not referencing any fields in display_np
+* and timings_np and drop our references to them before returning to
+* avoid leaking the nodes on probe deferral and driver unbind.
+*/
+
return 0;
 
 put_timings_node:
-- 
2.15.0

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

[PATCH 2/3] backlight: max8925_bl: fix device-tree node lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent mfd node was also prematurely freed,
while the child backlight node was leaked.

Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
Cc: stable  # 3.9
Cc: Qing Xu 
Cc: Haojian Zhuang 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/max8925_bl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/max8925_bl.c 
b/drivers/video/backlight/max8925_bl.c
index 7b738d60ecc2..f3aa6088f1d9 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(struct 
platform_device *pdev)
if (!pdata)
return;
 
-   np = of_find_node_by_name(nproot, "backlight");
+   np = of_get_child_by_name(nproot, "backlight");
if (!np) {
dev_err(>dev, "failed to find backlight node\n");
return;
@@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(struct 
platform_device *pdev)
if (!of_property_read_u32(np, "maxim,max8925-dual-string", ))
pdata->dual_string = val;
 
+   of_node_put(np);
+
pdev->dev.platform_data = pdata;
 }
 
-- 
2.15.0

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

Re: [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model

[Dmitry Osipenko]

On 07.11.2017 15:29, Mikko Perttunen wrote:
> On 05.11.2017 19:43, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> In the traditional channel allocation model, a single hardware channel
>>> was allocated for each client. This is simple from an implementation
>>> perspective but prevents use of hardware scheduling.
>>>
>>> This patch implements a channel allocation model where when a user
>>> submits a job for a context, a hardware channel is allocated for
>>> that context. The same channel is kept for as long as there are
>>> incomplete jobs for that context. This way we can use hardware
>>> scheduling and channel isolation between userspace processes, but
>>> also prevent idling contexts from taking up hardware resources.
>>>
>>
>> The dynamic channels resources (pushbuf) allocation is very expensive,
>> neglecting all benefits that this model should bring at least in non-IOMMU 
>> case.
>> We could have statically preallocated channels resources or defer resources
>> freeing.
> 
> This is true. I'll try to figure out a nice way to keep the pushbuf 
> allocations.

One variant could be to have all channels resources statically preallocated in a
non-IOMMU case because CMA is expensive. Then you should measure the allocations
impact in a case of IOMMU allocations and if it is significant, maybe implement
Host1x PM autosuspend, releasing all channels when Host1x become idle.

I think the above should be efficient and easy to implement.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the devicetree tree with the drm tree

[Jyri Sarha]

On 11/13/17 07:58, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 30 Oct 2017 20:37:56 + Mark Brown  wrote:
>>
>> Today's linux-next merge of the devicetree tree got a conflict in:
>>
>>   drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>>
>> between commit:
>>
>>   44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting")
>>
>> from the drm tree and commit:
>>
>>   f948d6d8b792bb ("of: overlay: avoid race condition between applying 
>> multiple overlays")
>>
>> from the devicetree tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>> diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>> index 482299a6f3b0,54025af534d4..
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>> @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc
>>  return NULL;
>>  }
>>   
>> -ret = of_resolve_phandles(overlay);
>> -if (ret) {
>> -pr_err("%s: Failed to resolve phandles: %d\n", __func__, ret);
>> -return NULL;
>> -}
>>  -   of_node_set_flag(overlay, OF_DETACHED);
>> --
>>  return overlay;
>>   }
>>   
> 
> Just a reminder that this conflict still exists.
> 

After some consideration, I think we can drop the dts backward
compatibility code from drm/tilcdc. It seems that it is causing a lot of
trouble and I do not even know if anybody uses it anymore. Here is a
patch for dropping it:

https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html

I did not plan to merge it before v4.16, but if this is a bigger problem
I can push is right now for v4.15.

Best regards,
Jyri

-- 
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 103697] [regression] shared memory size 64k -> 32k?

[bugzilla-daemon]

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

--- Comment #2 from O Heid  ---
I checked back with AMD and they say that there is hardware support for 64kB
shared memory. This actually gets exposed in OpenCL and ROCm/HC.
The 2016 AMD GCN3 manual wrongly states it is only 32kB, but the AMD Vega ISA
reference guide has the correct 64kB LDS size.
So it seems the restriction is due to the mesa software stack, not due to
hardware. Could you please raise the bar back to 64kB? I wouldn't ask if it
wouldn't hit me with with a 2x performance penalty...

-- 
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 libdrm 0/4] Dynamicly disable suites and tets.

[Christian König]

Am 13.11.2017 um 15:57 schrieb Andrey Grodzovsky:

On 11/13/2017 07:39 AM, Christian König wrote:


Am 13.11.2017 um 12:32 schrieb Michel Dänzer:

On 12/11/17 10:35 AM, Christian König wrote:

A few comments on the code:


+/* Validate bo size is bit bigger then the request domain */
+static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
*adev,
+  unsigned long size, u32 domain)

Drop the inline keyword and the second _bo_ in the name here.


+{
+    struct ttm_mem_type_manager *man = NULL;
+
+    if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
+    man = >mman.bdev.man[TTM_PL_VRAM];
+
+    if (man && size < (man->size << PAGE_SHIFT))

Drop the extra check that man is not NULL. We get the pointer to an
array element, that can't be NULL.


+    return true;

Mhm, domain is a bitmask of allowed domains.

So we should check all valid domains if the size fit, not just the 
first

one.

Assuming VRAM <-> system migration of BOs larger than the GTT domain
works, I'd say we should only require that the BO can fit in any of the
allowed domains. Otherwise it must also always fit in GTT.
Good point, and yes VRAM <-> system migration of BOs larger than the 
GTT domain works now.


I can agree on that VRAM should probably be optional, otherwise we 
can't allocate anything large when the driver uses only very low 
amounts of stolen VRAM on APUs.


But I think when userspace requests VRAM and GTT at the same time we 
still should be able to fall back to GTT.


Attached V2 patch, I still don't understand why I experience the 
SIGSEV in the tester when the check fails and the IOCTLs will return 
ENOMEM




Reviewed-by: Christian König  for this one, 
but please use git send-email to send out patches.


I will update the libdrm test to correctly handle mem failure, it 
segfaults at the moment.


Sounds like it just tries to use the BO for VM or CPU mapping while the 
underlying function has failed (or we have another bug somewhere).


Please commit the kernel patch and leave me a note so that I can push 
the libdrm patches. BTW: Do you have the link where you request an 
account at hand? I want to ping the admins once more.


Regards,
Christian.




Thanks,
Andey


Regards,
Christian.




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

Re: [PATCH] drm/vblank: Fix vblank timestamp debugs

[Arnd Bergmann]

On Mon, Nov 13, 2017 at 4:02 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> We're currently calling ktime_to_timespec64() on stack garbage
> hence the debug output for vblank timestamps also contains garbage.
> Let's assing something to the ktime_t first before we go converting
> it to a timespec.
>
> While at it micro-optimize the ktime_to_timespec64() calls away
> when vblank debugging isn't enabled.
>
> Fixes: 67680d3c0464 ("drm: vblank: use ktime_t instead of timeval")

Acked-by: Arnd Bergmann 

Sorry about the mess and thanks for cleaning up behind me.

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

[Bug 197851] Resume from suspend sometimes results in black screen on Radeon R5

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your xorg log and dmesg output.

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

[PATCH] drm/vblank: Fix vblank timestamp debugs

[Ville Syrjala]

From: Ville Syrjälä 

We're currently calling ktime_to_timespec64() on stack garbage
hence the debug output for vblank timestamps also contains garbage.
Let's assing something to the ktime_t first before we go converting
it to a timespec.

While at it micro-optimize the ktime_to_timespec64() calls away
when vblank debugging isn't enabled.

Fixes: 67680d3c0464 ("drm: vblank: use ktime_t instead of timeval")
Cc: Arnd Bergmann 
Cc: Keith Packard 
Cc: Sean Paul 
Cc: Dave Airlie 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_vblank.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 09c1c4ff93ca..2c68909637b5 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -664,14 +664,16 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
delta_ns = div_s64(100LL * (vpos * mode->crtc_htotal + hpos),
   mode->crtc_clock);
 
-   /* save this only for debugging purposes */
-   ts_etime = ktime_to_timespec64(etime);
-   ts_vblank_time = ktime_to_timespec64(*vblank_time);
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   etime = ktime_sub_ns(etime, delta_ns);
-   *vblank_time = etime;
+   *vblank_time = ktime_sub_ns(etime, delta_ns);
+
+   if ((drm_debug & DRM_UT_VBL) == 0)
+   return true;
+
+   ts_etime = ktime_to_timespec64(etime);
+   ts_vblank_time = ktime_to_timespec64(*vblank_time);
 
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %lld.%06ld -> %lld.%06ld [e %d us, 
%d rep]\n",
  pipe, hpos, vpos,
-- 
2.13.6

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

[Bug 197841] lg 25um58-P monitor wrong refresh rate with rx 460

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your xorg log and dmesg output.

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

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Andrey Grodzovsky]

On 11/13/2017 07:39 AM, Christian König wrote:


Am 13.11.2017 um 12:32 schrieb Michel Dänzer:

On 12/11/17 10:35 AM, Christian König wrote:

A few comments on the code:


+/* Validate bo size is bit bigger then the request domain */
+static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
*adev,
+  unsigned long size, u32 domain)

Drop the inline keyword and the second _bo_ in the name here.


+{
+struct ttm_mem_type_manager *man = NULL;
+
+if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
+man = >mman.bdev.man[TTM_PL_VRAM];
+
+if (man && size < (man->size << PAGE_SHIFT))

Drop the extra check that man is not NULL. We get the pointer to an
array element, that can't be NULL.


+return true;

Mhm, domain is a bitmask of allowed domains.

So we should check all valid domains if the size fit, not just the 
first

one.

Assuming VRAM <-> system migration of BOs larger than the GTT domain
works, I'd say we should only require that the BO can fit in any of the
allowed domains. Otherwise it must also always fit in GTT.
Good point, and yes VRAM <-> system migration of BOs larger than the 
GTT domain works now.


I can agree on that VRAM should probably be optional, otherwise we 
can't allocate anything large when the driver uses only very low 
amounts of stolen VRAM on APUs.


But I think when userspace requests VRAM and GTT at the same time we 
still should be able to fall back to GTT.


Attached V2 patch, I still don't understand why I experience the SIGSEV 
in the tester when the check fails and the IOCTLs will return ENOMEM


I will update the libdrm test to correctly handle mem failure, it 
segfaults at the moment.



Thanks,
Andey


Regards,
Christian.


>From 37369b3a58027dedf7e9dc65fd9bc0f9e86d0d80 Mon Sep 17 00:00:00 2001
From: Andrey Grodzovsky 
Date: Fri, 10 Nov 2017 18:35:56 -0500
Subject: drm/amdgpu: Implement BO size validation V2

Validates BO size against each requested domain's total memory.

v2:
Make GTT size check a MUST to allow fall back to GTT.
Rmove redundant NULL check.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index a937c49..5acf20c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -281,6 +281,44 @@ void amdgpu_bo_free_kernel(struct amdgpu_bo **bo, u64 *gpu_addr,
 		*cpu_addr = NULL;
 }
 
+/* Validate bo size is bit bigger then the request domain */
+static bool amdgpu_bo_validate_size(struct amdgpu_device *adev,
+	  unsigned long size, u32 domain)
+{
+	struct ttm_mem_type_manager *man = NULL;
+
+	/*
+	 * If GTT is part of requested domains the check must succeed to
+	 * allow fall back to GTT
+	 */
+	if (domain & AMDGPU_GEM_DOMAIN_GTT) {
+		man = >mman.bdev.man[TTM_PL_TT];
+
+		if (size < (man->size << PAGE_SHIFT))
+			return true;
+		else
+			goto fail;
+	}
+
+	if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
+		man = >mman.bdev.man[TTM_PL_VRAM];
+
+		if (size < (man->size << PAGE_SHIFT))
+			return true;
+		else
+			goto fail;
+	}
+
+
+	/* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU */
+	return true;
+
+fail:
+	DRM_ERROR("BO size %lu > total memory in domain: %llu\n", size,
+	  man->size << PAGE_SHIFT);
+	return false;
+}
+
 static int amdgpu_bo_do_create(struct amdgpu_device *adev,
 			   unsigned long size, int byte_align,
 			   bool kernel, u32 domain, u64 flags,
@@ -299,6 +337,9 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
 	page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT;
 	size = ALIGN(size, PAGE_SIZE);
 
+	if (!amdgpu_bo_validate_size(adev, size, domain))
+		return -ENOMEM;
+
 	if (kernel) {
 		type = ttm_bo_type_kernel;
 	} else if (sg) {
-- 
2.7.4

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

RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver

[Chen, Horace]

Reivewed-by: Horace Chen 

-Original Message-
From: Liu, Monk 
Sent: Monday, November 13, 2017 11:43 AM
To: Chen, Horace ; Colin King ; 
Deucher, Alexander ; Koenig, Christian 
; David Airlie ; Yu, Xiangliang 
; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver
Importance: High

+ Horace

-Original Message-
From: Colin King [mailto:colin.k...@canonical.com] 
Sent: 2017年11月11日 19:51
To: Deucher, Alexander ; Koenig, Christian 
; David Airlie ; Liu, Monk 
; Yu, Xiangliang ; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver

From: Colin Ian King 

Variable pf2vf_ver is assigned but never read, it is redundant and hence can be 
removed.

Cleans up clang warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:310:3: warning: Value stored to 
'pf2vf_ver' is never read

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 6738df836a70..b1cc179512fa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -296,7 +296,6 @@ int amdgpu_virt_fw_reserve_get_checksum(void *obj,
 
 void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev)  {
-   uint32_t pf2vf_ver = 0;
uint32_t pf2vf_size = 0;
uint32_t checksum = 0;
uint32_t checkval;
@@ -309,7 +308,6 @@ void amdgpu_virt_init_data_exchange(struct amdgpu_device 
*adev)
adev->virt.fw_reserve.p_pf2vf =
(struct amdgim_pf2vf_info_header *)(
adev->fw_vram_usage.va + AMDGIM_DATAEXCHANGE_OFFSET);
-   pf2vf_ver = adev->virt.fw_reserve.p_pf2vf->version;
AMDGPU_FW_VRAM_PF2VF_READ(adev, header.size, _size);
AMDGPU_FW_VRAM_PF2VF_READ(adev, checksum, );
 
--
2.14.1

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

Re: [PATCH] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Marek Szyprowski]

Hi Inki,

On 2017-11-13 02:24, Inki Dae wrote:

Hi Marek,

2017년 11월 10일 16:35에 Marek Szyprowski 이(가) 쓴 글:

Dear Inki,

On 2017-11-10 04:04, Inki Dae wrote:

2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:

When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
are contiguous, because of the underlying dma_alloc_attrs() function
provides only such buffers. In such case it makes no sense to keep

What if user disabled CMA support? In this case, it guarantees also to allocate 
physically contiguous memory?
I think it depends on CMA support so wouldn't be true.

dma_alloc_attrs() always guarantees the contiguity of the allocated memory
in DMA address space. When NOIOMMU is available, this mean that the allocated
buffer is contiguous in the physical memory. When CMA is disabled,
dma_alloc_attrs() uses alloc_pages() allocator. The drawback of alloc_pages()
is that it easily fails if physical memory is fragmented and it cannot
allocate memory larger than MAX_ORDER (4MiB in case of ARM32bit).

You are right. Without IOMMU suppot alloc_pages always tryies to allocate 
contiguous memory,
order = get_order(size);
page = alloc_pages(..., order);
if (!page)
return NULL;
...


Right


Real problem I think is that user don't know whether the gem buffer allocated 
with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer.
So user can request a page flip with NONCONTIG buffer to kernel which doesn't 
support IOMMU.

And another is that user may want to use NONCONTIG buffer for another purpose, 
not scanout.
So if we enforce on using CONTIG buffer on kernel without IOMMU support, then 
it wouldn't be really what user intended.

When IOMMU support is disabled, ANY buffer allocated with dma_alloc_attrs()
will be contiguous, so I see no point propagating incorrect flag for it.

The only way to create a NONCONTIG buffer with IOMMU disabled is to import
it from other driver and this path is already handled correctly.


My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate 
a buffer with a different allocation type - CONTIG or NONCONTIG - according to 
IOMMU support.
And any page flip request with NONCONTIG buffer to kernel without IOMMU support 
should fail and it has to return a error with a proper error message.

I don't think that we need it. With the proposed patch the same userspace will
work fine in both cases IOMMU enabled and disabled, even if it allocate GEM
with NONCONTIG flag. We can assume that CONTIG is a special case of NONCONTIG
then.

The problem is really not whether user space will work fine or not but is that 
this may be not what user space wanted.
I.e., user space expects the allocated buffer is NONCONTIG buffer because user 
space requested NONCONTIG buffer but kernel internally, this is changed to 
CONTIG buffer.


What's the problem when kernel allocated contiguous buffer but user
requested non-contiguous? Contiguous is a subclass of non-contiguous
in general. There is no driver nor scenario which will not work because
of such change (any code for handing n-segments should be fine with only
1 segment). In some conditions, by luck, kernel might allocate
a contiguous buffer even with IOMMU enabled. When we know that the
buffer is contiguous, then flag it as such.


So you could provide some information - maybe warning message?? - to user space 
the buffer type is changed to CONTIG buffer due to NO IOMMU support.


I don't think this needs a warning. I just think that when we know that
the allocated buffer IS contiguous there is no point flagging it as
non-contiguous and fail a few calls later although the driver allocated
the contiguous buffer in fact. That's all.


Regarding the buffer type Exynos DRM has, I'm not sure that providing CONTIG 
and NONCONTIG buffer types to user space is reasonable because I think such 
buffer types - physically contiguous or non contiguous - should be transparent 
to user space.
And I looked into other ARM DRM drivers - omap and msm provides SCANOUT buffer 
type, tegra and rockchip have no such buffer types (contiguous or 
non-contiguous).

This is also a thing I felt while working on kernel in collaborating with 
Platform guys - we made user spaces to care about the memory allocation way.

I wonder why you say SCANOUT type is incorrect flag.


I'm not against adding SCANOUT flag. It is a good idea in general,
especially if the driver can simply select which set of flags will
be best for such use case on the given hardware (IOMMU is practically
always used on newer Exynos SoCs, IOMMU has enough TLB cache and
handling of non-contiguous buffers is cheap there).

I would only separate it from fixing the current code.

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

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

Re: [PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup

[Daniel Thompson]

On 13/11/17 10:20, Johan Hovold wrote:

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent mfd node was also prematurely freed.

Note that the nodes returned from the two calls to of_parse_phandle()
are also leaking, but fixing that is a bit more involved as pointers to
node fields are being stored for later use.


Is using a devm_kstrdup() to remember the full_name sufficient so get 
each of the FIXMEs cleaned up as well?



Daniel.



Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
Cc: stable  # 3.10
Cc: Guennadi Liakhovetski 
Signed-off-by: Johan Hovold 
---
  drivers/video/backlight/as3711_bl.c | 35 +--
  1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/as3711_bl.c 
b/drivers/video/backlight/as3711_bl.c
index 734a9158946b..21ce56053c88 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -262,15 +262,16 @@ static int as3711_bl_register(struct platform_device 
*pdev,
  static int as3711_backlight_parse_dt(struct device *dev)
  {
struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
-   struct device_node *bl =
-   of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
+   struct device_node *bl, *fb;
int ret;
  
+	bl = of_get_child_by_name(dev->parent->of_node, "backlight");

if (!bl) {
dev_dbg(dev, "backlight node not found\n");
return -ENODEV;
}
  
+	/* FIXME: need to drop reference to returned node */

fb = of_parse_phandle(bl, "su1-dev", 0);
if (fb) {
pdata->su1_fb = fb->full_name;
@@ -279,9 +280,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su1_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
-   return ret;
+   goto err_put_bl;
}
  
+	/* FIXME: need to drop reference to returned node */

fb = of_parse_phandle(bl, "su2-dev", 0);
if (fb) {
int count = 0;
@@ -292,7 +294,7 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su2_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
-   return ret;
+   goto err_put_bl;
  
  		if (of_find_property(bl, "su2-feedback-voltage", NULL)) {

pdata->su2_feedback = AS3711_SU2_VOLTAGE;
@@ -314,8 +316,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
count++;
}
-   if (count != 1)
-   return -EINVAL;
+   if (count != 1) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
  
  		count = 0;

if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
@@ -334,8 +338,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_fbprot = AS3711_SU2_GPIO4;
count++;
}
-   if (count != 1)
-   return -EINVAL;
+   if (count != 1) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
  
  		count = 0;

if (of_find_property(bl, "su2-auto-curr1", NULL)) {
@@ -355,11 +361,20 @@ static int as3711_backlight_parse_dt(struct device *dev)
 * At least one su2-auto-curr* must be specified iff
 * AS3711_SU2_CURR_AUTO is used
 */
-   if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
-   return -EINVAL;
+   if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
}
  
+	of_node_put(bl);

+
return 0;
+
+err_put_bl:
+   of_node_put(bl);
+
+   return ret;
  }
  
  static int as3711_backlight_probe(struct platform_device *pdev)



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

Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values

[Ville Syrjälä]

On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> will automatically calculate the normalized zpos values, but it won't
> currently do so. Modify the atomic helpers to behave as documented.

NAK

See commit  38d868e41c4b ("drm: Don't force all planes to be added to
the state due to zpos")

> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 71d712f1b56a..6c3ceb3a5dc0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -791,6 +791,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> + ret = drm_atomic_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> +
>   ret = drm_atomic_helper_check_planes(dev, state);
>   if (ret)
>   return ret;
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 2/3] backlight: max8925_bl: fix device-tree node lookup

[Daniel Thompson]

On 13/11/17 10:20, Johan Hovold wrote:

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent mfd node was also prematurely freed,
while the child backlight node was leaked.

Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
Cc: stable  # 3.9
Cc: Qing Xu 
Cc: Haojian Zhuang 
Signed-off-by: Johan Hovold 


Acked-by: Daniel Thompson 



---
  drivers/video/backlight/max8925_bl.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/max8925_bl.c 
b/drivers/video/backlight/max8925_bl.c
index 7b738d60ecc2..f3aa6088f1d9 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(struct 
platform_device *pdev)
if (!pdata)
return;
  
-	np = of_find_node_by_name(nproot, "backlight");

+   np = of_get_child_by_name(nproot, "backlight");
if (!np) {
dev_err(>dev, "failed to find backlight node\n");
return;
@@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(struct 
platform_device *pdev)
if (!of_property_read_u32(np, "maxim,max8925-dual-string", ))
pdata->dual_string = val;
  
+	of_node_put(np);

+
pdev->dev.platform_data = pdata;
  }
  


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

Re: [PATCH 3/3] backlight: tps65217_bl: fix device-tree node lookup

[Daniel Thompson]

On 13/11/17 10:20, Johan Hovold wrote:

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

This would only cause trouble if the child node is missing while there
is an unrelated node named "backlight" elsewhere in the tree.

Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
Cc: stable  # 3.7
Cc: Matthias Kaehlcke 
Signed-off-by: Johan Hovold 


Acked-by: Daniel Thompson 



---
  drivers/video/backlight/tps65217_bl.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index 380917c86276..762e3feed097 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -184,11 +184,11 @@ static struct tps65217_bl_pdata *
  tps65217_bl_parse_dt(struct platform_device *pdev)
  {
struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
-   struct device_node *node = of_node_get(tps->dev->of_node);
+   struct device_node *node;
struct tps65217_bl_pdata *pdata, *err;
u32 val;
  
-	node = of_find_node_by_name(node, "backlight");

+   node = of_get_child_by_name(tps->dev->of_node, "backlight");
if (!node)
return ERR_PTR(-ENODEV);
  


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

Re: [PATCH/RFC 0/2] R-Car DU: Support importing non-contiguous dma-buf with VSP

[Kieran Bingham]

Hi Laurent,

On 13/11/17 10:32, Laurent Pinchart wrote:
> Hello everybody,
> 
> This patch series fixes two issues related to dma-buf import for the Renesas
> R-Car DU when the imported buffer is either not physically contiguous or
> located in high memory.
> 
> Both cases require the use of an IOMMU to remap the buffers contiguously and
> in 32-bit DMA space. On Gen2 platforms this is transparent and works already,
> but on Gen3 platforms the situation is more complex.
> 
> The Gen3 DU doesn't perform DMA access directly but instead goes through a VSP
> IP core that acts as an external composer. When importing a dma-buf buffer the
> GEM PRIME helper drm_gem_prime_import() maps the buffer to the DU device, and
> the DU driver later remaps it to the VSP device. The driver unfortunately
> can't use the drm_gem_prime_import_dev() helper to map th buffer to the VSP
> device directly, as at import time we don't know yet to which VSP device the
> buffer will need to be mapped (there is one VSP composer per CRTC). Mapping
> the buffer to the VSP can thus only be done when pinning the framebuffer, as
> we know at that time which plane and CRTC it will be used with.
> 
> This works currently (with the caveat that an unneeded mapping to the DU is
> created), but fails when the imported buffer is not physically contiguous or
> is located in high memory. In the first case the GEM CMA helper
> drm_gem_cma_prime_import_sg_table() will reject the buffer as it hasn't been
> mapped contiguously in the DU DMA address space (because the DU has no IOMMU),
> and in the second case the DMA mapping API will try to allocate a bounce
> buffer and fail due to bounce buffer memory exhaustion.
> 
> The first patch in this series fixes the second issue by setting the DMA
> coherent mask of the DU device to the full 40 bits address space. All memory
> will thus be accepted without trying to allocate a bounce buffer.
> 
> The second patch in this series fixes the first issue by using an internal
> copy of the drm_gem_cma_prime_import_sg_table() function that doesn't ensure
> that the buffer is contiguous in memory. This is what caused me to post this
> series as an RFC, as I'm not very happy with duplication of helper code in the
> driver that could lead to breakages when the GEM CMA helpers are modified. If
> this approach is accepted, I would prefer implementing the code in the GEM CMA
> helpers.
> 
> Another point that bothers me is that buffers can now be imported
> unconditionally on Gen3 platforms, but atomic commits will fail if the buffer
> can't be remapped through the VSP (for instance if no IOMMU is available).
> Given the hardware architecture and the DRM/KMS API I don't really see a way
> around this.
> 
> Testing this series isn't easy as it requires getting hold of exported
> dma-bufs located in high memory or not physically contiguous. I have used the
> V4L2 vivid driver as an exporter for that purpose, with a few hacks that can
> be found at
> 
>   git://linuxtv.org/pinchartl/media.git drm/du/devel/iommu
> 

Ok - testing from this branch with "drm: rcar-du: Allow importing non-contiguous
dma-buf with VSP" applied on top (it appeared to be missing)

> On the userspace side I have used the v4l2-drm-example test application
> available at
> 
>   git://git.infradead.org/users/kmpark/public-apps
> 
> and run with
> 
> dmabuf-sharing -M rcar-du -i /dev/video0 -S 640,480 -f YUYV -F YUYV \
>   -s 640,480@0,0 -t 640,480@0,0 -o 70:68:640x480 -b 4 -e v4l2
> 
> (the -o argument needs to be modified based on the connector and CRTC ID).

I've build dmabuf-sharing from kmpark/public-apps/v4l2-drm-example, but it
doesn't appear to have a "-e v4l2" option (not listed in the -h, and complains
with "ERROR(dmabuf-sharing.c:560) : failed to parse arguments")

Have you also modified this application to run your tests?

If it's easier, I can look at the screen while you run the test under your
control as well.


> Up to patch "[DEBUG] v4l: videobuf2-dma-contig: Print allocated buffer
> address" buffer sharing should work. Patch "[HACK] vivid: Allocate buffers
> from high memory" then breaks buffer import, and the issue is fixed by patch
> "drm: rcar-du: Set the DMA coherent mask for the DU device". Patch "[HACK]
> vivid: Use vmalloc allocator" breaks buffer import again, and is fixed by
> "drm: rcar-du: Allow importing non-contiguous dma-buf with VSP".
> 
> Kieran, I have tested this remotely on your Salvator-X H3 ES1.1 and haven't
> noticed any problem, but couldn't check the output on the screen. Would you be
> able to rerun the test locally for me ? Please note that the IPMMU is known to
> have issues on H3 ES1.1, so you might need to test the code on H3 ES2.0
> instead.
> 
> Laurent Pinchart (2):
>   drm: rcar-du: Set the DMA coherent mask for the DU device
>   drm: rcar-du: Allow importing non-contiguous dma-buf with VSP
> 
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 13 +++-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 

[PATCH] drm/atomic-helper: Calculate normalized zpos values

[Thierry Reding]

From: Thierry Reding 

kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it won't
currently do so. Modify the atomic helpers to behave as documented.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f1b56a..6c3ceb3a5dc0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -791,6 +791,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
 
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
-- 
2.14.1

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

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

Thomas Hellström  changed:

   What|Removed |Added

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

--- Comment #38 from Thomas Hellström  ---
Fix has now been pushed to mesa master.

-- 
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 libdrm 0/4] Dynamicly disable suites and tets.

[Christian König]

Am 13.11.2017 um 12:32 schrieb Michel Dänzer:

On 12/11/17 10:35 AM, Christian König wrote:

A few comments on the code:


+/* Validate bo size is bit bigger then the request domain */
+static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
*adev,
+                      unsigned long size, u32 domain)

Drop the inline keyword and the second _bo_ in the name here.


+{
+    struct ttm_mem_type_manager *man = NULL;
+
+    if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
+        man = >mman.bdev.man[TTM_PL_VRAM];
+
+        if (man && size < (man->size << PAGE_SHIFT))

Drop the extra check that man is not NULL. We get the pointer to an
array element, that can't be NULL.


+            return true;

Mhm, domain is a bitmask of allowed domains.

So we should check all valid domains if the size fit, not just the first
one.

Assuming VRAM <-> system migration of BOs larger than the GTT domain
works, I'd say we should only require that the BO can fit in any of the
allowed domains. Otherwise it must also always fit in GTT.
Good point, and yes VRAM <-> system migration of BOs larger than the GTT 
domain works now.


I can agree on that VRAM should probably be optional, otherwise we can't 
allocate anything large when the driver uses only very low amounts of 
stolen VRAM on APUs.


But I think when userspace requests VRAM and GTT at the same time we 
still should be able to fall back to GTT.


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

[PATCH 4.9 80/87] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c upstream.

Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls instead of duplciating
logic.

This does change behavior slightly as it adds the HPD signal
pulse to the EDID probe path, but Archit has had a patch to
add HPD signal pulse to the EDID probe path before, so this
should address the cases where that helped. Another difference
is that regcache_mark_dirty() is also called in the power off
path once EDID is probed.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-6-git-send-email-john.stu...@linaro.org
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |   17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -573,24 +573,13 @@ static int adv7511_get_modes(struct adv7
unsigned int count;
 
/* Reading the EDID only works if the device is powered */
-   if (!adv7511->powered) {
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN, 0);
-   if (adv7511->i2c_main->irq) {
-   regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
-ADV7511_INT0_EDID_READY);
-   regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
-ADV7511_INT1_DDC_ERROR);
-   }
-   adv7511->current_edid_segment = -1;
-   }
+   if (!adv7511->powered)
+   __adv7511_power_on(adv7511);
 
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
 
if (!adv7511->powered)
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN,
-  ADV7511_POWER_POWER_DOWN);
+   __adv7511_power_off(adv7511);
 
kfree(adv7511->edid);
adv7511->edid = edid;


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

[PATCH 4.9 81/87] drm/bridge: adv7511: Re-write the i2c address before EDID probing

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.

I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
HiKey.

Investigating further, it turns out that some of the register
state in hardware is getting lost, as the device registers are
reset when the chip is powered down.

Thus this patch simply re-writes the i2c address to the
ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set
before we try to read the EDID data.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-email-john.stu...@linaro.org
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -573,9 +573,17 @@ static int adv7511_get_modes(struct adv7
unsigned int count;
 
/* Reading the EDID only works if the device is powered */
-   if (!adv7511->powered)
+   if (!adv7511->powered) {
+   unsigned int edid_i2c_addr =
+   (adv7511->i2c_main->addr << 1) + 4;
+
__adv7511_power_on(adv7511);
 
+   /* Reset the EDID_I2C_ADDR register as it might be cleared */
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+edid_i2c_addr);
+   }
+
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
 
if (!adv7511->powered)


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

[PATCH 4.9 79/87] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 

commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream.

In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.

This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-email-john.stu...@linaro.org
Signed-off-by: Nhan Nguyen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -325,7 +325,7 @@ static void adv7511_set_link_config(stru
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
 }
 
-static void adv7511_power_on(struct adv7511 *adv7511)
+static void __adv7511_power_on(struct adv7511 *adv7511)
 {
adv7511->current_edid_segment = -1;
 
@@ -354,6 +354,11 @@ static void adv7511_power_on(struct adv7
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
   ADV7511_REG_POWER2_HPD_SRC_MASK,
   ADV7511_REG_POWER2_HPD_SRC_NONE);
+}
+
+static void adv7511_power_on(struct adv7511 *adv7511)
+{
+   __adv7511_power_on(adv7511);
 
/*
 * Most of the registers are reset during power down or when HPD is low.
@@ -362,21 +367,23 @@ static void adv7511_power_on(struct adv7
 
if (adv7511->type == ADV7533)
adv7533_dsi_power_on(adv7511);
-
adv7511->powered = true;
 }
 
-static void adv7511_power_off(struct adv7511 *adv7511)
+static void __adv7511_power_off(struct adv7511 *adv7511)
 {
/* TODO: setup additional power down modes */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
   ADV7511_POWER_POWER_DOWN,
   ADV7511_POWER_POWER_DOWN);
regcache_mark_dirty(adv7511->regmap);
+}
 
+static void adv7511_power_off(struct adv7511 *adv7511)
+{
+   __adv7511_power_off(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_off(adv7511);
-
adv7511->powered = false;
 }
 


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

[PATCH] drm/tilcdc: Remove obsolete "ti, tilcdc, slave" dts binding support

[Jyri Sarha]

This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the
obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based
binding - that is widely used in other drm driver too - has been
supported since Linux v4.2. Maintaining the the backwards dts
conversion code in 0the DRM_TILCDC_SLAVE_COMPAT has become a nuisance
for the device/of development so the we decided to drop it after Linux
v4.14, the 2017 LTS.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/Kconfig |  11 -
 drivers/gpu/drm/tilcdc/Makefile|   3 -
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 269 -
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 ---
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h   |  25 ---
 5 files changed, 380 deletions(-)
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 28fed7e..81ac824 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -12,14 +12,3 @@ config DRM_TILCDC
  controller, for example AM33xx in beagle-bone, DA8xx, or
  OMAP-L1xx.  This driver replaces the FB_DA8XX fbdev driver.
 
-config DRM_TILCDC_SLAVE_COMPAT
-   bool "Support device tree blobs using TI LCDC Slave binding"
-   depends on DRM_TILCDC
-   default y
-   select OF_RESOLVE
-   select OF_OVERLAY
-   help
- Choose this option if you need a kernel that is compatible
- with device tree blobs using the obsolete "ti,tilcdc,slave"
- binding. If you find "ti,tilcdc,slave"-string from your DTB,
- you probably need this. Otherwise you do not.
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 55ebd51..efc2c4f 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -2,9 +2,6 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
 endif
 
-obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \
-tilcdc_slave_compat.dtb.o
-
 tilcdc-y := \
tilcdc_plane.o \
tilcdc_crtc.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
deleted file mode 100644
index 482299a..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ /dev/null
@@ -1,269 +0,0 @@
-/*
- * Copyright (C) 2015 Texas Instruments
- * Author: Jyri Sarha 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- */
-
-/*
- * To support the old "ti,tilcdc,slave" binding the binding has to be
- * transformed to the new external encoder binding.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "tilcdc_slave_compat.h"
-
-struct kfree_table {
-   int total;
-   int num;
-   void **table;
-};
-
-static int __init kfree_table_init(struct kfree_table *kft)
-{
-   kft->total = 32;
-   kft->num = 0;
-   kft->table = kmalloc(kft->total * sizeof(*kft->table),
-GFP_KERNEL);
-   if (!kft->table)
-   return -ENOMEM;
-
-   return 0;
-}
-
-static int __init kfree_table_add(struct kfree_table *kft, void *p)
-{
-   if (kft->num == kft->total) {
-   void **old = kft->table;
-
-   kft->total *= 2;
-   kft->table = krealloc(old, kft->total * sizeof(*kft->table),
- GFP_KERNEL);
-   if (!kft->table) {
-   kft->table = old;
-   kfree(p);
-   return -ENOMEM;
-   }
-   }
-   kft->table[kft->num++] = p;
-   return 0;
-}
-
-static void __init kfree_table_free(struct kfree_table *kft)
-{
-   int i;
-
-   for (i = 0; i < kft->num; i++)
-   kfree(kft->table[i]);
-
-   kfree(kft->table);
-}
-
-static
-struct property * __init tilcdc_prop_dup(const struct property *prop,
-struct kfree_table *kft)
-{
-   struct property *nprop;
-
-   nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
-   if (!nprop || kfree_table_add(kft, nprop))
-   return NULL;
-
-   nprop->name = kstrdup(prop->name, GFP_KERNEL);
-   if (!nprop->name || kfree_table_add(kft, nprop->name))
-   return NULL;
-
-   nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL);
-   if (!nprop->value || kfree_table_add(kft, nprop->value))
-   return NULL;
-
-   nprop->length = prop->length;
-
-   return nprop;
-}
-
-static void __init tilcdc_copy_props(struct device_node *from,
-  

Re: [PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

[Liviu Dudau]

On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote:
> When the DU sources its frames from a VSP, it performs no memory access
> and thus has no requirements on imported dma-buf memory types. In
> particular the DU could import a physically non-contiguous buffer that
> would later be mapped contiguously through the VSP IOMMU.
> 
> This use case isn't supported at the moment as the GEM CMA helpers will
> reject any non-contiguous buffer, and the DU isn't connected to an IOMMU
> that can make the buffer contiguous for DMA. Fix this by implementing a
> custom .gem_prime_import_sg_table() operation that accepts all imported
> dma-buf regardless of the number of scatterlist entries.

This patch raises the question of why use CMA at all if you can accept
any kind of buffers.

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 
> +++
>  drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
>  3 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 48c166f925a3..d999231f98c7 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = {
>   .gem_prime_import   = drm_gem_prime_import,
>   .gem_prime_export   = drm_gem_prime_export,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> + .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
>   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 566d1a948c8f..2dd0c2ba047d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -148,6 +149,44 @@ const struct rcar_du_format_info 
> *rcar_du_format_info(u32 fourcc)
>   * Frame buffer
>   */
>  
> +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device 
> *dev,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sgt)
> +{
> + struct rcar_du_device *rcdu = dev->dev_private;
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *gem_obj;
> + int ret;
> +
> + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
> + return drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> +
> + /* Create a CMA GEM buffer. */
> + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> + if (!cma_obj)
> + return ERR_PTR(-ENOMEM);
> + gem_obj = _obj->base;
> +
> + ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size);
> + if (ret)
> + goto error;
> +
> + ret = drm_gem_create_mmap_offset(gem_obj);
> + if (ret) {
> + drm_gem_object_release(gem_obj);
> + goto error;
> + }
> +
> + cma_obj->paddr = 0;

This is going to break drm_gem_cma_describe() if you are using it plus
the rcar_du_plane_setup_scanout() unless I'm missing something besides
familiarity with the RCAR driver code :)

This function looks very similar to what I tried to do for mali-dp to
allow the import of contiguous DMA buffers that have more than 1 sgt
entries. In the end I gave up as I kept finding issues and went for the
drm_gem_cma_prime_import_sg_table() changes. Maybe you need to do a
similar change in the function to bypass some requirements if the driver
signals that it can accept relaxed requirements?

Best regards,
Liviu

> + cma_obj->sgt = sgt;
> +
> + return gem_obj;
> +
> +error:
> + kfree(cma_obj);
> + return ERR_PTR(ret);
> +}
> +
>  int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
>   struct drm_mode_create_dumb *args)
>  {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
> index 07951d5fe38b..10b2bb0f0df9 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
> @@ -16,10 +16,13 @@
>  
>  #include 
>  
> +struct dma_buf_attachment;
>  struct drm_file;
>  struct drm_device;
> +struct drm_gem_object;
>  struct drm_mode_create_dumb;
>  struct rcar_du_device;
> +struct sg_table;
>  
>  struct rcar_du_format_info {
>   u32 fourcc;
> @@ -36,4 +39,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu);
>  int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
>   struct drm_mode_create_dumb *args);
>  
> +struct 

[Bug 103443] [CI] igt@kms_setmode@[clone-exclusive-crtc | invalid-clone-exclusive-crtc] - warn - no modes for connector 76

[bugzilla-daemon]

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

--- Comment #3 from Marta Löfstedt  ---
here also:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3331/shard-glkb2/i...@testdisplay.html

-- 
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 103443] [CI] igt@kms_setmode@[clone-exclusive-crtc | invalid-clone-exclusive-crtc] - warn - no modes for connector 76

[bugzilla-daemon]

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

--- Comment #2 from Marta Löfstedt  ---
Here is another test that produce WARN only where there a no modes available

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3335/shard-glkb2/igt@kms_sysfs_edid_timing.html

-- 
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/RFC 1/2] drm: rcar-du: Set the DMA coherent mask for the DU device

[Liviu Dudau]

On Mon, Nov 13, 2017 at 12:32:27PM +0200, Laurent Pinchart wrote:
> The DU DMA address space is limited to 32 bits, so the DMA coherent mask
> should be set accordingly. The DMA mapping implementation will
> transparently map high memory buffers to 32-bit addresses through an
> IOMMU when present (or through bounce buffers otherwise, which isn't a
> supported use case as performances would be terrible).
> 
> However, when sourcing frames from a VSP, the situation is more
> complicated. The DU delegates all memory accesses to the VSP and doesn't
> perform any DMA access by itself. Due to how the GEM CMA helpers are
> structured buffers are still mapped to the DU device. They are later
> mapped to the VSP as well to perform DMA access, through the IOMMU
> connected to the VSP.
> 
> Setting the DMA coherent mask to 32 bits for the DU when using a VSP can
> cause issues when importing a dma_buf. If the buffer is located above
> the 32-bit address space, the DMA mapping implementation will try to map
> it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer
> will be allocated, which in the best case will waste memory and in the
> worst case will just fail.
> 
> To work around this issue, set the DMA coherent mask to the full 40-bit
> address space for the DU. All dma-buf instances will be imported without
> any restriction, and will be mapped to the VSP when preparing the
> associated framebuffer.

This does indeed look like a work around, but I can't see anything wrong
with it.

Reviewed-by: Liviu Dudau 

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 6e02c762a557..48c166f925a3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -370,6 +370,7 @@ static int rcar_du_probe(struct platform_device *pdev)
>   struct rcar_du_device *rcdu;
>   struct drm_device *ddev;
>   struct resource *mem;
> + unsigned int mask;
>   int ret;
>  
>   /* Allocate and initialize the R-Car device structure. */
> @@ -388,6 +389,16 @@ static int rcar_du_probe(struct platform_device *pdev)
>   if (IS_ERR(rcdu->mmio))
>   return PTR_ERR(rcdu->mmio);
>  
> + /*
> +  * Set the DMA coherent mask to reflect the DU 32-bit DMA address space
> +  * limitations. When sourcing frames from a VSP the DU doesn't perform
> +  * any memory access so set the mask to 40 bits to accept all buffers.
> +  */
> + mask = rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE) ? 40 : 32;
> + ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(mask));
> + if (ret)
> + return ret;
> +
>   /* DRM/KMS objects */
>   ddev = drm_dev_alloc(_du_driver, >dev);
>   if (IS_ERR(ddev))
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Michel Dänzer]

On 12/11/17 10:35 AM, Christian König wrote:
> A few comments on the code:
> 
>> +/* Validate bo size is bit bigger then the request domain */
>> +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
>> *adev,
>> +                      unsigned long size, u32 domain)
> Drop the inline keyword and the second _bo_ in the name here.
> 
>> +{
>> +    struct ttm_mem_type_manager *man = NULL;
>> +
>> +    if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
>> +        man = >mman.bdev.man[TTM_PL_VRAM];
>> +
>> +        if (man && size < (man->size << PAGE_SHIFT))
> 
> Drop the extra check that man is not NULL. We get the pointer to an
> array element, that can't be NULL.
> 
>> +            return true;
> Mhm, domain is a bitmask of allowed domains.
> 
> So we should check all valid domains if the size fit, not just the first
> one.

Assuming VRAM <-> system migration of BOs larger than the GTT domain
works, I'd say we should only require that the BO can fit in any of the
allowed domains. Otherwise it must also always fit in GTT.


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

Re: [PATCH] drm/stm: ltdc: add clut mode support

[Philippe CORNU]

Hi Peter,

On 11/12/2017 01:31 PM, Peter Rosin wrote:
> On 2017-11-10 17:12, Philippe CORNU wrote:
>> Hi Peter,
>>
>> On 11/07/2017 05:34 PM, Peter Rosin wrote:
>>> On 2017-11-07 16:53, Philippe CORNU wrote:
 + Peter

 Hi Peter,

 CLUT support on STM32 has been removed thanks to your clean up patch
>>>
>>> Support is a bit strong for what I thought was a dead function, or
>>> are you saying that it used to work before my series? Really sorry
>>> if that is the case!
>>
>> As I wrote in the previous related thread
>> (https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html),
>> STM32 chipsets supports 8-bit CLUT mode but this driver version does not
>> support it "yet"...
>>
>> So, no worry regarding your clean up, I gave you an "acked-by" for that : )
> 
> Ok, good. Thanks for clearing that up!
> 
>>>
>>> Anyway, the function I removed seemed to indicate that the hardware
>>> could handle a separate clut for each layer, but your new version
>>> does not. Why is that?
>>
>> Yes I confirm the clut support is available for each layer... but I
>> thought the gamma_lut was only at the crtc level, not at layer level...
>> Maybe I am wrong.
>> Moreover, small test applications I used play only with clut at crtc
>> level...
>>
>> Anyway, could you please help me to "find" a per-layer clut
>> implementation because when I read "crtc->state->gamma_lut->data" it
>> looks like gamma_lut is per crtc, not per plane...? or maybe I have to
>> add extra properties for that...
> 
> I wasn't clear enough. Yes, there is to my knowledge only one clut,
> not one per plane. What I noticed was that the function I removed
> seemed to touch clut registers for multiple layers, but your new
> function appears to only touch registers for one layer. So, I
> wondered if the "one and only" clut needed to be copied to the
> registers for the other layers, or if the old dead code was simply
> confused. Clearer?
> 

The old code was a generic helper function (ie. for all layers) but used 
only for the 1st layer. So, we could say that "old dead code was simply 
confused" :-)

When I put back the clut support in this patch, I decided to update only 
the 1st layer (because there is no API for handling it on other layers). 
I also decided to not re-use the former generic helper function as the 
update loop is pretty small.

This patch offers the clut mode feature for fbdev (only one plane in 
fbdev) and for drm (single plane for many use cases, 2nd plane being 
used mostly for video...)

If tomorrow the API offers clut support per plane, the update loop will 
be moved to the plane update function, means the generic helper function 
will not be require anymore too.

Many thanks
Philippe :)

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

[PATCH/RFC 1/2] drm: rcar-du: Set the DMA coherent mask for the DU device

[Laurent Pinchart]

The DU DMA address space is limited to 32 bits, so the DMA coherent mask
should be set accordingly. The DMA mapping implementation will
transparently map high memory buffers to 32-bit addresses through an
IOMMU when present (or through bounce buffers otherwise, which isn't a
supported use case as performances would be terrible).

However, when sourcing frames from a VSP, the situation is more
complicated. The DU delegates all memory accesses to the VSP and doesn't
perform any DMA access by itself. Due to how the GEM CMA helpers are
structured buffers are still mapped to the DU device. They are later
mapped to the VSP as well to perform DMA access, through the IOMMU
connected to the VSP.

Setting the DMA coherent mask to 32 bits for the DU when using a VSP can
cause issues when importing a dma_buf. If the buffer is located above
the 32-bit address space, the DMA mapping implementation will try to map
it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer
will be allocated, which in the best case will waste memory and in the
worst case will just fail.

To work around this issue, set the DMA coherent mask to the full 40-bit
address space for the DU. All dma-buf instances will be imported without
any restriction, and will be mapped to the VSP when preparing the
associated framebuffer.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..48c166f925a3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -370,6 +370,7 @@ static int rcar_du_probe(struct platform_device *pdev)
struct rcar_du_device *rcdu;
struct drm_device *ddev;
struct resource *mem;
+   unsigned int mask;
int ret;
 
/* Allocate and initialize the R-Car device structure. */
@@ -388,6 +389,16 @@ static int rcar_du_probe(struct platform_device *pdev)
if (IS_ERR(rcdu->mmio))
return PTR_ERR(rcdu->mmio);
 
+   /*
+* Set the DMA coherent mask to reflect the DU 32-bit DMA address space
+* limitations. When sourcing frames from a VSP the DU doesn't perform
+* any memory access so set the mask to 40 bits to accept all buffers.
+*/
+   mask = rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE) ? 40 : 32;
+   ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(mask));
+   if (ret)
+   return ret;
+
/* DRM/KMS objects */
ddev = drm_dev_alloc(_du_driver, >dev);
if (IS_ERR(ddev))
-- 
Regards,

Laurent Pinchart

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

[PATCH/RFC 0/2] R-Car DU: Support importing non-contiguous dma-buf with VSP

[Laurent Pinchart]

Hello everybody,

This patch series fixes two issues related to dma-buf import for the Renesas
R-Car DU when the imported buffer is either not physically contiguous or
located in high memory.

Both cases require the use of an IOMMU to remap the buffers contiguously and
in 32-bit DMA space. On Gen2 platforms this is transparent and works already,
but on Gen3 platforms the situation is more complex.

The Gen3 DU doesn't perform DMA access directly but instead goes through a VSP
IP core that acts as an external composer. When importing a dma-buf buffer the
GEM PRIME helper drm_gem_prime_import() maps the buffer to the DU device, and
the DU driver later remaps it to the VSP device. The driver unfortunately
can't use the drm_gem_prime_import_dev() helper to map th buffer to the VSP
device directly, as at import time we don't know yet to which VSP device the
buffer will need to be mapped (there is one VSP composer per CRTC). Mapping
the buffer to the VSP can thus only be done when pinning the framebuffer, as
we know at that time which plane and CRTC it will be used with.

This works currently (with the caveat that an unneeded mapping to the DU is
created), but fails when the imported buffer is not physically contiguous or
is located in high memory. In the first case the GEM CMA helper
drm_gem_cma_prime_import_sg_table() will reject the buffer as it hasn't been
mapped contiguously in the DU DMA address space (because the DU has no IOMMU),
and in the second case the DMA mapping API will try to allocate a bounce
buffer and fail due to bounce buffer memory exhaustion.

The first patch in this series fixes the second issue by setting the DMA
coherent mask of the DU device to the full 40 bits address space. All memory
will thus be accepted without trying to allocate a bounce buffer.

The second patch in this series fixes the first issue by using an internal
copy of the drm_gem_cma_prime_import_sg_table() function that doesn't ensure
that the buffer is contiguous in memory. This is what caused me to post this
series as an RFC, as I'm not very happy with duplication of helper code in the
driver that could lead to breakages when the GEM CMA helpers are modified. If
this approach is accepted, I would prefer implementing the code in the GEM CMA
helpers.

Another point that bothers me is that buffers can now be imported
unconditionally on Gen3 platforms, but atomic commits will fail if the buffer
can't be remapped through the VSP (for instance if no IOMMU is available).
Given the hardware architecture and the DRM/KMS API I don't really see a way
around this.

Testing this series isn't easy as it requires getting hold of exported
dma-bufs located in high memory or not physically contiguous. I have used the
V4L2 vivid driver as an exporter for that purpose, with a few hacks that can
be found at

git://linuxtv.org/pinchartl/media.git drm/du/devel/iommu

On the userspace side I have used the v4l2-drm-example test application
available at

git://git.infradead.org/users/kmpark/public-apps

and run with

dmabuf-sharing -M rcar-du -i /dev/video0 -S 640,480 -f YUYV -F YUYV \
-s 640,480@0,0 -t 640,480@0,0 -o 70:68:640x480 -b 4 -e v4l2

(the -o argument needs to be modified based on the connector and CRTC ID).

Up to patch "[DEBUG] v4l: videobuf2-dma-contig: Print allocated buffer
address" buffer sharing should work. Patch "[HACK] vivid: Allocate buffers
from high memory" then breaks buffer import, and the issue is fixed by patch
"drm: rcar-du: Set the DMA coherent mask for the DU device". Patch "[HACK]
vivid: Use vmalloc allocator" breaks buffer import again, and is fixed by
"drm: rcar-du: Allow importing non-contiguous dma-buf with VSP".

Kieran, I have tested this remotely on your Salvator-X H3 ES1.1 and haven't
noticed any problem, but couldn't check the output on the screen. Would you be
able to rerun the test locally for me ? Please note that the IPMMU is known to
have issues on H3 ES1.1, so you might need to test the code on H3 ES2.0
instead.

Laurent Pinchart (2):
  drm: rcar-du: Set the DMA coherent mask for the DU device
  drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 13 +++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
 3 files changed, 58 insertions(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

[Laurent Pinchart]

When the DU sources its frames from a VSP, it performs no memory access
and thus has no requirements on imported dma-buf memory types. In
particular the DU could import a physically non-contiguous buffer that
would later be mapped contiguously through the VSP IOMMU.

This use case isn't supported at the moment as the GEM CMA helpers will
reject any non-contiguous buffer, and the DU isn't connected to an IOMMU
that can make the buffer contiguous for DMA. Fix this by implementing a
custom .gem_prime_import_sg_table() operation that accepts all imported
dma-buf regardless of the number of scatterlist entries.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.h |  7 +++
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 48c166f925a3..d999231f98c7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = {
.gem_prime_import   = drm_gem_prime_import,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+   .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..2dd0c2ba047d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -148,6 +149,44 @@ const struct rcar_du_format_info *rcar_du_format_info(u32 
fourcc)
  * Frame buffer
  */
 
+struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device 
*dev,
+   struct dma_buf_attachment *attach,
+   struct sg_table *sgt)
+{
+   struct rcar_du_device *rcdu = dev->dev_private;
+   struct drm_gem_cma_object *cma_obj;
+   struct drm_gem_object *gem_obj;
+   int ret;
+
+   if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
+   return drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
+
+   /* Create a CMA GEM buffer. */
+   cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
+   if (!cma_obj)
+   return ERR_PTR(-ENOMEM);
+   gem_obj = _obj->base;
+
+   ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size);
+   if (ret)
+   goto error;
+
+   ret = drm_gem_create_mmap_offset(gem_obj);
+   if (ret) {
+   drm_gem_object_release(gem_obj);
+   goto error;
+   }
+
+   cma_obj->paddr = 0;
+   cma_obj->sgt = sgt;
+
+   return gem_obj;
+
+error:
+   kfree(cma_obj);
+   return ERR_PTR(ret);
+}
+
 int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
 {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
index 07951d5fe38b..10b2bb0f0df9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
@@ -16,10 +16,13 @@
 
 #include 
 
+struct dma_buf_attachment;
 struct drm_file;
 struct drm_device;
+struct drm_gem_object;
 struct drm_mode_create_dumb;
 struct rcar_du_device;
+struct sg_table;
 
 struct rcar_du_format_info {
u32 fourcc;
@@ -36,4 +39,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu);
 int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
 
+struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device 
*dev,
+   struct dma_buf_attachment *attach,
+   struct sg_table *sgt);
+
 #endif /* __RCAR_DU_KMS_H__ */
-- 
Regards,

Laurent Pinchart

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

Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties

[Daniel Stone]

Hi Uma,

On 10 November 2017 at 08:37, Shankar, Uma  wrote:
>>This is missing documentation on how plane colour management interacts with
>>CRTC colour management. Is it a step before CRTC colour management is
>>applied, or does it bypass CRTC colour management, or ... ?
>>
>
> We can have color correction at 2 places in the Display hardware pipeline
> 1. At plane level (before blending)
> 2. At pipe level (after blending)
>
> Both can be used and function independently of each other. Typical use case 
> can be:
>
> 2 Layers planes/overlays with different color space and formats. These can be 
> converted to one
> common color space using the plane level color correction, then blended 
> together. If needed
> pipe color correction can be applied on the blended output (based on use case 
> and scenarios)

This is roughly what I'd expected, but I don't believe the same to be
true of all hardware, and it would certainly need to be documented.
Thanks for the explanation!

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

[PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Mark Yao]

For personal reasons, Mark Yao will leave rockchip,
can not continue maintain drm/rockchip, Sandy Huang
will take over the drm/rockchip.

Cc: Sandy Huang 
Cc: Heiko Stuebner 

Signed-off-by: Mark Yao 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..31bf080 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4627,7 +4627,7 @@ F:
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-M: Mark Yao 
+M: Sandy Huang 
 L: dri-devel@lists.freedesktop.org
 S: Maintained
 F: drivers/gpu/drm/rockchip/
-- 
2.7.4


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