Hi Souptick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commi
Add the device tree bindings for Truly NT35597 panel.
This panel supports both single DSI and dual DSI.
However, this patch series supports only dual DSI.
Changes in v4:
- None
Signed-off-by: Abhinav Kumar
---
.../devicetree/bindings/display/truly,nt35597.txt | 69 ++
1
Add support for Truly NT35597 panel used
in MSM reference platforms.
This panel supports both single DSI and dual DSI
modes.
However, this patch series adds support only for
dual DSI mode.
Changes in v4:
- Fix the license identifier
- Fix formatting issues for the regulator loads
- Fix error mes
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #29 from Francisco Pina Martins ---
Created attachment 139779
--> https://bugs.freedesktop.org/attachment.cgi?id=139779&action=edit
journaltcl log file for linux-amd-staging-drm-next
I was able to compile the "amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #28 from Francisco Pina Martins ---
Currently "amd-staging-drm-next" fails to build for me, with the following
error:
```
../lib/str_error_r.c: In function ‘str_error_r’:
../lib/str_error_r.c:25:3: error: passing argument 1 to restr
Hi Jordan
Thanks for the review. Will fix the ones listed below and upload V4.
Abhinav
On 2018-05-24 10:31, Jordan Crouse wrote:
On Wed, May 23, 2018 at 06:44:00PM -0700, Abhinav Kumar wrote:
Add support for Truly NT35597 panel used
in MSM reference platforms.
This panel supports both single
Remove custom ioctl support in SDM845 which allows
user space to register/unregister for hw events.
changes in v2:
- none
changes in v3:
- none
Reviewed-by: Sean Paul
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm
Upstream DSI driver doesn't support DSC panels yet. Remove
the support for compression from DPU for now.
changes in v2:
- indents and unrelated change clean up (Sean Paul)
- fix compilation dependency in dsi-staging
changes in v3:
- none
Signed-off-by: Jeykumar Sankaran
S
ping pong split topology was meant for low end soc's which
doesn't have enough layer mixers to support split panels.
Considering how uncommon the topology is for current chipset's and
also to simply the driver programming, striping off the support
for SDM845.
changes in v2:
- none
changes
SDM845 DPU driver was talking to dsi-staging driver for its dsi
operations through the customized dpu_connector layer. The following
series of patches removes DPU dependency from various dpu
connector API's before purging the dpu_connector altogether. It
also completes the switch to upstream DSI
Remove autorefresh support for smart panels in SDM845 for now.
It needs more discussion to figure out the user space
communication to set preference for the feature.
changes in v2:
- none
changes in v3:
- none
Reviewed-by: Sean Paul
Signed-off-by: Jeykumar Sankaran
Signed-off-by
Switch DPU from dsi-staging to upstream dsi driver. To make
the switch atomic, this change includes:
- remove dpu connector layers
- clean up dpu connector dependencies in encoder/crtc
- compile out writeback and display port drivers
- compile out dsi-staging driver (separate patch submitted to
r
https://bugs.freedesktop.org/show_bug.cgi?id=106471
Joshua Cogliati changed:
What|Removed |Added
CC||jjcogliati...@yahoo.com
--- Comment #
Hi Peter,
On Wednesday, 21 March 2018 12:08:25 EEST Peter Ujfalusi wrote:
> Hi,
>
> Changes since v1:
> - rebased it on drm-next
> - Dropped the devm_kzalloc conversion patch
>
> Changes since RFC:
> - Comments from Laurent have been addressed:
> - Get alias ID once and store it for later use i
On 05/25/2018 02:36 PM, David Lechner wrote:
This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).
The vendor prefix "noname" is used because the vendor is not known.
Looks like I forgot to update "noname"
"dirver"?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Peter,
On Monday, 4 September 2017 13:03:36 EEST Peter Ujfalusi wrote:
I should drop dates when I reply to such old e-mails...
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> On 2017-09-01 14:36, Laurent Pinc
https://bugs.freedesktop.org/show_bug.cgi?id=106658
--- Comment #4 from Justin Mitzel ---
Created attachment 139776
--> https://bugs.freedesktop.org/attachment.cgi?id=139776&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106658
--- Comment #3 from Justin Mitzel ---
Created attachment 139775
--> https://bugs.freedesktop.org/attachment.cgi?id=139775&action=edit
Current Xorg log
for some reason xorg.log.1 is empty, I will have to post it some other time
--
You are re
https://bugs.freedesktop.org/show_bug.cgi?id=106658
--- Comment #2 from Justin Mitzel ---
Created attachment 139774
--> https://bugs.freedesktop.org/attachment.cgi?id=139774&action=edit
Journalctl -k -b 2 output
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106658
--- Comment #1 from Justin Mitzel ---
Created attachment 139773
--> https://bugs.freedesktop.org/attachment.cgi?id=139773&action=edit
Journalctl -k output
I've disabled the PCI errors in the past, it does not stop the hangs.
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=106658
Bug ID: 106658
Summary: 2500u HP Envy x360 Hangs randomly
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: c
This adds a device tree vendor prefix for Adafruit Industries, LLC.
Signed-off-by: David Lechner
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/binding
This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).
The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in
This adds a new driver for display panels that use the Ilitek ILI9341
controller. It currently supports a single display panel, namely
the YX240QV29-T (e.g. Adafruit 2.4" TFT).
The init sequence is from the Adafruit Python library for the ILI9341
controller. https://github.com/adafruit/Adafruit_Py
This fixes the path to the ilitek,ili9225 device tree binding file.
Signed-off-by: David Lechner
Reviewed-by: Noralf Trønnes
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 334a00350922..bc219de9cbee 100644
--- a/MAINTAINERS
++
This series adds a new tinydrm driver for the Ilitek ILI9341 controller and
a 2.4" display panel that uses this controller.
A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned on it
anywhere, so I have used "adafruit" as the vendor prefix. If someone ha
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #19 from Alex Deucher ---
(In reply to Timothy Pearson from comment #17)
> We have been unable to replicate this with the latest AMD GPU firmware from
> https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/ . Xorg starts
> fin
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #18 from Timothy Pearson ---
(In reply to Timothy Pearson from comment #17)
> We have been unable to replicate this with the latest AMD GPU firmware from
> https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/ . Xorg starts
>
From: Ville Syrjälä
Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_crtc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/driv
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop setting it.
v2: s/fb/crtc/ in the commit message (Gerd)
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Dan
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Catch a few more cases
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
Reviewed-by: Daniel Ve
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
v2: Fix up the comment in intel_crtc_active() and
nuke the rest of the stale comments (Daniel)
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst #v1
Reviewed-by: Daniel Vetter
---
dr
From: Ville Syrjälä
plane->fb/old_fb/crtc should no longer be used by atomic
drivers. Stop messing about with them.
Cc: Deepak Rawat
Cc: Thomas Hellstrom
Cc: Sinclair Yeh
Cc: VMware Graphics
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 24 ---
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop setting it.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Harry Wentland
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Harry Wen
From: Ville Syrjälä
We want to get rid of plane->crtc on atomic drivers. Stop setting it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
Acked-by: Inki Dae
---
drivers/gpu/drm/exy
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop setting it.
Cc: Deepak Rawat
Cc: Thomas Hellstrom
Cc: Sinclair Yeh
Cc: VMware Graphics
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
Reviewed-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
dri
From: Ville Syrjälä
The only caller of vmw_kms_update_implicit_fb() is the page_flip
hook which itself gets called with the plane mutex already held.
Hence we can look at plane->state safely. Toss in a lockdep assert
to make the situation more clear.
Cc: Deepak Rawat
Cc: Thomas Hellstrom
Cc: S
From: Ville Syrjälä
Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.
Due to that same reason, I'm actually not sure
From: Ville Syrjälä
Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_upda
From: Ville Syrjälä
Instead of looking at plane->fb let's look at the proper new
plane state.
Not that the code makes a ton of sense. It's only going through the
crtcs in the atomic state, so assuming not all of them are included
we're not even calculating the total bandwidth here. Also we're
no
From: Ville Syrjälä
Here are again the last (?) bits of eliminating the plane->fb/crtc
usage for atomic drivers. I've pushed everything else (thanks to
everyone who reviewed them).
Deepak said he'd tested the vmwgfx stuff, so I think it should be
safe to land. Just missing a bit of review...
C
https://bugs.freedesktop.org/show_bug.cgi?id=106258
Timothy Pearson changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #17 from Timothy
Hi Arnd,
Thank you for the patch.
On Friday, 25 May 2018 18:50:11 EEST Arnd Bergmann wrote:
> The "alpha" struct member was removed in one commit but another user
> added in another, leading to a build failure:
>
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function
> 'rcar_du_vsp_plane_atomic_du
On Fri, May 25, 2018 at 04:00:46PM +0530, Sharat Masetty wrote:
> devfreq framework requires the drivers to provide busy time estimations.
> The GPU driver relies on the hardware performance counters for the busy time
> estimations, but different hardware revisions have counters which can be
> sour
On Fri, 25 May 2018, "Taylor, Clinton A" wrote:
> Looks like the seek=%d in the sprintf is not working.
Yeah. Try skip=%d instead.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Fri, May 25, 2018 at 04:00:45PM +0530, Sharat Masetty wrote:
> This is needed for hardware revisions which do not rely on the generic
> suspend, resume handlers for power management.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 26 ++
> dri
On Fri, May 25, 2018 at 04:00:44PM +0530, Sharat Masetty wrote:
> Devfreq turns on and starts recommending power level as soon as it is
> initialized. The GPU is still not powered on by the time the devfreq
> init happens and this leads to problems on GPU's where register access
> is needed to get/
https://bugs.freedesktop.org/show_bug.cgi?id=106430
--- Comment #5 from mikhail.v.gavri...@gmail.com ---
After updating kernel to 4.17.0-0.rc6.git1.1 strange mce error messages after
reboot disappeared. But GPU still hangs.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=106430
--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 139764
--> https://bugs.freedesktop.org/attachment.cgi?id=139764&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.__
From: Daniel Vetter
- None of the list walkings where protected.
- Switch to a mutex since the list walking at device resume time can
sleep when pinning buffers through the tiler.
Only thing we need to be careful with here is that while we walk the
list we can't unreference any gem objects, s
Hello,
This patch series removes the usage of struct_mutex from the omapdrm driver in
order to switch to gem_free_object_unlocked(). The series is inspired by
Daniel Vetter's recent gem_free_object_unlocked() patches (starting with
"[PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked") and
get_pages() as a local function name is too generic and easily confused
for a generic MM kernel function. Rename it to __omap_gem_get_pages().
Rename the is_contiguous(), is_cache_coherent(), evict(), evict_entry(),
fault_1d() and fault_2d() functions for the same reason.
Signed-off-by: Laurent P
The __omap_gem_get_pages() function is a wrapper around
omap_gem_attach_pages() that returns the omap_obj->pages pointer through
a function argument. Some callers don't need the pages pointer, and all
of them can access omap_obj->pages directly. To simplify the code merge
the __omap_gem_get_pages()
From: Daniel Vetter
The only thing that omap_gem_free_object does that might need the magic
protection of struct_mutex (of keeping all objects alive if that lock is
held, even if the last reference is gone) is the mm_list manipulation.
This is already protected by the separate omapdrm->list_lock,
The DRM device struct_mutex is used to protect against concurrent GEM
object operations that deal with memory allocation and pinning. All
those operations are local to a GEM object and don't need to be
serialized across different GEM objects. Replace the struct_mutex with
a local omap_obj.lock or d
GEM objects mmap offsets are created by calling
drm_gem_create_mmap_offset_size() that doesn't need struct_mutex
protection as it includes its own locking, based on a size that is
static across the object's life time. Remove the unneeded struct_mutex
locking.
Signed-off-by: Laurent Pinchart
Revie
The documentation of drm_sched_job_init and drm_sched_entity_push_job has
been clarified. Both functions should be called under a shared lock, to
avoid jobs getting pushed into the scheduler queue in a different order
than their sched_fence seqnos, which will confuse checks that are looking
at the
/commits/stu-hsieh-mediatek-com/Add-support-for-mediatek-SOC-MT2712/20180525-24
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
On Fri, May 25, 2018 at 04:48:59PM +0100, Brian Starkey wrote:
> Hi Ayan,
>
> On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote:
> >If a plane supports a pixel format and the framebuffer does not pass any
> >modifiers, then drm_plane_check_pixel_format() should always return true
>
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #27 from Jerry Zuo ---
The issue could get reproduced on 4.16.3, but not on 4.16-rc7.
I've verified the commit a0f282dcdb1775cbcc0a151570fc01c0aae5ca0f (current top)
on amd-staging-drm-next without seeing the issue on Raven by havi
These two functions are unused in some configurations, and using __maybe_unused
is the easiest way to shut up the harmless warnings:
drivers/gpu/drm/bridge/cdns-dsi.c:1353:12: error: 'cdns_dsi_suspend' defined
but not used [-Werror=unused-function]
static int cdns_dsi_suspend(struct device *dev)
The DRM panel bridge code is built into the kms helpers module, so we
get a link error when trying to use it from a built-in driver while the
kms helper is a loadable module:
drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
lvds-encoder.c:(.text+0x124): undefined reference
Modern gcc versions warn about returning a ternary operator with an 'int'
type in a function returning type 'bool':
drivers/gpu/drm/exynos/exynos_drm_scaler.c: In function 'scaler_task_done':
drivers/gpu/drm/exynos/exynos_drm_scaler.c:402:47: error: ?: using integer
constants in boolean context [
Without CONFIG_MMU, we get a link error:
drivers/gpu/drm/v3d/v3d_bo.o: In function `v3d_gem_fault':
v3d_bo.c:(.text+0x3ca): undefined reference to `vm_insert_mixed'
The other drivers with this problem already depend on CONFIG_MMU,
so let's do the same thing here.
Fixes: 57692c94dcbe ("drm/v3d: I
In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit
type:
In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18:
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to integ
The "alpha" struct member was removed in one commit but another user
added in another, leading to a build failure:
drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function
'rcar_du_vsp_plane_atomic_duplicate_state':
drivers/gpu/drm/rcar-du/rcar_du_vsp.c:325:6: error: 'struct
rcar_du_vsp_plane_state' h
Looks like the seek=%d in the sprintf is not working. 0x11 0x0A are being
returned by the monitor from DPCD’s 0x and 0x0001 repeatedly. The first is
DPCD revision (1.1) and the second is maximum Link Rate (0x0a) which is 2.7
Gbps. You might want to do a printf of call to make sure seek is be
Casting a pointer to a 64-bit type causes a warning on 32-bit targets:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:24: error: cast from
pointer to integer of different size [-Werror=pointer-to-int-cast]
lower_32_bits((uint64_t)wptr));
^
drivers/gpu/drm/
Disabling CONFIG_PM produces a compile time warning when these
functions are not referenced:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error:
'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
static int sun6i_dsi_runtime_suspend(struct device *dev)
^~~~
On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote:
> If a plane supports a pixel format and the framebuffer does not pass any
> modifiers, then drm_plane_check_pixel_format() should always return true
> for the given format regardless of whether the plane supports any
> modifiers or
https://bugs.freedesktop.org/show_bug.cgi?id=106548
--- Comment #13 from Chris Wilson ---
Frequency changes are accompanied by a tracepoint (though note we only say what
we ask the hw to do, the hw is at liberty to do whatever it wants), and you can
enable the tracepoints for batch submission, so
Hi Ayan,
On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote:
If a plane supports a pixel format and the framebuffer does not pass any
modifiers, then drm_plane_check_pixel_format() should always return true
for the given format regardless of whether the plane supports any
modifier
If a plane supports a pixel format and the framebuffer does not pass any
modifiers, then drm_plane_check_pixel_format() should always return true
for the given format regardless of whether the plane supports any
modifiers or not.
Signed-off-by: Ayan Kumar Halder
---
drivers/gpu/drm/drm_plane.c |
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c| 116 +
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only v
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other dom
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed soluti
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
co
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is m
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated module for the shared code and export corresponding
sym
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table
On Thu, May 24, 2018 at 05:41:01PM +0100, Liviu Dudau wrote:
From: Brian Starkey
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback connect
https://bugs.freedesktop.org/show_bug.cgi?id=106548
--- Comment #12 from Francesco Balestrieri ---
(In reply to Chris Wilson from comment #11)
> An idle gpu is always reported as running at the min(idle) freq. You have to
> be very careful in the workload you construct that it does indeed keep th
On Fri, May 25, 2018 at 12:45 AM, Nayan Deshmukh
wrote:
> Signed-off-by: Nayan Deshmukh
Reviewed-by: Alex Deucher
> ---
> Documentation/gpu/drm-mm.rst | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> ind
On Fri, May 25, 2018 at 12:45 AM, Nayan Deshmukh
wrote:
> convert existing raw comments into kernel-doc format as well
> as add new documentation
>
> Signed-off-by: Alex Deucher
> Signed-off-by: Nayan Deshmukh
Looks good. just a couple comments below to clarify the language.
With those fixed:
https://bugs.freedesktop.org/show_bug.cgi?id=106647
--- Comment #3 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
On Fri, May 25, 2018 at 10:21:20AM -0400, Alex Deucher wrote:
> On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala
> wrote:
> > From: Ville Syrjälä
> >
> > Fix up a bunch of bad indentation and insconsistent comments
>
> inconsistent
Dang. Pulled the trigger on dim mere seconds before seeing your
r
From: kbuild test robot
drivers/dma-buf/udmabuf.c:167:6-12: inconsistent IS_ERR and PTR_ERR on line 168.
PTR_ERR should access the value just tested by IS_ERR
Semantic patch information:
There can be false positives in the patch case, where it is the call to
IS_ERR that is wrong.
Generated
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #5 from coolo...@gmail.com ---
Is there any additional info we need to get? Anything we can test? My system is
currently unusable until this is fixed and it has been 3 months since being
reported and haven't heard anything but more re
On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Fix up a bunch of bad indentation and insconsistent comments
inconsistent
With that fixed:
Reviewed-by: Alex Deucher
> in edid_cea_modes[].
>
> v2: Instead of stripping the aspect ratio comments let's
> add th
A driver to let userspace turn memfd regions into dma-bufs.
Use case: Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources. Then they can be passed around to display
those guest things on the host. To spice client for classic full
framebuffer display, and hopefully some d
https://bugs.freedesktop.org/show_bug.cgi?id=106548
--- Comment #11 from Chris Wilson ---
An idle gpu is always reported as running at the min(idle) freq. You have to be
very careful in the workload you construct that it does indeed keep the gpu
busy if you want to use a sampling method.
No sign
https://bugs.freedesktop.org/show_bug.cgi?id=106548
--- Comment #10 from Francesco Balestrieri ---
Indeed, after some more investigation I found out that the test case uses (via
MDAPI) the root-only interface:
/sys/devices/pci:00/:00:02.0/drm/card0/gt_boost_freq_mhz
/sys/devices/pci:
Drivers that want to implement mmap handling different to what
drm_gem_mmap provides need a way to look up the GEM BO from the
fake VMA offset. Split this out to make it reusable.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/drm_gem.c | 56 +++
include/drm/d
The intention of the existing code was to deflect the actual work
of mmaping a dma-buf to the exporter, as that one probably knows best
how to handle the buffer. Unfortunately the call to drm_gem_mmap did
more than what etnaviv needs in this case by actually setting up the
mapping.
Move mapping se
On 30/04/18 18:59, Sinan Kaya wrote:
On 4/30/2018 9:54 AM, Robin Murphy wrote:
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses which drm_prime_sg_to_page_addr_arrays()
iterates
Den 24.05.2018 11.16, skrev Daniel Vetter:
On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.
A t
1 - 100 of 144 matches
Mail list logo