On Thu, Mar 28, 2019 at 05:03:03PM -0400, Sean Paul wrote:
> On Wed, Mar 27, 2019 at 07:15:00PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 26, 2019 at 04:44:54PM -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > This patch adds a new drm helper library to help drivers implement
> > > sel
On Thu, Mar 28, 2019 at 11:52:30AM -0500, Reza Arbab wrote:
On Thu, Mar 28, 2019 at 05:33:31PM +0100, Linus Walleij wrote:
This makes perfect sense, but Dave Airlie already sent a similar
patch some two weeks ago, I wonder what happened with it?
Subject "avoid setting 0 depth".
Argh, that he d
On Thu, Mar 28, 2019 at 04:12:10PM +0200, Laurent Pinchart wrote:
> Hi Jagadeesh,
>
> On Thu, Mar 28, 2019 at 09:32:06PM +0530, Jagadeesh Pagadala wrote:
> > On Thu, Mar 28, 2019 at 08:51:24AM +0200, Laurent Pinchart wrote:
> > > On Thu, Mar 28, 2019 at 02:41:56AM +0530, jagdsh.li...@gmail.com wro
On 3/29/2019 7:11 AM, YueHaibing wrote:
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Signed-off-by: YueHaibing
Reviewed-by: Mukesh Ojha
-Mukesh
---
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gp
Sometimes it is desirabled to use a separate i2c controller for ddc
access. This adds support for the ddc-i2c-bus property of the
hdmi-connector node, using the specified controller if provided.
Signed-off-by: Mans Rullgard
---
Changed in v2:
- Return ERR_PTR(-ENODEV) instead of NULL when proper
On 3/29/2019 12:32 AM, Jagadeesh Pagadala wrote:
On Thu, Mar 28, 2019 at 04:12:10PM +0200, Laurent Pinchart wrote:
Hi Jagadeesh,
On Thu, Mar 28, 2019 at 09:32:06PM +0530, Jagadeesh Pagadala wrote:
On Thu, Mar 28, 2019 at 08:51:24AM +0200, Laurent Pinchart wrote:
On Thu, Mar 28, 2019 at 02:41
> -Original Message-
> From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> Sent: 2019年3月29日 0:39
> To: Wen He
> Cc: brian.star...@arm.com; mal...@foss.arm.com;
> dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid
> flicker
Hi,
Question for Heiko cs. See below.
Let me know if there's a need for V6?
On 3/19/19 12:44 PM, Heiko Stübner wrote:
> Am Mittwoch, 6. März 2019, 23:41:10 CET schrieb Johan Jonker:
>> +static int rk3066_hdmi_connector_get_modes(struct drm_connector *connector)
>> +{
>> +struct rk3066_hdmi
On Thu, Mar 28, 2019 at 05:33:31PM +0100, Linus Walleij wrote:
This makes perfect sense, but Dave Airlie already sent a similar
patch some two weeks ago, I wonder what happened with it?
Subject "avoid setting 0 depth".
Argh, that he did! I'm not subscribed to dri-devel so I didn't see that.
Di
Am 27.03.19 um 09:19 schrieb Guido Günther:
> Add vendor prefix "mixel" for Mixel Inc. Will be used for a MIPI DSI
> PHY driver.
Nit: s/driver/binding/ (to not be Linux specific)
>
> Signed-off-by: Guido Günther
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file chan
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Signed-off-by: YueHaibing
---
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
index e384
Calling strncpy with a maximum size argument of 64 bytes on destination
array "domain->name" of size 64 bytes might leave the destination string
unterminated.
Detected by CoverityScan, CID# 1443992: Memory - illegal accesses
(BUFFER_SIZE_WARNING)
Fixes: 9e2c2e2730126 (drm/etnaviv: add infrastru
On Fri, Mar 22, 2019 at 12:44 PM Catalin Marinas
wrote:
>
> On Wed, Mar 20, 2019 at 03:51:18PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) a
On a failed resume we may experience unrecoverable errors. Plumb the error code
through to actually let the driver fail. On a reverse-prime setup this helps the
drm subsystem to at least recover the integrated gpu.
This can especially happen with secboot timing out, leaving the hardware in a
non-f
On Fri, Mar 29, 2019 at 02:46:55PM +1000, Dave Airlie wrote:
> commit 2e1c9b2867656ff9a469d23e1dfe90cf77ec0c72
> Author: Tejun Heo
> Date: Fri Mar 8 12:43:30 2013 -0800
>
> idr: remove WARN_ON_ONCE() on negative IDs
>
> We used to WARN_ON if we hit a negative id, it appears we don't
> anym
On Thu, Mar 28, 2019 at 05:13:05PM +0100, Paul Kocialkowski wrote:
> The firstopen DRM driver hook was initially used to perform hardware
> initialization, which is now considered legacy. Only a single user of
> firstopen remains at this point (savage).
>
> In some specific cases, non-legacy drive
On Fri, Mar 29, 2019 at 09:35:34AM +0100, Daniel Vetter wrote:
> On Thu, Mar 28, 2019 at 05:13:05PM +0100, Paul Kocialkowski wrote:
> > The firstopen DRM driver hook was initially used to perform hardware
> > initialization, which is now considered legacy. Only a single user of
> > firstopen remain
Hi Daniel,
On Fri, 2019-03-29 at 09:35 +0100, Daniel Vetter wrote:
> On Thu, Mar 28, 2019 at 05:13:05PM +0100, Paul Kocialkowski wrote:
> > The firstopen DRM driver hook was initially used to perform hardware
> > initialization, which is now considered legacy. Only a single user of
> > firstopen r
Hi,
On Thu, 28 Mar 2019 at 18:53, Daniel Vetter wrote:
> On Thu, Mar 21, 2019 at 04:27:06PM +0100, Paul Kocialkowski wrote:
> > I don't see other options either, and using firstclose/lastopen feels
> > overall more readable in the driver code.
> >
> > I'm not sure there is such a big overhead ass
Interpreting it as a 0.16 fixed point means we can't accurately
represent 1.0. Which is one of the values we really should be able to
represent.
Since most (all?) luts have lower precision this will only affect
rounding of 0x.
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Shashank Sharma
Cc: "Kuma
On 27/03/2019 16:58, Damian Kos wrote:
> We would be very happy to have a separate driver for mhdp8546 instead of
> mixing it with Rockchip's driver. Unfortunately we need to have one driver
> for both IP's, so I'll just change mhdp8546.ko to cdns-mhdp.ko. (Unless,
> maintainers give us a green li
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #39 from Dimitar Atanasov ---
I am with same problem. Computer is Dell Precision 5530 2-in-1 with VegaM
inside
EGPU is Vega56. EGPU is not starting even with acpi=off. Kernel 5.0.4
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #40 from Dimitar Atanasov ---
Created attachment 143804
--> https://bugs.freedesktop.org/attachment.cgi?id=143804&action=edit
acpi=off amd.dpm=0
Vega 56
--
You are receiving this mail because:
You are the assignee for the bug.__
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
S
In order to support the HDMI2.0 YUV420, YUV422 and the 10bit, 12bit and
16bits outpu use cases, add support for the recently introduced bridge
callback format_set().
This callback will setup the new input format and encoding from encoder,
then these information will be used instead of the default
This patch adds a new format_set() callback to the bridge ops permitting
the encoder to specify the new input format and encoding.
This allows supporting the very specific HDMI2.0 YUV420 output mode
when the bridge cannot convert from RGB or YUV444 to YUV420.
In this case, the encode must downsam
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixe
The Synopsys DW-HDMI CSC does not support downsampling to YUV420, so
the encoder must downsamle before, feeding the controller with a YUV420
pixel stream.
The encoder must declare the new bus format enc encoding the bridge, in
order to take it in account.
To solve this, a new format_set() bridge
On Tue, Mar 26, 2019 at 08:50:03AM +0100, Daniel Vetter wrote:
> On Mon, Mar 25, 2019 at 08:29:06AM -0300, Rodrigo Siqueira wrote:
> > On 03/15, Daniel Vetter wrote:
> > > On Thu, Mar 14, 2019 at 03:48:45PM -0300, Rodrigo Siqueira wrote:
> > > > Allow atomic_enable and atomic_disable operations fro
If we're going to export ion_alloc() for other drivers to use then let's
make an ion_free() helper function as well.
void ion_free(struct dma_buf *dmabuf)
{
dma_buf_put(dmabuf);
}
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@list
On 3/20/2019 4:18 PM, Uma Shankar wrote:
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
Signed-off-by: Uma Shankar
---
drive
On 3/20/2019 4:18 PM, Uma Shankar wrote:
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comme
On Fri, Mar 29, 2019 at 08:32:41PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> t
The hopefully final patch series, with feedback applied and
r-b / acked-by tags added. Rebased to current agd5f/drm-5.2-wip
branch.
Numbering has slightly changed. Patches 3-5 are identical to last
series. Patch 2/5 v3 (the former 1/4 v2) trivially rebased on top of
the new 1/5.
Patch 1/5 is new
We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.
In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must
During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations wh
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR mod
For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.
This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no lo
We need the VRR active/inactive state info earlier in
the commit sequence, so VRR related setup functions like
amdgpu_dm_handle_vrr_transition() know the final VRR state
when they need to do their hw setup work.
Split update_freesync_state_on_stream() into an early part,
that can run at the beginn
On 3/20/2019 4:18 PM, Uma Shankar wrote:
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
1 file changed, 13 insertions
On 3/20/2019 4:18 PM, Uma Shankar wrote:
Added the const version of infoframe for DRM metadata
for HDR.
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 63 ++--
include/linux/hdmi.h | 5 +
2 files changed, 66 insertions(+), 2 delet
On 3/20/2019 4:18 PM, Uma Shankar wrote:
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
Initialize the CEC device embedded into sii902x bridge. By default,
the CEC device must be disabled to allow other CEC devices to bypass
the bridge.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/bridge/sii902x.c | 64
1 file changed, 64 insertions(+)
https://bugzilla.kernel.org/show_bug.cgi?id=202873
Thomas (v10la...@myway.de) changed:
What|Removed |Added
CC||v10la...@myway.de
--- Commen
https://bugzilla.kernel.org/show_bug.cgi?id=202873
--- Comment #2 from Thomas (v10la...@myway.de) ---
One more thing: I'm connected to a 60Hz monitor which AFAIK has no FreeSync
support (Dell ST2220M).
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 3/20/2019 4:18 PM, Uma Shankar wrote:
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic.c | 15 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 4
2 fil
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #41 from Dimitar Atanasov ---
Created attachment 143805
--> https://bugs.freedesktop.org/attachment.cgi?id=143805&action=edit
default boot vega 56
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugzilla.kernel.org/show_bug.cgi?id=202873
--- Comment #3 from Thomas (v10la...@myway.de) ---
Now I just realized that I have a second display (TV - Samsung UE40H5090 -
AFAIK also no FreeSync) attached and turned it on to see what happens: Both
displays flicker. If I disable the second scr
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #42 from Dimitar Atanasov ---
actualy with acpi=off, Vega 56 is not found at all during boot, only enclosure
--
You are receiving this mail because:
You are the assignee for the bug.___
d
On Fri, Mar 29, 2019 at 09:21:10AM +0100, Daniel Vetter wrote:
> On Thu, Mar 28, 2019 at 05:03:03PM -0400, Sean Paul wrote:
> > On Wed, Mar 27, 2019 at 07:15:00PM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 26, 2019 at 04:44:54PM -0400, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > T
On 3/29/19 11:40 AM, Zeng Tao wrote:
There are two reasons for this patch:
1. There are some potential requirements for ion_alloc in kernel space,
some media drivers need to allocate media buffers from ion instead of
buddy or dma framework, this is more convient and clean very for media
drivers.
On 3/29/19 8:00 AM, Mario Kleiner wrote:
> We need the VRR active/inactive state info earlier in
> the commit sequence, so VRR related setup functions like
> amdgpu_dm_handle_vrr_transition() know the final VRR state
> when they need to do their hw setup work.
>
> Split update_freesync_state_on_st
Signed-off-by: Qiang Yu
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f8e63bcc4c1c..cd2d632b713d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5101,6 +5101,15 @@ S: Maintained
F: drivers/gpu/drm/hisilicon/
F: Document
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #43 from Alex Deucher ---
(In reply to Dimitar Atanasov from comment #41)
> Created attachment 143805 [details]
> default boot vega 56
Similar issues on your system:
[ 168.653171] pci :3d:00.0: BAR 0: no space for [mem size 0x0
On Wed, Mar 20, 2019 at 04:18:25PM +0530, Uma Shankar wrote:
> HDR metadata requires a infoframe to be set. Due to fastset,
> full modeset is not performed hence adding it to update_pipe
> to handle that.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 13 +
On 3/29/19 8:00 AM, Mario Kleiner wrote:
> During VRR mode we can not allow vblank irq dis-/enable
> transitions, as an enable after a disable can happen at
> an arbitrary time during the video refresh cycle, e.g.,
> with a high likelyhood inside vblank front-porch. An
> enable during front-porch w
On 3/28/19 7:15 PM, John Stultz wrote:
> Here is another RFC of the dma-buf heaps patchset Andrew and I
> have been working on which tries to destage a fair chunk of ION
> functionality.
>
> The patchset implements per-heap devices which can be opened
> directly and then an ioctl is used to alloca
https://bugs.freedesktop.org/show_bug.cgi?id=110229
--- Comment #10 from Laurent ---
Hey is there someone here ???
I tested and, for the bug with the shader, it seems it works, I thing, you made
a mistake, if I look at the source code, I didn't see any command to start the
shader execution so, I
On Fri, Mar 29, 2019 at 08:32:41PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> t
On 3/28/19 7:15 PM, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schul
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of
Am 27.03.19 um 17:32 schrieb Jann Horn:
> When ttm_put_pages() tries to figure out whether it's dealing with
> transparent hugepages, it just reads past the bounds of the pages array
> without a check; instead, when the end of the array is reached, treat that
> as "we don't have enough pages left f
On 29/03/2019 09:20, Daniel Vetter wrote:
Interpreting it as a 0.16 fixed point means we can't accurately
represent 1.0. Which is one of the values we really should be able to
represent.
Since most (all?) luts have lower precision this will only affect
rounding of 0x.
Cc: Uma Shankar
Cc: V
https://bugs.freedesktop.org/show_bug.cgi?id=110229
--- Comment #11 from Daniel Stone ---
(In reply to Laurent from comment #10)
> -You load the first instruction (the boot) tho the GPU memory, it initialize
> the offset register to go to the next instruction but, there is no guarantee
> that the
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of
On 29/03/2019 14:47, Qiang Yu wrote:
> Signed-off-by: Qiang Yu
> ---
> MAINTAINERS | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f8e63bcc4c1c..cd2d632b713d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5101,6 +5101,15 @@ S: Maintai
Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
>
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin
Hi,
On Fri, 2019-03-29 at 09:09 +, Daniel Stone wrote:
> Hi,
>
> On Thu, 28 Mar 2019 at 18:53, Daniel Vetter wrote:
> > On Thu, Mar 21, 2019 at 04:27:06PM +0100, Paul Kocialkowski wrote:
> > > I don't see other options either, and using firstclose/lastopen feels
> > > overall more readable i
Hi,
Le jeudi 28 mars 2019 à 19:53 +0100, Daniel Vetter a écrit :
> On Thu, Mar 21, 2019 at 04:27:06PM +0100, Paul Kocialkowski wrote:
> > Hi,
> >
> > Le mercredi 20 mars 2019 à 09:56 -0700, Eric Anholt a écrit :
> > > Paul Kocialkowski writes:
> > >
> > > > The firstopen DRM driver hook was ini
On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
> Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
>>
>> This adds a CMA heap, which allows userspace to allocate
>> a dma-buf of contiguous memory out of a CMA region.
>>
>> This code is an evolution of the Android ION implementation, so
>> thanks t
On Fri, Mar 29, 2019 at 09:47:48PM +0800, Qiang Yu wrote:
> Signed-off-by: Qiang Yu
> ---
> MAINTAINERS | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f8e63bcc4c1c..cd2d632b713d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5101,6 +5101
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of
On Fri, Mar 29, 2019 at 04:02:23PM +0100, Paul Kocialkowski wrote:
> Hi,
>
> On Fri, 2019-03-29 at 09:09 +, Daniel Stone wrote:
> > Hi,
> >
> > On Thu, 28 Mar 2019 at 18:53, Daniel Vetter wrote:
> > > On Thu, Mar 21, 2019 at 04:27:06PM +0100, Paul Kocialkowski wrote:
> > > > I don't see othe
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #19 from Michel Dänzer ---
(In reply to Diego Viola from comment #12)
> I also tried recompiling xorg-server (git and 1.20.0) and the problem still
> persists with those, [...]
Did you build xserver with meson or autotools?
--
You
Le ven. 29 mars 2019 à 16:19, Andrew F. Davis a écrit :
>
> On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
> > Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
> >>
> >> This adds a CMA heap, which allows userspace to allocate
> >> a dma-buf of contiguous memory out of a CMA region.
> >>
> >> Th
On Fri, Mar 29, 2019 at 09:16:59AM -0400, Sean Paul wrote:
> On Fri, Mar 29, 2019 at 09:21:10AM +0100, Daniel Vetter wrote:
> > On Thu, Mar 28, 2019 at 05:03:03PM -0400, Sean Paul wrote:
> > > On Wed, Mar 27, 2019 at 07:15:00PM +0100, Daniel Vetter wrote:
> > > > On Tue, Mar 26, 2019 at 04:44:54PM
On 3/29/19 10:30 AM, Benjamin Gaignard wrote:
> Le ven. 29 mars 2019 à 16:19, Andrew F. Davis a écrit :
>>
>> On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
>>> Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
This adds a CMA heap, which allows userspace to allocate
a dma-buf of c
https://bugs.freedesktop.org/show_bug.cgi?id=110229
--- Comment #12 from Laurent ---
Ok so the problem wasn't there.
It's when I bind a texture to an image or to a frame buffer objet that
sometimes that texture is not correctly updated. (Even if I don't use shaders)
I'll try to find where data
On 3/29/19 10:20 AM, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of 0x.
>
> Cc: Um
Interrupt register must be disabled before call of
devm_request_threaded_irq function to avoid dummy interruption.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm
From: Philippe Cornu
Use DRM_WARN() instead of DRM_DEBUG_DRIVER() to better
inform the user in case of fifo underruns or
transfer errors.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/stm/ltdc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltd
Hi,
Le vendredi 29 mars 2019 à 16:25 +0100, Daniel Vetter a écrit :
> On Fri, Mar 29, 2019 at 04:02:23PM +0100, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Fri, 2019-03-29 at 09:09 +, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Thu, 28 Mar 2019 at 18:53, Daniel Vetter wrote:
> > > > On Thu
Wrong DISPLAY_FLAGS used to set the data enable polarity.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index b1741a9..6ba326a 100644
--- a/drivers/gpu/drm/s
https://bugs.freedesktop.org/show_bug.cgi?id=110229
Laurent changed:
What|Removed |Added
Summary|The driver is not waiting |Textures binded to
|the sha
Found with scripts/coccinelle/misc/boolconv.cocci.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3..c010a
On Sat, Mar 30, 2019 at 02:40:16AM +0800, Zeng Tao wrote:
> There are two reasons for this patch:
> 1. There are some potential requirements for ion_alloc in kernel space,
> some media drivers need to allocate media buffers from ion instead of
> buddy or dma framework, this is more convient and cle
On Sat, Mar 30, 2019 at 02:40:16AM +0800, Zeng Tao wrote:
> There are two reasons for this patch:
> 1. There are some potential requirements for ion_alloc in kernel space,
> some media drivers need to allocate media buffers from ion instead of
> buddy or dma framework, this is more convient and cle
https://bugs.freedesktop.org/show_bug.cgi?id=110283
Bug ID: 110283
Summary: [drm] REG_WAIT timeout 10us * 3000 tries -
dce110_stream_encoder_dp_blank line:943
Product: DRI
Version: XOrg git
Hardware: Other
O
On Fri, Mar 29, 2019 at 08:20:00AM +, Wen He wrote:
>
>
> > -Original Message-
> > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com]
> > Sent: 2019年3月29日 0:39
> > To: Wen He
> > Cc: brian.star...@arm.com; mal...@foss.arm.com;
> > dri-devel@lists.freedesktop.org
> > Subject: Re:
On Thu, Mar 28, 2019 at 6:50 PM Doug Anderson wrote:
>
> Hi,
>
>
> On Thu, Mar 28, 2019 at 1:27 PM Ezequiel Garcia
> wrote:
> >
> > On Thu, 2019-03-28 at 10:17 -0700, Douglas Anderson wrote:
> > > From: Sean Paul
> > >
> > > This patch adds a new subnode to simple-panel allowing us to override
Hi,
On Fri, Mar 29, 2019 at 9:13 AM Rob Herring wrote:
>
> On Thu, Mar 28, 2019 at 6:50 PM Doug Anderson wrote:
> >
> > Hi,
> >
> >
> > On Thu, Mar 28, 2019 at 1:27 PM Ezequiel Garcia
> > wrote:
> > >
> > > On Thu, 2019-03-28 at 10:17 -0700, Douglas Anderson wrote:
> > > > From: Sean Paul
> >
On Fri, Mar 29, 2019 at 06:44:45AM +, Lowry Li (Arm Technology China) wrote:
> Creates plane alpha and blend mode properties attached to plane.
>
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff
On Thu, Mar 28, 2019 at 07:25:00AM +, Lowry Li (Arm Technology China) wrote:
> Fixing the DMA mapping sg segment warning, which shows "DMA-API: mapping
> sg segment longer than device claims to support [len=921600] [max=65536]".
> Fixed by setting the max segment size at Komeda driver.
>
> Sig
Hi DRM maintainers,
This pull requests adds initial Mali D71 support into the Arm "komeda" DRM
driver. The code has been reviewed at the end of last year, I just been
too slow with pushing it into mainline. Since it started baking in
linux-next we had a kbuild-bot issue raised and one from Joe Per
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #44 from Dimitar Atanasov ---
Works with 4.19.32 witch acpi=off, but CPU is single core
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On 3/28/19 7:16 PM, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin Gaignard, Laura
The docs state the callback is optional but it is not, make it optional.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/dma-buf.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..4d4ae9fe
Op 29-03-2019 om 10:20 schreef Daniel Vetter:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of 0x.
>
> Cc: Um
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #45 from Alex Deucher ---
(In reply to Dimitar Atanasov from comment #44)
> Works with 4.19.32 witch acpi=off, but CPU is single core
Most likely some other device failed to get enumerated in that case and that
freed up resources fo
1 - 100 of 139 matches
Mail list logo
