On 05/31/2017 01:57 AM, Clint Taylor wrote:
On 05/26/2017 12:18 AM, Daniel Vetter wrote:
On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfor
On 05/31/2017 01:25 AM, Clint Taylor wrote:
On 05/30/2017 02:29 PM, Hans Verkuil wrote:
On 05/30/2017 10:32 PM, Clint Taylor wrote:
On 05/30/2017 09:54 AM, Hans Verkuil wrote:
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM
Hi Philippe,
Le Tue, 30 May 2017 16:55:42 +,
Philippe CORNU a écrit :
> Hi Eric,
>
> I took your patch for the panel-bridge and it works perfectly in both
> DPI mode (panel RGB //) and DSI mode (bridge dw mipi dsi), bravo :-)
I still don't understand how it can work without a call to
drm_
On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter wrote:
> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote:
>> On 31 May 2017 at 08:10, David Miller wrote:
>>> From: Daniel Vetter
>>> Date: Tue, 30 May 2017 22:15:42 +0200
>>>
If the e1000e maintainer wants to coalesce or not return stateme
On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote:
> On 31 May 2017 at 08:10, David Miller wrote:
>> From: Daniel Vetter
>> Date: Tue, 30 May 2017 22:15:42 +0200
>>
>>> If the e1000e maintainer wants to coalesce or not return statements
>>> this simple way, that's imo on him to change the color
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #6 from Michel Dänzer ---
Which rendering backend and tearing prevention method are selected in the kwin
settings?
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Hans,
thanx for investigating :)
On 05/30/2017 03:06 PM, Hans de Goede wrote:
Hi,
On 29-05-17 22:25, Chris Wilson wrote:
On Fri, Apr 14, 2017 at 11:15:04AM -0400, Sean Paul wrote:
On Thu, Apr 13, 2017 at 03:32:44PM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still ow
On 2017年05月31日 10:14, Caesar Wang wrote:
As the allocation and free buffer that need to add mutex lock for drm mm,
but it lacks the locking on error path in rockchip_gem_iommu_map().
Also, the trivial changes like The comment should be placed in the
kerneldoc and unused blank line.
Signed-off-b
As the allocation and free buffer that need to add mutex lock for drm mm,
but it lacks the locking on error path in rockchip_gem_iommu_map().
Also, the trivial changes like The comment should be placed in the
kerneldoc and unused blank line.
Signed-off-by: Caesar Wang
---
drivers/gpu/drm/rockc
Hi Mark,
Reviewed-by: Jeffy Chen
On 05/27/2017 07:43 PM, yao mark wrote:
Force vop output mode on encoder driver seem not a good idea,
EDP, HDMI, DisplayPort all have 10bit input on rk3399,
On non-10bit vop, vop 8bit output bit[0-7] connect to the
encoder high 8bit [2-9].
So force RGB10 to R
Hi Shashank,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170530]
[cannot apply to v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI
On 05/26/2017 12:18 AM, Daniel Vetter wrote:
On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI a
Using the extension saves a bit of code.
Miscellanea:
o Neaten and simplify dump_dp_payload_table
o Removed trailing blank space from output
$ size drivers/gpu/drm/drm_dp_mst_topology.o.* drivers/gpu/drm/tinydrm/*.o*
textdata bss dec hex filename
25848 0 16 2586
On 05/30/2017 02:29 PM, Hans Verkuil wrote:
On 05/30/2017 10:32 PM, Clint Taylor wrote:
On 05/30/2017 09:54 AM, Hans Verkuil wrote:
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Ha
On 31 May 2017 at 08:10, David Miller wrote:
> From: Daniel Vetter
> Date: Tue, 30 May 2017 22:15:42 +0200
>
>> If the e1000e maintainer wants to coalesce or not return statements
>> this simple way, that's imo on him to change the color as needed.
>
> That's not how things work.
>
> If the maint
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #5 from Paul ---
(In reply to Michel Dänzer from comment #1)
> Can you create a video demonstrating the problem when moving windows? If
> not, please describe which desktop environment / window manager /
> compositing manager you're
Hi Shashank,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20170530]
[cannot apply to v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #4 from Paul ---
Created attachment 131585
--> https://bugs.freedesktop.org/attachment.cgi?id=131585&action=edit
dmesg | radeon
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #2 from Paul ---
Created attachment 131583
--> https://bugs.freedesktop.org/attachment.cgi?id=131583&action=edit
xorg
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #3 from Paul ---
Created attachment 131584
--> https://bugs.freedesktop.org/attachment.cgi?id=131584&action=edit
display modes
--
You are receiving this mail because:
You are the assignee for the bug._
From: Daniel Vetter
Date: Tue, 30 May 2017 22:15:42 +0200
> If the e1000e maintainer wants to coalesce or not return statements
> this simple way, that's imo on him to change the color as needed.
That's not how things work.
If the maintainer wants you to style things a certain way, either you
d
On 05/30/2017 10:32 PM, Clint Taylor wrote:
On 05/30/2017 09:54 AM, Hans Verkuil wrote:
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Dan
Hi Jyri,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170530]
[cannot apply to v4.12-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jyri-Sarha/drm-Add-const
On 2017-05-26 00:00, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote:
>> On 2017-05-24 07:51, Daniel Vetter wrote:
>>> Again cleanup before irq disabling doesn't really stop the races,
>>> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
>>> before
The driver depends on the backlight functions, but we have no dependency
on it in Kconfig. Add this dependency to avoid breakages.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/pa
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #154 from gsc_m...@yahoo.com ---
R9 390 owner here. Just replaced my old Ubuntu 14.04 + fglrx with Fedora 25,
then 26 + Mesa and hit this problem as well. It took me a lot of fiddling and
searching to understand why my 3 years newer sy
On 05/30/2017 09:54 AM, Hans Verkuil wrote:
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12
On 05/30/2017 09:49 AM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26
Hi Dave (both of them),
topic/e1000e-fix-2017-05-30:
Just an e1000e crash fix that somehow got stuck in a trivial bikeshed,
see
https://patchwork.ozlabs.org/patch/729312/
Sending this your way since not even the intel-internal escalation seems
to have worked out. If the e1000e maintainer wants t
On 05/30/2017 06:49 PM, Hans Verkuil wrote:
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2
On 05/30/2017 05:42 PM, Clint Taylor wrote:
On 05/29/2017 11:53 PM, Hans Verkuil wrote:
For those who are interested in HDMI CEC support I made a little status
document that I intend to keep up to date:
https://hverkuil.home.xs4all.nl/cec-status.txt
My goal is to get CEC supported for any ma
On 05/30/2017 04:19 PM, Clint Taylor wrote:
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you l
Regards
Shashank
On 5/30/2017 10:06 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:
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
https://bugs.freedesktop.org/show_bug.cgi?id=101189
--- Comment #13 from Pavel Vinogradov ---
works like a charm. thanks.
(In reply to Emil Velikov from comment #12)
> This series [1] should address it properly although there's some contentious
> points around patch 2/5
>
> [1] https://patchwor
On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:
> 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 d
On Tue, May 30, 2017 at 12:20 PM, Jordan Crouse wrote:
> On Sun, May 28, 2017 at 09:43:35AM -0400, Rob Clark wrote:
>> On Mon, May 8, 2017 at 4:35 PM, Jordan Crouse wrote:
>> > Add the infrastructure to support the idea of multiple ringbuffers.
>> > Assign each ringbuffer an id and use that as an
Thanks. Reviewed and queued.
On Sat, May 27, 2017 at 07:52:30PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in DRM_ERROR error message.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
> 1 file changed, 1 insert
On Tue, May 30, 2017 at 05:43:43PM +0530, Shashank Sharma wrote:
> 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 i
Regards
Shashank
On 5/30/2017 9:43 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
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 vid
There is no reason why the name field should not be const, but
several why it should. The struct should only be used by
drm_property_create_enum() and there the name-field from the struct
is passed to drm_property_add_enum(), which takes a const char * as
a parameter.
Signed-off-by: Jyri Sarha
--
Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are stored to drm_plane
This is almost just a resend of the previous version, but I had
forgotten the EXPORT_SYMBOL(drm_plane_create_color_properties) so
bumped the version up. Just wanted to be sure the latest public
version actually working.
Changes since v4 version:
- Add EXPORT_SYMBOL(drm_plane_create_color_propertie
Regards
Shashank
On 5/30/2017 9:48 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:
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 mo
On Tue, May 30, 2017 at 05:43:42PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for ycbcr420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID, to provide information
> about sink's support for ycbcr420 output.
>
> One of these new blocks is: ycbcr420cmdb(ycbcr 420 capabili
On Sun, May 28, 2017 at 09:43:35AM -0400, Rob Clark wrote:
> On Mon, May 8, 2017 at 4:35 PM, Jordan Crouse wrote:
> > Add the infrastructure to support the idea of multiple ringbuffers.
> > Assign each ringbuffer an id and use that as an index for the various
> > ring specific operations.
> >
> >
On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:
> 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
On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
> 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
On 05/29/2017 11:53 PM, Hans Verkuil wrote:
For those who are interested in HDMI CEC support I made a little status
document that I intend to keep up to date:
https://hverkuil.home.xs4all.nl/cec-status.txt
My goal is to get CEC supported for any mainlined HDMI driver where
the hardware
supp
On Tue, May 30, 2017 at 01:55:20PM +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_ioctl, the low han
On 05/29/2017 04:06 AM, Jani Nikula wrote:
On Thu, 18 May 2017, Clint Taylor wrote:
On 05/18/2017 04:10 AM, Jani Nikula wrote:
Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just oth
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #28 from Jean Delvare (jdelv...@suse.de) ---
I don't know how reliable it is, but Wikipedia claims that the Radeon R5 240
has a 128-bit bus to video RAM. Is it possible that the amdgpu driver is
getting it wrong?
--
You are receiving
On 05/30/2017 12:11 AM, Jani Nikula wrote:
On Tue, 30 May 2017, Hans Verkuil wrote:
On 05/29/2017 09:00 PM, Daniel Vetter wrote:
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you look into also wiring this up for dp mst chain
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #27 from Marek Olšák (mar...@gmail.com) ---
Well then I wonder what the number in Oland128 means if it's not the bus width.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=101189
--- Comment #12 from Emil Velikov ---
This series [1] should address it properly although there's some contentious
points around patch 2/5
[1] https://patchwork.freedesktop.org/series/24960/
--
You are receiving this mail because:
You are the
On ti, 2017-05-30 at 13:55 +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_ioctl, the low hanging fru
https://bugzilla.kernel.org/show_bug.cgi?id=194761
Jean Delvare (jdelv...@suse.de) changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
--- Comment #2
When looking at simple ioctls coupled with conveniently small user
parameters, the overhead of the syscall and drm_ioctl() present large
low hanging fruit. Profiling trivial microbenchmarks around
i915_gem_busy_ioctl, the low hanging fruit comprises of the call to
copy_user(). Those calls are only
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
To get a ycbcr420 output from intel platforms, there are two
major steps:
- RGB->YCBCR conversion using a pipe CSC.
- Program PIPE_MISC register to generate a ycbcr420 output.
- Scaling down YCBCR444 samples to YCBCR420 samples using a pipe
scaler.
This patch:
- Does scaler allocation for HDMI y
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.
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c
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
This patch adds support for HDMI ycbcr outputs in i915 layer.
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:
This patch adds helper functions for ycbcr HDMI output handling.
These functions provide functionality like:
- getting the highest subsamled ycbcr output
- getting the lowest subsamled ycbcr output
- check if a given source and sink combination can support any YCBCR output
- check if a given source
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.
Cc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Sha
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, using which, a userspace
can specify its preference, for the HDMI outp
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
This patch series adds DRM layer support for YCBCR HDMI output handling.
The target HDMI YCBCR outputs are:
- YCBCR444
- YCBCR422
- YCBCR420
As YCBCR420 output is added in HDMI 2.0, this patch series also
contain few patches to handle new EDID extention blocks, added
for YCBCR420 modes (CEA-861-F)
HDMI 2.0 spec adds support for ycbcr420 sub-sampled output.
CEA-861-F adds two new blocks in EDID, to provide information
about sink's support for ycbcr420 output.
One of these new blocks is: ycbcr420cmdb(ycbcr 420 capability
map data block). This gives information about video modes which
can supp
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
Hi,
On 29-05-17 21:02, Daniel Vetter wrote:
On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:
Since commit a39be606f99d ("drm: Do a full device unregister when
unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
by a drm_put_dev when open_count reaches 0. This
On Tue, May 30, 2017 at 11:22 AM, Arnd Bergmann wrote:
> When DRM_PANEL is disabled, we get a link error for pl111:
>
> drivers/gpu/built-in.o: In function `pl111_connector_destroy':
> pl111_connector.c:(.text+0x3487e6): undefined reference to `drm_panel_detach'
>
> For some reason this only appe
https://bugs.freedesktop.org/show_bug.cgi?id=101145
--- Comment #3 from JL ---
(FYI: Switched back to 4.11 and mesa 17.1.0 week ago, since newer kernel and
mesa didn't help)
I installed latest batch of updates today: gcc 7.1, glibc 2.25, linux 4.11,
linux-firmware among others but no mesa or win
On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
> On 26.05.2017 23:03, Lukas Wunner wrote:
> > On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
> >> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However,
> >> even
> >> with the most recent HWE st
On 05/30/2017 12:58 PM, Neil Armstrong wrote:
On 05/25/2017 04:19 PM, Jose Abreu wrote:
Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.
Also, there is no
Hi Archit,
On Tue, 2017-05-30 at 15:54 +0530, Archit Taneja wrote:
> Hi,
>
> On 05/25/2017 07:49 PM, Jose Abreu wrote:
> > Now that we have a callback to check if bridge supports a given mode
> > we can use it in Synopsys Designware HDMI bridge so that we restrict
> > the number of probbed modes
Hey,
Op 02-05-17 om 11:56 schreef Daniel Vetter:
> On Mon, May 01, 2017 at 03:37:57PM +0200, Maarten Lankhorst wrote:
>> Some atomic properties are common between the various kinds of
>> connectors, for example a lot of them use panel fitting mode.
>> It makes sense to put a lot of it in a common
Hi,
On 05/25/2017 07:49 PM, Jose Abreu wrote:
Now that we have a callback to check if bridge supports a given mode
we can use it in Synopsys Designware HDMI bridge so that we restrict
the number of probbed modes to the ones we can actually display.
Also, there is no need to use mode_fixup() cal
On Tue, May 30, 2017 at 09:29:44AM +0200, Neil Armstrong wrote:
> On 05/25/2017 04:19 PM, Jose Abreu wrote:
> > Now that we have a callback to check if crtc supports a given mode
> > we can use it in malidp so that we restrict the number of probbed
> > modes to the ones we can actually display.
> >
On Tue, May 23, 2017 at 03:16:32AM +0300, Dmitry Osipenko wrote:
> There is no IOMMU on Tegra20, instead a GART would be picked as an IOMMU
> provider.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/drm.c | 5 -
> drivers/gpu/host1x/dev.c| 5 -
> 2 files changed, 8
On Tue, May 23, 2017 at 03:16:33AM +0300, Dmitry Osipenko wrote:
> The GART driver was disabled because it was picked by as an IOMMU provider
> for the DRM driver on Tegra20, which is not the purpose of the GART. Now
> DRM driver avoids to use IOMMU on Tegra20, so the GART driver can be
> re-enable
When DRM_PANEL is disabled, we get a link error for pl111:
drivers/gpu/built-in.o: In function `pl111_connector_destroy':
pl111_connector.c:(.text+0x3487e6): undefined reference to `drm_panel_detach'
For some reason this only appears in the latest linux-next
although the driver appears to have us
https://bugzilla.kernel.org/show_bug.cgi?id=194761
Jean Delvare (jdelv...@suse.de) changed:
What|Removed |Added
Status|REOPENED|NEEDINFO
--- Comment #2
On 05/30/17 09:21, Neil Armstrong wrote:
> Hi Hans,
>
> On 05/30/2017 08:53 AM, Hans Verkuil wrote:
>> For those who are interested in HDMI CEC support I made a little status
>> document that I intend to keep up to date:
>>
>> https://hverkuil.home.xs4all.nl/cec-status.txt
>>
>> My goal is to get
Hey,
Op 29-05-17 om 21:34 schreef Daniel Vetter:
> In the conversion to drop drm_modeset_lock_all and the magic implicit
> context I failed to realize that _resume starts out with a pile of
> state copies, but not with the locks. And hence drm_atomic_commit
> won't grab these for us.
>
> Cc: Jyri
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #1 from Michel Dänzer ---
Please attach the Xorg log file and the output of xrandr and dmesg
corresponding to the problem.
Can you create a video demonstrating the problem when moving windows? If not,
please describe which desktop e
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> The kernel doc explained what needs to happen, but not how to most
> easily accomplish that using the functions. Fix that.
>
> Cc: Boris Brezillon
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_crtc.h | 4 +++-
> 1 file changed, 3 insertion
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> This is a leftover from the drm_bus days, where we've had a
> bus-specific device type for every bus type in drm_device. Except for
> pci (which we can't remove because dri1 drivers) this is all gone. And
> the virt driver also doesn't really need it,
On 05/24/2017 04:51 PM, Daniel Vetter wrote:
> And document them lightly. Unfortunately kernel-doc isn't the most
> awesome for documenting #defines that don't look like functions, it
> makes functions out of them :-/
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 17
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Now that we have a callback to check if crtc and encoder supports a
> given mode we can use it in vc4 so that we restrict the number of
> probbed modes to the ones we can actually display.
>
> Also, remove the mode_fixup() calls as these are no longer ne
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Now that we have a callback to check if crtc supports a given mode
> we can use it in atmel-hlcdc so that we restrict the number of probbed
> modes to the ones we can actually display.
>
> Also, remove the mode_fixup() callback as this is no longer neede
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Now that we have a callback to check if crtc supports a given mode
> we can use it in malidp so that we restrict the number of probbed
> modes to the ones we can actually display.
>
> Also, remove the mode_fixup() callback as this is no longer needed
> b
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Now that we have a callback to check if bridge supports a given mode
> we can use it in Analogix bridge so that we restrict the number of
> probbed modes to the ones we can actually display.
>
> Also, there is no need to use mode_fixup() callback as mode
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Now that we have a callback to check if crtc supports a given mode
> we can use it in arcpgu so that we restrict the number of probbed
> modes to the ones we can actually display.
>
> This is specially useful because arcpgu crtc is responsible to set
> a
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> This patches makes use of the new mode_valid() callbacks introduced
> previously to validate the full video pipeline when modesetting.
>
> This calls the connector->mode_valid(), encoder->mode_valid(),
> bridge->mode_valid() and crtc->mode_valid() so tha
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
> helper callbacks to validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Introduce a new helper function which calls mode_valid() callback
> for all bridges in an encoder chain.
>
> Signed-off-by: Jose Abreu
> Reviewed-by: Daniel Vetter
> Cc: Carlos Palminha
> Cc: Ville Syrjälä
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Add a new helper to call crtc->mode_valid, connector->mode_valid
> and encoder->mode_valid callbacks.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jose Abreu
> Reviewed-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> Cc: Carlos Palminha
> Cc: D
On 05/24/2017 11:28 AM, Daniel Vetter wrote:
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
>
> Also update the docs to highlight that review requirements hold
> especia
Hi Hans,
On 05/30/2017 08:53 AM, Hans Verkuil wrote:
> For those who are interested in HDMI CEC support I made a little status
> document that I intend to keep up to date:
>
> https://hverkuil.home.xs4all.nl/cec-status.txt
>
> My goal is to get CEC supported for any mainlined HDMI driver where t
On Tue, 30 May 2017, Hans Verkuil wrote:
> On 05/29/2017 09:00 PM, Daniel Vetter wrote:
>> On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
>>> On 05/26/2017 09:15 AM, Daniel Vetter wrote:
Did you look into also wiring this up for dp mst chains?
>>>
>>> Isn't this sufficient? I h
1 - 100 of 102 matches
Mail list logo
