2018년 03월 21일 19:20에 Peter Ujfalusi 이(가) 쓴 글:
> Instead of re-implementing the drm_atomic_helper_check() locally with just
> adding drm_atomic_normalize_zpos() into it, set the
> drm_mode_config->normalize_zpos.
>
> Signed-off-by: Peter Ujfalusi
> CC: Inki Dae
> CC: Joonyoung Shim
> CC: Seung
https://bugs.freedesktop.org/show_bug.cgi?id=105426
--- Comment #9 from Tapani Pälli ---
*** Bug 105568 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
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head: a611dd16c69025b6df115427af0a5d63ae9f5145
commit: 2cac05dee6e309bb21424c7d59c62f662d01309e [148/164] drm/amd/powerplay:
add the hw manager for vega12 (v4)
reproduce:
# apt-get install sparse
git checkout
Hi Maruthi,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 2b50aeab552432fab618856c1721cb2bfc7d4c1a
commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/993] ASoC: AMD: enable
ACP3x drivers build
config: tile-allyesconfig
https://bugs.freedesktop.org/show_bug.cgi?id=104082
mikhail.v.gavri...@gmail.com changed:
What|Removed |Added
Attachment #138301|dmesh 4.16-rc6 |dmesg 4.16-rc6
des
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #37 from mikhail.v.gavri...@gmail.com ---
Created attachment 138301
--> https://bugs.freedesktop.org/attachment.cgi?id=138301&action=edit
dmesh 4.16-rc6
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #36 from mikhail.v.gavri...@gmail.com ---
In which kernel mainline version merged patch for this issue?
I see that on `amd-staging-drm-next` branch which branched from 4.16-rc1 this
issue not happens now, but on mainline 4.16-rc6 stil
https://bugzilla.kernel.org/show_bug.cgi?id=199157
--- Comment #3 from Kyle De'Vir (kyle.de...@mykolab.com) ---
GPU-wise, I have an RX580 8GB. This morning, I started to wonder whether the
issue was not even be a driver bug, but actually related to the whole
"Performance Marginality Problem", as m
https://bugzilla.kernel.org/show_bug.cgi?id=199157
--- Comment #2 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274891
--> https://bugzilla.kernel.org/attachment.cgi?id=274891&action=edit
dmesg log
--
You are receiving this mail because:
You are watching the assignee of the
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #13 from jian-h...@endlessm.com ---
Because system hangs up after loading amdgpu module, I cannot get dmesg
directly at that time.
Therefore, I load efi-pstore module to store the dmesg in efi before panic
happens.
The attachments:
"
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #12 from jian-h...@endlessm.com ---
Created attachment 138300
--> https://bugs.freedesktop.org/attachment.cgi?id=138300&action=edit
Oops7 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #11 from jian-h...@endlessm.com ---
Created attachment 138299
--> https://bugs.freedesktop.org/attachment.cgi?id=138299&action=edit
Oops6 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #10 from jian-h...@endlessm.com ---
Created attachment 138298
--> https://bugs.freedesktop.org/attachment.cgi?id=138298&action=edit
Oops5 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #9 from jian-h...@endlessm.com ---
Created attachment 138297
--> https://bugs.freedesktop.org/attachment.cgi?id=138297&action=edit
Oops4 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #7 from jian-h...@endlessm.com ---
Created attachment 138295
--> https://bugs.freedesktop.org/attachment.cgi?id=138295&action=edit
Oops2 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #8 from jian-h...@endlessm.com ---
Created attachment 138296
--> https://bugs.freedesktop.org/attachment.cgi?id=138296&action=edit
Oops3 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #6 from jian-h...@endlessm.com ---
Created attachment 138294
--> https://bugs.freedesktop.org/attachment.cgi?id=138294&action=edit
Oops1 after loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #5 from jian-h...@endlessm.com ---
Created attachment 138293
--> https://bugs.freedesktop.org/attachment.cgi?id=138293&action=edit
dmesg before loading amdgpu module
--
You are receiving this mail because:
You are the assignee for
On 2018.03.22 21:31:33 +, Chris Wilson wrote:
> Quoting Gustavo A. R. Silva (2018-03-22 18:21:54)
> > The checks are misleading and not required [1].
> >
> > [1] https://lkml.org/lkml/2018/3/19/1792
> >
> > Addresses-Coverity-ID: 1466017
> > Cc: Chris Wilson
> > Signed-off-by: Gustavo A. R.
https://bugs.freedesktop.org/show_bug.cgi?id=104193
--- Comment #8 from Shmerl ---
I got a new Sapphire Pulse Vega 56, and when using it - no freezes, I tested
multiple times. It's possible, that with RX 480 it exposed some kind of
hardware defect, hard to tell.
--
You are receiving this mail b
On Mon, Mar 19, 2018 at 2:15 AM, Tomi Valkeinen wrote:
> Hi Rob,
>
> On 19/03/18 02:06, Rob Herring wrote:
>> On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen
>> wrote:
>>> On 09/03/18 20:27, Benoit Parrot wrote:
>>>
> Is logical plane a h/w concept?
It does represent a hardware res
Hi all,
On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/scheduler.c
>
> between commit:
>
> fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
>
> from Linus' tree and c
Hi all,
On Thu, 15 Mar 2018 14:14:25 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> sound/pci/hda/hda_intel.c
>
> between commits:
>
> 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
> 40088dc4e1ea ("ALSA: hda - Revert power
Hi all,
On Tue, 20 Mar 2018 12:08:41 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/sun4i/sun4i_tcon.h
>
> between commit:
>
> e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")
>
> from Linus
Hi Linus,
A bunch of fixes all over the place, nothing too serious or worrying
at this stage.
One uapi fix to stop multi-planar images with getfb,
Sun4i error path and clock fixes
udl driver mmap offset fix
i915 DP MST and GPU reset fixes
vmwgfx mutex and black screen fixes
imx array underflow fi
Den 22.03.2018 21.27, skrev Ville Syrjala:
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems
From: Colin Ian King
Passing stream_res by value is inefficient as it requires a large copy
of 320 bytes. Instead, pass it by reference and also use a pointer to
stream_res->tg and also stream_res->abm to clean up the code a little.
Detected by CoverityScan, CID#1466432 ("Big parameter passed b
Den 22.03.2018 19.49, skrev Ville Syrjälä:
On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote:
tinydrm is also using plane->fb:
$ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/
drivers/gpu/drm/tinydrm/repaper.c: if (tdev->pipe.plane.fb != fb)
drivers/gpu/drm/tinydrm/mipi-dbi.c:
From: Colin Ian King
Pointer hwmgr is dereferenced before it is null checked, hence there
is a possibility of a null pointer dereference. Fix this by only
dereferencing hwmgr once it is null checked.
Detected by CoverityScan, CID#1466428 ("Dereference before null check")
Fixes: 59156faf810e ("
On 03/22/2018 10:02 AM, Daniel Vetter wrote:
It published
s/It/If
the gem object to userspace, by that point other threads
can guess the id and start using it. And gem IDs are _very_ easy to
guess (it's just an idr).
Since gem objects is the only thing we allow drivers to create
themselves (
I've splitted these fixes into 2 patches becasue they do not fixe the same
commit.
Christophe JAILLET (2):
drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
drm/sun4i: hdmi: Fix another error handling path in
'sun4i_hdmi_bind()'
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6
In order to check whether the frontend supports a specific format, an
explicit list and a related helper are introduced.
They are then used to determine whether the frontend can actually support
the requested format when it was selected to be used.
Signed-off-by: Paul Kocialkowski
---
drivers/g
This introduces support for YUV formats in the sun4i DRM driver, through
the frontend. In addition to regular YUV formats, a modifier for the
Allwinner MB32 tiling format is introduced along with a dedicated ioctl
for allocating buffers (through CMA) with the appropriate constraints.
This ioctl mu
This adds all the required configuration and support for handling YUV
formats tiled with the Allwinner MB32 modifier. This newly-introduced
YUV support should be in as good a shape as RGB support.
While this implementation covers most MB32-capable formats supported
by the frontend, only NV12-based
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:05
> To: Nipun Gupta
> Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> m.szyprow...@samsung.com; bhelg...@google.com; zaj...@gmail.com;
> andy.gr...@linaro.org; d
2018-03-23 0:13 GMT+09:00 Geert Uytterhoeven :
> Hi Laurent,
>
> CC Yamada-san
>
> On Thu, Mar 22, 2018 at 3:50 PM, Laurent Pinchart
> wrote:
>> On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote:
>>> On Fri, Mar 16, 2018 at 2:39 AM, wrote:
>>> > On Thursday, March 15, 2018 8:37 AM
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 22, 2018 13:46
> To: Nipun Gupta
>
> > +static int amba_dma_configure(struct device *dev)
> > +{
> > + return dma_common_configure(dev);
> > +}
>
> So it turns out we only end with two callers
The checks are misleading and not required [1].
[1] https://lkml.org/lkml/2018/3/19/1792
Addresses-Coverity-ID: 1466017
Cc: Chris Wilson
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/d
Hi Chris,
On 03/19/2018 03:38 PM, Chris Wilson wrote:
Quoting Gustavo A. R. Silva (2018-03-19 19:30:53)
_workload_ is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the pointer dereference after _workload_ has
been null che
This moves the various helpers and tables related to format detection
and conversion to a dedicated file, while adding a bunch of new helpers
(especially for YUV and tiling support) along the way.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/Makefile| 1 +
drivers/gpu/drm
The YUV channel was only disabled in sun4i_backend_update_layer_formats,
which is not called when the frontend is selected.
Thus, creating a layer with a YUV format handled by the backend and then
switching to a format that requires the frontend would keep the YUV
channel enabled for the layer.
T
Considering the lukewarm reception of my last past request and Keith's
recommendation, I've created and tested a new patch, to bring the intended
functionality back, only prohibiting non-desktop devices if a regular desktop
screen is present.
Previous email chain:
https://lists.freedesktop.or
Hi
On Tuesday, March 20, 2018 06:20 PM, Emil Velikov wrote:
On 20 March 2018 at 06:24, hl wrote:
Hi Emil,
On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:
On 15 March 2018 at 02:35, hl wrote:
Hi Emil,
On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:
Hi Lin,
On 14 M
On Mon, 2018-03-19 at 17:52 +0100, Thierry Reding wrote:
> On Mon, Mar 19, 2018 at 02:32:08PM +, Marcel Ziswiler wrote:
> > Hi Thierry
> >
> > On Mon, 2018-03-19 at 10:59 +0100, Thierry Reding wrote:
> > > Hi Dave,
> > >
> > > The following changes since commit
> > > 7928b2cbe55b2a410a0f5c1f1
It's bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces '/dma_configure/' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.
The change eases the addition of new
It seems there is a classical off-by-one typo from the beginning
when commit
ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
introduced a new helper.
Fix a typo by introducing a macro constant.
Cc: Dave Airlie
Signed-off-by: Andy Shevchenko
---
- use macro for buffer
* Sebastian Reichel [180208 18:31]:
> In preparation for manually updated display support, such as DSI
> command mode panels, this adds a simple helper to see if a connector
> is manually updated.
Tested-by: Tony Lindgren
___
dri-devel mailing list
dri
The frontend supports many YUV formats as input and also contains a
color-space converter (CSC) block that can convert YUV input into
RGB output. It also allows scaling between the input and output for
every possible combination of supported formats.
This adds support for all the (untiled) YUV vid
"foo * bar" should be "foo *bar"
Signed-off-by: Paul McQuade
---
drivers/gpu/drm/drm_bufs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 1ee84dd802d4..83b3d0801262 100644
--- a/drivers/gpu/drm/drm_bufs.c
If we can not get the HDMI DDC clock, we still need to free some
resources before returning.
Fixes: 939d749ad664 ("drm/sun4i: hdmi: Add support for controller hardware
variants")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 3 ++-
1 file changed, 2 insertions(+
Hi Thierry
On Mon, 2018-03-19 at 10:59 +0100, Thierry Reding wrote:
> Hi Dave,
>
> The following changes since commit
> 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
>
> Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/teg
On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hello!
>
> Resending with all the patches squashed on Daniel's request.
Which of the two series are we supposed to review? The 8-patch one or
this? (I hope it's the former)
-boris
__
Remove drmP.h as it is not needed anymore since nothing it defines is
used in these files and use drm_print.h instead as these files are using
the debug macros defined there.
Signed-off-by: Haneen Mohammed
---
drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
drivers/gpu/drm/zte/zx_hdmi.c| 2 +-
driv
Assign true or false to boolean variables instead of an integer value.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/aty/aty128fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/aty12
Hi Emil,
On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:
On 15 March 2018 at 02:35, hl wrote:
Hi Emil,
On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:
Hi Lin,
On 14 March 2018 at 09:12, Lin Huang wrote:
From: huang lin
Refactor Innolux P079ZCA panel driver, let it
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 22, 2018 13:49
> To: Nipun Gupta
>
> > --- a/drivers/dma/qcom/hidma_mgmt.c
> > +++ b/drivers/dma/qcom/hidma_mgmt.c
> > @@ -398,7 +398,7 @@ static int __init
> hidma_mgmt_of_populate_channels(stru
With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described
This adds a dedicated function for disabling the layer video channel
from the frontend to the backend. It is called automatically on an
atomic update, as to disable the frontend by default (it will be enabled
later on in the atomic update if necessary).
It fixes an issue when enabling a layer that
This introduces a dedicated ioctl for allocating tiled buffers in the
Allwinner MB32 format, that comes with a handful of specific
constraints. In particular, the stride of the buffers is expected to be
aligned to 32 bytes.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_drv.c |
* Sebastian Reichel [180208 18:31]:
> This prepares framedone interrupt handling for
> manual display update support.
>
> Signed-off-by: Sebastian Reichel
Tested-by: Tony Lindgren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lis
This patch remove the compatibility aliases
drm_property_{reference/unreference}_blob of
drm_property_blob_{get/put} since all callers have been converted to the
prefered _{get/put}.
Remove the helpers from the semantic patch drm-get-put-cocci.
Signed-off-by: Haneen Mohammed
---
include/drm/drm
Tomi,
* Sebastian Reichel [180208 10:31]:
> Hi,
>
> These are the remaining patches from my previous patchset to get
> Droid 4 (omap4) display working. The patches have been rebased to
> current master branch from Torvalds (581e400ff935). Since N950
> (omap3) is broken even with the workaround I
code indent should use tabs where possible
Signed-off-by: Paul McQuade
---
drivers/gpu/drm/drm_bufs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 8e345ba16858..ba8cfe65c65b 100644
--- a/drivers/gpu/drm/drm_
* Sebastian Reichel [180208 18:31]:
> This adds the required infrastructure for manually
> updated displays, such as DSI command mode panels.
>
> While those panels often support partial updates
> we currently always do a full refresh. Display
> will be refreshed when something calls the dirty
>
It turns out that the frontend is not capable of preserving the alpha
component (that is always set to 0xff), so only support XRGB
instead.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4
drivers/gpu/drm/sun4i/sun4i_frontend.c | 3 +--
drivers/gpu/drm/su
In order to check whether the backend supports a specific format, an
explicit list and a related helper are introduced.
They are then used to determine whether the frontend should be used for
a layer, when the format is not supported by the backend.
Signed-off-by: Paul Kocialkowski
---
drivers/
"foo ** bar" should be "foo **bar"
Signed-off-by: Paul McQuade
---
drivers/gpu/drm/drm_bufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 83b3d0801262..9af9efd84ee7 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b
> -Original Message-
> From: Nipun Gupta
> Sent: Wednesday, March 21, 2018 12:25 PM
> To: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> gre...@linuxfoundation.org; m.szyprow...@samsung.com
> Cc: bhelg...@google.com; zaj...@gmail.com; andy.gr...@linaro.org;
> david.br...@lina
platform_get_resource_byname() may fail and return NULL, so we should
better check it's return value to avoid a NULL pointer dereference
a bit later in the code.
This is detected by Coccinelle semantic patch.
@@
expression pdev, res, n, t, e, e1, e2;
@@
res = platform_get_resource_byname(pdev, t
> -Original Message-
> From: Bharat Bhushan
> Sent: Wednesday, March 21, 2018 12:49
> >
> > +int dma_configure(struct device *dev)
> > +{
> > + if (dev->bus->dma_configure)
> > + return dev->bus->dma_configure(dev);
>
> What if dma_common_configure() is called in case "bus->
_workload_ is being dereferenced before it is null checked, hence
there is a potential null pointer dereference.
Fix this by moving the pointer dereference after _workload_ has
been null checked.
Addresses-Coverity-ID: 1430136 ("Dereference before null check")
Fixes: fa3dd623e559 ("drm/i915/gvt:
On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM maste
On 16-03-18, 12:51, Jordan Crouse wrote:
> (resend because I forgot to CC everybody on the patches)
>
> Add DT nodes for the sdm845 GPU/GMU (graphics management unit) and the
> companion
> arm-smmu-v2 compatible SMMU.
>
> This builds on the following dependencies -
> https://patchwork.kernel.org
This introduces specific definitions for vendor Allwinner and its
specific MB32 tiled format, an NV12-based format with 32x32 tiles.
This format is the default output format used by the VPU on most
Allwinner platforms.
Signed-off-by: Paul Kocialkowski
---
include/uapi/drm/drm_fourcc.h | 10
Em Mon, 5 Mar 2018 14:51:38 +0100
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> The CEC Pin framework adds support for Error Injection.
>
> Document all the error injections commands and how to use it.
Please notice that all debugfs/sysfs entries should *also* be
documented at the standard
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:00
> > +int dma_configure(struct device *dev)
> > +{
> > + if (dev->bus->dma_configure)
> > + return dev->bus->dma_configure(dev);
> > +
> > + return 0;
> > +}
>
From: Stefan Agner
Use tegra124_(primary|overlay)_formats for Tegra124.
Fixes: 511c7023cf23 ("drm/tegra: dc: Support more formats")
Signed-off-by: Stefan Agner
Acked-by: Marcel Ziswiler
---
Changes in v2:
- re-based on top of today's next
- added my ACK
drivers/gpu/drm/tegra/dc.c | 4 ++--
space prohibited after that open parenthesis '('
Signed-off-by: Paul McQuade
---
drivers/gpu/drm/drm_bufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 9af9efd84ee7..8e345ba16858 100644
--- a/drivers/gpu/drm/dr
If we can not allocate the HDMI encoder regmap, we still need to free some
resources before returning.
Fixes: 4b1c924b1fc1 ("drm/sun4i: hdmi: create a regmap for later use")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 3 ++-
1 file changed, 2 insertions(+), 1 d
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1466154 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/gvt/handlers.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
On 03/19/2018 04:23 PM, Chris Wilson wrote:
Quoting Gustavo A. R. Silva (2018-03-19 20:50:12)
Hi Chris,
On 03/19/2018 03:38 PM, Chris Wilson wrote:
Quoting Gustavo A. R. Silva (2018-03-19 19:30:53)
_workload_ is being dereferenced before it is null checked, hence
there is a potential null p
This patch remove the compatibility aliases
drm_mode_object_{reference/unreference} of drm_mode_object_{get/put}
since all callers have been converted to the prefered _{get/put}.
Remove the helpers from the semantic patch drm-get-put-cocci.
Signed-off-by: Haneen Mohammed
---
include/drm/drm_mod
Quoting Gustavo A. R. Silva (2018-03-22 18:21:54)
> The checks are misleading and not required [1].
>
> [1] https://lkml.org/lkml/2018/3/19/1792
>
> Addresses-Coverity-ID: 1466017
> Cc: Chris Wilson
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Chris Wilson
Zhenyu?
-Chris
The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.
The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into ac
The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.
The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into ac
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems simpler to split the fb->dirty() into a tinydrm
From: Ville Syrjälä
We'll need access to the plane state during .atomic_enable().
Performed with coccinelle:
@r1@
identifier F =~ ".*enable$";
identifier P, CS;
@@
F(
struct drm_simple_display_pipe *P
,struct drm_crtc_state *CS
+ ,struct drm_plane_state *plane_state
https://bugs.freedesktop.org/show_bug.cgi?id=105697
Bug ID: 105697
Summary: gcc -static-libgcc -static-libstdc++ support is broken
by libtool for dri drivers
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
This is a register to help debug what is in the last SDP VSC
packet revived by sink.
Signed-off-by: José Roberto de Souza
---
include/drm/drm_dp_helper.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0bac0c7d0dec..91c
To comply with eDP1.4a this bit should be set when enabling PSR2.
Signed-off-by: José Roberto de Souza
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 62903bae0221..0bac0c7d0dec 100644
--- a/inclu
Hi Dave,
A few fixes for 4.16. Main thing here is getting getfb to reject
multiplanar fbs. I should have sent some of these before but conference
and traveling got in the way.
Thanks,
Gustavo
drm-misc-fixes-2018-03-22:
Main change is a patch to reject getfb call for multiplanar framebuffers,
th
On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote:
> tinydrm is also using plane->fb:
>
> $ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/
> drivers/gpu/drm/tinydrm/repaper.c: if (tdev->pipe.plane.fb != fb)
> drivers/gpu/drm/tinydrm/mipi-dbi.c: if (tdev->pipe.plane.fb != fb)
>
On 22 March 2018 at 18:03, Harry Wentland wrote:
> On 2018-03-22 01:54 PM, Emil Velikov wrote:
>> Hi Ville,
>>
>> On 22 March 2018 at 15:22, Ville Syrjala
>> wrote:
>>> From: Ville Syrjälä
>>>
>>> I really just wanted to fix i915 to re-enable its planes afer load
>>> detection (a two line patch
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
> label, is an industrial Human Machine Interface.
> It features:
> - 512MB DDR RAM
> - 1 Sd-card >= 4GB
> - 1 Usb otg(programmable via software) with A-Usb C
Quoting Matt Roper (2018-03-21 23:23:37)
> There are cases where other parts of the kernel may wish to store data
> associated with individual cgroups without building a full cgroup
> controller. Let's add interfaces to allow them to register and lookup
> this private data for individual cgroups.
On 2018-03-22 01:54 PM, Emil Velikov wrote:
> Hi Ville,
>
> On 22 March 2018 at 15:22, Ville Syrjala
> wrote:
>> From: Ville Syrjälä
>>
>> I really just wanted to fix i915 to re-enable its planes afer load
>> detection (a two line patch). This is what I actually ended up with
>> after I ran int
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Ville,
On 22 March 2018 at 15:22, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I really just wanted to fix i915 to re-enable its planes afer load
> detection (a two line patch). This is what I actually ended up with
> after I ran into a framebuffer refcount leak with said two line patch.
>
On Thu, Mar 22, 2018 at 05:14:08PM +0100, Maarten Lankhorst wrote:
> Op 22-03-18 om 16:23 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > We want to get rid of plane->fb on atomic drivers. Stop looking at it.
> >
> > Cc: Boris Brezillon
> > Signed-off-by: Ville Syrjälä
> > ---
> > driver
From: Ville Syrjälä
When doing forced load detection testing we should totally ignore any
hotplug status for the connector. This is mostly relevant for machines
where we already ignore the hotplug status based on the DMI quirks. On
other machines we would currently skip the force load detection t
1 - 100 of 231 matches
Mail list logo