Re: [PATCH 3/5] drm/vblank: Do not update vblank count if interrupts are already disabled.

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:05PM +, Dhinakaran Pandiyan wrote:
> Updating vblank counts requires register reads and these reads may not
> return meaningful values if the device was in a low power state after
> vblank interrupts were last disabled. So, update the count only if vblank
> interrupts are enabled. Secondly, this means the registers should be read
> before disabling vblank interrupts.
> 
> v2: Don't check vblank->enabled outside it's lock (Chris)
> 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index f2bf1f5dbaa5..2559d2d7b907 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -347,23 +347,25 @@ void drm_vblank_disable_and_save(struct drm_device 
> *dev, unsigned int pipe)
>   spin_lock_irqsave(>vblank_time_lock, irqflags);
>  
>   /*
> -  * Only disable vblank interrupts if they're enabled. This avoids
> -  * calling the ->disable_vblank() operation in atomic context with the
> -  * hardware potentially runtime suspended.
> +  * Update vblank count and disable vblank interrupts only if the
> +  * interrupts were enabled. This avoids calling the ->disable_vblank()
> +  * operation in atomic context with the hardware potentially runtime
> +  * suspended.
>*/
> - if (vblank->enabled) {
> - __disable_vblank(dev, pipe);
> - vblank->enabled = false;
> - }
> + if (!vblank->enabled)
> + goto out;
>  
>   /*
> -  * Always update the count and timestamp to maintain the
> +  * Update the count and timestamp to maintain the
>* appearance that the counter has been ticking all along until
>* this time. This makes the count account for the entire time
>* between drm_crtc_vblank_on() and drm_crtc_vblank_off().
>*/

I feel that this entire comment can be simply removed now...
The approach looks good and right to me so you can use

Reviewed-by: Rodrigo Vivi 

but please ping Ville to take a look here since he introduced this approach with
4dfd64862ff8 ("drm: Use vblank timestamps to guesstimate how many vblanks were 
missed")

>   drm_update_vblank_count(dev, pipe, false);
> + __disable_vblank(dev, pipe);
> + vblank->enabled = false;
>  
> +out:
>   spin_unlock_irqrestore(>vblank_time_lock, irqflags);
>  }
>  
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:04PM +, Dhinakaran Pandiyan wrote:
> Now that drm_vblank_count() returns all bits of the vblank count, update
> drm_crtc_arm_vblank_event() so that it queues the correct sequence.
> Otherwise, this leads to prolonged waits for a vblank sequence when the
> current count is >=2^32.

This could be probably squashed to the previous patch...
Specially if you apply the Fixes tag.

Anyways, in case you decide to go with 2 patches:

Reviewed-by: Rodrigo Vivi 

> 
> Cc: Keith Packard 
> Cc: Michel Dänzer 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 4 ++--
>  include/drm/drm_vblank.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 768a8e44d99b..f2bf1f5dbaa5 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -292,11 +292,11 @@ static u64 drm_vblank_count(struct drm_device *dev, 
> unsigned int pipe)
>   * This is mostly useful for hardware that can obtain the scanout position, 
> but
>   * doesn't have a hardware frame counter.
>   */
> -u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
> +u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
>   unsigned int pipe = drm_crtc_index(crtc);
> - u32 vblank;
> + u64 vblank;
>   unsigned long flags;
>  
>   WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 848b463a0af5..a4c3b0a0a197 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -179,7 +179,7 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
>  void drm_crtc_vblank_off(struct drm_crtc *crtc);
>  void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  void drm_crtc_vblank_on(struct drm_crtc *crtc);
> -u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
> +u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
>  
>  bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
>  unsigned int pipe, int *max_error,
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:03PM +, Dhinakaran Pandiyan wrote:
> drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> space requested vblank sequence using this clipped 32-bit count(when the
> value is >= 2^32) as reference, the requested sequence remains a 32-bit
> value and gets queued like that. However, the code that checks if the
> requested sequence has passed compares this against the 64-bit vblank
> count.

Worth to mention and probably
Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")

btw, I spotted at least one more place even with the series applied.
32 current_vblank; at drm_mode_page_flip_ioctl...

so, probably worth to do a deeper check down to all paths...

anayway, for this patch:
Reviewed-by: Rodrigo Vivi 

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

Re: [PATCH 5/5] drm/i915: Estimate and update missed vblanks.

[Rodrigo Vivi]

On Fri, Jan 12, 2018 at 09:57:07PM +, Dhinakaran Pandiyan wrote:
> The frame counter may have got reset between disabling and enabling vblank
> interrupts due to DMC putting the hardware to DC5/6 state if PSR was
> active. The frame counter also could have stalled if PSR is active in cases
> where there is no DMC. The frame counter resetting as a user visible impact
> of screen freezes. Use drm_vblank_restore() to compute missed vblanks
> in the duration for which vblank interrupts are disabled. There's no need
> particularly check if PSR was active in the interrupt disabled duration.
> 
> Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
> from going back again as long as the there are pending interrupts. So, we
> don't have to explicity disallow DC5/6 after enabling vblank interrupts
> to keep the counter running.
> 
> Let's not apply this to CHV for now, as enabling interrupts does not
> prevent the hardware from activating PSR and thereby stalling the counter.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 3517c6548e2c..db3466ec6faa 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2956,6 +2956,9 @@ static int ironlake_enable_vblank(struct drm_device 
> *dev, unsigned int pipe)
>   ilk_enable_display_irq(dev_priv, bit);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
> + if (HAS_PSR(dev_priv))
> + drm_vblank_restore(dev, pipe);
> +

I don't believe we need this one here.

pre-gen9 platform has psr but not dmc, so the case
where we need to restore the counter doesn't exist.

>   return 0;
>  }
>  
> @@ -2968,6 +2971,9 @@ static int gen8_enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
>   bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  
> + if (HAS_PSR(dev_priv))

HAS_PSR(dev_priv) && HAS_CSR(dev_priv)
maybe?
So it gets clear that it is not because PSR that we need to restore
the counter, but also don't do it when not needed.

> + drm_vblank_restore(dev, pipe);
> +
>   return 0;
>  }
>  
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198513] [DRM] amdgpu fails to load firmware on boot

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
The firmware is not available for some reason.  Depending on how you've
configured your kernel, make sure the firmware is either:
1. included in the initrd if you are using one
or
2. built into the kernel if the driver is built into the kernel

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

[git pull] drm fixes for 4.15 final

[Dave Airlie]

Hi Linus,

This is a set of drm regression fixes that I'd like to get into 4.15
final, but I understand if it's too much too late, and am happy to
drop these into -next and make people chase the stable monkey.

The i915 change fixes a display corruption problem introduced in 4.15,
the nouveau changes are for regressions in 4.15, one of the vmwgfx
fixes goes back a little further, the other is a 4.15 regression fix,
the 3 sun4i changes fix blank HDMI output on those devices.

Again happy if you don't take these, just let me know, I suspect 4.15
will have a lot of stable backports for security things over time!

Thanks,
Dave.


The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da:

  Linux 4.15-rc8 (2018-01-14 15:32:30 -0800)

are available in the git repository at:

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

for you to fetch changes up to 04cef3eadcf0bf9783a985286cc5f48c5d33fd7a:

  Merge tag 'drm-intel-fixes-2018-01-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-01-19
12:40:07 +1000)


nouveau, i915, vmwgfx and sun4i regression fixes


Ben Skeggs (1):
  drm/nouveau/mmu/mcp77: fix regressions in stolen memory handling

Dave Airlie (4):
  Merge branch 'vmwgfx-fixes-4.15' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2018-01-17' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-01-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Jon Hunter (1):
  drm/nouveau/bar/gk20a: Avoid bar teardown during init

Jonathan Liu (3):
  drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
  drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
  drm/sun4i: hdmi: Add missing rate halving check in
sun4i_tmds_determine_rate

Rob Clark (1):
  drm/vmwgfx: fix memory corruption with legacy/sou connectors

Thierry Reding (1):
  drm/nouveau/drm/nouveau: Pass the proper arguments to
nvif_object_map_handle()

Ville Syrjälä (3):
  drm/i915: Add .get_hw_state() method for planes
  drm/i915: Redo plane sanitation during readout
  drm/i915: Fix deadlock in i830_disable_pipe()

Woody Suwalski (1):
  drm/vmwgfx: Fix a boot time warning

 drivers/gpu/drm/i915/intel_display.c   | 303 +++--
 drivers/gpu/drm/i915/intel_drv.h   |   2 +
 drivers/gpu/drm/i915/intel_sprite.c|  83 ++
 drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h  |   1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c   |   4 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |   4 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c |   3 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c|   1 -
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/Kbuild |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mcp77.c|  41 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h  |  10 +
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmmcp77.c |  45 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv50.c  |  16 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c|   9 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |   4 +-
 17 files changed, 367 insertions(+), 167 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/mcp77.c
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmmcp77.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: fix missing parameter change for ttm_bo_cleanup_refs

[Roger He]

Missed in the patche:
dc94777 drm/ttm: enable swapout for reserved BOs during allocation.
don't unreserve the BO if it is not reserved by itself.

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 893003f..2fef09a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1727,7 +1727,7 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct 
ttm_operation_ctx *ctx)
kref_get(>list_kref);
 
if (!list_empty(>ddestroy)) {
-   ret = ttm_bo_cleanup_refs(bo, false, false, true);
+   ret = ttm_bo_cleanup_refs(bo, false, false, locked);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
}
-- 
2.7.4

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

Re: [PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

On 1/18/2018 9:34 PM, Ville Syrjälä wrote:

On Thu, Jan 18, 2018 at 09:11:19PM +0530, ankit.k.nauti...@intel.com wrote:

Hi Marteen,

Thanks for the review comments. Please find my comments in-line.


On Thursday 18 January 2018 03:46 PM, Maarten Lankhorst wrote:

Op 12-01-18 om 07:21 schreef Nautiyal, Ankit K:

From: Ankit Nautiyal 

A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

What's missing from the commit message is why this needs to be a flag that 
userspace needs to enable,
instead of something that only counts as an informative query.

I gathered from danvet that blindly exposing things breaks existing userspace, 
so could that information be added to the commit?

Agreed. This information indeed brings out the real reason for the patch.
Will add the details in the commit message in the next patch-set.


Also missing IGT tests, would be nice we at least get some verification things 
work as expected.

Currently this is being tested with the corresponding userspace changes
in weston compositor, but a simple IGT on the same lines of kms_3d
can be prepared.

A separate test to check that the different aspect ratio modes are
correctly enumerated, and filtered out when the cap is not set seems
like a good idea.

As for actaully testing different aspect ratio modes, maybe just
intergrate that into testdisplay?
Alright. Will modify the testdisplay to have a 
"test_aspect_ratio_modes", which will just set the aspect ratio modes 
from the

connector modelist, to verify the basic functionality.
kms_aspect_ratio to do detailed testing will be taken later.

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

[PATCH] drm: Check for lessee in DROP_MASTER ioctl

[Keith Packard]

Don't let a lessee control what the current DRM master is set to;
that's the job of the "real" master. Otherwise, the lessee would
disable all access to master operations for the owner and all lessees
under it.

This matches the same check made in the SET_MASTER ioctl.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_auth.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index aad468d170a7..d9c0f7573905 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -230,6 +230,12 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void 
*data,
if (!dev->master)
goto out_unlock;
 
+   if (file_priv->master->lessor != NULL) {
+   DRM_DEBUG_LEASE("Attempt to drop lessee %d as master\n", 
file_priv->master->lessee_id);
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = 0;
drm_drop_master(dev, file_priv);
 out_unlock:
-- 
2.15.1

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

[Bug 198513] New: [DRM] amdgpu fails to load firmware on boot

[bugzilla-daemon]

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

Bug ID: 198513
   Summary: [DRM] amdgpu fails to load firmware on boot
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15rc7.git4.1 and above
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: m.mcn...@gmail.com
Regression: No

on Fedora kernel 4.15rc7git4.1 and above with R9 NANO (Fiji) GPU dmesg shows a
failure to load the firmware. cloned the latest firmware from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
still fails to load.

[2.423859] amdgpu :26:00.0: Direct firmware load for
amdgpu/fiji_pfp.bin failed with erro
r -2
[2.423860] amdgpu :26:00.0: gfx8: Failed to load firmware
"amdgpu/fiji_pfp.bin"
[2.423897] [drm:gfx_v8_0_sw_init [amdgpu]] *ERROR* Failed to load gfx
firmware!
[2.423924] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block
 failed -2
[2.423926] amdgpu :26:00.0: amdgpu_init failed


dropping back to 4.15rc7git0.1 and all loads correctly, no longer drops back to
llvmpipe as a fallback.

-- 
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: [RFC] Per file OOM badness

[He, Roger]

Basically the idea is right to me.

1. But we need smaller granularity to control the contribution to OOM badness.
 Because when the TTM buffer resides in VRAM rather than evict to system 
memory, we should not take this account into badness.
 But I think it is not easy to implement.

2. If the TTM buffer(GTT here) is mapped to user for CPU access, not quite sure 
the buffer size is already taken into account for kernel.
 If yes, at last the size will be counted again by your patches.

So, I am thinking if we can counted the TTM buffer size into: 
struct mm_rss_stat {
atomic_long_t count[NR_MM_COUNTERS];
};
Which is done by kernel based on CPU VM (page table).

Something like that:
When GTT allocate suceess:
add_mm_counter(vma->vm_mm, MM_ANONPAGES, buffer_size);

When GTT swapped out:
dec_mm_counter from MM_ANONPAGES frist, then 
add_mm_counter(vma->vm_mm, MM_SWAPENTS, buffer_size);  // or MM_SHMEMPAGES or 
add new item.

Update the corresponding item in mm_rss_stat always.
If that, we can control the status update accurately. 
What do you think about that?
And is there any side-effect for this approach?


Thanks
Roger(Hongbo.He)

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Andrey Grodzovsky
Sent: Friday, January 19, 2018 12:48 AM
To: linux-ker...@vger.kernel.org; linux...@kvack.org; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: [RFC] Per file OOM badness

Hi, this series is a revised version of an RFC sent by Christian König a few 
years ago. The original RFC can be found at 
https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html

This is the same idea and I've just adressed his concern from the original RFC 
and switched to a callback into file_ops instead of a new member in struct file.

Thanks,
Andrey

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

[Bug 198513] [DRM] amdgpu fails to load firmware on boot

[bugzilla-daemon]

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

Matt (m.mcn...@gmail.com) changed:

   What|Removed |Added

 Regression|No  |Yes

--- Comment #1 from Matt (m.mcn...@gmail.com) ---
Forgot to mention I have amdgpu.dc=1 kernel parameter set, however the same
behaviour is exposed without the parameter

-- 
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: [RFC] Per file OOM badness

[He, Roger]

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Michal Hocko
Sent: Friday, January 19, 2018 1:14 AM
To: Grodzovsky, Andrey 
Cc: linux...@kvack.org; amd-...@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Koenig, 
Christian 
Subject: Re: [RFC] Per file OOM badness

On Thu 18-01-18 18:00:06, Michal Hocko wrote:
> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:
> > Hi, this series is a revised version of an RFC sent by Christian 
> > König a few years ago. The original RFC can be found at 
> > https://lists.freedesktop.org/archives/dri-devel/2015-September/0897
> > 78.html
> > 
> > This is the same idea and I've just adressed his concern from the 
> > original RFC and switched to a callback into file_ops instead of a new 
> > member in struct file.
> 
> Please add the full description to the cover letter and do not make 
> people hunt links.
> 
> Here is the origin cover letter text
> : I'm currently working on the issue that when device drivers allocate 
> memory on
> : behalf of an application the OOM killer usually doesn't knew about 
> that unless
> : the application also get this memory mapped into their address space.
> : 
> : This is especially annoying for graphics drivers where a lot of the 
> VRAM
> : usually isn't CPU accessible and so doesn't make sense to map into 
> the
> : address space of the process using it.
> : 
> : The problem now is that when an application starts to use a lot of 
> VRAM those
> : buffers objects sooner or later get swapped out to system memory, 
> but when we
> : now run into an out of memory situation the OOM killer obviously 
> doesn't knew
> : anything about that memory and so usually kills the wrong process.

OK, but how do you attribute that memory to a particular OOM killable 
entity? And how do you actually enforce that those resources get freed on the 
oom killer action?

Here I think we need more fine granularity for distinguishing the buffer is 
taking VRAM or system memory.

> : The following set of patches tries to address this problem by 
> introducing a per
> : file OOM badness score, which device drivers can use to give the OOM 
> killer a
> : hint how many resources are bound to a file descriptor so that it 
> can make
> : better decisions which process to kill.

But files are not killable, they can be shared... In other words this doesn't 
help the oom killer to make an educated guess at all.

> : 
> : So question at every one: What do you think about this approach?

I thing is just just wrong semantically. Non-reclaimable memory is a 
pain, especially when there is way too much of it. If you can free that memory 
somehow then you can hook into slab shrinker API and react on the memory 
pressure. If you can account such amemory to a particular process and 
make sure that the consumption is bound by the process life time then we can 
think of an accounting that oom_badness can consider when selecting a victim.

I think you are misunderstanding here.
Actually for now, the memory in TTM Pools already has mm_shrink which is 
implemented in ttm_pool_mm_shrink_init.
And here the memory we want to make it contribute to OOM badness is not in TTM 
Pools.
Because when TTM buffer allocation success, the memory already is removed from 
TTM Pools.  

Thanks
Roger(Hongbo.He)

--
Michal Hocko
SUSE Labs
___
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 08/12] drm: msm: Use drm_atomic_helper_shutdown() to disable planes on removal

[Archit Taneja]

On 01/18/2018 03:25 AM, Laurent Pinchart wrote:

The plane cleanup handler currently calls drm_plane_helper_disable(),
which is a legacy helper function. Replace it with a call to
drm_atomic_helper_shutdown() at removal time.


Reviewed-by: Archit Taneja 



Signed-off-by: Laurent Pinchart 
---
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 1 -
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 1 -
  drivers/gpu/drm/msm/msm_drv.c | 1 +
  3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 7a1ad3af08e3..db356d22ef15 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -68,7 +68,6 @@ static void mdp4_plane_destroy(struct drm_plane *plane)
  {
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
  
-	drm_plane_helper_disable(plane);

drm_plane_cleanup(plane);
  
  	kfree(mdp4_plane);

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 29678876fc09..986684e33a03 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -46,7 +46,6 @@ static void mdp5_plane_destroy(struct drm_plane *plane)
  {
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
  
-	drm_plane_helper_disable(plane);

drm_plane_cleanup(plane);
  
  	kfree(mdp5_plane);

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d90ef1d78a1b..4ba48e5acbe9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -233,6 +233,7 @@ static int msm_drm_uninit(struct device *dev)
if (fbdev && priv->fbdev)
msm_fbdev_free(ddev);
  #endif
+   drm_atomic_helper_shutdown(ddev);
drm_mode_config_cleanup(ddev);
  
  	pm_runtime_get_sync(dev);




--
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 00/48] omapdrm: Merge omapdrm and omapdss

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 18 October 2017 12:56:12 EET Tomi Valkeinen wrote:
> On 18/10/17 12:46, Tomi Valkeinen wrote:
> > On 13/10/17 17:58, Laurent Pinchart wrote:
> >> Hello,
> >> 
> >> This patch series merges the omapdrm and omapdss drivers into a single
> >> driver called omapdrm. The split in two drivers was historical, in order
> >> to support the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver
> >> supports DRM/KMS only there's no need to keep two seperate drivers.

[snip]

> >> The series has been tested on a Pandaboard with the DVI and HDMI output.
> > 
> > Here's what I get on AM5 EVM:

[snip]

> [   14.783558] dmm 4e00.dmm: initialized all PAT entries
> [   14.805775] DSS: OMAP DSS rev 6.1
> [   14.809989] omapdss_dss 5800.dss: bound 58001000.dispc (ops
> dispc_component_ops [omapdrm])
> [   14.821844] omapdss_dss 5800.dss: bound 5804.encoder (ops
> hdmi5_component_ops [omapdrm])
> [   14.833482] omapdss_dss 5800.dss: master bind failed: -517
> 
> When I remove modules, something is left enabled as I get:
> 
> [   99.623954] platform 5800.dss: enabled after unload, idling

I initially thought this would disappear after fixing the other issues, but it 
seems to be a problem of its own, which I have thus investigated. I had to 
trace through the runtime PM code to understand what was going on, which 
wasn't a pleasant experience, but I managed to find the root cause and to 
create a fix.

The culprit is initialization of runtime PM in the DSS component master bind 
handler coupled with probe deferral from within that handler.

The bind handler performs the following sequence of PM operations:

pm_runtime_enable(dev);
pm_runtime_get_sync(dev);

... (access the hardware to read the device revision) ... 

pm_runtime_put_sync(dev);

If a failure occurs at this point, the error path calls pm_runtime_disable() 
to balance the pm_runtime_enable() call.

Now it should be noted that the bind handler is called when one of the 
component registers itself, which happens in the component's probe handler. 
Furthermore, as the components are children of the DSS, the device core calls 
pm_runtime_get_sync() on the DSS platform device before calling the 
component's probe handler. This increases the DSS power usage count but 
doesn't runtime resume the device, as runtime PM is disabled at that point.

The bind handler is thus called with runtime PM disabled, with the device 
runtime suspended, but with the power usage count larger than 0. The 
pm_runtime_get_sync() call will thus further increase the power usage count 
and runtime resume the device. The pm_runtime_put_sync() handler will decrease 
the power usage count to a non-zero value and will thus not suspend the 
device. Finally, the pm_runtime_disable() call will disable runtime PM, 
preventing the pm_runtime_put() call in the device core from runtime 
suspending the device. The DSS device is thus left powered on. 

To fix this, I've created a patch that moves the runtime PM initialization 
code (as well as most of the rest of the initialization code) from the bind 
handler to the probe handler. I'll post it in v2 of this series.

-- 
Regards,

Laurent Pinchart

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

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

[Pandiyan, Dhinakaran]

ping for review.

Let me know if there's anything that needs to be done, thanks!


On Fri, 2018-01-12 at 13:57 -0800, Dhinakaran Pandiyan wrote:
> drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> space requested vblank sequence using this clipped 32-bit count(when the
> value is >= 2^32) as reference, the requested sequence remains a 32-bit
> value and gets queued like that. However, the code that checks if the
> requested sequence has passed compares this against the 64-bit vblank
> count.
> 
> Cc: Keith Packard 
> Cc: Michel Dänzer 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_vblank.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 32d9bcf5be7f..768a8e44d99b 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
>  }
>  
> -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #17 from mikhail.v.gavri...@gmail.com ---
Created attachment 136836
  --> https://bugs.freedesktop.org/attachment.cgi?id=136836=edit
dmesg with 4.15.0-rc4 amd-staging-drm-next e6555e61902c with SysRq : Show State

-- 
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/ttm: Don't unreserve swapped BOs that were previously reserved

[He, Roger]

good catch! 

Thanks
Roger(Hongbo.He)
-Original Message-
From: Kuehling, Felix 
Sent: Friday, January 19, 2018 12:56 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Koenig, 
Christian ; He, Roger 
Cc: Kuehling, Felix 
Subject: [PATCH 2/2] drm/ttm: Don't unreserve swapped BOs that were previously 
reserved

If ttm_bo_swapout doesn't own the lock, don't release it. Someone else probably 
depends on it still being locked.

Signed-off-by: Felix Kuehling 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
62518b6..893003f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1780,8 +1780,8 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct 
ttm_operation_ctx *ctx)
 * Unreserve without putting on LRU to avoid swapping out an
 * already swapped buffer.
 */
-
-   reservation_object_unlock(bo->resv);
+   if (locked)
+   reservation_object_unlock(bo->resv);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
 }
--
2.7.4

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

Re: [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers

[Chunming Zhou]

On 2018年01月19日 00:47, Andrey Grodzovsky wrote:

Large amounts of VRAM are usually not CPU accessible, so they are not mapped
into the processes address space. But since the device drivers usually support
swapping buffers from VRAM to system memory we can still run into an out of
memory situation when userspace starts to allocate to much.

This patch gives the OOM another hint which process is
holding how many resources.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_file.c | 12 
  drivers/gpu/drm/drm_gem.c  |  8 
  include/drm/drm_file.h |  4 
  3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b3c6e99..626cc76 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -747,3 +747,15 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
spin_unlock_irqrestore(>event_lock, irqflags);
  }
  EXPORT_SYMBOL(drm_send_event);
+
+long drm_oom_badness(struct file *f)
+{
+
+   struct drm_file *file_priv = f->private_data;
+
+   if (file_priv)
+   return atomic_long_read(_priv->f_oom_badness);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_oom_badness);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 01f8d94..ffbadc8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -264,6 +264,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(>vma_node, file_priv);
  
+	atomic_long_sub(obj->size >> PAGE_SHIFT,

+   _priv->f_oom_badness);
+
drm_gem_object_handle_put_unlocked(obj);
  
  	return 0;

@@ -299,6 +302,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);
  
+	atomic_long_sub(obj->size >> PAGE_SHIFT, >f_oom_badness);

+
return 0;
  }
  EXPORT_SYMBOL(drm_gem_handle_delete);
@@ -417,6 +422,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
}
  
  	*handlep = handle;

+
+   atomic_long_add(obj->size >> PAGE_SHIFT,
+   _priv->f_oom_badness);
For VRAM case, it should be counted only when vram bo is evicted to 
system memory.
For example, vram total is 8GB, system memory total is 8GB, one 
application allocates 7GB vram and 7GB system memory, which is allowed, 
but if following your idea, then this application will be killed by OOM, 
right?


Regards,
David Zhou

return 0;
  
  err_revoke:

diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..ac3aa75 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -317,6 +317,8 @@ struct drm_file {
  
  	/* private: */

unsigned long lock_count; /* DRI1 legacy lock count */
+
+   atomic_long_t   f_oom_badness;
  };
  
  /**

@@ -378,4 +380,6 @@ void drm_event_cancel_free(struct drm_device *dev,
  void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event 
*e);
  void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
  
+long drm_oom_badness(struct file *f);

+
  #endif /* _DRM_FILE_H_ */


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

[Bug 104683] WebGL crashes the kernel driver and Xorg

[bugzilla-daemon]

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

--- Comment #2 from Dieter Nützel  ---
Can you both try this site, too?

http://webglsamples.org/aquarium/aquarium.html

It worked some days/weeks before XMas on RX580 (radeonsi) under Konqueror
(5.0.97).
Since then I get WebGL unsupportet with Firefox (57.0.4).

'It does not appear your computer supports WebGL.
Click here for more information.

Status: WebGL creation failed: * Error during native OpenGL init. * Error
during native OpenGL init. * Error during native OpenGL init. * Error during
native OpenGL init. * Error during native OpenGL init. * Exhausted GL driver
caps. * Exhausted GL driver options.'

Some subpages (Google) demos works with Konqueror (5.0.97)
http://webglsamples.org/blob/blob.html
http://webglsamples.org/dynamic-cubemap/dynamic-cubemap.html
http://webglsamples.org

But nothing with Firefox.

If this is unrelated I'll open my own bug.

-- 
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 1566/1583] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:2123:9: sparse: incorrect type in assignment (different base types)

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   f1182e58cded6542924c9ae92c1e9cf4da9c73d3
commit: 53ebbecb43fc075cedd5057e07adafd112e881ca [1566/1583] drm/amd/pp: 
Implement voltage regulator config on CI
reproduce:
# apt-get install sparse
git checkout 53ebbecb43fc075cedd5057e07adafd112e881ca
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1440:9: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1441:9: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
SpllSpreadSpectrum @@ got ed int SpllSpreadSpectrum @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1441:9: expected 
unsigned int SpllSpreadSpectrum
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1441:9: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1442:9: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
SpllSpreadSpectrum2 @@ got ed int SpllSpreadSpectrum2 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1442:9: expected 
unsigned int SpllSpreadSpectrum2
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1442:9: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1443:9: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
CcPwrDynRm @@ got ed int CcPwrDynRm @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1443:9: expected 
unsigned int CcPwrDynRm
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1443:9: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1444:9: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
CcPwrDynRm1 @@ got ed int CcPwrDynRm1 @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1444:9: expected 
unsigned int CcPwrDynRm1
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1444:9: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1455:57: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
MinVddci @@ got ed int MinVddci @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1455:57: expected 
unsigned int MinVddci
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1455:57: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1457:57: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
MinVddci @@ got ed int MinVddci @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1457:57: expected 
unsigned int MinVddci
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1457:57: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1461:48: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
MinMvdd @@ got ed int MinMvdd @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1461:48: expected 
unsigned int MinMvdd
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1461:48: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1484:51: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
DllCntl @@ got ed int DllCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1484:51: expected 
unsigned int DllCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1484:51: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1486:51: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
MclkPwrmgtCntl @@ got ed int MclkPwrmgtCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1486:51: expected 
unsigned int MclkPwrmgtCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1486:51: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1488:51: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
MpllAdFuncCntl @@ got ed int MpllAdFuncCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1488:51: expected 
unsigned int MpllAdFuncCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1488:51: got 
restricted __be32 
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1490:51: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned int 
MpllDqFuncCntl @@ got ed int MpllDqFuncCntl @@
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1490:51: expected 
unsigned int MpllDqFuncCntl
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smumgr.c:1490:51: got 
restricted __be32 
   

Re: linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree

[Stephen Rothwell]

Hi Thomas,

On Thu, 18 Jan 2018 22:18:48 +0100 Thomas Hellstrom  
wrote:
>
> That would be me.
> I've historically only added my signed-off-by:s on commits I've (co-) 
> authored myself, as the committer info is already registered,
> 
> But I take it that's not the correct approach?

Please read "Developer's Certificate of Origin 1.1" in
Documentation/process/submitting-patches.rst.  Basically, if you handle
the patch on its way to Linus (e.g. commit it to a branch of a git tree
that Linus (or someone else along the path) merges) then you need to
add a Signed-off-by tag.

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

Re: [RFC v2 6/8] drm: Handle fbdev emulation in core

[Daniel Vetter]

[oops, this was stuck in my draft folder, sry]

On Thu, Jan 11, 2018 at 3:09 PM, Noralf Trønnes  wrote:
>
> Den 11.01.2018 08.45, skrev Daniel Vetter:
>>
>> On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:
>>>
>>> Den 09.01.2018 11.38, skrev Daniel Vetter:

 On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
>
> Prepare for generic fbdev emulation by letting DRM core work directly
> with the fbdev compatibility layer. This is done by adding new fbdev
> helper vtable callbacks for restore, hotplug_event, unregister and
> release.
>
> Signed-off-by: Noralf Trønnes 

 No clue whether my idea is any good, but inspired by the bootsplash
 discussion, and the prospect that we might get other in-kernel drm/kms
 clients I'm wondering whether we should make this a bit more generic and
 tie it to drm_file?

 The idea would be to have a list of internal drm clients by putting all
 the internal drm_files onto a list (same way we do with the userspace
 ones). Then we'd just walk that list and call ->hotplug, ->unregister
 and
 ->release at the right places.

 ->restore would be a bit different, I guess for that we'd only call the
 ->restore callback of the very first kernel-internal client.

 With that we could then add/remove kernel-internal drm clients like
 normal
 userspace clients, which should make integration of emergency consoles,
 boot splashes and whatever else real easy. And I think it would be a lot
 cleaner than leaking fb_helper knowledge into the drm core, which feels
 a
 rather backwards.

 Otoh that feels a bit overengineered (but at least it shouldn't be a lot
 more code really). If the list is too much work we could start with 1
 drm_file * pointer for internal stuff (but would still need locking, so
 list_head is probably easier).

 Thoughts?
>>>
>>> I prefer to have a proper in-kernel client API from the get go, instead
>>> of fixing it up later. The reason I skipped spending time on it in this
>>> RFC, was that I didn't know if I was on the right track at the right time
>>> to get the necessary attention to make this dumb_buffer idea happen.
>>>
>>> With a drm_file centric approach, are you thinking something like this:
>>>
>>>   struct drm_device {
>>> +struct list_head filelist_internal;
>>>   };
>>>
>>> +struct drm_file_funcs {
>>> +int (*restore)(struct drm_file *file);
>>> +void (*hotplug)(struct drm_file *file);
>>> +void (*unregister)(struct drm_file *file);
>>
>> I guess we still need a cleanup callback here? For the usual two-stage
>> driver unload sequence of 1. unregister 2. cleanup.
>
>
> There's no need for a cleanup callback in this scenario.
> The client holds a ref on drm_device through drm_internal_open() and if
> it can't release the drm_file on .unregister, there won't be any cleanup.
> When the client is in a position to release drm_file (fb_close), it will
> do so and the ref is dropped.

But when will we clean up fbdev helper allocations and things like
that? If we do that through a ->release callback I think we can avoid
a few special cases.

Hm right, drm_file holds a full ref, so we won't ever enter that case.
That's annoying, since this means there's no clear place for us to
release stuff again  Should we perhaps try to drop the references
in ->unregister, but keep the drm_file on the list for ->release time?
I'd assume that trying to guess when exactly it's safe to release all
the fbdev allocated resources is otherwise going to be somewhat
tricky.

Or maybe I'm just seeing monsters when there's actually no problem at all :-)

> If for some reason we can't take a ref, then we need to use
> drm_device.open_count to avoid drm_device going away in drm_dev_unplug().

open_count also holds a drm_get_dev reference (but implicitly).
-Daniel

>
> Noralf.
>
>
>>
>>> +};
>>>
>>>   struct drm_file {
>>> +struct drm_device *dev;
>>> +const struct drm_file_funcs *funcs;
>>>   };
>>>
>>>   struct drm_file *drm_file_alloc(struct drm_minor *minor)
>>>   {
>>> +file->dev = dev;
>>>   }
>>>
>>> struct drm_file* drm_internal_open(struct drm_device *dev,
>>> const struct drm_file_funcs *funcs)
>>>  struct drm_file *file;
>>>  int ret;
>>>
>>>  if (!try_module_get(dev->driver->fops->owner))
>>>  return ERR_PTR(-ENODEV);
>>>
>>>  drm_dev_ref(dev);
>>>
>>>  file = drm_file_alloc(dev);
>>>  if (IS_ERR(file)) {
>>>  drm_dev_unref(dev);
>>>  module_put(dev->driver->fops->owner);
>>>  return file;
>>>  }
>>>
>>>  file->funcs = funcs;
>>>
>>>  mutex_lock(>filelist_mutex);
>>>  list_add(>lhead, >filelist_internal);
>>>  mutex_unlock(>filelist_mutex);
>>>
>>>  return file;
>>> }
>>>
>>> void drm_internal_release(struct drm_file *file)
>>> {
>>>  struct 

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #8 from Peter Weber  ---
Hello!

I'm using a LG 27UD88-W, which featurese 1 x DP, 1 x USB-C (DP) and 2 x HDMI.
In my desktop is a Radeon RX 560 which offers DP "1.4" and HDMI "2.0b" and I
also use a ThinkPad X220 which offers DP "1.1".

USB-C -> No hardware available
DP-> Reserved for ThinkPad, so I can use 3480x2180@30 Hz (probably even 44
Hz [1])
HDMI  -> RX 560

The DP of the RX 560 works fine at 3480x2180@60Hz, but via HDMI it fails with
Fedora 27 and kernel "3.14". Only 1920x1***@30Hz is possible any higher
resolution results in visual garbage on the screen or "NO SIGNAL". Finally I
remembered, that kernel 3.15 will over the new graphics stack "AMDGPU DC". I
booted a live ISO with kernel 3.15 and passed the requried option "amdgpu.dc=1"
and got 3480x2180@30Hz. GNOME also offers 60Hz as option, but that fails and
cannot be used, screen goes blank, until GNOME reverts the settings. I'm afraid
the previous people are right, HDMI2.0b and 4K@60Hz are broken.




HINT: Don't used "DEEP COLOR" (LG OPTION for 8/10BIT COLOR?) with HDMI or
everything is busted, but that is a minor issue, as for now.














[1]
https://medium.com/@ValdikSS/how-to-use-high-resolutions-with-older-hardware-58577d91b1f8

-- 
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 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #9 from Peter Weber  ---
(In reply to S.H. from comment #3)
> Sorry, pressed the send button too early.

Me too!

> - iiyama G-Master GB2888UHSU 

This was my other candidate to buy, glad to hear that this monitor wouldn't
have changed anything :D

-- 
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 v2 1/1] drm: add kernel doc for exported gem dmabuf_ops

[Samuel Li]

Signed-off-by: Samuel Li 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_prime.c | 88 +
 1 file changed, 88 insertions(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index ca09ce7..e82a976 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -73,6 +73,9 @@
  * Drivers should detect this situation and return back the gem object
  * from the dma-buf private.  Prime will do this automatically for drivers that
  * use the drm_gem_prime_{import,export} helpers.
+ *
+ * GEM struct _buf_ops symbols are now exported. They can be resued by
+ * drivers which implement GEM interface.
  */
 
 struct drm_prime_member {
@@ -180,6 +183,18 @@ static int drm_prime_lookup_buf_handle(struct 
drm_prime_file_private *prime_fpri
return -ENOENT;
 }
 
+/**
+ * drm_gem_map_attach - dma_buf attach implementation for GEM
+ * @dma_buf: buffer to attach device to
+ * @target_dev: not used
+ * @attach: buffer attachment data
+ *
+ * Allocates _prime_attachment and calls _driver.gem_prime_pin for
+ * device specific attachment. This can be used as the _buf_ops.attach
+ * callback.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
 int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
   struct dma_buf_attachment *attach)
 {
@@ -201,6 +216,14 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, struct 
device *target_dev,
 }
 EXPORT_SYMBOL(drm_gem_map_attach);
 
+/**
+ * drm_gem_map_detach - dma_buf detach implementation for GEM
+ * @dma_buf: buffer to detach from
+ * @attach: attachment to be detached
+ *
+ * Cleans up _buf_attachment. This can be used as the _buf_ops.detach
+ * callback.
+ */
 void drm_gem_map_detach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
 {
@@ -255,6 +278,18 @@ void drm_prime_remove_buf_handle_locked(struct 
drm_prime_file_private *prime_fpr
}
 }
 
+/**
+ * drm_gem_map_dma_buf - map_dma_buf implementation for GEM
+ * @attach: attachment whose scatterlist is to be returned
+ * @dir: direction of DMA transfer
+ *
+ * Calls _driver.gem_prime_get_sg_table and then maps the scatterlist. This
+ * can be used as the _buf_ops.map_dma_buf callback.
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ */
+
 struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
 enum dma_data_direction dir)
 {
@@ -294,6 +329,12 @@ struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
 }
 EXPORT_SYMBOL(drm_gem_map_dma_buf);
 
+/**
+ * drm_gem_unmap_dma_buf - unmap_dma_buf implementation for GEM
+ *
+ * Not implemented. The unmap is done at drm_gem_map_detach().  This can be
+ * used as the _buf_ops.unmap_dma_buf callback.
+ */
 void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
   struct sg_table *sgt,
   enum dma_data_direction dir)
@@ -351,6 +392,15 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_release);
 
+/**
+ * drm_gem_dmabuf_vmap - dma_buf vmap implementation for GEM
+ * @dma_buf: buffer to be mapped
+ *
+ * Sets up a kernel virtual mapping. This can be used as the _buf_ops.vmap
+ * callback.
+ *
+ * Returns the kernel virtual address.
+ */
 void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
@@ -360,6 +410,14 @@ void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
 
+/**
+ * drm_gem_dmabuf_vunmap - dma_buf vunmap implementation for GEM
+ * @dma_buf: buffer to be unmapped
+ * @vaddr: the virtual address of the buffer
+ *
+ * Releases a kernel virtual mapping. This can be used as the
+ * _buf_ops.vunmap callback.
+ */
 void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 {
struct drm_gem_object *obj = dma_buf->priv;
@@ -369,6 +427,11 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
 
+/**
+ * drm_gem_dmabuf_kmap_atomic - map_atomic implementation for GEM
+ *
+ * Not implemented. This can be used as the _buf_ops.map_atomic callback.
+ */
 void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
 unsigned long page_num)
 {
@@ -376,6 +439,11 @@ void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_kmap_atomic);
 
+/**
+ * drm_gem_dmabuf_kunmap_atomic - unmap_atomic implementation for GEM
+ *
+ * Not implemented. This can be used as the _buf_ops.unmap_atomic callback.
+ */
 void drm_gem_dmabuf_kunmap_atomic(struct dma_buf *dma_buf,
  unsigned long page_num, void *addr)
 {
@@ -383,12 +451,22 @@ void drm_gem_dmabuf_kunmap_atomic(struct dma_buf 

[PATCH v2 0/2] Add R-Car V3M (R8A77970) support to the DU driver

[Sergei Shtylyov]

Hello!

Here's the set of 2 patches against the 'drm-next' branch of David Airlie's
'linux.git' repo. The purpose of these patches is to add the R-Car V3M
(R8A77970) support to the DU driver; the LVDS driver patches will be posted
separately...

[1/2] DT: display: renesas,du: document R8A77970 bindings
[2/2] drm: rcar-du: add R8A77970 support

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

[PATCH v2 1/2] DT: display: renesas,du: document R8A77970 bindings

[Sergei Shtylyov]

Document the R-Car V3M (R8A77970) SoC in the R-Car DU bindings.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- documented  R8A77970 DU ports;
- patch split from the main R8A77970 DU support patch.

 Documentation/devicetree/bindings/display/renesas,du.txt |2 ++
 1 file changed, 2 insertions(+)

Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
===
--- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
+++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -13,6 +13,7 @@ Required Properties:
 - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
+- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
 
   - reg: A list of base address and length of each memory resource, one for
 each entry in the reg-names property.
@@ -63,6 +64,7 @@ corresponding to each DU output.
  R8A7794 (R-Car E2)   DPAD 0 DPAD 1 -  -
  R8A7795 (R-Car H3)   DPAD 0 HDMI 0 HDMI 1 LVDS 0
  R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
+ R8A77970 (R-Car V3M) DPAD 0 LVDS 0 -  -
 
 
 Example: R8A7795 (R-Car H3) ES2.0 DU

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

Re: [PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

[Deucher, Alexander]

From: Kuehling, Felix
Sent: Thursday, January 18, 2018 4:12 PM
To: Koenig, Christian; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org; He, Roger; Deucher, Alexander
Subject: Re: [PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

On 2018-01-18 01:09 PM, Christian König wrote:
> Am 18.01.2018 um 17:56 schrieb Felix Kuehling:
>> A BO that's already swapped would be added back to the swap-LRU list
>> for example if its validation failed under high memory pressure. This
>> could later lead to swapping it out again and leaking previous swap
>> storage.
>>
>> This commit adds a condition to prevent that from happening.
>>
>> v2: Check page_flags instead of swap_storage
>>
>> Signed-off-by: Felix Kuehling 
>
> Reviewed-by: Christian König  for both.

Thanks. I pushed them to amd-staging-drm-next. I think patch 1 should
also go to -fixes. Alex?

Yup, already planning on it.

Alex

Regards,
  Felix

>
>> ---
>>   drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 2eb71ff..62518b6 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -170,7 +170,8 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
>>   list_add_tail(>lru, >lru[bo->priority]);
>>   kref_get(>list_kref);
>>   -if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {
>> +if (bo->ttm && !(bo->ttm->page_flags &
>> + (TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
>>   list_add_tail(>swap,
>> >glob->swap_lru[bo->priority]);
>>   kref_get(>list_kref);
>

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

Re: [PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

[Felix Kuehling]

On 2018-01-18 01:09 PM, Christian König wrote:
> Am 18.01.2018 um 17:56 schrieb Felix Kuehling:
>> A BO that's already swapped would be added back to the swap-LRU list
>> for example if its validation failed under high memory pressure. This
>> could later lead to swapping it out again and leaking previous swap
>> storage.
>>
>> This commit adds a condition to prevent that from happening.
>>
>> v2: Check page_flags instead of swap_storage
>>
>> Signed-off-by: Felix Kuehling 
>
> Reviewed-by: Christian König  for both.

Thanks. I pushed them to amd-staging-drm-next. I think patch 1 should
also go to -fixes. Alex?

Regards,
  Felix

>
>> ---
>>   drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 2eb71ff..62518b6 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -170,7 +170,8 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
>>   list_add_tail(>lru, >lru[bo->priority]);
>>   kref_get(>list_kref);
>>   -    if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {
>> +    if (bo->ttm && !(bo->ttm->page_flags &
>> + (TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
>>   list_add_tail(>swap,
>>     >glob->swap_lru[bo->priority]);
>>   kref_get(>list_kref);
>

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

[PATCH v2 2/2] drm: rcar-du: add R8A77970 support

[Sergei Shtylyov]

Add support for the R-Car V3M (R8A77970) SoC to the R-Car DU driver.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 2:
- removed  the 'model' and 'dpll_ch' field initializers;
- fixed up the DU port numbers;
- split the DU bindings and the LVDS driver updates into a separate patches;
- removed  the check before the DPTSR write (to be done in a separate patch).

 drivers/gpu/drm/rcar-du/rcar_du_drv.c |   21 +
 1 file changed, 21 insertions(+)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -249,6 +249,26 @@ static const struct rcar_du_device_info
.dpll_ch =  BIT(1),
 };
 
+static const struct rcar_du_device_info rcar_du_r8a77970_info = {
+   .gen = 3,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+   .num_crtcs = 1,
+   .routes = {
+   /* R8A77970 has one RGB output and one LVDS output. */
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(0),
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .port = 1,
+   },
+   },
+   .num_lvds = 1,
+};
+
 static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
{ .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
@@ -260,6 +280,7 @@ static const struct of_device_id rcar_du
{ .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
{ .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
{ .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
+   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
{ }
 };
 

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

Re: linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree

[Thomas Hellstrom]

Hi, Stephen,

That would be me.
I've historically only added my signed-off-by:s on commits I've (co-) 
authored myself, as the committer info is already registered,


But I take it that's not the correct approach?
/Thomas



On 01/18/2018 09:23 PM, Stephen Rothwell wrote:

Hi all,

Commit

   8a510a5c7526 ("drm/vmwgfx: fix memory corruption with legacy/sou connectors")

is missing a Signed-off-by from its committer.



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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #4 from Barto (mister.free...@laposte.net) ---
I will try(In reply to Alex Deucher from comment #3)
> Can you bisect?

I will try to bisect

-- 
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 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

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

linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree

[Stephen Rothwell]

Hi all,

Commit

  8a510a5c7526 ("drm/vmwgfx: fix memory corruption with legacy/sou connectors")

is missing a Signed-off-by from its committer.

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

Re: [RFC] Per file OOM badness

[Eric Anholt]

Michal Hocko  writes:

> On Thu 18-01-18 18:00:06, Michal Hocko wrote:
>> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:
>> > Hi, this series is a revised version of an RFC sent by Christian König
>> > a few years ago. The original RFC can be found at 
>> > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
>> > 
>> > This is the same idea and I've just adressed his concern from the original 
>> > RFC 
>> > and switched to a callback into file_ops instead of a new member in struct 
>> > file.
>> 
>> Please add the full description to the cover letter and do not make
>> people hunt links.
>> 
>> Here is the origin cover letter text
>> : I'm currently working on the issue that when device drivers allocate 
>> memory on
>> : behalf of an application the OOM killer usually doesn't knew about that 
>> unless
>> : the application also get this memory mapped into their address space.
>> : 
>> : This is especially annoying for graphics drivers where a lot of the VRAM
>> : usually isn't CPU accessible and so doesn't make sense to map into the
>> : address space of the process using it.
>> : 
>> : The problem now is that when an application starts to use a lot of VRAM 
>> those
>> : buffers objects sooner or later get swapped out to system memory, but when 
>> we
>> : now run into an out of memory situation the OOM killer obviously doesn't 
>> knew
>> : anything about that memory and so usually kills the wrong process.
>
> OK, but how do you attribute that memory to a particular OOM killable
> entity? And how do you actually enforce that those resources get freed
> on the oom killer action?
>
>> : The following set of patches tries to address this problem by introducing 
>> a per
>> : file OOM badness score, which device drivers can use to give the OOM 
>> killer a
>> : hint how many resources are bound to a file descriptor so that it can make
>> : better decisions which process to kill.
>
> But files are not killable, they can be shared... In other words this
> doesn't help the oom killer to make an educated guess at all.

Maybe some more context would help the discussion?

The struct file in patch 3 is the DRM fd.  That's effectively "my
process's interface to talking to the GPU" not "a single GPU resource".
Once that file is closed, all of the process's private, idle GPU buffers
will be immediately freed (this will be most of their allocations), and
some will be freed once the GPU completes some work (this will be most
of the rest of their allocations).

Some GEM BOs won't be freed just by closing the fd, if they've been
shared between processes.  Those are usually about 8-24MB total in a
process, rather than the GBs that modern apps use (or that our testcases
like to allocate and thus trigger oomkilling of the test harness instead
of the offending testcase...)

Even if we just had the private+idle buffers being accounted in OOM
badness, that would be a huge step forward in system reliability.

>> : So question at every one: What do you think about this approach?
>
> I thing is just just wrong semantically. Non-reclaimable memory is a
> pain, especially when there is way too much of it. If you can free that
> memory somehow then you can hook into slab shrinker API and react on the
> memory pressure. If you can account such a memory to a particular
> process and make sure that the consumption is bound by the process life
> time then we can think of an accounting that oom_badness can consider
> when selecting a victim.

For graphics, we can't free most of our memory without also effectively
killing the process.  i915 and vc4 have "purgeable" interfaces for
userspace (on i915 this is exposed all the way to GL applications and is
hooked into shrinker, and on vc4 this is so far just used for
userspace-internal buffer caches to be purged when a CMA allocation
fails).  However, those purgeable pools are expected to be a tiny
fraction of the GPU allocations by the process.


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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #1 from Barto (mister.free...@laposte.net) ---
Created attachment 273695
  --> https://bugzilla.kernel.org/attachment.cgi?id=273695=edit
glxinfo

glxinfo

-- 
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 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #2 from Barto (mister.free...@laposte.net) ---
Created attachment 273697
  --> https://bugzilla.kernel.org/attachment.cgi?id=273697=edit
dmesg kernel 4.14.13 good

dmesg kernel 4.14.13

with this version there is no problem of lags in youtube 1080p@60 fps in
fullscreen

-- 
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 198511] New: lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

Bug ID: 198511
   Summary: lags in youtube videos 1080p 60fps with radeon hd4650
and kernel 4.15rc8
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15rc8 mainline
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: mister.free...@laposte.net
Regression: No

Hello,

I have a radeon HD4650 pcie, I use the radeon driver,

I notice that with kernel 4.15.rc8 mainline some videos in 1080p@60fps format
in youtube play with slight lags in fullscreen mode,

but If use kernel 4.14.13-1 then all is Ok, streaming videos in 1080p@60fps
play without lags ( perfect 60 fps ),

so I suspect a bug in radeon driver provided by kernel 4.15.rc8,

my OS is archlinux 64 bits,

some example of video 1080@60 fps for youtube :
https://www.youtube.com/watch?v=CcUXxM_rbAM

-- 
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 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

Bjorn Helgaas (bhelg...@google.com) changed:

   What|Removed |Added

 CC||bhelg...@google.com
  Component|Video(DRI - non Intel)  |PCI
   Assignee|drivers_video-dri@kernel-bu |drivers_...@kernel-bugs.osd
   |gs.osdl.org |l.org
 Regression|No  |Yes

--- Comment #18 from Bjorn Helgaas (bhelg...@google.com) ---
Reassigning to PCI and marking as a regression (v4.10 works, v4.11 fails).

Can you please test a current kernel, e.g., v4.14 or even v4.15-rc8?  The v4.11
kernel you're using is quite old, and it's possible this has been fixed since
then.  If that's the case, we would just need to decide whether a v4.11 stable
kernel needs the fix, and if so, backport the existing fix.

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

[radeon-alex:amd-staging-drm-next 1493/1581] sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in declaration of 'module_pci_driver'

[kbuild test robot]

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

All errors (new ones prefixed by >>):

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

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

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

Re: [PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

[Christian König]

Am 18.01.2018 um 17:56 schrieb Felix Kuehling:

A BO that's already swapped would be added back to the swap-LRU list
for example if its validation failed under high memory pressure. This
could later lead to swapping it out again and leaking previous swap
storage.

This commit adds a condition to prevent that from happening.

v2: Check page_flags instead of swap_storage

Signed-off-by: Felix Kuehling 


Reviewed-by: Christian König  for both.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2eb71ff..62518b6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -170,7 +170,8 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
list_add_tail(>lru, >lru[bo->priority]);
kref_get(>list_kref);
  
-		if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {

+   if (bo->ttm && !(bo->ttm->page_flags &
+(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
list_add_tail(>swap,
  >glob->swap_lru[bo->priority]);
kref_get(>list_kref);


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

[Bug 102296] R9 285 VCE corruption since drm/amdgpu/gmc8: use the vram location programmed by the vbios

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #15 from Christian König  ---
Good that we finally found the root cause and thanks for testing.

-- 
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 97886] radeon r300 vdpau broken

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from Christian König  ---
Sorry, but the vdpau backend for r300 never did anything else than displaying
the playback content. There actually never was any decoding acceleration.

So you should be able to actually use Xv just the same way.

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

Re: [PATCH 00/12] Cargo cult cleanup in atomic drivers

[Liviu Dudau]

On Wed, Jan 17, 2018 at 11:55:23PM +0200, Laurent Pinchart wrote:
> Hello,

Hi Laurent,

> 
> This patch series removes a few cargo-cult constructs from a set of atomic
> drivers.
> 
> Patches 01/12 and 02/12 remove the unneeded .mode_set() and .mode_set_base()
> CRTC handlers from the arc and atmel-hlcdc drivers.
> 
> Patches 03/12 to 12/12 then remove the use of drm_plane_helper_disable() from
> the plane .destroy() handlers of atomic drivers, replacing them with the use
> of drm_atomic_helper_shutdown() at removal time. Interleaved there are patches
> 04/12 and 06/12 that remove unnecessary cleanups in error paths, and patch
> 09/12 that adds missing cleanup.

Thanks for the cleanup!

> 
> All this has been compile-tested only.

And I was trying to test the patches today but I've made the foolish
decision to update the firmware on my Juno board first :( I hope to
finish the testing tomorrow.

> 
> Laurent Pinchart (12):
>   drm: arc: Don't set CRTC .mode_set and .mode_set_base handlers
>   drm: atmel-hlcdc: Don't set CRTC .mode_set and .mode_set_base handlers
>   drm: arc: Use drm_atomic_helper_shutdown() to disable planes on
> removal
>   drm: arm: hdlcd: Don't destroy plane manually in hdlcd_setup_crtc()
>   drm: arm: hdlcd: Use drm_atomic_helper_shutdown() to disable planes on
> removal
>   drm: arm: malidp: Don't destroy planes manually in error handlers
>   drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes
> on removal
>   drm: msm: Use drm_atomic_helper_shutdown() to disable planes on
> removal
>   drm: sti: Cleanup KMS objects on removal
>   drm: sti: Use drm_atomic_helper_shutdown() to disable planes on
> removal
>   drm: vc4: Use drm_atomic_helper_shutdown() to disable planes on
> removal
>   drm: zte: Use drm_atomic_helper_shutdown() to disable planes on
> removal

Anyway, for the hdlcd and malidp patches in the series:

Acked-by: Liviu Dudau 

If you need me to get the driver patches into my trees let me know.

Best regards,
Liviu

> 
>  drivers/gpu/drm/arc/arcpgu_crtc.c  | 12 ++--
>  drivers/gpu/drm/arc/arcpgu_drv.c   |  1 +
>  drivers/gpu/drm/arm/hdlcd_crtc.c   | 12 ++--
>  drivers/gpu/drm/arm/hdlcd_drv.c|  1 +
>  drivers/gpu/drm/arm/malidp_crtc.c  | 10 ++
>  drivers/gpu/drm/arm/malidp_drv.c   |  2 +-
>  drivers/gpu/drm/arm/malidp_drv.h   |  1 -
>  drivers/gpu/drm/arm/malidp_planes.c| 17 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  2 --
>  drivers/gpu/drm/msm/Kconfig|  1 -
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c  |  1 -
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c  |  1 -
>  drivers/gpu/drm/msm/msm_drv.c  |  1 +
>  drivers/gpu/drm/sti/sti_cursor.c   | 10 +-
>  drivers/gpu/drm/sti/sti_drv.c  |  2 ++
>  drivers/gpu/drm/sti/sti_gdp.c  | 10 +-
>  drivers/gpu/drm/sti/sti_hqvdp.c| 10 +-
>  drivers/gpu/drm/vc4/Kconfig|  1 -
>  drivers/gpu/drm/vc4/vc4_drv.c  |  3 +++
>  drivers/gpu/drm/vc4/vc4_plane.c|  8 +---
>  drivers/gpu/drm/zte/Kconfig|  2 +-
>  drivers/gpu/drm/zte/zx_drm_drv.c   |  1 +
>  drivers/gpu/drm/zte/zx_plane.c |  8 +---
>  23 files changed, 23 insertions(+), 94 deletions(-)
> 
> -- 
> 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 4/4] drm/vgem: flush page during page fault

[Gurchetan Singh]

On Wed, Jan 17, 2018 at 11:38 PM, Daniel Vetter  wrote:

> On Wed, Jan 17, 2018 at 11:49 PM, Gurchetan Singh
>  wrote:
> >
> > On Wed, Jan 17, 2018 at 12:39 AM, Daniel Vetter  wrote:
> >>
> >> On Tue, Jan 16, 2018 at 04:35:59PM -0800, Gurchetan Singh wrote:
> >> > This is required to use buffers allocated by vgem on AMD and ARM
> >> > devices.
> >> > We're experiencing a case where eviction of the cache races with
> >> > userspace
> >> > writes. To fix this, flush the cache after retrieving a page.
> >> >
> >> > Signed-off-by: Gurchetan Singh 
> >> > ---
> >> >  drivers/gpu/drm/vgem/vgem_drv.c | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> >> > b/drivers/gpu/drm/vgem/vgem_drv.c
> >> > index 35bfdfb746a7..fb263969f02d 100644
> >> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> >> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> >> > @@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> >> >   break;
> >> >   }
> >> >
> >> > + drm_flush_pages(obj->base.dev->dev, , 1);
> >>
> >> Uh ... what exactly are you doing?
> >>
> >> Asking because the entire "who's responsible for coherency" story is
> >> entirely undefined still when doing buffer sharing :-/ What is clear is
> >> that currently vgem entirely ignores this (there's not
> >> begin/end_cpu_access callback), mostly because the shared dma-buf
> support
> >> in drm_prime.c also entirely ignores this.
> >
> >
> >
> > This patch isn't trying to address the case of a dma-buf imported into
> vgem.
> > It's trying to address the case when a buffer is created by
> > vgem_gem_dumb_create, mapped by vgem_gem_dumb_map and then accessed by
> user
> > space.  Since the page retrieved by shmem_read_mapping_page during the
> page
> > fault may still be in the cache, we're experiencing incorrect data in
> > buffer.  Here's the test case we're running:
> >
> > https://chromium.googlesource.com/chromiumos/platform/drm-te
> sts/+/master/vgem_test.c
>
> 404s over here (Internal url?).


Hmm ... I was able to access that link without being logged in to any
accounts.

> It fails on line 210 on AMD and ARM devices (not Intel though).
>
> So you _do_ import it on the other device driver as a dma-buf (and
> export it from vgem)?


Those portions of the test work fine (if the platform has a drm_clflush
implementation).  vgem_prime_pin calls drm_clflush_pages for the exporting
case.  Typically, ARM drivers flush the cache after drm_gem_get_pages() and
only do WC mappings, so import works.  For Intel, there is some hardware
level coherency involved.  The problem is vgem doesn't flush the cache on
ARM/AMD when getting pages for the non-export/non-import case (when
faulting after a vgem_gem_dumb_map, not during dma-buf mmap) -- i.e, during
regular use of the buffer.

>
> >> And doing a one-time only
> >> flushing in your fault handler is definitely not going to fix this (at
> >> least not if you do anything else than one-shot uploads).
> >
> >
> > There used to be a be vgem_gem_get_pages function, but that's been
> removed.
> > I don't know where else to flush in this situation.
>
> dma_buf begin/end cpu access. Even exposed as an ioctl when you're
> using the dma-buf mmap stuff. Vgem doesn't have that, which means
> as-is the dumb mmap support of vgem can't really support this if you
> want to do explicit flushing.


> What would work is uncached/writecombine/coherent dma memory. But then
> we're in the middle of the entire
> "who's responsible.
> -Daniel
>
> >
> >>
> >> -Daniel
> >>
> >> >   }
> >> >   return ret;
> >> >  }
> >> > --
> >> > 2.13.5
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
> >
> >
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Gurchetan Singh]

On Wed, Jan 17, 2018 at 11:42 PM, Daniel Vetter  wrote:

> On Wed, Jan 17, 2018 at 11:46 PM, Gurchetan Singh
>  wrote:
> >> dma api just isn't quite sufficient for implementing fast gpu drivers.
> >
> >
> > Can you elaborate?  IIRC the DMA API has strong synchronization
> guarantees
> > and that can be problematic for GPU drivers.  However, using the DMA API
> for
> > flushing doesn't necessarily mean the driver has to use the rest of the
> DMA
> > API.
> >
> >> but then it'd need to directly flush cpu caches and bypass the dma api.
> >
> >
> > On ARM, cache flushing seems to vary from chipset to chipset.  For
> example,
> > on ARM32 a typical call-stack for dma_sync_single_for_device looks like:
> >
> > arm_dma_sync_single_for_device
> > __dma_page_cpu_to_dev
> > outer_clean_range
> > outer_cache.clean_range
> >
> > There are multiple clean_range implementations out there (i.e,
> > aurora_clean_range, l2c210_clean_range, feroceon_l2_clean_range), so
> that's
> > why the DMA API was used in this case.  On ARM64, things are a little
> > simpler, but the DMA API seems to go directly to assembly
> (__dma_map_area)
> > after a little indirection.  Why do you think that's inefficient?
>
> I never said it's inefficient. My only gripe is with adding the
> pointless struct device * argument to flushing functions which really
> don't care (nor should care) about the device. Because what we really
> want to call is outer_clean_range here, and that doesn't need a struct
> device *. Imo that function (or something similar) needs to be
> exported and then used by drm_flush_* functions.
>

Okay, we can go with outer_clean_range on ARM and
__dma_map_area/__dma_flush_area
on ARM64.  One concern, on ARM64 at-least, the header
(arm64/include/asm/cacheflush.h) indicates we shouldn't call these
functions directly for whatever reason:

"Cache maintenance functions used by the DMA API. No to be used directly."

However, if no one objects, that's the route we'll go.

>
> Also note that arm has both flush and invalidate functions, but on x86
> those are the same implementation (and we don't have a separate
> drm_invalidate_* set of functions). That doesn't look like a too good
> idea.
>
> Of course that doesn't solve the problem of who's supposed to call it
> and when in the dma-buf sharing situation.
> -Daniel
>
> > On Wed, Jan 17, 2018 at 12:31 AM, Daniel Vetter  wrote:
> >>
> >> On Tue, Jan 16, 2018 at 04:35:58PM -0800, Gurchetan Singh wrote:
> >> > The DMA API can be used to flush scatter gather tables and physical
> >> > pages on ARM devices.
> >> >
> >> > Signed-off-by: Gurchetan Singh 
> >> > ---
> >> >  drivers/gpu/drm/drm_cache.c | 17 +
> >> >  drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  7 ++-
> >> >  drivers/gpu/drm/tegra/gem.c |  6 +-
> >> >  3 files changed, 20 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> >> > index 3d2bb9d71a60..98d6ebb40e96 100644
> >> > --- a/drivers/gpu/drm/drm_cache.c
> >> > +++ b/drivers/gpu/drm/drm_cache.c
> >> > @@ -105,6 +105,18 @@ drm_flush_pages(struct device *dev, struct page
> >> > *pages[],
> >> >  (unsigned long)page_virtual +
> >> > PAGE_SIZE);
> >> >   kunmap_atomic(page_virtual);
> >> >   }
> >> > +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> >> > + unsigned long i;
> >> > + dma_addr_t dma_handle;
> >> > +
> >> > + if (!dev)
> >> > + return;
> >> > +
> >> > + for (i = 0; i < num_pages; i++) {
> >> > + dma_handle = phys_to_dma(drm->dev,
> >> > page_to_phys(pages[i]));
> >> > + dma_sync_single_for_device(dev, dma_handle, PAGE_SIZE,
> >> > +DMA_TO_DEVICE);
> >>
> >> Erm no. These functions here are super-low-level functions used by
> drivers
> >> which know exactly what they're doing. Which is reimplementing half of
> the
> >> dma api behind the dma api's back because the dma api just isn't quite
> >> sufficient for implementing fast gpu drivers.
> >>
> >> If all you end up doing is calling the dma api again, then pls just call
> >> it directly.
> >>
> >> And just to make it clear: I'd be perfectly fine with adding arm support
> >> here, but then it'd need to directly flush cpu caches and bypass the dma
> >> api. Otherwise this is pointless.
> >> -Daniel
> >>
> >> > + }
> >> >  #else
> >> >   pr_err("Architecture has no drm_cache.c support\n");
> >> >   WARN_ON_ONCE(1);
> >> > @@ -136,6 +148,11 @@ drm_flush_sg(struct device *dev, struct sg_table
> >> > *st)
> >> >
> >> >   if (wbinvd_on_all_cpus())
> >> >   pr_err("Timed out waiting for cache flush\n");
> >> > +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> >> > + if (!dev)
> >> > + return;
> >> > +
> >> > + 

[PULL] drm-misc-next-fixes

[Gustavo Padovan]

Hi Dave,

A few fixes for 4.16. Please pull. Thanks.

drm-misc-next-fixes-2018-01-18:
Fixes for 4.16:

Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.
The following changes since commit a1c55bccf6004ec9fbcf892328f9658767aa22bb:

  drm/panel: lvds: Add support for the power-supply property (2018-01-05 
10:00:14 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-01-18

for you to fetch changes up to 341a0ffceaa44660c43d219a3b2569ebbd7d3ad1:

  drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig 
(2018-01-17 10:10:18 +0100)


Fixes for 4.16:

Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.


Dan Carpenter (1):
  drm/sun4i: Fix error code in sun4i_tcon_bind()

Hans de Goede (1):
  drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig

Maxime Ripard (1):
  drm/panel: lvds: Handle the optional regulator case properly

 drivers/gpu/drm/Kconfig|  8 
 drivers/gpu/drm/panel/panel-lvds.c | 11 +--
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  2 +-
 3 files changed, 14 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link

[Sean Paul]

On Thu, Jan 18, 2018 at 04:10:25PM +, Chris Wilson wrote:
> drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’:
> drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in 
> boolean context [-Werror=int-in-bool-context]
>return ret >= 0 ? -EIO : ret;
> 
> Fixes: 20f24d776d1b ("drm/i915: Implement HDCP for DisplayPort")
> Signed-off-by: Chris Wilson 

Thanks for the patch! Applied to the topic branch.

Sean

> Cc: Daniel Vetter 
> Cc: Ramalingam C 
> Cc: Sean Paul 
> Cc: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 68229f53d5b8..0f2290c7bede 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5184,12 +5184,14 @@ bool intel_dp_hdcp_check_link(struct 
> intel_digital_port *intel_dig_port)
>  {
>   ssize_t ret;
>   u8 bstatus;
> +
>   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
>  , 1);
>   if (ret != 1) {
>   DRM_ERROR("Read bstatus from DP/AUX failed (%zd)\n", ret);
> - return ret >= 0 ? -EIO : ret;
> + return false;
>   }
> +
>   return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
>  }
>  
> -- 
> 2.15.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 1/2] drm/ttm: Don't add swapped BOs to swap-LRU list

[Felix Kuehling]

A BO that's already swapped would be added back to the swap-LRU list
for example if its validation failed under high memory pressure. This
could later lead to swapping it out again and leaking previous swap
storage.

This commit adds a condition to prevent that from happening.

v2: Check page_flags instead of swap_storage

Signed-off-by: Felix Kuehling 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2eb71ff..62518b6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -170,7 +170,8 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
list_add_tail(>lru, >lru[bo->priority]);
kref_get(>list_kref);
 
-   if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+   if (bo->ttm && !(bo->ttm->page_flags &
+(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
list_add_tail(>swap,
  >glob->swap_lru[bo->priority]);
kref_get(>list_kref);
-- 
2.7.4

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

[PATCH 2/2] drm/ttm: Don't unreserve swapped BOs that were previously reserved

[Felix Kuehling]

If ttm_bo_swapout doesn't own the lock, don't release it. Someone
else probably depends on it still being locked.

Signed-off-by: Felix Kuehling 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 62518b6..893003f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1780,8 +1780,8 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct 
ttm_operation_ctx *ctx)
 * Unreserve without putting on LRU to avoid swapping out an
 * already swapped buffer.
 */
-
-   reservation_object_unlock(bo->resv);
+   if (locked)
+   reservation_object_unlock(bo->resv);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
 }
-- 
2.7.4

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

[PATCH 1/4] fs: add OOM badness callback in file_operatrations struct.

[Andrey Grodzovsky]

This allows device drivers to specify an additional badness for the OOM
when they allocate memory on behalf of userspace.

Signed-off-by: Andrey Grodzovsky 
---
 include/linux/fs.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 511fbaa..938394a 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1728,6 +1728,7 @@ struct file_operations {
u64);
ssize_t (*dedupe_file_range)(struct file *, u64, u64, struct file *,
u64);
+   long (*oom_file_badness)(struct file *);
 } __randomize_layout;
 
 struct inode_operations {
-- 
2.7.4

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

[PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers

[Andrey Grodzovsky]

Large amounts of VRAM are usually not CPU accessible, so they are not mapped
into the processes address space. But since the device drivers usually support
swapping buffers from VRAM to system memory we can still run into an out of
memory situation when userspace starts to allocate to much.

This patch gives the OOM another hint which process is
holding how many resources.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/drm_file.c | 12 
 drivers/gpu/drm/drm_gem.c  |  8 
 include/drm/drm_file.h |  4 
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b3c6e99..626cc76 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -747,3 +747,15 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
spin_unlock_irqrestore(>event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_send_event);
+
+long drm_oom_badness(struct file *f)
+{
+
+   struct drm_file *file_priv = f->private_data;
+
+   if (file_priv)
+   return atomic_long_read(_priv->f_oom_badness);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_oom_badness);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 01f8d94..ffbadc8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -264,6 +264,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(>vma_node, file_priv);
 
+   atomic_long_sub(obj->size >> PAGE_SHIFT,
+   _priv->f_oom_badness);
+
drm_gem_object_handle_put_unlocked(obj);
 
return 0;
@@ -299,6 +302,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);
 
+   atomic_long_sub(obj->size >> PAGE_SHIFT, >f_oom_badness);
+
return 0;
 }
 EXPORT_SYMBOL(drm_gem_handle_delete);
@@ -417,6 +422,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
}
 
*handlep = handle;
+
+   atomic_long_add(obj->size >> PAGE_SHIFT,
+   _priv->f_oom_badness);
return 0;
 
 err_revoke:
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..ac3aa75 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -317,6 +317,8 @@ struct drm_file {
 
/* private: */
unsigned long lock_count; /* DRI1 legacy lock count */
+
+   atomic_long_t   f_oom_badness;
 };
 
 /**
@@ -378,4 +380,6 @@ void drm_event_cancel_free(struct drm_device *dev,
 void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event 
*e);
 void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
 
+long drm_oom_badness(struct file *f);
+
 #endif /* _DRM_FILE_H_ */
-- 
2.7.4

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

[RFC] Per file OOM badness

[Andrey Grodzovsky]

Hi, this series is a revised version of an RFC sent by Christian König
a few years ago. The original RFC can be found at 
https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html

This is the same idea and I've just adressed his concern from the original RFC 
and switched to a callback into file_ops instead of a new member in struct file.

Thanks,
Andrey

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

[PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu.

[Andrey Grodzovsky]

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 46a0c93..6a733cdc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -828,6 +828,7 @@ static const struct file_operations amdgpu_driver_kms_fops 
= {
 #ifdef CONFIG_COMPAT
.compat_ioctl = amdgpu_kms_compat_ioctl,
 #endif
+   .oom_file_badness = drm_oom_badness,
 };
 
 static bool
-- 
2.7.4

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

[PATCH 2/4] oom: take per file badness into account

[Andrey Grodzovsky]

Try to make better decisions which process to kill based on
per file OOM badness

Signed-off-by: Andrey Grodzovsky 
---
 mm/oom_kill.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 29f8555..825ed52 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -49,6 +49,8 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+#include 
+
 int sysctl_panic_on_oom;
 int sysctl_oom_kill_allocating_task;
 int sysctl_oom_dump_tasks = 1;
@@ -182,6 +184,21 @@ static bool is_dump_unreclaim_slabs(void)
 }
 
 /**
+ * oom_file_badness - add per file badness
+ * @points: pointer to summed up badness points
+ * @file: tasks open file
+ * @n: file descriptor id (unused)
+ */
+static int oom_file_badness(const void *points, struct file *file, unsigned n)
+{
+   if (file->f_op->oom_file_badness)
+   *((long *)points) += file->f_op->oom_file_badness(file);
+
+   return 0;
+}
+
+
+/**
  * oom_badness - heuristic function to determine which candidate task to kill
  * @p: task struct of which task we should calculate
  * @totalpages: total present RAM allowed for page allocation
@@ -222,6 +239,12 @@ unsigned long oom_badness(struct task_struct *p, struct 
mem_cgroup *memcg,
 */
points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +
mm_pgtables_bytes(p->mm) / PAGE_SIZE;
+
+   /*
+* Add how much memory a task uses in opened files, e.g. device drivers.
+*/
+   iterate_fd(p->files, 0, oom_file_badness, );
+
task_unlock(p);
 
/*
-- 
2.7.4

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

[Bug 97886] radeon r300 vdpau broken

[bugzilla-daemon]

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

--- Comment #7 from GHPS  ---
> We no longer support the VDPAU backend for r300.
I see the point that at some moment in time the support for 
an old platform has to be ceased.

As for myself I've been using my trusty old Thinkpad T60 
since 10 years with various operating systems and drivers.
While starting with Win XP and the proprietary ATI drivers the
system became slower with every iteration of Windows rendering
it ultimately useless under Windows 10. Switching to Kubuntu 14.04
not only made the old hardware usable again but showed the surprising
effect that the machine becomes faster with every release cycle of kernel
and drivers. 

That my Thinkpad now is more usable than it ever was is
in parts a result of the great work of the Mesa team. They - You! - 
developed a driver that is much better than ATI’s original work.

Therefore I regret that the r300 platform is no longer supported.

More so since the vdpau driver seemed to be working fine in previous
versions, the initial bug report is from September 2016 and a patch
was submitted to fix the problem.

And the bug bites every user who is trying to play back mpeg1/mpeg2 content 
- DVDs - since VLC and other players silently rely on vpdau.

So it would be very kind if a developer would take a second look at the
problem.

-- 
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/i915/dp: Fix compilation of intel_dp_hdcp_check_link

[Chris Wilson]

drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’:
drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in 
boolean context [-Werror=int-in-bool-context]
   return ret >= 0 ? -EIO : ret;

Fixes: 20f24d776d1b ("drm/i915: Implement HDCP for DisplayPort")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ramalingam C 
Cc: Sean Paul 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 68229f53d5b8..0f2290c7bede 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5184,12 +5184,14 @@ bool intel_dp_hdcp_check_link(struct intel_digital_port 
*intel_dig_port)
 {
ssize_t ret;
u8 bstatus;
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
   , 1);
if (ret != 1) {
DRM_ERROR("Read bstatus from DP/AUX failed (%zd)\n", ret);
-   return ret >= 0 ? -EIO : ret;
+   return false;
}
+
return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
 }
 
-- 
2.15.1

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

Re: [PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[Ville Syrjälä]

On Thu, Jan 18, 2018 at 09:11:19PM +0530, ankit.k.nauti...@intel.com wrote:
> Hi Marteen,
> 
> Thanks for the review comments. Please find my comments in-line.
> 
> 
> On Thursday 18 January 2018 03:46 PM, Maarten Lankhorst wrote:
> > Op 12-01-18 om 07:21 schreef Nautiyal, Ankit K:
> >> From: Ankit Nautiyal 
> >>
> >> A new drm client cap is required to enable user-space to advertise
> >> if it supports modes with aspect-ratio. Based on this cap value, the
> >> kernel will take a call on exposing the aspect ratio information in
> >> modes or not.
> >>
> >> This patch adds the client cap for aspect-ratio.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Shashank Sharma 
> >> Signed-off-by: Ankit Nautiyal 
> > What's missing from the commit message is why this needs to be a flag that 
> > userspace needs to enable,
> > instead of something that only counts as an informative query.
> >
> > I gathered from danvet that blindly exposing things breaks existing 
> > userspace, so could that information be added to the commit?
> 
> Agreed. This information indeed brings out the real reason for the patch.
> Will add the details in the commit message in the next patch-set.
> 
> >
> > Also missing IGT tests, would be nice we at least get some verification 
> > things work as expected.
> 
> Currently this is being tested with the corresponding userspace changes 
> in weston compositor, but a simple IGT on the same lines of kms_3d
> can be prepared.

A separate test to check that the different aspect ratio modes are
correctly enumerated, and filtered out when the cap is not set seems
like a good idea.

As for actaully testing different aspect ratio modes, maybe just
intergrate that into testdisplay?

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

Re: [PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[ankit.k.nauti...@intel.com]

Hi Marteen,

Thanks for the review comments. Please find my comments in-line.


On Thursday 18 January 2018 03:46 PM, Maarten Lankhorst wrote:

Op 12-01-18 om 07:21 schreef Nautiyal, Ankit K:

From: Ankit Nautiyal 

A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

What's missing from the commit message is why this needs to be a flag that 
userspace needs to enable,
instead of something that only counts as an informative query.

I gathered from danvet that blindly exposing things breaks existing userspace, 
so could that information be added to the commit?


Agreed. This information indeed brings out the real reason for the patch.
Will add the details in the commit message in the next patch-set.



Also missing IGT tests, would be nice we at least get some verification things 
work as expected.


Currently this is being tested with the corresponding userspace changes 
in weston compositor, but a simple IGT on the same lines of kms_3d
can be prepared. Will work on that and include the reference in this 
series. I hope in the meanwhile, the other patches of the series would 
be continued

to be reviewed.


~Maarten

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

[PATCH] drm/ast: Load lut in crtc_commit

[Daniel Vetter]

In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But since

commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin 
Date:   Tue Jul 4 12:36:57 2017 +0200

drm/fb-helper: factor out pseudo-palette

that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.

Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin 
Cc: Daniel Vetter 
Cc:  # v4.14+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Cc: Bill Fraser 
Reported-and-Tested-by: Bill Fraser 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/ast/ast_mode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 9555a3542022..831b73392d82 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -644,6 +644,7 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
 {
struct ast_private *ast = crtc->dev->dev_private;
ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0);
+   ast_crtc_load_lut(crtc);
 }
 
 
-- 
2.15.1

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

[Bug 104683] WebGL crashes the kernel driver and Xorg

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Version|17.3|git

--- Comment #1 from Michel Dänzer  ---
Reproducible with Firefox 57.0.3 using Mesa Git master on

OpenGL renderer string: AMD Radeon HD 7700 Series (CAPE VERDE / DRM 3.23.0 /
4.14.13+, LLVM 7.0.0)

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

Re: [PATCH v1 08/15] drm/i2c: tda998x: Remove duplicate NULL check

[Ville Syrjälä]

On Tue, Oct 31, 2017 at 05:03:43PM +, Russell King - ARM Linux wrote:
> On Tue, Oct 31, 2017 at 04:21:42PM +0200, Andy Shevchenko wrote:
> > Since i2c_unregister_device() became NULL-aware we may remove duplicate
> > NULL check.
> > 
> > Cc: Russell King 
> 
> Acked-by: Russell King 

commit 7b43dd19c9b1 ("i2c: Make i2c_unregister_device() NULL-aware")
seems to be the thing that makes this possible. So these three
patches lgtm -> pushed to drm-misc-next.

> 
> Thanks.
> 
> > Cc: David Airlie 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  drivers/gpu/drm/i2c/tda998x_drv.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > index 4d1f45acf2cd..7a349e85f964 100644
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -1602,8 +1602,7 @@ static int tda998x_create(struct i2c_client *client, 
> > struct tda998x_priv *priv)
> > /* if encoder_init fails, the encoder slave is never registered,
> >  * so cleanup here:
> >  */
> > -   if (priv->cec)
> > -   i2c_unregister_device(priv->cec);
> > +   i2c_unregister_device(priv->cec);
> > return -ENXIO;
> >  }
> >  
> > -- 
> > 2.14.2
> > 
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #9 from Vedran Miletić  ---
Same on RX580 (polaris10).

-- 
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 104685] [polaris10] amdgpu 0000:01:00.0: swiotlb buffer is full

[bugzilla-daemon]

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

--- Comment #2 from Vedran Miletić  ---
Whoops. First time observed here, thought it was rare, should have searched.
Sorry.

-- 
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 v2] drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

[Boris Brezillon]

When saving BOs in the hang state we skip one entry of the
kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL
pointer dereference when, later in this function, we iterate over all
BOs to check their ->madv state.

Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
rendering jobs")
Cc: 
Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Get rid of prev_idx an replace it by k which is indepently incremented
  every time a new object is added to kernel_state->bo[].
- Add a WARN_ON_ONCE() when final value of k is inconsistent
---
 drivers/gpu/drm/vc4/vc4_gem.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 6c32c89a83a9..3216f12052fe 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -146,7 +146,7 @@ vc4_save_hang_state(struct drm_device *dev)
struct vc4_exec_info *exec[2];
struct vc4_bo *bo;
unsigned long irqflags;
-   unsigned int i, j, unref_list_count, prev_idx;
+   unsigned int i, j, k, unref_list_count;
 
kernel_state = kcalloc(1, sizeof(*kernel_state), GFP_KERNEL);
if (!kernel_state)
@@ -182,7 +182,7 @@ vc4_save_hang_state(struct drm_device *dev)
return;
}
 
-   prev_idx = 0;
+   k = 0;
for (i = 0; i < 2; i++) {
if (!exec[i])
continue;
@@ -197,7 +197,7 @@ vc4_save_hang_state(struct drm_device *dev)
WARN_ON(!refcount_read(>usecnt));
refcount_inc(>usecnt);
drm_gem_object_get([i]->bo[j]->base);
-   kernel_state->bo[j + prev_idx] = [i]->bo[j]->base;
+   kernel_state->bo[k++] = [i]->bo[j]->base;
}
 
list_for_each_entry(bo, [i]->unref_list, unref_head) {
@@ -205,12 +205,12 @@ vc4_save_hang_state(struct drm_device *dev)
 * because they are naturally unpurgeable.
 */
drm_gem_object_get(>base.base);
-   kernel_state->bo[j + prev_idx] = >base.base;
-   j++;
+   kernel_state->bo[k++] = >base.base;
}
-   prev_idx = j + 1;
}
 
+   WARN_ON_ONCE(k != state->bo_count);
+
if (exec[0])
state->start_bin = exec[0]->ct0ca;
if (exec[1])
-- 
2.11.0

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

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

[Boris Brezillon]

On Thu, 18 Jan 2018 10:23:54 +0530
Archit Taneja  wrote:

> Add a section that describes dt-bindings for peripherals that support
> MIPI DSI, but have a different bus as the primary control bus, or no
> control bus at all. Add an example for a peripheral with a non-DSI
> control bus.
> 
> Signed-off-by: Archit Taneja 

Reviewed-by: Boris Brezillon 

Thanks for this clarification.

Boris

> ---
> v2:
> - Mentioned what to do if peripheral has no control bus
> - Drop unit-address and #*-cells where applicable.
> 
>  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 71 
> +++---
>  1 file changed, 64 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 973c27273772..94fb72cb916f 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -16,7 +16,7 @@ The following assumes that only a single peripheral is 
> connected to a DSI
>  host. Experience shows that this is true for the large majority of setups.
>  
>  DSI host
> -
> +
>  
>  In addition to the standard properties and those defined by the parent bus of
>  a DSI host, the following properties apply to a node representing a DSI host.
> @@ -30,11 +30,16 @@ Required properties:
>different value here. See below.
>  
>  DSI peripheral
> ---
> +==
>  
> -Peripherals are represented as child nodes of the DSI host's node. Properties
> -described here apply to all DSI peripherals, but individual bindings may want
> -to define additional, device-specific properties.
> +Peripherals with DSI as control bus, or no control bus
> +--
> +
> +Peripherals with the DSI bus as the primary control bus, or peripherals with
> +no control bus but use the DSI bus to transmit pixel data are represented
> +as child nodes of the DSI host's node. Properties described here apply to all
> +DSI peripherals, but individual bindings may want to define additional,
> +device-specific properties.
>  
>  Required properties:
>  - reg: The virtual channel number of a DSI peripheral. Must be in the range
> @@ -49,9 +54,25 @@ case two alternative representations can be chosen:
>property is the number of the first virtual channel and the second cell is
>the number of consecutive virtual channels.
>  
> -Example
> 
> +Peripherals with a different control bus
> +
> +
> +There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
> +primary control bus, but are also connected to a DSI bus (mostly for the data
> +path). Connections between such peripherals and a DSI host can be represented
> +using the graph bindings [1], [2].
> +
> +[1] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> +Examples
> +
> +- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
> +  with different virtual channel configurations.
> +- (4) is an example of a peripheral on a I2C control bus connected with to
> +  a DSI host using of-graph bindings.
> +
> +1)
>   dsi-host {
>   ...
>  
> @@ -67,6 +88,7 @@ Example
>   ...
>   };
>  
> +2)
>   dsi-host {
>   ...
>  
> @@ -82,6 +104,7 @@ Example
>   ...
>   };
>  
> +3)
>   dsi-host {
>   ...
>  
> @@ -96,3 +119,37 @@ Example
>  
>   ...
>   };
> +
> +4)
> + i2c-host {
> + ...
> +
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + ...
> +
> + port {
> + bridge_mipi_in: endpoint {
> + remote-endpoint = 
> <_mipi_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi-host {
> + ...
> +
> + ports {
> + ...
> +
> + port {
> + host_mipi_out: endpoint {
> + remote-endpoint = <_mipi_in>;
> + };
> + };
> + };
> + };

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

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

[Noralf Trønnes]

Den 18.01.2018 13.07, skrev Meghana Madhyastha:

On Tue, Jan 16, 2018 at 06:08:53PM +0100, Noralf Trønnes wrote:

Den 16.01.2018 11.36, skrev Meghana Madhyastha:

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

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

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

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

I have a quick question here. So devm_of_find_backlight automatically
does a put_device on detachment of the driver. However in this case,
put_device is called when panel_add is not successful (i.e when it
returns a negative value here). So is devm's release mechanism still
invoked here ?


As long as the error is propagated back up the chain, which it is in this
case, devres_release_all() is called and the resources are released.

Driver callchain passing up the error:
innolux_panel_driver.probe = innolux_panel_probe <- innolux_panel_add <- 
devm_of_find_backlight


This is mipi_dsi setting up the probe hook and calling into it's own 
version:


drivers/gpu/drm/drm_mipi_dsi.c:
int mipi_dsi_driver_register_full(struct mipi_dsi_driver *drv,
                  struct module *owner)
{
...
    if (drv->probe)
        drv->driver.probe = mipi_dsi_drv_probe;
...
}

static int mipi_dsi_drv_probe(struct device *dev)
{
    struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
    struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);

    return drv->probe(dsi);
}

This is the device-driver core that initiates the probing:

drivers/base/dd.c
static int really_probe(struct device *dev, struct device_driver *drv)
{
...
    } else if (drv->probe) {
        ret = drv->probe(dev);
        if (ret)
            goto probe_failed;
    }
...
probe_failed:
...
    devres_release_all(dev);
...
}


err = drm_panel_add(>base);
if (err < 0)
goto put_backlight;

return 0;

put_backlight:
put_device(>backlight->dev);
return err;

If so then I should change this to
err = drm_panel_add(>base)
return err;


Yes, and you can drop the variable:

    return drm_panel_add(>base);

Noralf.



Thanks and regards,
Meghana


I haven't checked the other drivers.

Noralf.

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


-   if (!innolux->backlight)
-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(innolux->backlight))
+   return PTR_ERR(innolux->backlight);
drm_panel_init(>base);
innolux->base.funcs = _panel_funcs;
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 1512ec4f3..d5450c9d9 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -329,14 +329,10 @@ static int sharp_panel_add(struct sharp_panel *sharp)
if (IS_ERR(sharp->supply))
return PTR_ERR(sharp->supply);
-   np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);
-   if (np) {
-   sharp->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   sharp->backlight = devm_of_find_backlight(np);
-   if (!sharp->backlight)
-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(sharp->backlight))
+   return PTR_ERR(sharp->backlight);
drm_panel_init(>base);
sharp->base.funcs = _panel_funcs;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index a6af3257f..db31d8268 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -273,14 +273,10 @@ static int sharp_nt_panel_add(struct sharp_nt_panel 
*sharp_nt)

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||ved...@miletic.net

--- Comment #8 from Alex Deucher  ---
*** Bug 104685 has been marked as a duplicate of this bug. ***

-- 
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 104685] [polaris10] amdgpu 0000:01:00.0: swiotlb buffer is full

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 104082 ***

-- 
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 104685] [polaris10] amdgpu 0000:01:00.0: swiotlb buffer is full

[bugzilla-daemon]

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

Bug ID: 104685
   Summary: [polaris10] amdgpu :01:00.0: swiotlb buffer is
full
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net

The GPU is:

01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere
[Radeon RX 580] [1002:aaf0]

I'm using BOOT_IMAGE=/boot/vmlinuz-4.15.0-0.rc8.git1.1.fc28.x86_64
root=UUID=fcbff019-0fbb-41ba-885d-438e196bc269 ro selinux=0 rhgb quiet audit=0
amdgpu.dc=1 amdgpu.dc_log=1 LANG=en_US.UTF-8

Normal desktop work got me:

[ 1230.223709] amdgpu :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ 1230.223722] swiotlb: coherent allocation failed for device :01:00.0
size=2097152
[ 1230.223725] CPU: 2 PID: 1674 Comm: Xwayland Not tainted
4.15.0-0.rc8.git1.1.fc28.x86_64 #1
[ 1230.223726] Hardware name: Transtec AG/B85M-E, BIOS 3507 07/21/2017
[ 1230.223727] Call Trace:
[ 1230.223732]  dump_stack+0x85/0xbf
[ 1230.223736]  swiotlb_alloc_coherent+0xe0/0x150
[ 1230.223743]  ttm_dma_pool_get_pages+0x218/0x620 [ttm]
[ 1230.223752]  ttm_dma_populate+0x24d/0x340 [ttm]
[ 1230.223758]  ttm_tt_bind+0x23/0x50 [ttm]
[ 1230.223762]  ttm_bo_handle_move_mem+0x58c/0x5c0 [ttm]
[ 1230.223770]  ttm_bo_validate+0x19c/0x1b0 [ttm]
[ 1230.223775]  ? copy_page_regs+0x1d/0xe0
[ 1230.223780]  ttm_bo_init_reserved+0x46b/0x510 [ttm]
[ 1230.223809]  amdgpu_bo_do_create+0x1b0/0x4f0 [amdgpu]
[ 1230.223827]  ? amdgpu_fill_buffer+0x300/0x300 [amdgpu]
[ 1230.223849]  amdgpu_bo_create+0x50/0x2b0 [amdgpu]
[ 1230.223870]  amdgpu_gem_object_create+0x7f/0x110 [amdgpu]
[ 1230.223889]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[ 1230.223904]  amdgpu_gem_create_ioctl+0x1e8/0x280 [amdgpu]
[ 1230.223923]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[ 1230.223934]  drm_ioctl_kernel+0x59/0xb0 [drm]
[ 1230.223942]  drm_ioctl+0x2d5/0x370 [drm]
[ 1230.223957]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[ 1230.223962]  ? __pm_runtime_resume+0x54/0x90
[ 1230.223966]  ? trace_hardirqs_on_caller+0xed/0x180
[ 1230.223983]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 1230.223987]  do_vfs_ioctl+0xa2/0x6d0
[ 1230.223992]  ? __fget+0x125/0x210
[ 1230.223995]  SyS_ioctl+0x74/0x80
[ 1230.224000]  entry_SYSCALL_64_fastpath+0x25/0x9c
[ 1230.224002] RIP: 0033:0x7f9fc317a877
[ 1230.224003] RSP: 002b:7ffdbf6e0038 EFLAGS: 0246
[ 1236.389537] amdgpu :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ 1236.389541] swiotlb: coherent allocation failed for device :01:00.0
size=2097152
[ 1236.389543] CPU: 6 PID: 1674 Comm: Xwayland Not tainted
4.15.0-0.rc8.git1.1.fc28.x86_64 #1
[ 1236.389545] Hardware name: Transtec AG/B85M-E, BIOS 3507 07/21/2017
[ 1236.389546] Call Trace:
[ 1236.389552]  dump_stack+0x85/0xbf
[ 1236.389556]  swiotlb_alloc_coherent+0xe0/0x150
[ 1236.389564]  ttm_dma_pool_get_pages+0x218/0x620 [ttm]
[ 1236.389573]  ttm_dma_populate+0x24d/0x340 [ttm]
[ 1236.389579]  ttm_tt_bind+0x23/0x50 [ttm]
[ 1236.389583]  ttm_bo_handle_move_mem+0x58c/0x5c0 [ttm]
[ 1236.389591]  ttm_bo_validate+0x19c/0x1b0 [ttm]
[ 1236.389598]  ? copy_page_regs+0x1d/0xe0
[ 1236.389603]  ttm_bo_init_reserved+0x46b/0x510 [ttm]
[ 1236.389635]  amdgpu_bo_do_create+0x1b0/0x4f0 [amdgpu]
[ 1236.389665]  ? amdgpu_fill_buffer+0x300/0x300 [amdgpu]
[ 1236.389686]  amdgpu_bo_create+0x50/0x2b0 [amdgpu]
[ 1236.389707]  amdgpu_gem_object_create+0x7f/0x110 [amdgpu]
[ 1236.389726]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[ 1236.389741]  amdgpu_gem_create_ioctl+0x1e8/0x280 [amdgpu]
[ 1236.389759]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[ 1236.389771]  drm_ioctl_kernel+0x59/0xb0 [drm]
[ 1236.389778]  drm_ioctl+0x2d5/0x370 [drm]
[ 1236.389804]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[ 1236.389809]  ? __pm_runtime_resume+0x54/0x90
[ 1236.389814]  ? trace_hardirqs_on_caller+0xed/0x180
[ 1236.389842]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 1236.389846]  do_vfs_ioctl+0xa2/0x6d0
[ 1236.389852]  ? __fget+0x125/0x210
[ 1236.389855]  SyS_ioctl+0x74/0x80
[ 1236.389860]  entry_SYSCALL_64_fastpath+0x25/0x9c
[ 1236.389863] RIP: 0033:0x7f9fc317a877
[ 1236.389864] RSP: 002b:7ffdbf6e0038 EFLAGS: 0246
[ 1280.781784] amdgpu :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ 1280.781788] swiotlb: coherent allocation failed for device :01:00.0
size=2097152
[ 1280.781791] CPU: 3 PID: 1674 Comm: Xwayland Not tainted
4.15.0-0.rc8.git1.1.fc28.x86_64 #1
[ 1280.781793] Hardware name: Transtec AG/B85M-E, BIOS 3507 07/21/2017
[ 1280.781795] Call Trace:
[ 1280.781803]  dump_stack+0x85/0xbf
[ 1280.781808]  swiotlb_alloc_coherent+0xe0/0x150
[ 1280.781816]  ttm_dma_pool_get_pages+0x218/0x620 [ttm]
[ 1280.781825]  ttm_dma_populate+0x24d/0x340 [ttm]
[ 1280.781831]  

Re: [PATCH] drm/vc4: Flush the caches before the bin jobs, as well.

[Boris Brezillon]

On Thu, 21 Dec 2017 14:17:22 -0800
Eric Anholt  wrote:

> If the frame samples from a render target that was just written, its
> cache flush during the binning step may have occurred before the
> previous frame's RCL was completed.  Flush the texture caches again
> before starting each RCL job to make sure that the sampling of the
> previous RCL's output is correct.
> 
> Fixes flickering in the top left of 3DMMES Taiji.
> 
> Signed-off-by: Eric Anholt 
> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
> rendering jobs")

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/vc4/vc4_gem.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 6c32c89a83a9..afa7fe21b35e 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -436,6 +436,19 @@ vc4_flush_caches(struct drm_device *dev)
> VC4_SET_FIELD(0xf, V3D_SLCACTL_ICC));
>  }
>  
> +static void
> +vc4_flush_texture_caches(struct drm_device *dev)
> +{
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> +
> + V3D_WRITE(V3D_L2CACTL,
> +   V3D_L2CACTL_L2CCLR);
> +
> + V3D_WRITE(V3D_SLCACTL,
> +   VC4_SET_FIELD(0xf, V3D_SLCACTL_T1CC) |
> +   VC4_SET_FIELD(0xf, V3D_SLCACTL_T0CC));
> +}
> +
>  /* Sets the registers for the next job to be actually be executed in
>   * the hardware.
>   *
> @@ -474,6 +487,14 @@ vc4_submit_next_render_job(struct drm_device *dev)
>   if (!exec)
>   return;
>  
> + /* A previous RCL may have written to one of our textures, and
> +  * our full cache flush at bin time may have occurred before
> +  * that RCL completed.  Flush the texture cache now, but not
> +  * the instructions or uniforms (since we don't write those
> +  * from an RCL).
> +  */
> + vc4_flush_texture_caches(dev);
> +
>   submit_cl(dev, 1, exec->ct1ca, exec->ct1ea);
>  }
>  

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

[PATCH v5 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
Acked-by: Rob Herring 
---
Changes in v5:
- Add optional reset line for the peripheral/APB logic

Changes in v4:
- Rename DSI clks (suggested by Tomi)
- Drop the IP version in the compatible since it can be extracted from
  a register (suggested by Andrzej)

Changes in v3:
- Fix clock names in the example
- Document how to represent DSI devices that are controller through
  an external bus like I2C or SPI

Changes in v2:
- None
---
 .../bindings/display/bridge/cdns,dsi.txt   | 113 +
 1 file changed, 113 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..785141e302c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,113 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Optional properties:
+- resets: DSI reset lines.
+- reset-names: can contain "dsi_p_rst".
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  2 ports are available:
+  * port 0: this port is only needed if some of your DSI devices are
+   controlled through  an external bus like I2C or SPI. Can have at
+   most 4 endpoints. The endpoint number is directly encoding the
+   DSI virtual channel used by this device.
+  * port 1: represents the DPI input.
+  Other ports will be added later to support the new kind of inputs.
+
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its virtual channel.
+
+Example:
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi-1.3.1";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
+or
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dsi0_output: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_panel_input>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+   };
+
+   i2c@xxx {
+   panel: panel@59 {
+   compatible = "";
+   reg = <0x59>;
+
+   port {
+   dsi_panel_input: endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+   };
+   };
-- 
2.11.0

[PATCH v5 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Add a driver for Cadence DPI -> DSI bridge.

This driver only support a subset of Cadence DSI bridge capabilities.

Here is a non-exhaustive list of missing features:
 * burst mode
 * DPHY init/configuration steps
 * support for additional input interfaces (SDI input)

Signed-off-by: Boris Brezillon 
Reviewed-by: Andrzej Hajda 
Acked-by: Eric Anholt 
---
Hello,

This version is still missing DPHY config/init code, mainly because I
don't have a DPHY (either real or emulated) to test with. But I'm
working on a DPHY abstraction layer to help extract common DPHY
operations out of DSI drivers so that DPHY drivers can be used outside
of the DRM world (I know D-PHYs can be used with CSI which belongs in
V4L).

Regards,

Boris

This version is still missing
Changes in v5:
- Add runtime PM support

Changes in v4:
- Fix typos
- Rename clks as suggested by Tomi
- Fix DSI setup done in cdns_dsi_bridge_enable()
- Add a precision about where this bridge is supposed to used to the
  Kconfig entry
- Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE
- Remove the IP version from the DT compatible name
- Adapt register the layout to match the one used in the last revision
  of the IP (hopefully the final version)

Changes in v3:
- replace magic values by real timing calculation. The DPHY PLL clock
  is still hardcoded since we don't have a working DPHY block yet, and
  this is the piece of HW we need to dynamically configure the PLL
  rate based on the display refresh rate and the resolution.
- parse DSI devices represented with the OF-graph. This is needed to
  support DSI devices controlled through an external bus like I2C or
  SPI.
- use the DRM panel-bridge infrastructure to simplify the DRM panel
  logic

Changes in v2:
- rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
- return the correct error when devm_clk_get(sysclk) fails
- add missing depends on OF and select DRM_PANEL in the Kconfig entry

DSI runtime PM
---
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1123 +
 3 files changed, 1134 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a06c16..acd5b6b9ffc9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e3d5eb031f18..a0fbf0fe5f69 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..c7f999522642
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1123 @@
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IP_CONF0x0
+#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
+#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
+#define VRS_FIFO_DEPTH(x)  (((x) & GENMASK(20, 16)) >> 16)
+#define DIRCMD_FIFO_DEPTH(x)   (((x) & GENMASK(15, 13)) >> 13)
+#define SDI_IFACE_32   BIT(12)

[Bug 104683] WebGL crashes the kernel driver and Xorg

[bugzilla-daemon]

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

Bug ID: 104683
   Summary: WebGL crashes the kernel driver and Xorg
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: freedesk...@linux-geek.org
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136827
  --> https://bugs.freedesktop.org/attachment.cgi?id=136827=edit
kernel log

Running the GraphicsFuzz benchmark
(https://www.graphicsfuzz.com/benchmark/android-v1.html) on Chromium
63.0.3239.132. On shader 15, Xorg briefly freezes and then Xorg and the radeon
kernel driver crash. This is on an Arch Linux with mesa 17.3.2.

$ glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: AMD PITCAIRN (DRM 2.50.0 / 4.14.13-1-ARCH, LLVM 5.0.1)

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

Re: [PATCH v2] drm/bridge/synopsys: dsi: add optional pixel clock

[Philippe CORNU]

Hi Brian,

On 01/15/2018 06:11 PM, Andrzej Hajda wrote:
> On 15.01.2018 15:40, Philippe CORNU wrote:
>> Hi Andrzej,
>>
>> On 01/15/2018 02:52 PM, Andrzej Hajda wrote:
>>> On 12.01.2018 17:25, Philippe Cornu wrote:
 The pixel clock is optional. When available, it offers a better
 preciseness for timing computations and allows to reduce the extra dsi
 bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependent).

 Signed-off-by: Philippe Cornu 
 ---
 Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
 (thanks to Philipp Zabel & Andrzej Hajda comments)

drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 26 
 --
1 file changed, 20 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
 b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 index c39c7dce20ed..62fcff881b98 100644
 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 @@ -225,6 +225,7 @@ struct dw_mipi_dsi {
void __iomem *base;

struct clk *pclk;
 +  struct clk *px_clk;

unsigned int lane_mbps; /* per lane */
u32 channel;
 @@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge 
 *bridge,
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = 
 dsi->plat_data->phy_ops;
void *priv_data = dsi->plat_data->priv_data;
 +  struct drm_display_mode px_clk_mode = *mode;
int ret;

clk_prepare_enable(dsi->pclk);

 -  ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
 +  if (dsi->px_clk)
 +  px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
 +
 +  ret = phy_ops->get_lane_mbps(priv_data, _clk_mode, dsi->mode_flags,
 dsi->lanes, dsi->format, 
 >lane_mbps);
if (ret)
DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");

pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
 -  dw_mipi_dsi_dpi_config(dsi, mode);
 +  dw_mipi_dsi_dpi_config(dsi, _clk_mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
 -  dw_mipi_dsi_video_packet_config(dsi, mode);
 +  dw_mipi_dsi_video_packet_config(dsi, _clk_mode);
dw_mipi_dsi_command_mode_config(dsi);
 -  dw_mipi_dsi_line_timer_config(dsi, mode);
 -  dw_mipi_dsi_vertical_timing_config(dsi, mode);
 +  dw_mipi_dsi_line_timer_config(dsi, _clk_mode);
 +  dw_mipi_dsi_vertical_timing_config(dsi, _clk_mode);

dw_mipi_dsi_dphy_init(dsi);
dw_mipi_dsi_dphy_timing_config(dsi);
 @@ -784,7 +789,7 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge 
 *bridge,

dw_mipi_dsi_dphy_enable(dsi);

 -  dw_mipi_dsi_wait_for_two_frames(mode);
 +  dw_mipi_dsi_wait_for_two_frames(_clk_mode);

/* Switch to cmd mode for panel-bridge pre_enable & panel 
 prepare */
dw_mipi_dsi_set_mode(dsi, 0);
 @@ -878,6 +883,15 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
return ERR_PTR(ret);
}

 +  dsi->px_clk = devm_clk_get(dev, "px_clk");
 +  if (PTR_ERR(dsi->px_clk) == -ENOENT) {
 +  dsi->px_clk = NULL;
 +  } else if (IS_ERR(dsi->px_clk)) {
 +  ret = PTR_ERR(dsi->px_clk);
 +  dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
 +  dsi->px_clk = NULL;
 +  }
 +
>>> As I understand on fail you just log an error and continue?
>>> The code could be slightly simplified, for example:
>>> dsi->px_clk = devm_clk_get(dev, "px_clk");
>>> if (IS_ERR(dsi->px_clk)) {
>>>           ret = PTR_ERR(dsi->px_clk);
>>>           if (ret != ENOENT)
>>>                   dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
>>>           dsi->px_clk = NULL;
>>> }
>>>
>>> With or without this change:
>>>
>>> Reviewed-by: Andrzej Hajda 
>>>
>> Thanks for your review.
>>
>> Yes in this version, on fail, I just log an error and continue,
>> especially because this px_clk is "optional" in the documentation. Then
>> your proposal is much better than mine : )
>>
>> Nevertheless, I wonder now if it could be better to "return" in case of
>> error as we do for others mandatory clocks...
>> So then, the code could be:
>>
>> dsi->px_clk = devm_clk_get(dev, "px_clk");
>> if (IS_ERR(dsi->px_clk)) {
>>  dsi->px_clk = NULL;
>>  ret = PTR_ERR(dsi->px_clk);
>>  if (ret != ENOENT) {
>>  dev_err(dev, "Unable to get optional px_clk: 

Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

[Emil Velikov]

On 17 January 2018 at 16:37, Daniel Thompson  wrote:
>
>
> On 17/01/18 14:36, Emil Velikov wrote:
>>
>> On 17 January 2018 at 14:01, Daniel Vetter  wrote:
>>>
>>> Nothing in the entire tree ever sets this, which means this is dead
>>> code. Remove it.
>>>
>>> Cc: Lee Jones 
>>> Cc: Daniel Thompson 
>>> Cc: Jingoo Han 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>>   drivers/video/backlight/generic_bl.c | 5 -
>>
>>
>> Fly-by comment, while waiting for coffee to kick-in.
>> I think this patch should be after pandora/others have stopped abusing
>> BL_CORE_DRIVER1.
>
>
> You sure?
>
> I can't see why the use or disuse of BL_CORE_DRIVER1 in this driver should
> influence another independent driver.
>
Right my bad. Got mislead by the driver name.

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

Re: [PATCH v3 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Neil Armstrong]

On 17/01/2018 21:14, Jernej Skrabec wrote:
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of the Synopsys PHY
> related code could be reused.
> 
> Functions exported here are actually not specific to Synopsys PHYs but
> to DWC HDMI controller PHY interface. This means that even if the PHY is
> completely custom, i.e. not designed by Synopsys, exported functions can
> be useful.
> 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 
> +--
>  drivers/gpu/drm/meson/meson_dw_hdmi.c |  8 +++---
>  include/drm/bridge/dw_hdmi.h  | 11 
>  3 files changed, 45 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 7ca14d7325b5..7d80f4b56683 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
> *hdmi, u8 enable)
>HDMI_PHY_CONF0_SVSRET_MASK);
>  }
>  
> -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
>HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
>  
> -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
>HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
>  
>  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
>  {
> @@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct 
> dw_hdmi *hdmi, u8 enable)
>HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
>  
> +void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
> +{
> + /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> + hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> + hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
> +
> +void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
> +{
> + hdmi_phy_test_clear(hdmi, 1);
> + hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
> + hdmi_phy_test_clear(hdmi, 0);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
> +
>  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  {
>   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> @@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   if (phy->has_svsret)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
>  
> - /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> + dw_hdmi_phy_reset(hdmi);
>  
>   hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
>  
> - hdmi_phy_test_clear(hdmi, 1);
> - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> - HDMI_PHY_I2CM_SLAVE_ADDR);
> - hdmi_phy_test_clear(hdmi, 0);
> + dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
>  
>   /* Write to the PHY as configured by the platform */
>   if (pdata->configure_phy)
> @@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
> void *data)
>   dw_hdmi_phy_power_off(hdmi);
>  }
>  
> -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> -   void *data)
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data)
>  {
>   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
>   connector_status_connected : connector_status_disconnected;
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
>  
> -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> -bool force, bool disabled, bool rxsense)
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense)
>  {
>   u8 old_mask = hdmi->phy_mask;
>  
> @@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi 
> *hdmi, void *data,
>   if (old_mask != hdmi->phy_mask)
>   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>  }
> 

Re: [PATCH v3 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Neil Armstrong]

On 17/01/2018 21:14, Jernej Skrabec wrote:
> dw_hdmi shouldn't set drvdata since some drivers might need to store
> it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
> instead to store it in drvdata. This way drivers are responsible to
> store and pass structure when needed.
> 
> Idea was taken from the following commit:
> 8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")
> 
> Cc: p.za...@pengutronix.de
> Cc: narmstr...@baylibre.com
> Cc: laurent.pinch...@ideasonboard.com
> Cc: h...@rock-chips.com
> Cc: he...@sntech.de
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 31 
> -
>  drivers/gpu/drm/imx/dw_hdmi-imx.c   | 13 +---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +
>  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 12 +--
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
>  include/drm/bridge/dw_hdmi.h| 13 ++--
>  6 files changed, 60 insertions(+), 36 deletions(-)
> 

[...]
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index e8c3ef8a94ce..d49af17310c9 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -140,6 +140,7 @@ struct meson_dw_hdmi {
>   struct clk *venci_clk;
>   struct regulator *hdmi_supply;
>   u32 irq_stat;
> + struct dw_hdmi *hdmi;
>  };
>  #define encoder_to_meson_dw_hdmi(x) \
>   container_of(x, struct meson_dw_hdmi, encoder)
> @@ -878,9 +879,12 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
> device *master,
>   dw_plat_data->input_bus_format = MEDIA_BUS_FMT_YUV8_1X24;
>   dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709;
>  
> - ret = dw_hdmi_bind(pdev, encoder, _dw_hdmi->dw_plat_data);
> - if (ret)
> - return ret;
> + platform_set_drvdata(pdev, meson_dw_hdmi);
> +
> + meson_dw_hdmi->hdmi = dw_hdmi_bind(pdev, encoder,
> +_dw_hdmi->dw_plat_data);
> + if (IS_ERR(meson_dw_hdmi->hdmi))
> + return PTR_ERR(meson_dw_hdmi->hdmi);
>  
>   DRM_DEBUG_DRIVER("HDMI controller initialized\n");
>  
> @@ -890,7 +894,9 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
> device *master,
>  static void meson_dw_hdmi_unbind(struct device *dev, struct device *master,
>  void *data)
>  {
> - dw_hdmi_unbind(dev);
> + struct meson_dw_hdmi *meson_dw_hdmi = dev_get_drvdata(dev);
> +
> + dw_hdmi_unbind(meson_dw_hdmi->hdmi);
>  }
>  
>  static const struct component_ops meson_dw_hdmi_ops = {

[..]

> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index f3f3f0e1b2d3..dd2a8cf7d20b 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -143,12 +143,13 @@ struct dw_hdmi_plat_data {
>unsigned long mpixelclock);
>  };
>  
> -int dw_hdmi_probe(struct platform_device *pdev,
> -   const struct dw_hdmi_plat_data *plat_data);
> -void dw_hdmi_remove(struct platform_device *pdev);
> -void dw_hdmi_unbind(struct device *dev);
> -int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
> -  const struct dw_hdmi_plat_data *plat_data);
> +struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
> +   const struct dw_hdmi_plat_data *plat_data);
> +void dw_hdmi_remove(struct dw_hdmi *hdmi);
> +void dw_hdmi_unbind(struct dw_hdmi *hdmi);
> +struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
> +  struct drm_encoder *encoder,
> +  const struct dw_hdmi_plat_data *plat_data);
>  
>  void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
>  
> 

For meson-drm and dw-hdmi bridge changes :
Acked-by: Neil Armstrong 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Meghana Madhyastha]

On Tue, Jan 16, 2018 at 06:08:53PM +0100, Noralf Trønnes wrote:
> 
> Den 16.01.2018 11.36, skrev Meghana Madhyastha:
> >Replace of_find_backlight_by_node and of the code around it
> >with of_find_backlight helper to avoid repetition of code.
> >
> >Signed-off-by: Meghana Madhyastha 
> >---
> >  drivers/gpu/drm/panel/panel-innolux-p079zca.c   | 10 +++---
> >  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 10 +++---
> >  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 10 +++---
> >  3 files changed, 9 insertions(+), 21 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
> >b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> >index 4c1b29eec..a69b0530f 100644
> >--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> >+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> >@@ -230,14 +230,10 @@ static int innolux_panel_add(struct innolux_panel 
> >*innolux)
> > innolux->enable_gpio = NULL;
> > }
> >-np = of_parse_phandle(dev->of_node, "backlight", 0);
> >-if (np) {
> >-innolux->backlight = of_find_backlight_by_node(np);
> >-of_node_put(np);
> >+innolux->backlight = devm_of_find_backlight(np);
> 
> This driver isn't broken like tinydrm was, so it does put the backlight
> device on cleanup like it should. So when you're using the devm_ version,
> the result is a double put. Just remove the put_device() in
> innolux_panel_add/del() and you're good.

I have a quick question here. So devm_of_find_backlight automatically
does a put_device on detachment of the driver. However in this case,
put_device is called when panel_add is not successful (i.e when it
returns a negative value here). So is devm's release mechanism still
invoked here ?

err = drm_panel_add(>base);
if (err < 0)
goto put_backlight;

return 0;

put_backlight:
put_device(>backlight->dev);
return err;

If so then I should change this to 
err = drm_panel_add(>base)
return err;

Thanks and regards,
Meghana

> I haven't checked the other drivers.
> 
> Noralf.
> 
> PS:
> Give people a few days (one week?) to respond before respinning a new
> version, so we avoid a fragmented discussion.
> 
> >-if (!innolux->backlight)
> >-return -EPROBE_DEFER;
> >-}
> >+if (IS_ERR(innolux->backlight))
> >+return PTR_ERR(innolux->backlight);
> > drm_panel_init(>base);
> > innolux->base.funcs = _panel_funcs;
> >diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
> >b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> >index 1512ec4f3..d5450c9d9 100644
> >--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> >+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
> >@@ -329,14 +329,10 @@ static int sharp_panel_add(struct sharp_panel *sharp)
> > if (IS_ERR(sharp->supply))
> > return PTR_ERR(sharp->supply);
> >-np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);
> >-if (np) {
> >-sharp->backlight = of_find_backlight_by_node(np);
> >-of_node_put(np);
> >+sharp->backlight = devm_of_find_backlight(np);
> >-if (!sharp->backlight)
> >-return -EPROBE_DEFER;
> >-}
> >+if (IS_ERR(sharp->backlight))
> >+return PTR_ERR(sharp->backlight);
> > drm_panel_init(>base);
> > sharp->base.funcs = _panel_funcs;
> >diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
> >b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> >index a6af3257f..db31d8268 100644
> >--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> >+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> >@@ -273,14 +273,10 @@ static int sharp_nt_panel_add(struct sharp_nt_panel 
> >*sharp_nt)
> > gpiod_set_value(sharp_nt->reset_gpio, 0);
> > }
> >-np = of_parse_phandle(dev->of_node, "backlight", 0);
> >-if (np) {
> >-sharp_nt->backlight = of_find_backlight_by_node(np);
> >-of_node_put(np);
> >+sharp_nt->backlight = devm_of_find_backlight(np);
> >-if (!sharp_nt->backlight)
> >-return -EPROBE_DEFER;
> >-}
> >+if (IS_ERR(sharp_nt->backlight))
> >+return PTR_ERR(sharp_nt->backlight);
> > drm_panel_init(_nt->base);
> > sharp_nt->base.funcs = _nt_panel_funcs;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Thompson]

On Thu, Jan 18, 2018 at 04:29:23PM +0530, Meghana Madhyastha wrote:
> On Wed, Jan 17, 2018 at 11:03:24PM +0100, Noralf Trønnes wrote:
> > 
> > Den 17.01.2018 18.00, skrev Daniel Thompson:
> > >
> > >
> > >On 16/01/18 10:31, Meghana Madhyastha wrote:
> > >>Add helper functions backlight_enable and backlight_disable to
> > >>enable/disable a backlight device. These helper functions can
> > >>then be used by different drm and tinydrm drivers to avoid
> > >>repetition of code and also to enforce a uniform and consistent
> > >>way to enable/disable a backlight device.
> > >>
> > >>Signed-off-by: Meghana Madhyastha 
> > >
> > >To be clear I don't disagree with anthing Daniel V. said about the
> > >horribly confused (and confusing) power states for backlight.
> > >
> > >Nevertheless I don't recall seeing any response (positive or negative) to
> > >this post from v13:
> > >https://www.spinics.net/lists/dri-devel/msg154459.html
> > >
> > 
> > I see that Daniel V has answered while I was chasing this down, but anyways:
> > 
> > A grep suggests that omap1_bl is the only driver that only checks fb_blank.
> > All the other drivers check both fb_blank and power, a few check state. The
> > backlight fbdev notifier callback doesn't set power, but sets fb_blank and
> > state.
> > 
> > fb_blank was marked 'Due to be removed' 9 years ago, so it hasn't been
> > high priority.
> > 
> > So for completeness I guess it makes sense to set fb_blank.
> 
> So if I understood correctly, the suggestion is to set fb_blank along
> with power i.e something like this in backlight_enable.
> bd->props.power = FB_BLANK_UNBLANK;
> +   bd->props.fb_blank = FB_BLANK_UNBLANK;
> bd->props.state &= ~BL_CORE_FBBLANK;
> 
> and set it to FB_BLANK_POWERDOWN in backlight_disable ?

Yes please.

Note that strictly speaking it is not "along with power" it is "along with
clearing the BL_CORE_FBBLANK bit" since that is what fb_blank must be
consistent with.


Daniel.

> 
> Thanks and regards,
> Meghana
> 
> > Noralf.
> > 
> > $ grep -r -C10 "props\.fb_blank" .
> > ./drivers/video/backlight/corgi_lcd.c-  if (bd->props.power !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/corgi_lcd.c-  intensity = 0;
> > ./drivers/video/backlight/corgi_lcd.c-
> > ./drivers/video/backlight/corgi_lcd.c:  if (bd->props.fb_blank !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/corgi_lcd.c-  intensity = 0;
> > --
> > ./drivers/video/backlight/adp8860_bl.c- if (bl->props.power !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/adp8860_bl.c- brightness = 0;
> > ./drivers/video/backlight/adp8860_bl.c-
> > ./drivers/video/backlight/adp8860_bl.c: if (bl->props.fb_blank !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/adp8860_bl.c- brightness = 0;
> > --
> > ./drivers/video/backlight/hp680_bl.c-   if (bd->props.power !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/hp680_bl.c-   intensity = 0;
> > ./drivers/video/backlight/hp680_bl.c:   if (bd->props.fb_blank !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/hp680_bl.c-   intensity = 0;
> > --
> > ./drivers/video/backlight/cr_bllcd.c-static int
> > cr_backlight_set_intensity(struct backlight_device *bd)
> > ./drivers/video/backlight/cr_bllcd.c-{
> > ./drivers/video/backlight/cr_bllcd.c-   int intensity =
> > bd->props.brightness;
> > ./drivers/video/backlight/cr_bllcd.c-   u32 addr = gpio_bar +
> > CRVML_PANEL_PORT;
> > ./drivers/video/backlight/cr_bllcd.c-   u32 cur = inl(addr);
> > ./drivers/video/backlight/cr_bllcd.c-
> > ./drivers/video/backlight/cr_bllcd.c-   if (bd->props.power ==
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/cr_bllcd.c-   intensity =
> > FB_BLANK_UNBLANK;
> > ./drivers/video/backlight/cr_bllcd.c:   if (bd->props.fb_blank ==
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/cr_bllcd.c-   intensity =
> > FB_BLANK_UNBLANK;
> > ./drivers/video/backlight/cr_bllcd.c-   if (bd->props.power ==
> > FB_BLANK_POWERDOWN)
> > ./drivers/video/backlight/cr_bllcd.c-   intensity =
> > FB_BLANK_POWERDOWN;
> > ./drivers/video/backlight/cr_bllcd.c:   if (bd->props.fb_blank ==
> > FB_BLANK_POWERDOWN)
> > ./drivers/video/backlight/cr_bllcd.c-   intensity =
> > FB_BLANK_POWERDOWN;
> > --
> > ./drivers/video/backlight/max8925_bl.c- if (bl->props.power !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/max8925_bl.c- brightness = 0;
> > ./drivers/video/backlight/max8925_bl.c-
> > ./drivers/video/backlight/max8925_bl.c: if (bl->props.fb_blank !=
> > FB_BLANK_UNBLANK)
> > ./drivers/video/backlight/max8925_bl.c- brightness = 0;
> > ./drivers/video/backlight/max8925_bl.c-
> > ./drivers/video/backlight/max8925_bl.c- if (bl->props.state &
> > BL_CORE_SUSPENDED)
> > ./drivers/video/backlight/max8925_bl.c- brightness = 0;
> > --
> > ./drivers/video/backlight/lv5207lp.c-   if (backlight->props.power !=
> > FB_BLANK_UNBLANK ||
> > 

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

[Daniel Thompson]

On Thu, Jan 18, 2018 at 04:32:26PM +0530, Meghana Madhyastha wrote:
> On Wed, Jan 17, 2018 at 05:09:57PM +, Daniel Thompson wrote:
> > On 16/01/18 10:34, Meghana Madhyastha wrote:
> > >Add devm_of_find_backlight and the corresponding release
> > >function because some drivers use devres versions of functions
> > >for acquiring device resources.
> > >
> > >Signed-off-by: Meghana Madhyastha 
> > >---
> > >  drivers/video/backlight/backlight.c | 29 +
> > >  include/linux/backlight.h   |  7 +++
> > >  2 files changed, 36 insertions(+)
> > >
> > >diff --git a/drivers/video/backlight/backlight.c 
> > >b/drivers/video/backlight/backlight.c
> > >index 7e4a5d77d..b3f76945f 100644
> > >--- a/drivers/video/backlight/backlight.c
> > >+++ b/drivers/video/backlight/backlight.c
> > >@@ -620,6 +620,35 @@ struct backlight_device *of_find_backlight(struct 
> > >device *dev)
> > >  }
> > >  EXPORT_SYMBOL(of_find_backlight);
> > >+static void devm_backlight_put(void *data)
> > >+{
> > >+  backlight_put(data);
> > 
> > Shouldn't this be using devres_release()?
> 
> backlight_put calls put_device which essentially does a release right?
> And looking at the code in other driver, looks like most of them use
> put_device (to the best of my knowledge, correct me if I'm mistaken). 

Sorry, the name confused me. I mistakenly though this was API code like
devm_gpiod_put and devm_clk_put, rather than a static method.

Whilst its my fault for overlooking the "static" please could rename this to
devm_backlight_release(). I don't want to keep being confused every time
I re-read it!


Daniel.

> 
> Thanks and regards,
> Meghana
> 
> > 
> > >+}
> > >+
> > >+/**
> > >+  * devm_of_find_backlight - Resource-managed of_find_backlight()
> > >+  * @dev: Device
> > >+  *
> > >+  * Device managed version of of_find_backlight(). The reference on the 
> > >backlight
> > >+  * device is automatically dropped on driver detach.
> > >+  */
> > >+struct backlight_device *devm_of_find_backlight(struct device *dev)
> > >+{
> > >+  struct backlight_device *bd;
> > >+  int ret;
> > >+
> > >+  bd = of_find_backlight(dev);
> > >+  if (IS_ERR_OR_NULL(bd))
> > >+  return bd;
> > >+  ret = devm_add_action(dev, devm_backlight_put, bd);
> > >+  if (ret) {
> > >+  backlight_put(bd);
> > >+  return ERR_PTR(ret);
> > >+  }
> > >+  return bd;
> > >+}
> > >+EXPORT_SYMBOL(devm_of_find_backlight);
> > >+
> > >  static void __exit backlight_class_exit(void)
> > >  {
> > >   class_destroy(backlight_class);
> > >diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> > >index 32ea510da..1d373f5a6 100644
> > >--- a/include/linux/backlight.h
> > >+++ b/include/linux/backlight.h
> > >@@ -215,11 +215,18 @@ of_find_backlight_by_node(struct device_node *node)
> > >  #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> > >  struct backlight_device *of_find_backlight(struct device *dev);
> > >+struct backlight_device *devm_of_find_backlight(struct device *dev);
> > >  #else
> > >  static inline struct backlight_device *of_find_backlight(struct device 
> > > *dev)
> > >  {
> > >   return NULL;
> > >  }
> > >+
> > >+static inline struct backlight_device *
> > >+devm_of_find_backlight(struct device *dev)
> > >+{
> > >+  return NULL;
> > >+}
> > >  #endif
> > >  #endif
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

[Philippe CORNU]

Hi Brian,

On 01/11/2018 12:16 PM, Philippe CORNU wrote:
> Hi Brian,
> 
> On 01/09/2018 07:55 PM, Brian Norris wrote:
>> Hi Philippe,
>>
>> On Tue, Jan 09, 2018 at 10:48:43AM +, Philippe CORNU wrote:
>>> Hi Brian,
>>>
>>> And many thanks for implementing these TODOs.
>>
>> And thanks for adding them; it gave me a better option than just adding
>> yet another switch case (MIPI_DSI_GENERIC_LONG_WRITE) ;)
>>
>>> On 01/06/2018 01:38 AM, Brian Norris wrote:
 This takes care of 2 TODOs in this driver, by using the common DSI
 packet-marshalling code instead of our custom short/long write code.
 This both saves us some duplicated code and gets us free support for
 command types that weren't already part of our switch block (e.g.,
 MIPI_DSI_GENERIC_LONG_WRITE).

 The code logic stays mostly intact, except that it becomes unnecessary
 to split the short/long write functions, and we have to copy data a bit
 more.

 Along the way, I noticed that loop bounds were a little odd:

 while (DIV_ROUND_UP(len, pld_data_bytes))

 This really was just supposed to be 'len != 0', so I made that more
 clear.

 Tested on RK3399 with some pending refactoring patches by Nickey Yang,
 to make the Rockchip DSI driver wrap this common driver.

 Signed-off-by: Brian Norris 
 ---
 Could use an extra look from folks. This looks like the correct trivial
 transformation, but I'm not that familiar with DSI.

    drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78 
 ++-
    1 file changed, 16 insertions(+), 62 deletions(-)

 diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
 b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 index d9cca4fd66ec..2fed20e44dfe 100644
 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 @@ -136,10 +136,6 @@
     GEN_SW_0P_TX_LP)
    #define DSI_GEN_HDR    0x6c
 -/* TODO These 2 defines will be reworked thanks to 
 mipi_dsi_create_packet() */
 -#define GEN_HDATA(data)    (((data) & 0x) << 8)
 -#define GEN_HTYPE(type)    (((type) & 0xff) << 0)
 -
    #define DSI_GEN_PLD_DATA    0x70
    #define DSI_CMD_PKT_STATUS    0x74
 @@ -359,44 +355,15 @@ static int 
 dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
    return 0;
    }
 -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
 -   const struct mipi_dsi_msg *msg)
 -{
 -    const u8 *tx_buf = msg->tx_buf;
 -    u16 data = 0;
 -    u32 val;
 -
 -    if (msg->tx_len > 0)
 -    data |= tx_buf[0];
 -    if (msg->tx_len > 1)
 -    data |= tx_buf[1] << 8;
 -
 -    if (msg->tx_len > 2) {
 -    dev_err(dsi->dev, "too long tx buf length %zu for short 
 write\n",
 -    msg->tx_len);
 -    return -EINVAL;
 -    }
 -
 -    val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
 -    return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
 -}
 -
 -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
 -  const struct mipi_dsi_msg *msg)
 +static int dw_mipi_dsi_dcs_write(struct dw_mipi_dsi *dsi,
 + const struct mipi_dsi_packet *packet)
>>>
>>> Both DCS and Generic dsi transfers are managed by drm_mipi_dsi.c
>>> helpers. So maybe dw_mipi_dsi_dcs_write() should be renamed
>>> dw_mipi_dsi_write()...
>>
>> Ah, good point. I really meant to remove the _dcs naming too, but I
>> guess I missed it. Will follow up.
>>
    {
 -    const u8 *tx_buf = msg->tx_buf;
 -    int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
 -    u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
 +    const u8 *tx_buf = packet->payload;
 +    int len = packet->payload_length, pld_data_bytes = sizeof(u32), 
 ret;
    u32 remainder;
    u32 val;
 -    if (msg->tx_len < 3) {
 -    dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
 -    msg->tx_len);
 -    return -EINVAL;
 -    }
 -
 -    while (DIV_ROUND_UP(len, pld_data_bytes)) {
 +    while (len) {
    if (len < pld_data_bytes) {
    remainder = 0;
    memcpy(, tx_buf, len);
 @@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct 
 dw_mipi_dsi *dsi,
    }
    }
 -    return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
 +    remainder = 0;
 +    memcpy(, packet->header, sizeof(packet->header));
>>
>> By the way: I don't think it's an issue that should block this patch,
>> since if I'm right, this function already is "broken", but isn't this
>> actually a bad way to handle 

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

[Meghana Madhyastha]

On Wed, Jan 17, 2018 at 05:09:57PM +, Daniel Thompson wrote:
> On 16/01/18 10:34, Meghana Madhyastha wrote:
> >Add devm_of_find_backlight and the corresponding release
> >function because some drivers use devres versions of functions
> >for acquiring device resources.
> >
> >Signed-off-by: Meghana Madhyastha 
> >---
> >  drivers/video/backlight/backlight.c | 29 +
> >  include/linux/backlight.h   |  7 +++
> >  2 files changed, 36 insertions(+)
> >
> >diff --git a/drivers/video/backlight/backlight.c 
> >b/drivers/video/backlight/backlight.c
> >index 7e4a5d77d..b3f76945f 100644
> >--- a/drivers/video/backlight/backlight.c
> >+++ b/drivers/video/backlight/backlight.c
> >@@ -620,6 +620,35 @@ struct backlight_device *of_find_backlight(struct 
> >device *dev)
> >  }
> >  EXPORT_SYMBOL(of_find_backlight);
> >+static void devm_backlight_put(void *data)
> >+{
> >+backlight_put(data);
> 
> Shouldn't this be using devres_release()?

backlight_put calls put_device which essentially does a release right?
And looking at the code in other driver, looks like most of them use
put_device (to the best of my knowledge, correct me if I'm mistaken). 

Thanks and regards,
Meghana

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

Re: [PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs

[Maxime Ripard]

Hi,

On Wed, Jan 17, 2018 at 09:14:11PM +0100, Jernej Skrabec wrote:
> This commit changes formula from this:
> 
> Freq = (parent_freq * N * K) / (M * P)
> 
> to this:
> 
> Freq = (parent_freq / M) * N * K / P
> 
> This improves situation when N is in the range 1-255. PLL parent clock
> is almost always 24 MHz, which means that for N >= 180 original formula
> overflows and result becomes useless. Situation can be improved if M is
> used as predivider as it can be seen in the second formula. That way at
> least M > 1 is considered, but it still leaves small gap for wrong result
> when M = 1 and N >= 180.
> 
> Using M as predivider shouldn't cause any issue, because it is in range
> 1-4 at most, so there is no or only minimal rounding error.
> 
> Signed-off-by: Jernej Skrabec 

I'd really prefer to stick to the formula documented and that we've
used so far. NKMP clocks are most notably used for the CPU PLLs and
I've debugged way too many cpufreq bugs already :)

What about using long long types for the parent * n * k result?

Maxime

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


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

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

[Meghana Madhyastha]

On Wed, Jan 17, 2018 at 11:03:24PM +0100, Noralf Trønnes wrote:
> 
> Den 17.01.2018 18.00, skrev Daniel Thompson:
> >
> >
> >On 16/01/18 10:31, Meghana Madhyastha wrote:
> >>Add helper functions backlight_enable and backlight_disable to
> >>enable/disable a backlight device. These helper functions can
> >>then be used by different drm and tinydrm drivers to avoid
> >>repetition of code and also to enforce a uniform and consistent
> >>way to enable/disable a backlight device.
> >>
> >>Signed-off-by: Meghana Madhyastha 
> >
> >To be clear I don't disagree with anthing Daniel V. said about the
> >horribly confused (and confusing) power states for backlight.
> >
> >Nevertheless I don't recall seeing any response (positive or negative) to
> >this post from v13:
> >https://www.spinics.net/lists/dri-devel/msg154459.html
> >
> 
> I see that Daniel V has answered while I was chasing this down, but anyways:
> 
> A grep suggests that omap1_bl is the only driver that only checks fb_blank.
> All the other drivers check both fb_blank and power, a few check state. The
> backlight fbdev notifier callback doesn't set power, but sets fb_blank and
> state.
> 
> fb_blank was marked 'Due to be removed' 9 years ago, so it hasn't been
> high priority.
> 
> So for completeness I guess it makes sense to set fb_blank.

So if I understood correctly, the suggestion is to set fb_blank along
with power i.e something like this in backlight_enable.
bd->props.power = FB_BLANK_UNBLANK;
+   bd->props.fb_blank = FB_BLANK_UNBLANK;
bd->props.state &= ~BL_CORE_FBBLANK;

and set it to FB_BLANK_POWERDOWN in backlight_disable ?

Thanks and regards,
Meghana

> Noralf.
> 
> $ grep -r -C10 "props\.fb_blank" .
> ./drivers/video/backlight/corgi_lcd.c-  if (bd->props.power !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/corgi_lcd.c-  intensity = 0;
> ./drivers/video/backlight/corgi_lcd.c-
> ./drivers/video/backlight/corgi_lcd.c:  if (bd->props.fb_blank !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/corgi_lcd.c-  intensity = 0;
> --
> ./drivers/video/backlight/adp8860_bl.c- if (bl->props.power !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/adp8860_bl.c- brightness = 0;
> ./drivers/video/backlight/adp8860_bl.c-
> ./drivers/video/backlight/adp8860_bl.c: if (bl->props.fb_blank !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/adp8860_bl.c- brightness = 0;
> --
> ./drivers/video/backlight/hp680_bl.c-   if (bd->props.power !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/hp680_bl.c-   intensity = 0;
> ./drivers/video/backlight/hp680_bl.c:   if (bd->props.fb_blank !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/hp680_bl.c-   intensity = 0;
> --
> ./drivers/video/backlight/cr_bllcd.c-static int
> cr_backlight_set_intensity(struct backlight_device *bd)
> ./drivers/video/backlight/cr_bllcd.c-{
> ./drivers/video/backlight/cr_bllcd.c-   int intensity =
> bd->props.brightness;
> ./drivers/video/backlight/cr_bllcd.c-   u32 addr = gpio_bar +
> CRVML_PANEL_PORT;
> ./drivers/video/backlight/cr_bllcd.c-   u32 cur = inl(addr);
> ./drivers/video/backlight/cr_bllcd.c-
> ./drivers/video/backlight/cr_bllcd.c-   if (bd->props.power ==
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/cr_bllcd.c-   intensity =
> FB_BLANK_UNBLANK;
> ./drivers/video/backlight/cr_bllcd.c:   if (bd->props.fb_blank ==
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/cr_bllcd.c-   intensity =
> FB_BLANK_UNBLANK;
> ./drivers/video/backlight/cr_bllcd.c-   if (bd->props.power ==
> FB_BLANK_POWERDOWN)
> ./drivers/video/backlight/cr_bllcd.c-   intensity =
> FB_BLANK_POWERDOWN;
> ./drivers/video/backlight/cr_bllcd.c:   if (bd->props.fb_blank ==
> FB_BLANK_POWERDOWN)
> ./drivers/video/backlight/cr_bllcd.c-   intensity =
> FB_BLANK_POWERDOWN;
> --
> ./drivers/video/backlight/max8925_bl.c- if (bl->props.power !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/max8925_bl.c- brightness = 0;
> ./drivers/video/backlight/max8925_bl.c-
> ./drivers/video/backlight/max8925_bl.c: if (bl->props.fb_blank !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/max8925_bl.c- brightness = 0;
> ./drivers/video/backlight/max8925_bl.c-
> ./drivers/video/backlight/max8925_bl.c- if (bl->props.state &
> BL_CORE_SUSPENDED)
> ./drivers/video/backlight/max8925_bl.c- brightness = 0;
> --
> ./drivers/video/backlight/lv5207lp.c-   if (backlight->props.power !=
> FB_BLANK_UNBLANK ||
> ./drivers/video/backlight/lv5207lp.c: backlight->props.fb_blank !=
> FB_BLANK_UNBLANK ||
> ./drivers/video/backlight/lv5207lp.c- backlight->props.state &
> (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> ./drivers/video/backlight/lv5207lp.c-   brightness = 0;
> --
> ./drivers/video/backlight/lm3533_bl.c-  if (bd->props.power !=
> FB_BLANK_UNBLANK)
> ./drivers/video/backlight/lm3533_bl.c-  brightness = 0;
> ./drivers/video/backlight/lm3533_bl.c:  if (bd->props.fb_blank !=
> 

Re: [PATCH v3 01/12] clk: sunxi-ng: Mask nkmp factors when setting register

[Maxime Ripard]

On Wed, Jan 17, 2018 at 09:14:10PM +0100, Jernej Skrabec wrote:
> Currently, if one of the factors isn't present, bit 0 gets always set to
> 1. For example, A83T has NMP PLLs modelled as NKMP PLL without K. Since
> K is not specified, it's offset, width and shift is 0. Driver assumes
> that lowest value possible is 1, otherwise we would get division by 0.
> That situation causes that bit 0 is always set, which may change wanted
> clock rate.
> 
> Fix that by masking every factor according to it's specified width.
> Factors with width set to 0 won't have any influence to final register
> value.
> 
> Signed-off-by: Jernej Skrabec 

Acked-by: Maxime Ripard 

Thanks!
Maxime

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


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

Re: [PATCH] drm/panel: panasonic-vvx10f034n00: More return value fixes

[Philippe CORNU]

Hi Sean,

Reviewed-by: Philippe Cornu 

(do you mean you write patches during meetings :o ... I never did that 
and I will not ;-)

Philippe :-)

On 01/17/2018 10:37 PM, Sean Paul wrote:
> A couple more return value fixes which Philippe brought up during our
> previous review.
> 
> Suggested-by: Philippe CORNU 
> Signed-off-by: Sean Paul 
> ---
>   drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 17 +
>   1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
> b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> index 91dc5a6b14f9..74a806121f80 100644
> --- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> +++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
> @@ -59,35 +59,28 @@ static inline struct wuxga_nt_panel 
> *to_wuxga_nt_panel(struct drm_panel *panel)
>   
>   static int wuxga_nt_panel_on(struct wuxga_nt_panel *wuxga_nt)
>   {
> - struct mipi_dsi_device *dsi = wuxga_nt->dsi;
> - int ret;
> -
> - ret = mipi_dsi_turn_on_peripheral(dsi);
> - if (ret < 0)
> - return ret;
> -
> - return 0;
> + return mipi_dsi_turn_on_peripheral(wuxga_nt->dsi);
>   }
>   
>   static int wuxga_nt_panel_disable(struct drm_panel *panel)
>   {
>   struct wuxga_nt_panel *wuxga_nt = to_wuxga_nt_panel(panel);
> - int ret;
> + int mipi_ret, bl_ret = 0;
>   
>   if (!wuxga_nt->enabled)
>   return 0;
>   
> - ret = mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
> + mipi_ret = mipi_dsi_shutdown_peripheral(wuxga_nt->dsi);
>   
>   if (wuxga_nt->backlight) {
>   wuxga_nt->backlight->props.power = FB_BLANK_POWERDOWN;
>   wuxga_nt->backlight->props.state |= BL_CORE_FBBLANK;
> - backlight_update_status(wuxga_nt->backlight);
> + bl_ret = backlight_update_status(wuxga_nt->backlight);
>   }
>   
>   wuxga_nt->enabled = false;
>   
> - return ret;
> + return mipi_ret ? mipi_ret : bl_ret;
>   }
>   
>   static int wuxga_nt_panel_unprepare(struct drm_panel *panel)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[Maarten Lankhorst]

Op 12-01-18 om 07:21 schreef Nautiyal, Ankit K:
> From: Ankit Nautiyal 
>
> A new drm client cap is required to enable user-space to advertise
> if it supports modes with aspect-ratio. Based on this cap value, the
> kernel will take a call on exposing the aspect ratio information in
> modes or not.
>
> This patch adds the client cap for aspect-ratio.
>
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Signed-off-by: Ankit Nautiyal 
What's missing from the commit message is why this needs to be a flag that 
userspace needs to enable,
instead of something that only counts as an informative query.

I gathered from danvet that blindly exposing things breaks existing userspace, 
so could that information be added to the commit?

Also missing IGT tests, would be nice we at least get some verification things 
work as expected.

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

Re: [PATCH 2/2] drm/msm/adreno: fix nvmem related link error

[Lucas Stach]

Am Mittwoch, den 17.01.2018, 16:52 -0500 schrieb Rob Clark:
> On Mon, Jan 15, 2018 at 11:14 AM, Arnd Bergmann 
> wrote:
> > When NVMEM is configured as a loadable module, and adreno
> > is built-in, we get a link failure:
> > 
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init':
> > a5xx_gpu.c:(.text+0x15cc): undefined reference to `nvmem_cell_get'
> > a5xx_gpu.c:(.text+0x15da): undefined reference to `nvmem_cell_read'
> > a5xx_gpu.c:(.text+0x15e4): undefined reference to `nvmem_cell_put'
> > 
> > This adds a Kconfig dependency to enforce valid configurations,
> > when NVMEM is a loadable module, adreno now has to also be one.
> > The code seems to deal fine with nvmem being completely disabled,
> > it will just not set the right speed bin then, so we don't need
> > a hard dependency.
> > 
> > Fixes: f56d9df656c4 ("drm/msm/adreno: Read the speed bins for a5xx
> > targets")
> > Signed-off-by: Arnd Bergmann 
> 
> Arnd, beyond randconfig, I guess there are probably two real-world
> scenarios, both =m (distro) and both =y (android/oe/etc)..
> 
> Is there a kconfig way to say if nvmem=m then drm_msm must be =n or
> =m?

That's exactly what the below patch does.

Regards,
Lucas

> BR,
> -R
> 
> 
> > ---
> >  drivers/gpu/drm/msm/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/msm/Kconfig
> > b/drivers/gpu/drm/msm/Kconfig
> > index 99d39b2aefa6..74fb1c816da9 100644
> > --- a/drivers/gpu/drm/msm/Kconfig
> > +++ b/drivers/gpu/drm/msm/Kconfig
> > @@ -4,6 +4,7 @@ config DRM_MSM
> > depends on DRM
> > depends on ARCH_QCOM || (ARM && COMPILE_TEST)
> > depends on OF && COMMON_CLK
> > +   depends on NVMEM || !NVMEM
> > depends on MMU
> > select QCOM_MDT_LOADER if ARCH_QCOM
> > select REGULATOR
> > --
> > 2.9.0
> > 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/12] drm: msm: Use drm_atomic_helper_shutdown() to disable planes on removal

[Laurent Pinchart]

The plane cleanup handler currently calls drm_plane_helper_disable(),
which is a legacy helper function. Replace it with a call to
drm_atomic_helper_shutdown() at removal time.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 1 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 1 -
 drivers/gpu/drm/msm/msm_drv.c | 1 +
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 7a1ad3af08e3..db356d22ef15 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -68,7 +68,6 @@ static void mdp4_plane_destroy(struct drm_plane *plane)
 {
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
 
-   drm_plane_helper_disable(plane);
drm_plane_cleanup(plane);
 
kfree(mdp4_plane);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 29678876fc09..986684e33a03 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -46,7 +46,6 @@ static void mdp5_plane_destroy(struct drm_plane *plane)
 {
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
 
-   drm_plane_helper_disable(plane);
drm_plane_cleanup(plane);
 
kfree(mdp5_plane);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d90ef1d78a1b..4ba48e5acbe9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -233,6 +233,7 @@ static int msm_drm_uninit(struct device *dev)
if (fbdev && priv->fbdev)
msm_fbdev_free(ddev);
 #endif
+   drm_atomic_helper_shutdown(ddev);
drm_mode_config_cleanup(ddev);
 
pm_runtime_get_sync(dev);
-- 
Regards,

Laurent Pinchart

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

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

Display corruption regression bugfix with both a prep patch and a
follow-up fix.

Up to you to pick this up, or punt until next merge window.


BR,
Jani.

The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da:

  Linux 4.15-rc8 (2018-01-14 15:32:30 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-01-18

for you to fetch changes up to 4488496d58200c7511842e049a4cc891d928da56:

  drm/i915: Fix deadlock in i830_disable_pipe() (2018-01-15 16:46:33 +0200)


Display corruption regression bugfix with both a prep patch and a
follow-up fix


Ville Syrjälä (3):
  drm/i915: Add .get_hw_state() method for planes
  drm/i915: Redo plane sanitation during readout
  drm/i915: Fix deadlock in i830_disable_pipe()

 drivers/gpu/drm/i915/intel_display.c | 303 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_sprite.c  |  83 ++
 3 files changed, 242 insertions(+), 146 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Vetter]

On Wed, Jan 17, 2018 at 11:49 PM, Gurchetan Singh
 wrote:
>
> On Wed, Jan 17, 2018 at 12:39 AM, Daniel Vetter  wrote:
>>
>> On Tue, Jan 16, 2018 at 04:35:59PM -0800, Gurchetan Singh wrote:
>> > This is required to use buffers allocated by vgem on AMD and ARM
>> > devices.
>> > We're experiencing a case where eviction of the cache races with
>> > userspace
>> > writes. To fix this, flush the cache after retrieving a page.
>> >
>> > Signed-off-by: Gurchetan Singh 
>> > ---
>> >  drivers/gpu/drm/vgem/vgem_drv.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
>> > b/drivers/gpu/drm/vgem/vgem_drv.c
>> > index 35bfdfb746a7..fb263969f02d 100644
>> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> > @@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>> >   break;
>> >   }
>> >
>> > + drm_flush_pages(obj->base.dev->dev, , 1);
>>
>> Uh ... what exactly are you doing?
>>
>> Asking because the entire "who's responsible for coherency" story is
>> entirely undefined still when doing buffer sharing :-/ What is clear is
>> that currently vgem entirely ignores this (there's not
>> begin/end_cpu_access callback), mostly because the shared dma-buf support
>> in drm_prime.c also entirely ignores this.
>
>
>
> This patch isn't trying to address the case of a dma-buf imported into vgem.
> It's trying to address the case when a buffer is created by
> vgem_gem_dumb_create, mapped by vgem_gem_dumb_map and then accessed by user
> space.  Since the page retrieved by shmem_read_mapping_page during the page
> fault may still be in the cache, we're experiencing incorrect data in
> buffer.  Here's the test case we're running:
>
> https://chromium.googlesource.com/chromiumos/platform/drm-tests/+/master/vgem_test.c

404s over here (Internal url?).

> It fails on line 210 on AMD and ARM devices (not Intel though).

So you _do_ import it on the other device driver as a dma-buf (and
export it from vgem)? Because coherency isn't well-defined for dma-buf
no matter who the exporter/importer is.

>> And doing a one-time only
>> flushing in your fault handler is definitely not going to fix this (at
>> least not if you do anything else than one-shot uploads).
>
>
> There used to be a be vgem_gem_get_pages function, but that's been removed.
> I don't know where else to flush in this situation.

dma_buf begin/end cpu access. Even exposed as an ioctl when you're
using the dma-buf mmap stuff. Vgem doesn't have that, which means
as-is the dumb mmap support of vgem can't really support this if you
want to do explicit flushing.

What would work is uncached/writecombine/coherent dma memory. But then
we're in the middle of the entire
"who's responsible.
-Daniel

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



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

Re: [PATCH] drm/ttm: Don't add swapped BOs to swap-LRU list

[Christian König]

Am 18.01.2018 um 06:16 schrieb Felix Kuehling:

A BO that's already swapped would be added back to the swap-LRU list
for example if it validation failed under high memory pressure. This
could later lead to swapping it out again and leaking previous swap
storage.

This commit adds a condition to prevent that from happening.

Signed-off-by: Felix Kuehling 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 97c3da6..7192473 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -175,7 +175,8 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
list_add_tail(>lru, >lru[bo->priority]);
kref_get(>list_kref);
  
-		if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {

+   if (bo->ttm && !(bo->ttm->page_flags & TTM_PAGE_FLAG_SG) &&
+   !bo->ttm->swap_storage) {


Good catch, but using ttm->swap_storage is the wrong indicator cause on 
some drivers that is always set to something IIRC.


You need to use ttm->page_flags & TTM_PAGE_FLAG_SWAPPED here.

Regards,
Christian.


list_add_tail(>swap,
  >glob->swap_lru[bo->priority]);
kref_get(>list_kref);


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

[Bug 104611] [fiji, polaris10] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

--- Comment #6 from Vedran Miletić  ---
(In reply to Roman Li from comment #5)
> So what was the repro rate for the issue? 
> Can you try to reproduce on the latest rawhide
> 4.15.0-0.rc8.git0.1.fc28.x86_64 and/or collect dmesg with amdgpu.dc_log=1
> for the bad case? Thank you.

I can do that over the weekend.

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

Re: [PATCH 3/6] backlight/pandora: Stop using BL_CORE_DRIVER1

[Daniel Thompson]

On 17/01/18 21:38, Daniel Vetter wrote:

Thanks a lot for your comments.

On Wed, Jan 17, 2018 at 04:47:41PM +, Daniel Thompson wrote:

On 17/01/18 14:01, Daniel Vetter wrote:

Leaking driver internal tracking into the already massively confusing
backlight power tracking is really confusing.

Stop that by allocating a tiny driver private data structure instead.

Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Signed-off-by: Daniel Vetter 
---
   drivers/video/backlight/pandora_bl.c | 26 +++---
   1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/video/backlight/pandora_bl.c 
b/drivers/video/backlight/pandora_bl.c
index a186bc677c7d..6bd159946a47 100644
--- a/drivers/video/backlight/pandora_bl.c
+++ b/drivers/video/backlight/pandora_bl.c
@@ -35,11 +35,15 @@
   #define MAX_VALUE 63
   #define MAX_USER_VALUE (MAX_VALUE - MIN_VALUE)
-#define PANDORABL_WAS_OFF BL_CORE_DRIVER1
+struct pandora_private {
+   unsigned old_state;
+#define PANDORABL_WAS_OFF 1


Nit, but we using old_state like a bitfield so, BIT(0)?



+};
   static int pandora_backlight_update_status(struct backlight_device *bl)
   {
int brightness = bl->props.brightness;
+   struct pandora_private *priv = bl_get_data(bl);
u8 r;
if (bl->props.power != FB_BLANK_UNBLANK)
@@ -53,7 +57,7 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
brightness = MAX_USER_VALUE;
if (brightness == 0) {
-   if (bl->props.state & PANDORABL_WAS_OFF)
+   if (priv->old_state & PANDORABL_WAS_OFF)
goto done;
/* first disable PWM0 output, then clock */
@@ -66,7 +70,7 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
goto done;
}
-   if (bl->props.state & PANDORABL_WAS_OFF) {
+   if (priv->old_state & PANDORABL_WAS_OFF) {
/*
 * set PWM duty cycle to max. TPS61161 seems to use this
 * to calibrate it's PWM sensitivity when it starts.
@@ -93,9 +97,9 @@ static int pandora_backlight_update_status(struct 
backlight_device *bl)
   done:
if (brightness != 0)
-   bl->props.state &= ~PANDORABL_WAS_OFF;
+   priv->old_state 0;
else
-   bl->props.state |= PANDORABL_WAS_OFF;
+   priv->old_state = PANDORABL_WAS_OFF;


Well, we were using it like a bitfield until this bit...


I had a simple boolean first (because that's all we neeed), but that made
the code less readable. Should I s/1/true/ in the #define? The entire C99
bool tends to be a bit a bikeshed sometimes :-)


I'd prefer a simple boolean or just storing old_brightness directly in 
priv... it is only ever consumed as a boolean anyway. I'd have to say 
I'm not keen on #define true alongside the existing bitmask checks.


However... I'm happy to leave that with you. Providing the spurious 
kfree() is removed then please feel free to repost with:


Acked-by: Daniel Thompson 


Daniel.











return 0;
   }
@@ -109,15 +113,23 @@ static int pandora_backlight_probe(struct platform_device 
*pdev)
   {
struct backlight_properties props;
struct backlight_device *bl;
+   struct pandora_private *priv;
u8 r;
+   priv = devm_kmalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv) {
+   dev_err(>dev, "failed to allocate driver private data\n");
+   return -ENOMEM;
+   }
+
memset(, 0, sizeof(props));
props.max_brightness = MAX_USER_VALUE;
props.type = BACKLIGHT_RAW;
bl = devm_backlight_device_register(>dev, pdev->name, >dev,
-   NULL, _backlight_ops, );
+   priv, _backlight_ops, );
if (IS_ERR(bl)) {
dev_err(>dev, "failed to register backlight\n");
+   kfree(priv);


Why can't we rely on devres for cleanup?


Argh, I had kmalloc first and then changed to devm_kmalloc. The kfree here
needs to go indeed.

Cheers, Daniel





return PTR_ERR(bl);
}
@@ -126,7 +138,7 @@ static int pandora_backlight_probe(struct platform_device 
*pdev)
/* 64 cycle period, ON position 0 */
twl_i2c_write_u8(TWL_MODULE_PWM, 0x80, TWL_PWM0_ON);
-   bl->props.state |= PANDORABL_WAS_OFF;
+   priv->old_state = PANDORABL_WAS_OFF;
bl->props.brightness = MAX_USER_VALUE;
backlight_update_status(bl);




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

[RFC PATCH v3 03/13] bootsplash: Flush framebuffer after drawing

[Max Staudt]

Framebuffers with deferred I/O need to be flushed to the screen
explicitly, since we use neither the mmap nor the file I/O abstractions
that handle this for userspace FB clients.

Example: xenfb

Some framebuffer drivers implement lazy access to the screen without
actually exposing a fbdefio interface - we also match some known ones,
currently:
 - ast
 - cirrus
 - mgag200

Signed-off-by: Max Staudt 
Reviewed-by: Oliver Neukum 
---
 drivers/video/fbdev/core/bootsplash.c  |  2 ++
 drivers/video/fbdev/core/bootsplash_internal.h |  1 +
 drivers/video/fbdev/core/bootsplash_render.c   | 33 ++
 3 files changed, 36 insertions(+)

diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 843c5400fefc..815b007f81ca 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -112,6 +112,8 @@ void bootsplash_render_full(struct fb_info *info)
 
bootsplash_do_render_pictures(info, splash_state.file);
 
+   bootsplash_do_render_flush(info);
+
 out:
mutex_unlock(_state.data_lock);
 }
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index 71e2a27ac0b8..0acb383aa4e3 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/video/fbdev/core/bootsplash_internal.h
@@ -89,6 +89,7 @@ void bootsplash_do_render_background(struct fb_info *info,
 const struct splash_file_priv *fp);
 void bootsplash_do_render_pictures(struct fb_info *info,
   const struct splash_file_priv *fp);
+void bootsplash_do_render_flush(struct fb_info *info);
 
 
 void bootsplash_free_file(struct splash_file_priv *fp);
diff --git a/drivers/video/fbdev/core/bootsplash_render.c 
b/drivers/video/fbdev/core/bootsplash_render.c
index 2ae36949d0e3..8c09c306ff67 100644
--- a/drivers/video/fbdev/core/bootsplash_render.c
+++ b/drivers/video/fbdev/core/bootsplash_render.c
@@ -186,3 +186,36 @@ void bootsplash_do_render_pictures(struct fb_info *info,
pp->pic_header->width, pp->pic_header->height);
}
 }
+
+
+void bootsplash_do_render_flush(struct fb_info *info)
+{
+   /*
+* FB drivers using deferred_io (such as Xen) need to sync the
+* screen after modifying its contents. When the FB is mmap()ed
+* from userspace, this happens via a dirty pages callback, but
+* when modifying the FB from the kernel, there is no such thing.
+*
+* So let's issue a fake fb_copyarea (copying the FB onto itself)
+* to trick the FB driver into syncing the screen.
+*
+* A few DRM drivers' FB implementations are broken by not using
+* deferred_io when they really should - we match on the known
+* bad ones manually for now.
+*/
+   if (info->fbdefio
+   || !strcmp(info->fix.id, "astdrmfb")
+   || !strcmp(info->fix.id, "cirrusdrmfb")
+   || !strcmp(info->fix.id, "mgadrmfb")) {
+   struct fb_copyarea area;
+
+   area.dx = 0;
+   area.dy = 0;
+   area.width = info->var.xres;
+   area.height = info->var.yres;
+   area.sx = 0;
+   area.sy = 0;
+
+   info->fbops->fb_copyarea(info, );
+   }
+}
-- 
2.12.3

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

Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states

[Lee Jones]

On Wed, 17 Jan 2018, Daniel Thompson wrote:

> On 17/01/18 14:01, Daniel Vetter wrote:
> > The backlight power state handling is supremely confusing. We have:
> > - props.power, using FB_BLANK_* defines
> > - props.fb_blank, using the same, but deprecated int favour of
> >props.state
> > - props.state, using the BL_CORE_* defines
> > - and finally a bunch of backlight drivers treat brightness == 0 as
> >off. But of course not all of them.
> > 
> > This is way too much confusion to fix in a simple patch, but at least
> > prevent more hilarity from spreading by removing the unused BL_CORE_*
> > defines. I have no idea why exactly anyone would need that.
> > 
> > Wrt the ideal state, we really just want a boolean state. The 4 power
> > saving states that the fbdev subsystem uses are overkill in todays hw
> > (this was only relevant for VGA and similar analog circuits like
> > TV-out), the new drm atomic modeset api simplified even the uapi to a
> > simple bool. And there was never a valid technical reason to have the
> > intermediate fbdev power states for backlights (those really only can
> > be either off or on).
> > 
> > Cleanup motivated by Meghana's questions about all this.
> > 
> > Cc: Lee Jones 
> > Cc: Daniel Thompson 
> > Cc: Jingoo Han 
> > Cc: Meghana Madhyastha 
> > Signed-off-by: Daniel Vetter 
> 
> Acked-by: Daniel Thompson 
> 
> Daniel: Ack is info for Lee J, not to imply you should take it through
> one of your trees.

Right.  I'd rather take the set as a complete unit once all Acks are
acquired though.  Hence my silence thus far.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/12] drm: atmel-hlcdc: Don't set CRTC .mode_set and .mode_set_base handlers

[Boris Brezillon]

On Wed, 17 Jan 2018 23:55:25 +0200
Laurent Pinchart  wrote:

> The .mode_set() and .mode_set_base() operation handlers are used by
> legacy non-atomic helpers only. There's no need to set them for atomic
> drivers.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..cbe18df06e95 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -318,9 +318,7 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>  
>  static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
>   .mode_valid = atmel_hlcdc_crtc_mode_valid,
> - .mode_set = drm_helper_crtc_mode_set,
>   .mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
> - .mode_set_base = drm_helper_crtc_mode_set_base,
>   .atomic_check = atmel_hlcdc_crtc_atomic_check,
>   .atomic_begin = atmel_hlcdc_crtc_atomic_begin,
>   .atomic_flush = atmel_hlcdc_crtc_atomic_flush,

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

Re: [PATCH v3 3/8] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 1/17/2018 8:59 PM, Ville Syrjälä wrote:

On Wed, Jan 17, 2018 at 02:35:40PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 1/12/2018 11:51 AM, Nautiyal, Ankit K wrote:

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 1818a71..3d57c41 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2908,11 +2908,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;
@@ -2926,7 +2930,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));
}
@@ -2943,11 +2947,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;
+

How about stereo flags ? CEA modes can be 3d and in that case we might
want to add DRM_MODE_MATCH_3D_FLAGS here

There are no separate VICs for stereo vs. no stereo. So ignoring the
stereo flags here seems like the correct thing to do.

Agree,
Reviewed-by: Shashank Sharma 

- Shashank

for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2961,7 +2969,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));
}
@@ -3008,6 +3016,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)

@@ -3025,7 +3034,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;
}
   
@@