https://bugzilla.kernel.org/show_bug.cgi?id=196125
--- Comment #2 from cont...@florentflament.com ---
Created attachment 257079
--> https://bugzilla.kernel.org/attachment.cgi?id=257079&action=edit
dmesg output
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
On 06/19/2017 03:42 PM, Boris Brezillon wrote:
On Tue, 13 Jun 2017 11:02:47 +0200
Andrzej Hajda wrote:
Hi,
Just spotted this thread.
On 06.06.2017 14:58, Tomi Valkeinen wrote:
On 06/06/17 15:48, Boris Brezillon wrote:
Okay. Thanks for the clarification. Can you confirm that this versi
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #8 from Carlo Caione ---
Interesting. Ok then, back to square one: no BIOS options to tweak the
integrated graphics memory / controller.
On a side note: is it normal so many error messages in the journal? Like:
kernel: amdgpu :
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #7 from Michel Dänzer ---
There are two GPUs, the integrated one in the APU (Carrizo family) and a
dedicated one (Polaris 12 family). Xorg is using the integrated one, and
there's no way around that, because only the integrated GPU h
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #6 from Carlo Caione ---
Also I guess you are looking at the wrong controller:
[2.111381] amdgpu :00:01.0: VRAM: 32M 0x00F4 -
0x00F401FF (32M used)
[2.111390] [drm] Detected VRAM RAM=32M, BAR=32M
[
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #5 from Carlo Caione ---
> FWIW, it wouldn't say "VRAM" but rather "integrated graphics memory" or
> something like that.
Yeah :) Let me put this way: there is nothing in the BIOS related to graphic
controller / GPU / video in genera
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #4 from Michel Dänzer ---
(In reply to Carlo Caione from comment #3)
> There is nothing in the BIOS related to VRAM.
FWIW, it wouldn't say "VRAM" but rather "integrated graphics memory" or
something like that.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #3 from Carlo Caione ---
> I suspect the core problem is that there's only 32 MB of VRAM available.
> Is it possible to increase this in the BIOS setup?
It is not. There is nothing in the BIOS related to VRAM.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=101484
--- Comment #3 from Gregor Münch ---
One thing that comes to my mind, Im using Steam Beta. Maybe the problem is
limited to that or its just steam itself.
--
You are receiving this mail because:
You are the assignee for the bug.
Hello Tobias,
Sorry for late reply.
On 06/14/2017 09:30 PM, Tobias Jakobi wrote:
Hello Hoegeun,
my last question (does this regress the case "node required, but
absent") still stands.
Hoegeun Kwon wrote:
Remove the error handling of bridge_node because the bridge_node is
required optionally
On 06/19/2017 06:14 PM, Andrzej Hajda wrote:
On 15.06.2017 12:03, Hoegeun Kwon wrote:
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Gala
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #2 from Michel Dänzer ---
> Jun 19 17:09:49 endless kernel: [drm] Detected VRAM RAM=32M, BAR=32M
I suspect the core problem is that there's only 32 MB of VRAM available. Is it
possible to increase this in the BIOS setup?
--
You ar
On 06/16/2017 08:13 PM, Eric Anholt wrote:
Archit Taneja writes:
On 06/16/2017 02:11 AM, Eric Anholt wrote:
If the panel-bridge is being set up after the drm_mode_config_reset(),
then the connector's state would never get initialized, and we'd
dereference the NULL in the hotplug path. We a
On Fri, 2017-06-16 at 22:02 +0800, YT Shen wrote:
> Previous patch (c5f228ef6c drm/mediatek: add *driver_data for different
> hardware settings) calls devm_kfree() and then devm_kzalloc() to
> reallocate color module data structure. But this reallocation cannnot
> guarantee the new address is unch
On 20 June 2017 at 00:56, Liviu Dudau wrote:
> Hi Dave,
>
> Couple of fixes for HDLCD driver to fix an error message when
> working with TDA19988 driver and moving the framebuffer's physical
> address calculation to use the DRM CMA helper.
This pull had a patch that wasn't in the request, and als
Although header is included only once but still having an include guard
is a good practice. To avoid confusion, add SoC prefix to existing
Exynos5433 header include guard.
Signed-off-by: Krzysztof Kozlowski
---
include/video/exynos5433_decon.h | 6 +++---
include/video/exynos7_decon.h| 5 ++
On Mon, Jun 19, 2017 at 10:32:18PM +0200, Luc Van Oostenryck wrote:
> On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote:
> > struct uapistruct {
> > ...
> > __u64 __user myptr;
> > ---
> > };
> >
> > And then converting it for use in the kernel as such:
> >
> > {
> > v
On Mon, Jun 19, 2017 at 09:46:37PM +0100, Al Viro wrote:
> On Mon, Jun 19, 2017 at 10:32:18PM +0200, Luc Van Oostenryck wrote:
> > On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote:
> > > struct uapistruct {
> > > ...
> > > __u64 __user myptr;
> > > ---
> > > };
> > >
> > > And t
The DECON headers contain only defines for registers. There are no
other drivers using them so this should be put locally to the Exynos DRM
driver. Keeping headers local helps managing the code.
Suggested-by: Marek Szyprowski
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/exynos/exyno
Hi Inki,
On Sun, Jun 18, 2017 at 8:12 PM, Inki Dae wrote:
> Hi Shuah,
>
> 2017년 06월 17일 05:16에 Shuah Khan 이(가) 쓴 글:
>> On 06/16/2017 08:16 AM, Shuah Khan wrote:
>>> Hi Inki,
>>>
>>> On Fri, Jun 16, 2017 at 1:50 AM, Inki Dae wrote:
It doesn't need to try to find a bridge if bridge node doesn
On 06/08/2017 05:40 PM, Rob Herring wrote:
> On Fri, Jun 02, 2017 at 04:37:11PM +0200, Philippe CORNU wrote:
>> This patch adds documentation of device tree bindings for the
>> Synopsys DesignWare MIPI DSI host DRM bridge driver.
>>
>> Signed-off-by: Philippe CORNU
>> ---
>> .../bindings/display
This patch adds documentation of device tree bindings for the STM32
DSI host driver based on the Synopsys DW MIPI DSI bridge driver.
Signed-off-by: Philippe CORNU
Reviewed-by: Neil Armstrong
---
.../devicetree/bindings/display/st,stm32-ltdc.txt | 104 -
1 file changed, 103
This patch adds documentation of device tree bindings for the
Synopsys DesignWare MIPI DSI host DRM bridge driver.
Signed-off-by: Philippe CORNU
---
.../bindings/display/bridge/dw_mipi_dsi.txt| 30 ++
1 file changed, 30 insertions(+)
create mode 100644
Documentation
Add the panel-bridge support for both panels & bridges (used by DSI host &
HDMI/LVDS bridges).
Signed-off-by: Philippe CORNU
---
drivers/gpu/drm/stm/Kconfig | 2 +-
drivers/gpu/drm/stm/ltdc.c | 211
drivers/gpu/drm/stm/ltdc.h | 3 +-
3 files cha
The clut is not synchronized with the drm gamma_lut state.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 53 ++
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 12 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 ++
3 files ch
On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote:
> Which raised a bikeshed debate over whether it is appropriate to mark a scalar
> type as __user. My opinion is that it is appropriate because __user should
> mark
> user memory regardless of the container.
What the hell? __user i
There is no need anymore to have a "st-display-subsystem" parent node
in the device tree for the ltdc.
Signed-off-by: Philippe CORNU
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
Signed-off-by: Philippe CORNU
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 6 +
drivers/gpu/drm/bridge/synopsys/Makefile | 2 +
drivers/gpu
Version 4:
- bridge/synopsis/dw-mipi-dsi.c: Add panel-bridge support (-45 lines,
but no so easy to do) and is_panel_bridge for a better clean up, add
stm copyright/remove dpms_mode/remove drm_of.h/improve clk
management/add mode_valid (thanks to comments of Archit Taneja), use
"DesignWare"
Add the STM32 DSI host driver that uses the Synopsys DesignWare
MIPI DSI DRM bridge.
Signed-off-by: Philippe CORNU
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/stm/Kconfig | 7 +
drivers/gpu/drm/stm/Makefile | 2 +
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 352 ++
On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote:
> A number of us over in DRM land have been using __u64 scalar types
> to store pointers for uapi structures in accordance with Daniel Vetter's
> now classic treatise on ioctls:
>
> http://blog.ffwll.ch/2013/11/botching-up-ioctls.html
On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote:
> struct uapistruct {
> ...
> __u64 __user myptr;
> ---
> };
>
> And then converting it for use in the kernel as such:
>
> {
> void __user *userptr = (void __user *)(uintptr_t)args->myptr;
>
> copy_from_
On 06/08/2017 07:12 PM, Rob Herring wrote:
> On Fri, Jun 02, 2017 at 04:37:14PM +0200, Philippe CORNU wrote:
>> This patch adds documentation of device tree bindings for the STM32
>> DSI host driver based on the Synopsys DW MIPI DSI bridge driver.
>> ---
>> .../devicetree/bindings/display/st,st
All layers of all supported chips support this, the only variable is the
base address of the lookup table in the register map.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 5 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 13 +++
drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=101484
--- Comment #2 from Marek Olšák ---
I mean piglit results look good. ;)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=101484
--- Comment #1 from Marek Olšák ---
Sadly, I can't reproduce this on Cape Verde. Piglit results good good.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=101384
--- Comment #9 from Christian Lanig ---
Thanks a lot for your help!
I am still trying to give you the requested info as soon as possible but I ran
into several issues trying to compile Mesa and I am also a bit busy sometimes.
However, I know ho
On 06/19/2017 03:24 PM, Sean Paul wrote:
On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:
On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.
Hi Dave,
Take two. More stuff for 4.13:
- Semaphore support using sync objects
- Optimize bo list ioctl
Drop fb_location changes for now
The following changes since commit 925344ccc91d7a7fd84cab2dece1c34bbd86fd8c:
BackMerge tag 'v4.12-rc5' into drm-next (2017-06-16 13:58:27 +1000)
are availa
Hey Rob, here is a late breaking overflow fix suitable for sending up to Linus
for 4.12 if you are so inclined.
Kasin Li (1):
drm/msm: Fix potential buffer overflow issue
drivers/gpu/drm/msm/msm_gem_submit.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
1.9.1
___
From: Kasin Li
In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.
Signed-off-by: Kasin Li
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c
Le Mon, 19 Jun 2017 09:44:23 +0200,
Peter Rosin a écrit :
> Hi!
>
> This series adds support for an 8-bit clut mode in the atmel-hlcdc
> driver.
>
> I have now tested patch 1 with the below program (modeset.c
> adapted from https://github.com/dvdhrm/docs/tree/master/drm-howto
> to use an 8-bit
https://bugzilla.kernel.org/show_bug.cgi?id=196125
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #4 from Hi-Angel ---
>From a quick debugging session the error is coming from here
https://github.com/mesa3d/mesa/blob/a5e1c9f1d5b6063f0a92634967475a05362c0d31/src/gallium/drivers/r600/r600_asm.c#L603
Don't have time ATM to look clo
Le Mon, 19 Jun 2017 09:44:25 +0200,
Peter Rosin a écrit :
> DRM drivers supporting clut may want a convenient way to only use
> non-default .gamma_set and .gamma_get ops in the drm_fb_helper_funcs
> in order to avoid the following
>
> /*
>* The driver really shouldn't advertise pse
https://bugzilla.kernel.org/show_bug.cgi?id=196125
Bug ID: 196125
Summary: [Regression] AMD Radeon RX 480 flickering on HDMI port
with Linux 4.11.4
Product: Drivers
Version: 2.5
Kernel Version: 4.11.4
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=196117
--- Comment #4 from Paul K. Gerke (paulkge...@craftware.nl) ---
Hmm... I quickly checked the kernel codebase but do not really have a clue what
is going on. When cross-correlating my issues with other issues, I guess it all
starts to go wrong at t
On Mon, Jun 19, 2017 at 3:18 PM, Alex Deucher wrote:
> Hi Dave,
>
> A few more things for 4.13:
> - Semaphore support using sync objects
> - Drop fb location programming
> - Optimize bo list ioctl
Ignore this one. Andres reported a regression today related to the fb
location changes. I'll drop
https://bugs.freedesktop.org/show_bug.cgi?id=101492
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #12 from Tobias Auerochs ---
Can also confirm that this fixed the issue for me it seems.
It also patched nicely on 17.1.0, I should update my PKGBUILD I know...
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=101492
--- Comment #1 from leoxs...@gmail.com ---
I am afraid that I cannot do anything on amd-staging-4.11 branch, since I don't
have the write permit on any branch of agd5f.
The branch "https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.13";
On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:
> On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> > Problem:
> > While running IGT kms_atomic_transition test suite i encountered
> > a hang in drmHandleEvent immidietly follwoing an atomic_commit.
>
> s/immidietly/immediately/g
>
Hi Dave,
A few more things for 4.13:
- Semaphore support using sync objects
- Drop fb location programming
- Optimize bo list ioctl
The following changes since commit 925344ccc91d7a7fd84cab2dece1c34bbd86fd8c:
BackMerge tag 'v4.12-rc5' into drm-next (2017-06-16 13:58:27 +1000)
are available in
On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.
s/immidietly/immediately/g
s/follwoing/following/g
> After dumping the atomic state I relized that in th
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #11 from Fabian Maurer ---
Thanks for explaining, I already feared that the issue was deeper.
I think I found a configuration for Minecraft that triggers the issue in ~100%
of all tries.
I tested the patch, and it reliable fixes the
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #10 from Marek Olšák ---
Created attachment 132069
--> https://bugs.freedesktop.org/attachment.cgi?id=132069&action=edit
tentative fix
Please test the attached patch. Thanks.
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #71 from Eike ---
Sorry, I didn't want to get defensive.
I guess you are right about the drivers, it was just funny to me that I had the
same issue on Windows 10 with the AMD drivers provided by Windows Update on
install.
There seems
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #70 from Eike ---
Created attachment 132066
--> https://bugs.freedesktop.org/attachment.cgi?id=132066&action=edit
MG279Q (new firmware) xrandr incl. EDID
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=101491
--- Comment #2 from Alex Deucher ---
Created attachment 132063
--> https://bugs.freedesktop.org/attachment.cgi?id=132063&action=edit
add workaround
PX is known to be broken on K53TK systems. Add a quirk for another variant.
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #1 from Carlo Caione ---
Created attachment 132062
--> https://bugs.freedesktop.org/attachment.cgi?id=132062&action=edit
dmps_off_on
This is what we have in the log when we give 'xset dpms force off; xset dpms
force on'.
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=101499
Bug ID: 101499
Summary: Black screen when detaching HDMI cable (AMD A10-9620P)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: N
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #9 from Marek Olšák ---
Hm, I think the proper fix is not to loop on submission_in_progress in
amdgpu_cs_flush while bo_fence_lock is held. The looping is there because we
need to prepare the request.dependencies list. We can remove
On Mon, Jun 19, 2017 at 05:47:07PM +0200, Noralf Trønnes wrote:
>
> Den 19.06.2017 15.53, skrev Liviu Dudau:
> > Update the PM code to suspend/resume the fbdev_cma console.
> >
> > Changelog:
> > - v2: Use drm_fbdev_cma_set_suspend_unlocked() function for taking the
> >console lock (sugge
A number of us over in DRM land have been using __u64 scalar types
to store pointers for uapi structures in accordance with Daniel Vetter's
now classic treatise on ioctls:
http://blog.ffwll.ch/2013/11/botching-up-ioctls.html
A smaller number of us have further been marking the __u64 with __user,
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
Signed-off-by: Shashank Sharma
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
V2: Rebase
V3: Rebase
V4: Rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, t
This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr outpu
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
V2
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
sc
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.
This patch moves the
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI i
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference, f
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which c
This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is capable of handling YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
exampl
This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.
First 2 patches, comple
Den 19.06.2017 15.53, skrev Liviu Dudau:
Update the PM code to suspend/resume the fbdev_cma console.
Changelog:
- v2: Use drm_fbdev_cma_set_suspend_unlocked() function for taking the
console lock (suggested by Noralf Trønnes )
- v1: Initial submission [1]
[1] https://lists.freedesktop.
Den 19.06.2017 15.17, skrev Liviu Dudau:
On Fri, Jun 16, 2017 at 06:58:36PM +0200, Noralf Trønnes wrote:
Den 16.06.2017 15.53, skrev Liviu Dudau:
Update the PM code to suspend/resume the fbdev_cma console.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/hdlcd_drv.c | 11 ++-
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #8 from Marek Olšák ---
Actually, I think it's 3 locks we have to unify:
- bo_fence_lock
- pb_cache::mutex
- pb_slabs::mutex
--
You are receiving this mail because:
You are the assignee for the bug._
On 16/06/17 19:10, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu
> driver already implements a proper ->mapping_error method, so it's only
> using the value internally. Add a new local define using the value
> that arm64 which is the only curre
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #7 from Marek Olšák ---
The bisected commit only uncovers the existing deadlock scenario.
Summary of the issue.
amdgpu_bo_create
-> pb_cache_reclaim_buffer (lock pb_cache::mutex)
-> pb_cache_is_buffer_compat
-> amdgpu_bo_wait (lock
Hi Dave,
Here are the Mali DP driver changes. They include the mali-dp specific
changes from Jose Abreu on crtc->mode_valid() as well as a couple of
patches for fixing the sharing of IRQ lines and use of DRM CMA helper
for framebuffer physical address calculation. Please pull!
Best regards,
Liviu
Hi Dave,
Couple of fixes for HDLCD driver to fix an error message when
working with TDA19988 driver and moving the framebuffer's physical
address calculation to use the DRM CMA helper.
Best regards,
Liviu
The following changes since commit 925344ccc91d7a7fd84cab2dece1c34bbd86fd8c:
BackMerge t
https://bugzilla.kernel.org/show_bug.cgi?id=196121
Bug ID: 196121
Summary: ati x200m on Toshiba Sattellite L20-183 cannot resume
from suspend with KMS
Product: Drivers
Version: 2.5
Kernel Version: 4.11.5
Hardware: i386
Update the PM code to suspend/resume the fbdev_cma console.
Changelog:
- v2: Use drm_fbdev_cma_set_suspend_unlocked() function for taking the
console lock (suggested by Noralf Trønnes )
- v1: Initial submission [1]
[1] https://lists.freedesktop.org/archives/dri-devel/2017-June/144502.html
On Fri, Jun 16, 2017 at 06:58:36PM +0200, Noralf Trønnes wrote:
>
> Den 16.06.2017 15.53, skrev Liviu Dudau:
> > Update the PM code to suspend/resume the fbdev_cma console.
> >
> > Signed-off-by: Liviu Dudau
> > ---
> > drivers/gpu/drm/arm/hdlcd_drv.c | 11 ++-
> > 1 file changed, 10
https://bugs.freedesktop.org/show_bug.cgi?id=101384
Nicolai Hähnle changed:
What|Removed |Added
Attachment #131900|0 |1
is obsolete|
Hi Inki,
On 28.12.2016 15:32, Gabriel Krisman Bertazi wrote:
> num_ioctls is already assigned when declaring the exynos_drm_driver
> structure. No need to duplicate it here.
>
> Signed-off-by: Gabriel Krisman Bertazi
It looks like the patch has not been merged, probably due to lack of
your e-ma
File size before:
textdata bss dec hex filename
99831424 0 114072c8f drivers/gpu/drm/exynos/exynos_mixer.o
File size after constify:
textdata bss dec hex filename
11231 176 0 114072c8f drivers/gpu/drm/exynos/exynos_mixer.o
Hi!
This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.
I have now tested patch 1 with the below program (modeset.c
adapted from https://github.com/dvdhrm/docs/tree/master/drm-howto
to use an 8-bit mode).
Since v2 I have also cleared up why the first 16 entries of the clut
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by work with const
of_device_ids. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
48051408 062131845 drivers/gpu/d
Hi Emil,
> Daniel V has been working very hard on cleaning all the set_busid
> "chaos" and even has some patches which remove it completely [1].
> While your patch is correct, it would be nicer if we can remove the
> code so that nobody else gets bitten ;-)
>
> Can you be so kind and re-spin your
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by work with const
of_device_ids. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
122941192 0 1348634ae drivers/gpu/d
On 19.06.2017 12:12, Arvind Yadav wrote:
> File size before:
>text data bss dec hex filename
>9983 1424 0 114072c8f
> drivers/gpu/drm/exynos/exynos_mixer.o
>
> File size after constify:
>text data bss dec hex filename
> 1
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #13 from Hi-Angel ---
Possible fix
https://lists.freedesktop.org/archives/mesa-dev/2017-June/159872.html
It solves the problem, but needs more work to exclude other bugs of alike type.
--
You are receiving this mail because:
You a
On Tue, 13 Jun 2017 11:02:47 +0200
Andrzej Hajda wrote:
> Hi,
>
> Just spotted this thread.
>
> On 06.06.2017 14:58, Tomi Valkeinen wrote:
> > On 06/06/17 15:48, Boris Brezillon wrote:
> >
> >> Okay. Thanks for the clarification. Can you confirm that this version
> >> is correct?
> >>
> >>
1 - 100 of 105 matches
Mail list logo
