On 08.03.2018 16:24, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../bindings/display/bridge/thine,thc63lvd1024.txt | 59
> ++
> 1 file changed, 59 insertions(+)
> create mode 100644
> Documentation/devicetree/bind
Hi Jacopo,
On Thu, Mar 8, 2018 at 4:24 PM, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder.
>
> Signed-off-by: Jacopo Mondi
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,59 @@
> +THine Electron
Hi,
Dne četrtek, 08. marec 2018 ob 23:47:17 CET je Ondřej Jirman napisal(a):
> Hi,
>
> On Thu, Mar 01, 2018 at 10:34:32PM +0100, Jernej Skrabec wrote:
> > Currently exclusive TCON clock lock is never released, which, for
> > example, prevents changing resolution on HDMI.
> >
> > In order to fix
Hello,
this small series add a driver for transparent LVDS decoders, as
Thine THC63LVD1024 device.
The R-Car Gen3 V3M Eagle board feature such a converter, that has been so far
not described as part of the display output pipeline. Now that a driver has
been added, the Eagle DTS file has been up
Add transparent LVDS decoder driver.
A transparent LVDS decoder is a DRM bridge device that does not require
any configuration and converts LVDS input to digital CMOS/TTL parallel
data output. The driver is compatible with Thine THC63LVD1024 device
that can control a few power supplies and a few e
In preparation to enabling -Wvla, remove VLA usage.
Also, fixed as part of the directive to remove all VLAs from
the kernel: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/via/via_aux_sii164.c | 2 +-
drivers/video/fbdev/via/via_aux_vt1631.c | 2 +-
Document Thine THC63LVD1024 LVDS decoder.
Signed-off-by: Jacopo Mondi
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/D
Hi,
On Thu, Mar 01, 2018 at 10:34:32PM +0100, Jernej Skrabec wrote:
> Currently exclusive TCON clock lock is never released, which, for
> example, prevents changing resolution on HDMI.
>
> In order to fix that, release clock when disabling TCON. TCON is always
> disabled first before new mode is
On 08-03-18, 13:14, Jordan Crouse wrote:
> It seems to me that performance_state has a direct relationship with genpd
> which is good for CPU votes but in this case, we're just passing along raw
> data
> to an independent microcontroller. The 'qcom,arc-level' is used to construct
> the actual valu
Hi Emil,
On 03/08/2018 05:58 AM, Emil Velikov wrote:
Hi Gustavo,
On 7 March 2018 at 19:54, Gustavo A. R. Silva wrote:
In preparation to enabling -Wvla, remove VLA and replace it
with a fixed-length array instead. Also, remove variable 'len'.
What is the reason behind adding -Wvla? Is there
Hi,
Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a):
> Hi,
>
> I've debugged this further and it seems that the code has incorrect
> assumptions. See docs for mode_set_nofb.
>
> https://elixir.bootlin.com/linux/v4.16-rc4/source/include/drm/drm_modeset_he
> lper_vtables.h#L2
Hi,
I've debugged this further and it seems that the code has incorrect assumptions.
See docs for mode_set_nofb.
https://elixir.bootlin.com/linux/v4.16-rc4/source/include/drm/drm_modeset_helper_vtables.h#L209
I've added traces to a few functions that call clk_.*exclusive.*() functions,
and I see
Hi,
On Fri, Mar 09, 2018 at 07:19:33AM +0100, Jernej Škrabec wrote:
> Hi,
>
> Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a):
> > Hi,
> >
> > I've debugged this further and it seems that the code has incorrect
> > assumptions. See docs for mode_set_nofb.
> >
> > https://e
The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
to the on-chip LVDS encoder output on one side and to HDMI encoder
ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver for transparent LVDS decoder
Hi Jernej,
On Thu, Mar 08, 2018 at 11:57:40PM +0100, Jernej Škrabec wrote:
> Hi,
>
> Dne četrtek, 08. marec 2018 ob 23:47:17 CET je Ondřej Jirman napisal(a):
> > Hi,
> >
> > On Thu, Mar 01, 2018 at 10:34:32PM +0100, Jernej Skrabec wrote:
> > > Currently exclusive TCON clock lock is never release
Hello!
On 3/8/2018 6:24 PM, Jacopo Mondi wrote:
The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
to the on-chip LVDS encoder output on one side and to HDMI encoder
ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from
Hi Andrzej,
On Fri, Mar 09, 2018 at 09:01:24AM +0100, Andrzej Hajda wrote:
> On 08.03.2018 16:24, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > .../bindings/display/bridge/thine,thc63lvd1024.txt | 59
> > ++
https://bugs.freedesktop.org/show_bug.cgi?id=105369
cd changed:
What|Removed |Added
Attachment #137826|0 |1
is obsolete||
https://bugs.freedesktop.org/show_bug.cgi?id=105369
--- Comment #9 from cd ---
Created attachment 137925
--> https://bugs.freedesktop.org/attachment.cgi?id=137925&action=edit
4.16.0-rc1-085145ebf0e9-blank-screen
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Geert,
thanks for review
On Fri, Mar 09, 2018 at 09:10:55AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Mar 8, 2018 at 4:24 PM, Jacopo Mondi
> wrote:
> > Document Thine THC63LVD1024 LVDS decoder.
> >
> > Signed-off-by: Jacopo Mondi
>
> Thanks for your patch!
>
> > --- /dev/n
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #15 from denisgolo...@yandex.ru ---
Any news on that?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
Hi Chanwoo,
On 08.03.2018 02:52, Chanwoo Choi wrote:
> Hi Andrzej, Archit,
>
> On 2018년 03월 07일 20:13, Andrzej Hajda wrote:
>> Hi Chanwoo, Archit,
>>
>> On 07.03.2018 05:48, Chanwoo Choi wrote:
>>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
Hi Rob and Andrzej,
On 2018년 03월 06일 21:5
Hi Jacopo,
On Fri, Mar 9, 2018 at 10:04 AM, jacopo mondi wrote:
> On Fri, Mar 09, 2018 at 09:10:55AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Mar 8, 2018 at 4:24 PM, Jacopo Mondi
>> wrote:
>> > Document Thine THC63LVD1024 LVDS decoder.
>> >
>> > Signed-off-by: Jacopo Mondi
>>
>> Thanks for
On Thu, Mar 08, 2018 at 06:03:32PM +0530, Ramalingam C wrote:
> On Thursday 08 March 2018 06:00 PM, Winkler, Tomas wrote:
> >
> > > -Original Message-
> > > From: C, Ramalingam
> > > Sent: Thursday, March 08, 2018 13:58
> > > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop
On Thu, Mar 08, 2018 at 11:43:25AM -0800, John Stultz wrote:
> On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
> > Hey John,
> >
> >
> > On 03/07/2018 12:19 AM, John Stultz wrote:
> >>
> >> As suggested by Alexandru-Cosmin Gheorghe:
> >>
> >> ConvertHALFormatToDrm logic would work only for 1 pl
Hi John,
On 8 March 2018 at 19:43, John Stultz wrote:
> On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
>>> @@ -76,8 +76,6 @@ uint32_t
>>> DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
>>> return DRM_FORMAT_ABGR;
>>> case HAL_PIXEL_FORMAT_RGB_565:
>>>
Hi Geert,
On Fri, Mar 09, 2018 at 10:22:39AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Fri, Mar 9, 2018 at 10:04 AM, jacopo mondi wrote:
> > On Fri, Mar 09, 2018 at 09:10:55AM +0100, Geert Uytterhoeven wrote:
> >> On Thu, Mar 8, 2018 at 4:24 PM, Jacopo Mondi
> >> wrote:
> >> > Docume
Hi Daniel,
On Fri, Mar 09, 2018 at 09:29:24AM +, Daniel Stone wrote:
> Hi John,
>
> On 8 March 2018 at 19:43, John Stultz wrote:
> > On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss
> > wrote:
> >>> @@ -76,8 +76,6 @@ uint32_t
> >>> DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format)
On Wednesday, 2018-03-07 13:47:03 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead. Also, remove variable 'len'.
>
> Notice that no new IDs have been added in seven years.
>
> Signed-off-by: Gustavo A. R. Silva
>
Hey Jordan/Viresh,
On 03/09/2018 09:13 AM, Viresh Kumar wrote:
> On 08-03-18, 13:14, Jordan Crouse wrote:
>> It seems to me that performance_state has a direct relationship with genpd
>> which is good for CPU votes but in this case, we're just passing along raw
>> data
>> to an independent microc
https://bugs.freedesktop.org/show_bug.cgi?id=105414
Bug ID: 105414
Summary: R9 285 agd5f 4.17-wip DC flip_done timed out
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA usage.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva
Sorry for my reply on
On 9 March 2018 at 10:59, Eric Engestrom wrote:
> On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wvla, remove VLA usage.
>>
>> Also, fixed as part of the directive to remove all VLAs from
>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>
>> Sig
Hey,
On 03/09/2018 10:55 AM, Alexandru-Cosmin Gheorghe wrote:
Hi Daniel,
On Fri, Mar 09, 2018 at 09:29:24AM +, Daniel Stone wrote:
Hi John,
On 8 March 2018 at 19:43, John Stultz wrote:
On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
@@ -76,8 +76,6 @@ uint32_t
DrmGenericImporter::C
On 03/09/2018 03:35 AM, Inki Dae wrote:
> 2018년 03월 08일 20:22에 Sylwester Nawrocki 이(가) 쓴 글:
>> On 03/08/2018 09:15 AM, Inki Dae wrote:
[...]
>>> Is there a possibility for other boards based on Exynos4210/4212/5420/5433
>>> SoC to use this property later?
>>
>> All these SoCs have the HDMI IP bloc
All the DRM GEM dma-buf import/export operations are done through the
virtual DRM master device. As this isn't instanciated from DT anymore
we need to make sure the DMA ops are set up correctly.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ++-
1 file changed, 2 inser
The old way did clamp the jiffy conversion and thus caused the timeouts
to become negative after some time. Also it didn't work with userspace
which actually fills the upper 32bits of the 64bit timestamp value.
Fix this by using the solution developed and tested by Russell.
Suggested-by: Russell
Am Dienstag, den 13.02.2018, 16:36 -0200 schrieb Fabio Estevam:
> > From: Fabio Estevam
>
> etnaviv_sched_dependency() and etnaviv_sched_run_job() are only
> used in this file, so make them static.
>
> This fixes the following sparse warnings:
>
> drivers/gpu/drm/etnaviv/etnaviv_sched.c:30:18:
Apologies if this is not the right list for this question. Kernel
MAINTAINERS file suggests it is but please let me know if I should
repost elsewhere.
I have a custom OpenCL application running under Ubuntu 16.04.04, HWE
Kernel 4.13 and amdgpu-pro 17.50 drivers. This is running on a Fujitsu
D
On Thursday, 2018-03-08 18:10:03 +, Emil Velikov wrote:
> On 5 March 2018 at 12:03, Eric Engestrom wrote:
> > Ping? :)
> > Both for this patch and the equivalent autotools patch it replies to.
> >
> The autotools one needs the CFLAGS added - meson does it automatically for us.
I'll let Peter
Hi Russell,
Am Freitag, den 09.03.2018, 11:44 + schrieb Russell King - ARM Linux:
> Hi Lucas,
>
> Please retain my authorship of my patch, which was sent on 23 Oct 2017.
> The patch you have below is 100% identical to that which I sent.
I'll gladly do so if you provide me a proper Signed-off
https://bugs.freedesktop.org/show_bug.cgi?id=104201
--- Comment #1 from Vedran Miletić ---
This seems to no longer be the case in 4.15.7 (I should note, after a clean
reinstall of Fedora for an unrelated reason), did anything change?
--
You are receiving this mail because:
You are the assignee
On Fri, Mar 09, 2018 at 11:07:14AM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal
>
> If the user-space does not support aspect-ratio, then getblob called
> with the blob id of a user-mode, should clear the aspect-ratio
> information in the blob data.
>
> Currently for a given blob id, t
https://bugs.freedesktop.org/show_bug.cgi?id=100919
Thomas R. changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #16 from Harry Wentland ---
The ticket is on our backlog and we'll try to get to it in a week or so.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi Russell,
On Fri, Mar 9, 2018 at 8:34 AM, Russell King - ARM Linux
wrote:
> On Fri, Mar 09, 2018 at 12:20:59PM +0100, Lucas Stach wrote:
>> All the DRM GEM dma-buf import/export operations are done through the
>> virtual DRM master device. As this isn't instanciated from DT anymore
>> we need t
https://bugs.freedesktop.org/show_bug.cgi?id=104201
--- Comment #2 from Harry Wentland ---
Our display code in 4.15 would mostly be older than the version of
amd-staging-drm-next that you tested earlier.
Would you be able to give amd-staging-drm-next a spin again and see if it's
still an issue t
From: Ville Syrjälä
Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().
v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_fo
From: Ville Syrjälä
Put an empty line between the variable declarations and the code, and
use tabs for alignment.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/dri
From: Ville Syrjälä
Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.
v2: Nuke the
From: Ville Syrjälä
Only create framebuffers with supported format/modifier combinations by
checking that at least one plane supports the requested combination.
Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
the planes have (mostly) uniform capabilities. But I was lazy and
The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.
Signed-off-by: Sylwester Nawrocki
---
Changes since v2:
- the property has been moved to "Required properties" paragraph,
I didn't add Rob's Reviewed-by due to this change
--
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #42 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
With current LLVM7 master X does not start at all. I get the following output:
root@qt5122:~# X
X.Org X Server 1.19.3
Release Date: 2017-03-15
X Protocol Version 11, Revision 0
On Fri, Mar 09, 2018 at 03:49:00PM +0530, Rajendra Nayak wrote:
> Hey Jordan/Viresh,
>
> On 03/09/2018 09:13 AM, Viresh Kumar wrote:
> > On 08-03-18, 13:14, Jordan Crouse wrote:
> >> It seems to me that performance_state has a direct relationship with genpd
> >> which is good for CPU votes but in
On 9 March 2018 at 11:47, Eric Engestrom wrote:
>> > + dep_atomic_ops = []
>> >
>> The dummy dep_atomic_ops is needed for almost all cases in the if/else
>> ladder. The exception being the .found() case.
>
> Actually, because of the way the `if` chain is written, the dep_atomic_ops
> has to
https://bugzilla.kernel.org/show_bug.cgi?id=198985
--- Comment #3 from Fredrik (fred...@planet-express.se) ---
Still missing from 4.15.8
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-de
On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> On 08-03-18, 13:14, Jordan Crouse wrote:
> > It seems to me that performance_state has a direct relationship with genpd
> > which is good for CPU votes but in this case, we're just passing along raw
> > data
> > to an independent micr
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #43 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Ricardo Ribalda from comment #42)
> With current LLVM7 master X does not start at all. I get the following
> output:
Did you recompile current Mesa Git master against that a
https://bugs.freedesktop.org/show_bug.cgi?id=105369
--- Comment #10 from cd ---
A freeze occured while working with the laptop:
uname -r
4.16.0-rc1-085145ebf0e9
[20516.321517] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=448660, last emitted seq=448663
[20516.3
Hi Linus,
Please pull fbdev fix for v4.16-rc5 (just a single fix to close
kernel data leak in FBIOGETCMAP_SPARC ioctl).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:
Li
On Friday, 2018-03-09 15:48:51 +, Emil Velikov wrote:
> On 9 March 2018 at 11:47, Eric Engestrom wrote:
>
> >> > + dep_atomic_ops = []
> >> >
> >> The dummy dep_atomic_ops is needed for almost all cases in the if/else
> >> ladder. The exception being the .found() case.
> >
> > Actually,
(I wrote an email that seems to have been lost)
Quoting Jordan Crouse (2018-03-09 08:03:55)
> On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> > On 08-03-18, 13:14, Jordan Crouse wrote:
> > > It seems to me that performance_state has a direct relationship with genpd
> > > which is g
https://bugs.freedesktop.org/show_bug.cgi?id=103791
--- Comment #21 from Michel Dänzer ---
(In reply to Anthony Parsons from comment #18)
> Running xrandr doesn't seem to work as a workaround but flipping VTs does.
Have you tried turning it off and on again? (Who gets the reference? :)
xrandr -
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #16 from Michel Dänzer ---
(In reply to OmegaPhil from comment #15)
> I'm going to sit on this for a week to make sure its actually solved.
A month has passed, is there a verdict yet?
--
You are receiving this mail because:
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=105308
--- Comment #13 from Michel Dänzer ---
https://patchwork.freedesktop.org/patch/209464/ fixes this for me with DC
disabled.
--
You are receiving this mail because:
You are the assignee for the bug.___
On 03/09/2018 04:51 PM, Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
> to the on-chip LVDS encoder output on one side and to HDMI encoder
> ADV7511w on the other one.
>
> As the decoder does not need any configuration it has been so-far
> omitted
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #17 from omegap...@startmail.com ---
The patch was not enough, and my comments on that bug have been ignored - the
key bit is:
I've tracked part of the problem
On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote:
> (I wrote an email that seems to have been lost)
>
> Quoting Jordan Crouse (2018-03-09 08:03:55)
> > On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> > > On 08-03-18, 13:14, Jordan Crouse wrote:
> > > > It seems to me th
Hi Dave,
Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up
last week.
drm-misc-next-2018-03-09-3:
drm-misc-next for 4.17:
UAPI Changes:
plane: Add color encoding/range properties (Jyri)
nouveau: Replace iturbt_709 property with color_encoding property (Ville)
Core Chan
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.
S
Add Plane Degamma as a blob property and plane degamma size as
a range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Adde
This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data, CSC used for gamut
conversion, and gamma used to again non-linearize data as per panel
supported color space. These can be utilize by user space to convert
planes from one format to an
Add a blob property for plane CSC usage.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by
Add plane gamma as blob property and size as a
range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documen
Define helper function to enable Plane color features
to attach plane color properties to plane structure.
v2: Rebase
v3: Modiefied the function to use updated property names.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 42 ++
include/d
Enable and initialize plane color features.
v2: Rebase and some cleanup
v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers
Implement Plane Gamma feature for BDW and Gen9 platforms.
v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 5 +++-
drivers/gpu/drm/i915/i915_reg.h | 24 +++
driv
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 4
drivers/gpu/drm/i915/intel_color.c| 8
drivers/gpu/drm/i915/intel_drv.h
Rob Herring wrote on Fri [2018-Mar-02 13:19:13 -0600]:
> On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot wrote:
> > Add 'plane' child node to generic DISPC node as an optional
> > property.
>
> Why? What problem are you solving?
Ah yes, I guess on its own it does not mean much...
How about:
Cur
https://bugzilla.kernel.org/show_bug.cgi?id=198883
Nicolai Hähnle (nhaeh...@gmail.com) changed:
What|Removed |Added
CC||nhaeh...@gmail.com
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #45 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
(In reply to Michel Dänzer from comment #43)
> (In reply to Ricardo Ribalda from comment #42)
> > With current LLVM7 master X does not start at all. I get the following
> > outpu
https://bugs.freedesktop.org/show_bug.cgi?id=105423
Bug ID: 105423
Summary: Unable to unbind my 2nd GPU (Rx580)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severi
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 25 +
include/linux/dma-buf.h | 36
Instead of relying on the DRM functions just implement our own import
functions. This adds support for taking care of unpinned DMA-buf.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 64 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 25 +
include/linux/dma-buf.h | 36
This set of patches adds an option invalidate_mappings callback to each DMA-buf
attachment which can be filled in by the importer.
This callback allows the exporter to provided the DMA-buf content without
pinning it. The reservation objects lock acts as synchronization point for
buffer moves an
Make sure the transfered BO is never destroy before the transfer BO.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu
Instead of relying on the DRM functions just implement our own export
functions. This adds support for taking care of unpinned DMA-buf.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
drivers/gpu/drm/amd/a
Stefan Schake writes:
> This series improves the handling of alpha formats with the VC4 HVS
> compositor. Alpha formats are marked as premultiplied as is standard
> for DRM. Further fix a display corruption issue when planes with
> per-pixel alpha try blending from the (nonexistent) background by
Ville Syrjala writes:
> From: Ville Syrjälä
>
> Only create framebuffers with supported format/modifier combinations by
> checking that at least one plane supports the requested combination.
>
> Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
> the planes have (mostly) unif
https://bugs.freedesktop.org/show_bug.cgi?id=105423
--- Comment #1 from Max ---
Ok, i found an interesting thing. I have this issue when i unbind my GPU on
Kernel 4.15 but i have no issue when i do it on kernel 4.14.
I'll try to git bisect between kernel 4.15 and kernel 4.14.
--
You are receiv
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps tha
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're d
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if t
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is
Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for
https://bugs.freedesktop.org/show_bug.cgi?id=101672
MirceaKitsune changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=101672
--- Comment #26 from MirceaKitsune ---
Moved to a new bug report which addresses the new issue with fresh logs:
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105339
--- Comment #5 from Matias N. Goldberg ---
I traced the regression to commit:
commit bc65dcab3bc48673ff6180afb036561a4b8b1119
Author: Nicolai Hähnle
Date: Fri Nov 10 10:58:10 2017 +0100
radeonsi: avoid syncing the driver thread in si_fe
https://bugs.freedesktop.org/show_bug.cgi?id=105339
Matias N. Goldberg changed:
What|Removed |Added
Summary|Deadlock inside |Deadlock inside
1 - 100 of 128 matches
Mail list logo
