https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #8 from Matt Turner ---
(In reply to rol...@rptd.ch from comment #4)
> I tried compiling from source but it does not work. Seems to have troubles
> with libdrm.
>
> configure: error: Package requirements (libdrm >= 2.4.75 libdrm_int
Koenig, Christian 於 2019年7月16日週二 下午9:38寫道：
>
> Am 11.07.19 um 05:10 schrieb Fuqian Huang:
> > In function __ttm_dma_alloc_page(), d_page->addr is allocated
> > by dma_alloc_attrs() but freed with use dma_free_coherent() in
> > __ttm_dma_free_page().
> > Use the correct dma_free_attrs() to free d_p
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_word() calls with
pcie_ca
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_word() calls with
pcie_ca
Hi Dave, Daniel,
The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532:
drm/modes: Don't apply cmdline's rotation if it wasn't specified (2019-07-16
10:34:38 +0200)
are available in the Git repository at:
g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.
Various cleanup patches, improvements to display colour management,
fixes to ACR ("secure boot") issues on various newer systems, TU116
support.
Ben.
The following changes since commit 3729fe2bc2a01f4cc1aa88be8f64af06084c87d6:
Revert "Merge branch 'vmwgfx-next' of
git://people.freedesktop.org/
Am 18.07.19 um 09:21 schrieb Fuqian Huang:
> Koenig, Christian 於 2019年7月16日週二 下午9:38寫道：
>> Am 11.07.19 um 05:10 schrieb Fuqian Huang:
>>> In function __ttm_dma_alloc_page(), d_page->addr is allocated
>>> by dma_alloc_attrs() but freed with use dma_free_coherent() in
>>> __ttm_dma_free_page().
>>>
On Sun, Jun 30, 2019 at 08:18:59AM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
> Fix fallout.
>
> Signed-off-by: Sam Ravnborg
> Cc: Shawn Guo
> Cc: David Airlie
> Cc: Daniel Vetter
Acked-by: Shawn Guo
___
dri-devel m
Not really harmful not to, but also not harm in grabbing the lock. And
this shuts up a new WARNING I introduced in commit ddde3c18b700 ("vt:
More locking checks").
Reported-by: Jens Remus
Cc: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linu
https://bugs.freedesktop.org/show_bug.cgi?id=98369
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Product|xorg
On Thu, Jul 18, 2019 at 03:29:48AM +, Wen He wrote:
>
>
> > -Original Message-
> > From: Liviu Dudau
> > Sent: 2019年7月17日 19:22
> > To: Wen He
> > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> +void INIT_HEAP_HELPER_BUFFER(struct heap_helper_buffer *buffer,
> + void (*free)(struct heap_helper_buffer *))
Please use a lower case naming following the naming scheme for the
rest of the file.
> +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
>
This and the previous one seem very much duplicated boilerplate
code. Why can't just normal branches for allocating and freeing
normal pages vs cma? We even have an existing helper for that
with dma_alloc_contiguous().
On 2019-07-18 11:06 a.m., Timur Kristóf wrote:
>>> Thanks Marek, I didn't know about that option.
>>> Tried it, here is the output: https://pastebin.com/raw/9SAAbbAA
>>>
>>> I'm not quite sure how to interpret the numbers, they are
>>> inconsistent
>>> with the results from both pcie_bw and amdgpu.
Hi Daniel.
Patch looks good. You can add my:
Acked-by: Sam Ravnborg
For good measure I checked all other users of con_is_bound()
and they looked good from a locking perspective.
Then I looked a bit more for missing locking and lost
the overview.
On Thu, Jul 18, 2019 at 10:09:03AM +0200, Daniel
> -Original Message-
> From: Liviu Dudau
> Sent: 2019年7月18日 17:37
> To: Wen He
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
>
> Subject: Re: [EXT] Re: [PATCH] drm/arm/mali-dp: Add display QoS int
https://bugs.freedesktop.org/show_bug.cgi?id=110258
--- Comment #8 from Paul Gover ---
Git bisect:
106c7d6148e5aadd394e6701f7e498df49b869d1 is the first bad commit
commit 106c7d6148e5aadd394e6701f7e498df49b869d1
Author: Likun Gao
Date: Thu Nov 8 20:19:54 2018 +0800
drm/amdgpu: abstract t
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
syncobj,
then return non-block error code to user sapce.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
Quoting Chunming Zhou (2019-07-18 12:13:39)
> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
> syncobj,
> then return non-block error code to user sapce.
Block device required?
I presume you tried the EWOULDBLOCK which would be implied by your
sentence and found that wo
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
syncobj,
then return non-block error code to user sapce.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-
Am 18.07.2019 um 10:09 schrieb Daniel Vetter:
Not really harmful not to, but also not harm in grabbing the lock. And
this shuts up a new WARNING I introduced in commit ddde3c18b700 ("vt:
More locking checks").
Reported-by: Jens Remus
Cc: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesk
Den 17.07.2019 22.37, skrev Hans de Goede:
> Hi Noralf,
>
> Thank you for the review.
>
> On 17-07-19 17:24, Noralf Trønnes wrote:
>>
>>
>> Den 12.07.2019 20.53, skrev Hans de Goede:
>>> Add a modesetting driver for Grain Media GM12U320 based devices
>>> (primarily Acer C120 projector, but ther
Den 17.07.2019 21.48, skrev David Lechner:
> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>> This is only used by mipi-dbi drivers so move it there.
>>
>> The reason this isn't moved to the SPI subsystem is that it will in a
>> later patch pass a dummy rx buffer for SPI controllers that need this.
>
Den 17.07.2019 22.09, skrev David Lechner:
> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>> The tinydrm helper is going away so move it into the only user mipi-dbi.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/tinydrm/mipi-dbi.c | 15 ---
>> include/drm/tinydrm/t
Den 17.07.2019 22.46, skrev David Lechner:
> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>> tinydrm_display_pipe_init() has only one user now, so move it to
>> mipi-dbi.
>>
>> Changes:
>> - Remove drm_connector_helper_funcs.detect, it's always connected.
>> - Store the connector and mode in mipi_db
Cc devicet...@vger.kernel.org list - Rob once informed us this gets
higher priority in his queue this way.
On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> .../bindings/leds/backlight/led-backlight.txt | 28 +++
On Wed, Jul 17, 2019 at 9:08 PM Frederick Lawler wrote:
>
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
>
> Replace
On Wed, Jul 17, 2019 at 9:08 PM Frederick Lawler wrote:
>
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
>
> Replace
在 2019/7/18 19:31, Lionel Landwerlin 写道:
> On 18/07/2019 14:13, Chunming Zhou wrote:
>> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
>> on syncobj,
>> then return non-block error code to user sapce.
>>
>> Signed-off-by: Chunming Zhou
>> ---
>> drivers/gpu/drm/drm_synco
在 2019/7/18 19:18, Chris Wilson 写道:
> Quoting Chunming Zhou (2019-07-18 12:13:39)
>> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
>> syncobj,
>> then return non-block error code to user sapce.
> Block device required?
Yes, if WAIT_FOR_SUBMIT is set, then that will blo
Quoting Chunming Zhou (2019-07-18 14:04:09)
>
> 在 2019/7/18 19:18, Chris Wilson 写道:
> > Quoting Chunming Zhou (2019-07-18 12:13:39)
> >> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
> >> syncobj,
> >> then return non-block error code to user sapce.
> > Block device req
在 2019/7/18 21:10, Chris Wilson 写道:
> Quoting Chunming Zhou (2019-07-18 14:04:09)
>> 在 2019/7/18 19:18, Chris Wilson 写道:
>>> Quoting Chunming Zhou (2019-07-18 12:13:39)
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
syncobj,
then return non-block error cod
On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China) wrote:
> Adds to print the event message when error happens and the same event
> will not be printed until next vsync.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile
On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
> This series aims to add a led-backlight driver, similar to pwm-backlight,
> but using a LED class device underneath.
>
> A few years ago (2015), Tomi Valkeinen posted a series implementing a
> backlight driver on top of a LED device:
> https://patch
Quoting Chunming Zhou (2019-07-18 14:15:49)
>
> 在 2019/7/18 21:10, Chris Wilson 写道:
> > Quoting Chunming Zhou (2019-07-18 14:04:09)
> >> 在 2019/7/18 19:18, Chris Wilson 写道:
> >>> Quoting Chunming Zhou (2019-07-18 12:13:39)
> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fenc
在 2019/7/18 21:15, Zhou, David(ChunMing) 写道:
> 在 2019/7/18 21:10, Chris Wilson 写道:
>> Quoting Chunming Zhou (2019-07-18 14:04:09)
>>> 在 2019/7/18 19:18, Chris Wilson 写道:
Quoting Chunming Zhou (2019-07-18 12:13:39)
> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
Using 'imply' causes a new problem, as it allows the case of
CONFIG_INPUT=m with RC_CORE=y, which fails to link:
drivers/media/rc/rc-main.o: In function `ir_do_keyup':
rc-main.c:(.text+0x2b4): undefined reference to `input_event'
drivers/media/rc/rc-main.o: In function `rc_repeat':
rc-main.c:(.tex
Playing dota2 vulkan or GL?
I guess it's vulkan: and there I don't know how vulkan deal with multiple WSIs,
and how dota2 selects the one it will use.
The idea is to clearly identify the code paths which would be "buggy".
(my custom distro is x11 native)
That said, I don't know the status of wa
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #56 from Sylvain BERTRAND ---
Playing dota2 vulkan or GL?
I guess it's vulkan: and there I don't know how vulkan deal with multiple WSIs,
and how dota2 selects the one it will use.
The idea is to clearly identify the code paths whi
On Thu, Jul 18, 2019 at 5:11 AM Timur Kristóf wrote:
>
> On Fri, 2019-07-05 at 09:36 -0400, Alex Deucher wrote:
> > On Thu, Jul 4, 2019 at 6:55 AM Michel Dänzer
> > wrote:
> > > On 2019-07-03 1:04 p.m., Timur Kristóf wrote:
> > > > > > There may be other factors, yes. I can't offer a good
> > > >
On 18/07/2019 16:02, Chunming Zhou wrote:
在 2019/7/18 19:31, Lionel Landwerlin 写道:
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
on syncobj,
then return non-block error code to user sapce.
Signed-off-by: Chunming Zhou
---
dr
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #61 from Talha Khan ---
(In reply to Michael Eagle from comment #60)
> Created attachment 144787 [details]
> attachment-8612-0.html
>
> I am seeing reports with old BIOS, such as F.19.
> I have a 15-cp0001na
> https://support.hp.com
Hi Arnd,
On 18.07.2019 15:42, Arnd Bergmann wrote:
> Using 'imply' causes a new problem, as it allows the case of
> CONFIG_INPUT=m with RC_CORE=y, which fails to link:
>
> drivers/media/rc/rc-main.o: In function `ir_do_keyup':
> rc-main.c:(.text+0x2b4): undefined reference to `input_event'
> drive
On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
>
> Hi Arnd,
>
> On 18.07.2019 15:42, Arnd Bergmann wrote:
> > Using 'imply' causes a new problem, as it allows the case of
> > CONFIG_INPUT=m with RC_CORE=y, which fails to link:
> >
> > drivers/media/rc/rc-main.o: In function `ir_do_keyup':
>
在 2019/7/18 22:08, Lionel Landwerlin 写道:
> On 18/07/2019 16:02, Chunming Zhou wrote:
>> 在 2019/7/18 19:31, Lionel Landwerlin 写道:
>>> On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
on syncobj,
then return non-block erro
From: Ville Syrjälä
Now that we have standard defines for the MSA MISC bits lets use
them on HSW+ where we program these directly into the TRANS_MSA_MISC
register.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +-
drivers/gpu/drm/i915/i915_reg.h
From: Ville Syrjälä
Pull the code for computing the limited color range
setting into a small helper. We'll add a bit more to it
later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +++
1 file changed, 20 insertions(+), 10 deletions(-)
dif
From: Ville Syrjälä
We're configuring the AVI infoframe quantization range bits as if
we're always transmitting RGB pixels. Let's fix this so that we
correctly indicate limited range YCC quantization range when
transmitting YCbCr instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/d
From: Ville Syrjälä
I was playing around with YCbCr 4:4:4 output and noticed several
things wrong in our code. So I fixed it all and tossed in the
prep work for YCbCr 4:4:4 output on ilk+.
Ville Syrjälä (12):
drm/dp: Add definitons for MSA MISC bits
drm/i915: Fix HSW+ DP MSA YCbCr colorspac
From: Ville Syrjälä
Prepare the pipe csc for YCbCr output on ilk/snb. The main difference
to IVB+ is the lack of explicit post offsets, and instead we must
configure the CSC info RGB->YUV mode (which takes care of offsetting
Cb/Cr properly) and enable the "black screen offset" bit to add the
requ
From: Ville Syrjälä
Add definitions for the MSA (Main Stream Attribute) MISC bits. On
some hardware you can program these directly into a register.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 42 +
1 file changed, 42 insertions(+)
diff --
From: Ville Syrjälä
Add comments to explain the ilk pipe csc operation a bit better.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.
From: Ville Syrjälä
crtc_state->limited_color_range only applies to RGB output but
we're currently setting it even for YCbCr output. That will
lead to conflicting MSA and PIPECONF settings which can mess
up the image. Let's make sure limited_color_range stays unset
with YCbCr output.
Also WARN i
From: Ville Syrjälä
Since HSW the PIPECONF progressive vs. interlaced selection is done
with just two bits instead of the earlier three. Let's not look at the
extra bit on HSW+. Also gen2 doesn't support interlaced displays at all.
This is actually fine as is currently because the extra bit is m
From: Ville Syrjälä
Make intel_get_crtc_ycbcr_config() simpler and rename it
to bdw_get_pipemisc_output_format() to better reflect what
it does.
Also toss in some comments to document that the 4:2:0 PIPECONF
bits are glk+ only. They are mbz on earlier platforms so reading
them unconditionally is
From: Ville Syrjälä
Looks like we're currently setting the MSA to xvYCC BT.709 instead
of the YCbCr BT.601 claimed by the comment. But even that comment
is wrong since we configure the CSC matrix to BT.709.
Let's remove the bogus statement from the comment and fix the
MSA to indicate YCbCr BT.70
From: Ville Syrjälä
On HSW the pipe colorspace is configured via PIPECONF
(as opposed to PIPEMISC in BDW+). Let's configure+readout
that stuff correctly.
Enablling YCbCr 4:4:4 output will now be a simple matter of
setting crtc_state->output_format appropriately in the encoder
.compute_config().
From: Ville Syrjälä
On ILK-IVB the pipe colorspace is configured via PIPECONF
(as opposed to PIPEMISC in BDW+). Let's configure+readout
that stuff correctly.
Enablling YCbCr 4:4:4 output will now be a simple matter of
setting crtc_state->output_format appropriately in the encoder
.compute_config
On 18.07.2019 16:21, Arnd Bergmann wrote:
> On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
>> Hi Arnd,
>>
>> On 18.07.2019 15:42, Arnd Bergmann wrote:
>>> Using 'imply' causes a new problem, as it allows the case of
>>> CONFIG_INPUT=m with RC_CORE=y, which fails to link:
>>>
>>> drivers/medi
On Thu, Jul 18, 2019 at 4:56 PM Andrzej Hajda wrote:
> On 18.07.2019 16:21, Arnd Bergmann wrote:
> > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
> >> Hi Arnd,
> >>
> >> On 18.07.2019 15:42, Arnd Bergmann wrote:
> >>> Using 'imply' causes a new problem, as it allows the case of
> >>> CONF
Hi team,
I am Guest-Maarten this week and next! Not exactly a quiet last PR for the merge
window, but I think this is right in line with how things have gone over the
rest
of 5.3. Although there's more volume than we'd like, I don't think there's
anything here that is contraversial.
So, welcome
On Thu, Jul 18, 2019 at 6:13 PM Arnd Bergmann wrote:
>
> On Thu, Jul 18, 2019 at 4:56 PM Andrzej Hajda wrote:
> > On 18.07.2019 16:21, Arnd Bergmann wrote:
> > > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
> > >> Hi Arnd,
> > >>
> > >> On 18.07.2019 15:42, Arnd Bergmann wrote:
> > >>> U
On Thu, Jul 18, 2019 at 02:17:37PM +0100, Liviu Dudau wrote:
> On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China)
> wrote:
/snip
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index 647bce5..1462b
On Thu, Jul 18, 2019 at 5:17 PM Dmitry Torokhov
wrote:
> On Thu, Jul 18, 2019 at 6:13 PM Arnd Bergmann wrote:
> > On Thu, Jul 18, 2019 at 4:56 PM Andrzej Hajda wrote:
> > > On 18.07.2019 16:21, Arnd Bergmann wrote:
> > > > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda
> > > > wrote:
> > > >> P
Replace DRM_WAIT_ON() with wait_event_interruptible().
Be careful to keep same return value semantics
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/gpu/drm/via/via_v
This is some janitorial updates to the via driver
that is required to get rid of deprecated headers
in the drm subsystem.
The first three patches are trivial, where
the dependencies on drmP.h and drm_os_linux are dropped.
The remaining three patches drop use of DRM_WAIT_ON().
They are replaced by
Added the necessary header files to make this header file
self-contained.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/gpu/drm/via/via_drv.h | 6 +-
1 file chan
Drop use of the deprecated drmP.h header.
While touching the files divide include files in blocks
and sort the files alphabetically.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
The DRM_READ, DRM_WRITE macros comes from the deprecated drm_os_linux.h
header file. Remove their use to remove this dependency.
Replace the use of the macros with open coded variants.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
DRM_WAIT_ON() is a reliec from the past and is discouraged.
Use the standard wait_event_*() as replacement.
Be carefull to keep the same return values.
via_dma_blit_sync() changed -EINTR to -EAGAIN.
Moved this to via_dmablit_sync() so return value is
adjusted only once.
Signed-off-by: Sam Ravnbo
Replace DRM_WAIT_ON() with wait_event_interruptible().
While replacing be careful to keep same return value semantics.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/
On Sun, Jun 30, 2019 at 05:47:22AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Recently splats like this started showing up:
>
>WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
> __iommu_dma_unmap+0xb8/0xc0
>Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvc
First patch from Jani fixes so drm_print.h is self-contained.
Next two patches are trivial removal of uapi dependencies.
ati_pcigart is fixed to drop use of drm_os_linux.h
drm_vblank is likewise fixed to drop use of drm_os_linux.h
This was a non-trivial conversion, *review requested!*
The remain
drm_vblank.h included uapi/drm/drm.h.
It turns out this include was not required - delete it.
Note: uapi/drm/drm.h is included indirect via drm_file.h,
but there are no dependencies in drm_vblank.h so the removal
is legit.
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Vetter
Cc: Maarten Lankh
From: Jani Nikula
Fix build warning if drm_panel.h is built with CONFIG_OF=n or
CONFIG_DRM_PANEL=n and included without the prerequisite err.h:
./include/drm/drm_panel.h: In function ‘of_drm_find_panel’:
./include/drm/drm_panel.h:203:9: error: implicit declaration of function
‘ERR_PTR’ [-Werror
drm_print.h used DRM_NAME - thus adding a dependency from
include/drm/drm_print.h => uapi/drm/drm.h
Hardcode the name "drm" to break this dependency.
The idea is that there shall be a minimal dependency
between include/drm/* and uapi/*
Signed-off-by: Sam Ravnborg
Suggested-by: Daniel Vetter
Rev
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Thomas Zimmermann
Cc: Rob Herring
---
drivers/gpu/drm/drm
DRM_WAIT_ON() is from the deprecated drm_os_linux header and
the modern replacement is the wait_event_*.
The return values differ, so a conversion is needed to
keep the original interface towards userspace.
Introduced a switch/case to make code obvious and to allow
different debug prints depending
The drm_os_linux.h header is deprecated.
Just opencode the sole DRM_WRITE32().
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/ati_pcigart.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Thomas Zimmermann
Cc: Rob Herring
---
drivers/gpu/drm/drm
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Christian König
Cc: Noralf Trønnes
Cc: Chris Wilson
Cc: Eric Anholt
---
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: CK Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c
drm_file used drm_magic_t from uapi/drm/drm.h.
This is a simple unsigned int.
Just opencode it as such to break the dependency from this header file
to uapi.
Signed-off-by: Sam Ravnborg
Suggested-by: Daniel Vetter
Cc: Sean Paul
Cc: Liviu Dudau
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Maxim
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lionel Landwerlin
Cc: Chunming Zhou
Cc: Christian König
---
drivers/gpu/d
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #9 from rol...@rptd.ch ---
I get two config attempts. This is the second one. Do you see anything out of
place here?
meson --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr
--sysconfdir /etc --wrap-mode nodownl
On Wed, Jun 12, 2019 at 11:13:10AM +0200, Andrzej Hajda wrote:
> On 04.06.2019 14:23, Torsten Duwe wrote:
> > +
> > +static void anx6345_poweron(struct anx6345 *anx6345)
> > +{
> > + int err;
> > +
> > + /* Ensure reset is asserted before starting power on sequence */
> > + gpiod_set_value_ca
From: Ville Syrjälä
crtc_state->limited_color_range only applies to RGB output but
we're currently setting it even for YCbCr output. That will
lead to conflicting MSA and PIPECONF settings which can mess
up the image. Let's make sure limited_color_range stays unset
with YCbCr output.
Also WARN i
Quoting Sam Ravnborg (2019-07-18 17:14:58)
> drm_print.h used DRM_NAME - thus adding a dependency from
> include/drm/drm_print.h => uapi/drm/drm.h
>
> Hardcode the name "drm" to break this dependency.
> The idea is that there shall be a minimal dependency
> between include/drm/* and uapi/*
>
> Si
On Sun, Jul 07, 2019 at 09:19:02PM +0300, Laurent Pinchart wrote:
> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
>
> - It prevents supporting more complex di
On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>
> On 17/07/2019 19:33, Rob Herring wrote:
> > Executable buffers have an alignment restriction that they can't cross
> > 16MB boundary as the GPU program counter is 24-bits. This restriction is
> > currently not handled and we just get lucky. A
On Thu, Jul 18, 2019 at 06:14:57PM +0200, Sam Ravnborg wrote:
> From: Jani Nikula
>
> Fix build warning if drm_panel.h is built with CONFIG_OF=n or
> CONFIG_DRM_PANEL=n and included without the prerequisite err.h:
>
> ./include/drm/drm_panel.h: In function ‘of_drm_find_panel’:
> ./include/drm/dr
On Thu, Jul 18, 2019 at 06:14:58PM +0200, Sam Ravnborg wrote:
> drm_print.h used DRM_NAME - thus adding a dependency from
> include/drm/drm_print.h => uapi/drm/drm.h
>
> Hardcode the name "drm" to break this dependency.
> The idea is that there shall be a minimal dependency
> between include/drm/*
On Thu, Jul 18, 2019 at 06:14:59PM +0200, Sam Ravnborg wrote:
> drm_vblank.h included uapi/drm/drm.h.
> It turns out this include was not required - delete it.
>
> Note: uapi/drm/drm.h is included indirect via drm_file.h,
> but there are no dependencies in drm_vblank.h so the removal
> is legit.
>
On Thu, Jul 18, 2019 at 06:15:00PM +0200, Sam Ravnborg wrote:
> The drm_os_linux.h header is deprecated.
> Just opencode the sole DRM_WRITE32().
Any plans for the other users of DRM_WRITE()? It seems like it'd be trivial
to fix it up for via and mga. I don't really have any background on
drm_os_li
Quoting Brendan Higgins (2019-07-16 11:52:01)
> On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote:
> >
>
> > The only hypothetical case where this can't be done is a complicated
> > assertion or expectation that does more than one check and can't be
> > written as a function that dumps out what
On Thu, Jul 18, 2019 at 06:15:02PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airl
On Thu, Jul 18, 2019 at 06:15:01PM +0200, Sam Ravnborg wrote:
> DRM_WAIT_ON() is from the deprecated drm_os_linux header and
> the modern replacement is the wait_event_*.
>
> The return values differ, so a conversion is needed to
> keep the original interface towards userspace.
> Introduced a swit
On Thu, Jul 18, 2019 at 06:15:03PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airl
On Thu, Jul 18, 2019 at 06:15:06PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc: linux-arm-ker..
On Thu, Jul 18, 2019 at 06:15:04PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airl
1 - 100 of 223 matches
Mail list logo
