On Wed, Jun 21, 2017 at 12:12:02PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wednesday 21 Jun 2017 10:28:46 Daniel Vetter wrote:
> > It doesn't do anything in the driver load error paths that the drm
> > core doesn't also do.
>
> If I understand the code cor
On Thu, Jun 22, 2017 at 12:34:36AM +0800, kbuild test robot wrote:
> Hi Peter,
>
> [auto build test ERROR on drm/drm-next]
> [also build test ERROR on next-20170621]
> [cannot apply to v4.12-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to
On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote:
> On 2017-06-21 09:38, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obsolete.
> >>
> >> I think the gamma_
For some greater resolution, the rdma threshold
variable will overflow.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp
Hi, Guenter,
Thanks for your test and comment.
On Wed, 2017-06-21 at 14:14 -0700, Guenter Roeck wrote:
> On Fri, May 19, 2017 at 05:57:23PM +0800, Bibby Hsieh wrote:
> > For some greater resolution, the rdma threshold
> > variable will overflow.
> >
> > Signed-off-by: Bibby Hsieh
> > ---
> >
Hi, CK,
Thanks for your review and comment.
On Mon, 2017-05-22 at 13:46 +0800, CK Hu wrote:
> Hi, Bibby:
>
> One comment inline.
>
> On Fri, 2017-05-19 at 17:57 +0800, Bibby Hsieh wrote:
> > For some greater resolution, the rdma threshold
> > variable will overflow.
> >
> > Signed-off-by: Bibb
On 22/06/17 08:16 AM, Eric Engestrom wrote:
> As Chad [1] puts it:
>> it's excessive to jump through the PLT into a shared object for a mere
>> ioctl wrapper.
>
> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159951.html
>
> Signed-off-by: Eric Engestrom
NAK, at least in this fo
On 06/21/2017 06:19 PM, Eric Anholt wrote:
Mario Kleiner writes:
With instantaneous high precision vblank timestamping
that updates at leading edge of vblank, the emulated
"hw vblank counter" from vblank timestamping which
increments at leading edge of vblank, and reliable
page flip execution
With instantaneous high precision vblank timestamping
that updates at leading edge of vblank, the emulated
"hw vblank counter" from vblank timestamping which
increments at leading edge of vblank, and reliable
page flip execution and completion at leading edge
of vblank, we should meet the requireme
Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_of_cooling_device_register and this
argument is of type const. So, declare the structure as const.
Signed-off-by: Bhumika Goyal
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
1 fi
On 2017-06-20 21:25, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code and hook up the crtc .gamma_set
> to use the crtc gamma_store directly instead of duplicating that
> info locally.
[...]
> - for (i = 0; i < 256;
Hi gang!
I was wondering why lvds-encoder.c is named like that.
(https://github.com/torvalds/linux/commit/67cc3e22b00f9027eaa0902ecf52ac5f4f5cac97)
The driver is clearly a drm_bridge, nested in the drm/bridge subdir... so why
not "lvds-bridge.c"?
Also, the associated bindings document is named "
On Wed, 21 Jun 2017 10:15:56 +0100
Chris Wilson wrote:
> Quoting Daniel Vetter (2017-06-21 10:13:41)
> > On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote:
> > > kbuild test robot found a build failure when building with thin
> > > archives:
> > >
> > > http://marc.info/?l=linux-
On 06/16/2017 11:10 AM, Christoph Hellwig wrote:
Hi all,
for a while we have a generic implementation of the dma mapping routines
that call into per-arch or per-device operations. But right now there
still are various bits in the interfaces where don't clearly operate
on these ops. This seri
Hi Daniel, Alexey,
On 25-05-2017 15:19, 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 respo
Hi Maxime,
On 21 June 2017 at 18:41, Maxime Ripard
wrote:
> On Tue, Jun 13, 2017 at 09:53:31PM +1000, Jonathan Liu wrote:
>> >> --- /dev/null
>> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
>> >> @@ -0,0 +1,163 @@
>> >> +/*
>> >> + * Copyright (C) 2017 Jonathan Liu
>> >> + *
>> >> + * Jonathan
Undo preparation of a clock source, if sti_hqvdp_start_xp70 and
sti_hqvdp_atomic_check are not successful.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/sti/sti_hqvdp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
inde
On 2017-06-21 09:38, Daniel Vetter wrote:
> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>> totally obsolete.
>>
>> I think the gamma_store can end up invalid on error. But the way I read
>> it, that can hap
Hi Maxime,
On 21 June 2017 at 18:51, Maxime Ripard
wrote:
> On Thu, Jun 15, 2017 at 01:29:33AM +1000, Jonathan Liu wrote:
>> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
>> "As in the general case the DDC bus is accessible by the kernel at the I2C
>> level, drivers
On Fri, May 19, 2017 at 05:57:23PM +0800, Bibby Hsieh wrote:
> For some greater resolution, the rdma threshold
> variable will overflow.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git
On 2017-06-21 17:14, Nicolas Ferre wrote:
> On 16/06/2017 at 00:40, Peter Rosin wrote:
>> On 2017-06-15 11:37, Boris Brezillon wrote:
>>> On Thu, 15 Jun 2017 11:24:13 +0200
>>> Peter Rosin wrote:
>>>
From: Peter Rosin
Remove the layer.
>>>
>>> Duh. It was present in the datasheet I
On 16/06/2017 at 00:40, Peter Rosin wrote:
> On 2017-06-15 11:37, Boris Brezillon wrote:
>> On Thu, 15 Jun 2017 11:24:13 +0200
>> Peter Rosin wrote:
>>
>>> From: Peter Rosin
>>>
>>> Remove the layer.
>>
>> Duh. It was present in the datasheet I had. Just downloaded last
>> version of the datashee
Basically ripped off of [1] by Chris Wilson, which I thought should live
in libdrm too (even though it's needed in Mesa anyway).
[1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159894.html
Signed-off-by: Chris Wilson
Signed-off-by: Eric Engestrom
---
xf86drm.h | 27 ++
As Chad [1] puts it:
> it's excessive to jump through the PLT into a shared object for a mere
> ioctl wrapper.
[1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159951.html
Signed-off-by: Eric Engestrom
---
xf86drm.c | 14 --
xf86drm.h | 18 +-
2 files ch
On Wed, Jun 21, 2017 at 11:28 AM, Daniel Vetter wrote:
> Hi all,
>
> This is Thierry's deferred fbdev setup series, with the locking rework almost
> entirely redone. The much wider scope is to get rid of drm_modeset_lock_all
> calls for atomic drivers and remove users of the fairly nasty
> mode_co
Cc'ing dri-devel.
Dave.
On Tue, 13 Jun 2017, Tejun Heo wrote:
> Cc'ing David Airlie.
>
> This is from drm driver calling in idr_replace() w/ a negative id.
> Probably a silly bug in error handling path?
>
> Thanks.
>
> On Mon, Jun 12, 2017 at 08:10:54PM +0530, Abdul Haleem wrote:
> > Hi,
> >
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #16 from Christoph Schwerdtfeger ---
I can confirm that if I recompile the Debian sources with LLVM 4.0 it's not
working (the lighting bug is present) but if I set LLVM to 3.9 it's working
correctly (lighting bug is NOT present).
I w
On Wed, Jun 21, 2017 at 3:22 AM, Michel Dänzer wrote:
> On 21/06/17 10:44 AM, Mario Kleiner wrote:
>> With instantaneous high precision vblank timestamping
>> that updates at leading edge of vblank, a cooked hw
>> vblank counter which increments at leading edge of
>> vblank, and reliable page flip
On Wed, Jun 21, 2017 at 5:51 PM, Arnd Bergmann wrote:
> The debugfs interface has calls a function that was evidently
> defined under the wrong name in some configurations:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:64:12: error:
> 'amdgpu_debugfs_test_ib_ring_init' used but never defined [-W
The debugfs interface has calls a function that was evidently
defined under the wrong name in some configurations:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:64:12: error:
'amdgpu_debugfs_test_ib_ring_init' used but never defined [-Werror]
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3803:12: error
On Wed, Jun 21, 2017 at 07:42:47PM +1000, Jonathan Liu wrote:
> >> +static int wait_fifo_flag_unset(struct sun4i_hdmi *hdmi, u32 flag)
> >> +{
> >> + /* 1 byte takes 9 clock cycles (8 bits + 1 ack) */
> >> + unsigned long byte_time = DIV_ROUND_UP(USEC_PER_SEC,
> >> +
https://bugs.freedesktop.org/show_bug.cgi?id=98238
--- Comment #19 from Edmondo Tommasina ---
Marek sent a series of patches to the mailing list that could be interesting
to fix the black transition issue for Witcher 2:
https://lists.freedesktop.org/archives/mesa-dev/2017-June/160177.html
I sen
Le Wed, 21 Jun 2017 11:50:02 -0700,
Eric Anholt a écrit :
> It is no longer used as of commit 34c8ea400ff6 ("drm/vc4: Mimic
> drm_atomic_helper_commit() behavior")
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 8
> drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #74 from kees.aar...@hotmail.com ---
I have come here since my first git bisect learned me that commit
09be4a5219610a6fae3215d4f51f948d6f5d2609 causes problems on my system. I have a
RX 460 and LG 38UC99-W and 3840x1600 @ 60hz gives no
Hi Mario,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.12-rc6 next-20170621]
[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/Mario-Kleiner/drm-vc4-Allow
https://bugzilla.kernel.org/show_bug.cgi?id=194843
Johannes Hirte (johannes.hi...@datenkhaos.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=191281
Johannes Hirte (johannes.hi...@datenkhaos.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=191291
Johannes Hirte (johannes.hi...@datenkhaos.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
It is no longer used as of commit 34c8ea400ff6 ("drm/vc4: Mimic
drm_atomic_helper_commit() behavior")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
2 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/d
This way drm_atomic_helper_wait_for_fences() will actually do
something. The vc4_seqno_cb has been doing the fence waits on V3D
manually, so far.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_plane.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm
We should allow SIGIO and things to interrupt us before we get to the
no-error stage of the commit process. This code is effectively copied
from drm_atomic_helper_commit().
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
Now that we're using the atomic helpers for fence waits, we can use
the same codepath as drm_atomic_helper_commit() does for async,
getting rid of our custom vc4_commit struct.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_kms.c | 71 ---
1 file c
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu
Like with panning and modesetting, and like with those, stick with
simple drm_modeset_locking_all for the legacy path, and the full
atomic dance for atomic drivers.
This means a bit more boilerplate since setting up the atomic state
machinery is rather verbose, but then this is shared code for 30+
From: Thierry Reding
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fall
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Thierry Reding
Same game as with the panning function, use drm_modeset_lock_all for
legacy paths, and a proper acquire ctx w/w mutex dance for atomic.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 48 +
1 file cha
Like with the drm-native vblank wait ioctl we can entirely rely on the
spinlocks in drm_vblank.c, no need at all to take expensive mutexes.
The only reason we had to take mode_config.mutex was to protect the
fbdev helper's data-structures, but that's now done by
fb_helper->lock.
Cc: John Stultz
C
For the legacy path we'll keep drm_modeset_lock_all, for the atomic
one we drop the use of the magic implicit context and wire it up
properly.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 28 ++--
1 file changed,
Those are now all protected using fb_helper->lock.
v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 21 +++--
drivers/gpu/drm/drm_vblank
Hi all,
This is Thierry's deferred fbdev setup series, with the locking rework almost
entirely redone. The much wider scope is to get rid of drm_modeset_lock_all
calls for atomic drivers and remove users of the fairly nasty
mode_config->acquire_ctx hack, which breaks when doing multiple atomic com
Since
commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae
Author: Archit Taneja
Date: Wed Aug 5 12:28:57 2015 +0530
drm: Add top level Kconfig option for DRM fbdev emulation
this is properly handled using dummy functions. This essentially
undoes
commit 7296c849bf2eca2bd7d34a4686a53e3089150ac
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
This patch just adds the new lock everywhere we currently grab
mode_config->mutex (explicitly, or through d
That function only needs to take the individual crtc locks, not all
the kms locks. Push down the locking and then minimize it.
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 24 +---
1 file changed, 9 insertions(+), 15
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
v2: Also handle intel_connector_add_to_fbdev.
Tested-by: John Stultz
Signed-off-by: Thierry Reding (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 40 +-
Boris Brezillon writes:
> On Thu, 15 Jun 2017 16:33:11 -0700
> Eric Anholt wrote:
>
>> Eric Anholt writes:
>>
>> > [ Unknown signature status ]
>> > Boris Brezillon writes:
>> >
>> >> On Tue, 06 Jun 2017 13:27:09 -0700
>> >> Eric Anholt wrote:
>> >>
>> >>> Boris Brezillon writes:
>> >>>
Taken from make headers_install of drm-misc-next
(34c8ea400ff6383b028f63df2453914163afc07c)
---
include/drm/drm_fourcc.h | 23 ++-
include/drm/vc4_drm.h| 22 +++---
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/in
Hi Peter,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20170621]
[cannot apply to v4.12-rc6]
[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/Peter-Rosin/improve-the
Mario Kleiner writes:
> With instantaneous high precision vblank timestamping
> that updates at leading edge of vblank, the emulated
> "hw vblank counter" from vblank timestamping which
> increments at leading edge of vblank, and reliable
> page flip execution and completion at leading edge
> of
Regards
Shashank
On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote:
On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
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 HD
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #15 from Carlo Caione ---
Created attachment 132118
--> https://bugs.freedesktop.org/attachment.cgi?id=132118&action=edit
journal_HDMI_detaching_corruption
> Without seeing the corresponding Xorg log, I guess that's just
> a diffe
On Tue, Jun 20, 2017 at 10:16:51PM +0200, Arnd Bergmann wrote:
> When compile-testing for something other than ARCH_QCOM,
> we run into a link error:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init':
> a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to
> `qcom_mdt_
On Tue, Jun 20, 2017 at 10:16:50PM +0200, Arnd Bergmann wrote:
> In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t
> into dmam_alloc_coherent, which the compiler warns about:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt':
> drivers/gpu/drm/msm/adreno/a5xx_
Hi there.
I'm toying around with an ARM board which uses the S5P4418.
This one should have a Nexell chip and I'm trying to get Nexell support
running for my system.
On the net I already found some patches and were able to recompile my
libdrm.
Now comes the big question: How can I check it suppo
On Wed, Jun 21, 2017 at 11:16:27AM +0200, Daniel Vetter wrote:
> The crtc->commit_lock only protects commit_list and commit_entry. If
> we chase the pointer from the drm_atomic_state update structure, then
> we don't need any locks (since we hold a reference already).
>
> Simplify the locking acco
https://bugs.freedesktop.org/show_bug.cgi?id=100070
--- Comment #12 from Timothee Besset ---
No game fix is planned at this time.
Marek's addition of glsl_correct_derivatives_after_discard is generally a good
thing for mesa compatibility with the broader GL driver ecosystem.
--
You are receivi
2017-06-21 12:15 GMT+02:00 Arvind Yadav :
> Undo preparation of a clock source, if sti_hqvdp_start_xp70 and
> sti_hqvdp_atomic_check are not successful.
>
> Signed-off-by: Arvind Yadav
Applied on drm-misc-next, thanks,
Benjamin
> ---
> drivers/gpu/drm/sti/sti_hqvdp.c | 3 +++
> 1 file changed,
On Wed, Jun 21, 2017 at 03:04:29PM +0200, Daniel Vetter wrote:
> I've failed to remember that we have virtual drivers like vgem which
> have no underlying struct device. Fix this asap.
>
> Reported-by: Chris Wilson
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson
> Fixes: 5c484cee7ef9 ("drm: Remo
On 06/21/2017 12:34 PM, 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 modes using the e
On 06/21/2017 12:34 PM, Shashank Sharma wrote:
> 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 d
On 06/21/2017 12:33 PM, 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 (VIC 1-107).
>
>
On Wed, Mar 29, 2017 at 04:44:01PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The expression &private->fbdev_helper can never be NULL, so the check is
> completely unnecessary.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
I just noticed that these two patches at
Hi Christoph,
On 2017-06-20 15:16, Christoph Hellwig wrote:
On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next
Contacts: Marek Szyprowski and Kyungmin Park (cc'd)
I have called your tree dma-mapping-
On Thu, Apr 6, 2017 at 10:02 PM, Daniel Vetter wrote:
> Fixing this properly would mean we get to wire the acquire_ctx all the
> way through vmwgfx fbdev code, and doing the same was tricky for the
> shared fbdev layer. Probably much better to look into refactoring the
> entire code to use the hel
Hi,
On 26-05-17 09:35, Hans De Goede wrote:
The local #define of ACPI_VIDEO_NOTIFY_PROBE was only added temporarily
to avoid a dependency between the acpi and nouveau trees while merging.
This is now properly defined in acpi/video.h and the local #define can
be dropped.
Signed-off-by: Hans de
I've failed to remember that we have virtual drivers like vgem which
have no underlying struct device. Fix this asap.
Reported-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Fixes: 5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
Cc: Thierry Reding
Cc: Daniel Vetter
Signed
On Wed, Jun 21, 2017 at 10:28:49AM +0200, Daniel Vetter wrote:
> It again looks all cargo-culted for no good reasons.
>
> Cc: Shawn Guo
> Signed-off-by: Daniel Vetter
Acked-by: Shawn Guo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
What these architectures declare is the same as what can be found in
asm-generic/vga.h. So use that header instead.
Signed-off-by: Jiri Slaby
Acked-by: Max Filippov
Cc: Michal Simek
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Chris Zankel
Cc: x...@kernel.org
Cc: linux-xte..
Provided the architectures do not need any special handling (they seem
not to support vga at all, actually), there is no need to have an
empty vga.h. Let them refer to the generic one instead.
Signed-off-by: Jiri Slaby
Acked-by: Geert Uytterhoeven
Acked-by: Martin Schwidefsky
Cc: David Howells
When I was doing a grep . -r /sys/kernel/debug/dri/0 I noticed a WARN
appearing when I aborted the grep with ^C.
After investigating I've also noticed that the error handling was
lacking and there are race conditions involving multiple calls to
open/close simultaneously.
Fix this by setting the o
Remove the error handling of bridge_node because the bridge_node is
optional.
For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is optional.
Signed-off-by: Hoegeun Kwon
---
Hi all,
Than
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
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
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
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
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
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
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
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
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
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
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
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
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
Hi Dave,
not much news in etnaviv land for this cycle. A bit late, but all
patches had at least 2 weeks of soak time in linux-next.
- a fix from Eric for synchronization with etnaviv exported dma-bufs
- thermal throttle support for newer GPU cores
- updated module clock gating to work around GPU
Hi Dave,
Updated the tree to add the additional fix from Arnd Bergman. Also rebased
on top of current drm-next.
Sorry for the mess.
> 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 th
On Wed, Jun 21, 2017 at 11:31 AM, Laurent Pinchart
wrote:
> The M3-W HDMI TX controller seems to be compatible for the H3. No
> extension to the DT bindings are needed, add an SoC-specific compatible
> string in case differences between the IP versions are found later and
> require model-specific
1 - 100 of 148 matches
Mail list logo
