On Thu, 24 May 2018, Joe Perches wrote:
> On Fri, 2018-05-25 at 09:41 +0300, Jani Nikula wrote:
>> On Thu, 24 May 2018, Joe Perches wrote:
>> > There is currently a mixture of octal and symbolic permissions uses
>> > in files in drivers/gpu/drm and one file in drivers/gpu.
>> >
>> > There are ~2
This patch add checks for atomic_[duplicate/destroy]_state of
drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant
drm_*_init functions since these callback are mandatory for atomic drivers.
Update the kerneldoc comments for those callbacks.
Signed-off-by: Haneen Mohammed
---
dri
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp pa
Hi,
Dne četrtek, 24. maj 2018 ob 10:43:51 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Mon, May 21, 2018 at 05:15:15PM +0200, Jernej Škrabec wrote:
> > > > + /*
> > > > +* Default register values might have some reserved bits set,
which
> > > > +* prevents TCON TOP from w
* Tomi Valkeinen [180524 08:00]:
>
> On 24/05/18 01:03, Tony Lindgren wrote:
> > Hi all,
> >
> > I bisected the n900 LCD issue to commit 24aac6011f70 ("drm: omapdrm:
> > sdi: Allocate the sdi private data structure dynamically"). Reverting
> > this patch makes LCD work for me again on n900.
> >
Hey Jeffy, Robin:
Some odd issues to report here.
On 23 March 2018 at 04:38, Jeffy Chen wrote:
> Move request_irq to the end of rk_iommu_probe().
>
> Suggested-by: Robin Murphy
> Signed-off-by: Jeffy Chen
> Acked-by: Robin Murphy
> ---
>
> Changes in v8: None
> Changes in v7: None
> Changes i
In the quest to remove all stack VLA usage from the kernel[1], this
allocates the working buffers before starting the writing so it won't
abort in the middle. This needs an initial walk of the lists to figure
out how large the buffer should be.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQ
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as do
Changes in current patchset:
- Defer bridge driver probe until panel probe happens.
- Update the of_graph APIs based on comments.
- Add optional lane-config dt-binding to bridge documentation.
Sandeep Panda (4):
drm/bridge: add support for sn65dsi86 bridge driver
dt-bindings: drm/bridge: Do
On Wed, May 16, 2018 at 10:09 AM, Souptick Joarder wrote:
> On Thu, May 10, 2018 at 7:12 PM, Souptick Joarder
> wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
On Thu, May 24, 2018 at 6:27 PM, Daniel Vetter wrote:
> On Wed, May 23, 2018 at 03:05:35PM +0530, Souptick Joarder wrote:
>> On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
>> > On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
>> >> On Thu, May 10, 2018 at 07:58:11PM +0530, Soupti
This patch add checks for NULL drm_[connector/crtc/plane]_helper_funcs
pointers before derefrencing the variable to avoid NULL pointer
dereference and make the helper functions as optional as possible.
Signed-off-by: Haneen Mohammed
---
drivers/gpu/drm/drm_atomic_helper.c | 42 +++---
Hello everyone,
I am new to DRM and linux, I started reading developers guide and research
on my own.
I don't know where to start on how to communicate the DP helper functions
(drm_dp_dpcd_read, drm_dp_dpcd_readb, drm_dp_dpcd_write,
drm_dp_dpcd_writeb),
what will I include(#include) in my main
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/panel/panel-simple.c | 27
On Thu, 24 May 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix up a bunch of bad indentation and insconsistent comments
> in edid_cea_modes[].
>
> v2: Instead of stripping the aspect ratio comments let's
> add them to all modes
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nik
https://bugs.freedesktop.org/show_bug.cgi?id=106548
--- Comment #8 from Francesco Balestrieri ---
I attached the log I got from Kishore. I wasn't able to spot any kernel failure
though.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106548
--- Comment #9 from Chris Wilson ---
There's no user API that corresponds to a naive interpretation of
"GL_GPU_FREQ_OVERRIDE_MDAPI" (I assume that means to set the gpu frequency).
There is a root-only interface to set the global frequency limits
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #20 from Pontus Gråskæg ---
I got to here from the bug detailed in Ubuntu Launchpad -
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761751
It looks like amdgpu code does not support VGA on Kaveri, either.
I have a Lenovo Z5
Hi Jani,
I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the
brightness value of the display. I also did a test, when I disconnect the DP to
the display and execute the dd commands, it would say error reading
'dev/drm_dp_aux1': Connection timed out. So I think my displ
On Fri, 25 May 2018, John Sledge wrote:
> Hi Jani,
> I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the
> brightness value of the display. I also did a test, when I disconnect the DP
> to the display and execute the dd commands, it would say error reading
> 'dev/drm_
On Tue, May 22, 2018 at 03:13:58PM +0200, Christian König wrote:
> Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
>> On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
>>> On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
> No. __GFP_NOWARN (and gfp_t flags in general) are the wrong
On Fri, 25 May 2018, lester magtagad wrote:
> Hello everyone,
>
> I am new to DRM and linux, I started reading developers guide and research
> on my own.
>
> I don't know where to start on how to communicate the DP helper functions
> (drm_dp_dpcd_read, drm_dp_dpcd_readb, drm_dp_dpcd_write,
> drm
On 2018-05-25 10:41 AM, Christoph Hellwig wrote:
> On Tue, May 22, 2018 at 03:13:58PM +0200, Christian König wrote:
>> Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
>>> On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
>> No. _
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #21 from Pontus Gråskæg ---
Just to add, in addition to the Lenovo Z50-75, the following laptops use this
processor/gpu and have a VGA port
Acer Aspire E5-551-T5SV
Acer Aspire E5-551-T374
HP Probook 445 G2
Lenovo ThinkPad Edge E5
https://bugs.freedesktop.org/show_bug.cgi?id=106647
x...@ymail.com changed:
What|Removed |Added
Summary|powerplay |MSI R9 390 oops at boot
--- Comment #1
Hi, CK:
On Fri, 2018-05-25 at 11:18 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> > From: Stu Hsieh
> >
> > Update device tree binding documentation for the display subsystem for
> > Mediatek MT2712 SoCs.
> >
>
> I've acked v2 of this pa
Hi. CK:
On Fri, 2018-05-25 at 12:23 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> > From: Stu Hsieh
> >
> > This patch add component AAL1 and
> > rename AAL to AAL0
> >
> > Signed-off-by: Stu Hsieh
> > ---
> > drivers/gpu/drm/mediatek/m
https://bugs.freedesktop.org/show_bug.cgi?id=106647
x...@ymail.com changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
Priority|mediu
Hi, CK:
On Fri, 2018-05-25 at 12:51 +0800, CK Hu wrote:
> Hi, Stu:
>
> I've some inline comment.
>
> On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote:
> > From: Stu Hsieh
> >
> > This patch add support for the Mediatek MT2712 DISP subsystem.
> > There are two OVL engine and thre
Hi, CK:
For this patch, I would move it after "add ddp component OD1"
And add this line "#define OD1_MOUT_EN_RDMA1 BIT(16)" from
the path "Add support for mediatek SOC MT2712" to this patch
Regards,
Stu
On Fri, 2018-05-25 at 11:26 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Fri, 2018-05-
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
sourced from different clocks. So the busy time estimation will be target
de
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/set power levels. So we start suspended and only restart
devfreq when GP
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 ++
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 20 insertions(+), 8 delet
This series re-factors the devfreq code a bit in preparation for the upcoming
A6x related devfreq changes. The code applies cleanly on 4.17 and has been
verified on DB820C.
Sharat Masetty (3):
drm/msm: suspend devfreq on init
drm/msm: move suspend/resume devfreq to their own functions
drm/ms
Hi Tomi,
On Wednesday, 23 May 2018 12:42:48 EEST Tomi Valkeinen wrote:
> On 02/04/18 21:50, Laurent Pinchart wrote:
> > 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 Da
On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required notifier registration.
v2:
mei interface handle is protected with mutex. [Chri
https://bugzilla.kernel.org/show_bug.cgi?id=199425
--- Comment #7 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
dmesg output with drm.debug=0x6 and without your patch:
May 25 13:40:54 probook kernel: [drm:amdgpu_dm_do_flip] crtc:0,
pflip_stat:AMDGPU_FLIP_SUBMITTED
May 25 13:40:54 probook
Am 25.05.2018 um 06:45 schrieb Nayan Deshmukh:
When checking for a dependency fence for belonging to the same entity
compare it with scheduled as well finished fence. Earlier we were only
comparing it with the scheduled fence.
Signed-off-by: Nayan Deshmukh
Reviewed and pushed this patch into
Am 25.05.2018 um 06:45 schrieb Nayan Deshmukh:
convert existing raw comments into kernel-doc format as well
as add new documentation
Signed-off-by: Alex Deucher
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 214 --
include/drm/gpu_
Hi Marc,
Am Freitag, 25. Mai 2018, 13:07:02 CEST schrieb Marc Zyngier:
> [Thanks Robin for pointing me to that patch.]
>
> Hi Heiko,
>
> On 24/05/18 23:06, Heiko Stübner wrote:
> > From: Sandy Huang
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver mov
The algorithm used for linux Wound/Wait mutexes, is actually not Wound/Wait
but Wait/Die. See for example
http://www.mathcs.emory.edu/~cheung/Courses/554/Syllabus/8-recv+serial/deadlock-compare.html
Rather than renaming them across the tree to something like Wait/Die mutexes or
Deadlock Avoidance
For modeset locks we don't expect a high number of contending
transactions so change algorithm from Wait-Die to Wound-Wait.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.
The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a preemptive algorithm and is known to generate
fewer backoffs in some cases. Testing reveals that this is true if the
number of si
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
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
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
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
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:
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
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
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
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 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=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 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:
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
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 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
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
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
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
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
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
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 +
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 |
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
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
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
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)
^~~~
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/
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
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
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
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 [
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
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)
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
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
>
/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
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
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 __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
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
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.__
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
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/
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, 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: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
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
1 - 100 of 144 matches
Mail list logo
