2017ë
01ì 09ì¼ 18:53ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 09.01.2017 10:19, Inki Dae wrote:
>>
>> 2017ë
01ì 09ì¼ 16:37ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> On 06.01.2017 09:36, Inki Dae wrote:
2017ë
01ì 06ì¼ 17:18ì Andi Shyti ì´(ê°) ì´ ê¸:
> Hi Inki,
>
>
Hi Sean,
On Mon, Jan 09, 2017 at 11:27:44AM -0500, Sean Paul wrote:
> > +static inline void zx_osd_int_update(struct zx_crtc *zcrtc)
> > +{
> > + struct zx_vou_hw *vou = zcrtc->vou;
> > + int i;
> > +
> > + vou_chn_set_update(zcrtc);
> > + zx_plane_set_update(zcrtc->primary
From: Shawn Guo
Changes for v5:
- Use crtc->state->plane_mask to check which planes are active for a
given CRTC, so that we can save vou->overlays pointer array.
- Use plane->state->crtc to determine if a plane is enabled or not,
so that 'enabled' flag in zx_plane can be eliminated.
Chan
From: Shawn Guo
Move struct zx_plane from zx_plane.c to zx_plane.h, so that it can be
accessed from zx_vou driver, and we can save the use of struct
zx_layer_data completely. More importantly, those additional data used
by VOU controller to enable/disable graphic and video layers can later
be ad
From: Shawn Guo
There are a few hardware bits for each graphic layer to control main/aux
channel and clock selection, as well as the layer enabling. These bits
sit outside the layer block itself, but in VOU control glue block. We
currently set these bits up at CRTC initialization for once, and
From: Shawn Guo
It enables VOU VL (Video Layer) to support overlay plane with scaling
function. VL0 has some quirks on scaling support. We choose to skip it
and only adds VL1 and VL2 into DRM core for now.
Function zx_plane_atomic_disable() gets moved around with no changes to
save a forward d
On runtime resume, nouveau can try and take the mode_config
mutex in the poll reenable, however a poll can race with this,
and take the mutex and get stuck waiting for the runtime to
finish completion. These two patches allow the driver to
get hooked in before the mutex is taken.
I think radeon/am
From: Dave Airlie
In order to avoid a lockdep between pm resume and output poll
over the mode_config mutex we need to order the wakeup of the
device before we take the mode config mutex (as pm resume
can also try and take the mode config mutex).
This introduces an API for drivers to insert thems
From: Dave Airlie
This wraps the output poll and fixes a problem where
pm resume would try and take the mode config mutex
but the output poll thread would already have taken it.
I found this while looking for another bug, I've no idea
yet if this fixes that problem.
Signed-off-by: Dave Airlie
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/8223a26d/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/b0ecaaa0/attachment.html>
.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/d406a866/attachment.html>
Use BUG_ON instead of a if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
CC: Xiangliang Yu
Signed-off-by: Julia Lawall
Signed-off-by: Fengguang Wu
---
gfx_v8_0.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v
bbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/6372e57a/attachment.html>
org/archives/dri-devel/attachments/20170110/6fe6ff05/attachment-0001.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/374f77e0/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/3de06a53/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170110/27703928/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/e01944a0/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=191291
--- Comment #3 from Michel Dänzer ---
Please attach the dmesg output and Xorg log file corresponding to the problem.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/338bce5e/attachment.html>
On Tue, Jan 10, 2017 at 12:12:30PM +1000, Dave Airlie wrote:
> On runtime resume, nouveau can try and take the mode_config
> mutex in the poll reenable, however a poll can race with this,
> and take the mutex and get stuck waiting for the runtime to
> finish completion. These two patches allow the
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/c80300a2/attachment-0001.html>
Am 10.01.2017 um 06:52 schrieb Julia Lawall:
> Use BUG_ON instead of a if condition followed by BUG.
>
> Generated by: scripts/coccinelle/misc/bugon.cocci
>
> CC: Xiangliang Yu
> Signed-off-by: Julia Lawall
> Signed-off-by: Fengguang Wu
Reviewed-by: Christian König .
> ---
>
> gfx_v8_0.c
Hi Laurent,
On Fri, Aug 19, 2016 at 10:39 AM, Laurent Pinchart
wrote:
> This patch series fixes the rcar-du-drm driver to support VSP plane sources
> with an IOMMU. It is available for convenience at
>
> git://linuxtv.org/pinchartl/media.git iommu/devel/du
Dropped from renesas-drivers, a
Hi Dave,
Here is an update of the STI drm driver.
It contains stih410 cleanup, create fbdev at binding, HQVDP fixes.
Tag is available but not yet signed for the moment. I'm working on it.
Regards,
Vincent
The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d:
Merge bran
On Mon, Jan 09, 2017 at 05:59:39PM -0500, Alex Deucher wrote:
> On Mon, Jan 9, 2017 at 4:56 PM, Gabriel Krisman Bertazi
> wrote:
> > Notice that this uncovers an issue with the kernel-doc handling of array
> > arguments, causing the first parameter of drm_clflush_pages() to not
> > show up in the
On Mon, Jan 09, 2017 at 11:24:53PM +0530, Bhumika Goyal wrote:
> Declare exynos_drm_crtc_ops structures as const as they are only passed
> as an argument to the function exynos_drm_crtc_create. This argument is
> of type const struct exynos_drm_crtc_ops *, so exynos_drm_crtc_ops
> structures having
Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
replace the old for_each_xxx_in_state ones. This is useful for >1 flip
depth and getting rid of all xxx->state dereferences.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 6 +++
drivers/gpu/drm/dr
This kills another dereference of connector->state. connector_mask
holds all unchanged connectors at least and any changed connectors
are already in state anyway.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 18cdf2c956c6..7b61e0da9ace 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 293 +++-
1 file changed, 152 insertions(+), 141 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c468194934a8..b577977322d0 100644
Third version. Instead of trying to convert all drivers straight away,
implement all macros that are required to get state working.
Old situation:
Use obj->state, which can refer to old or new state.
Use drm_atomic_get_(existing_)obj_state, which can refer to new or old state.
Use for_each_obj_in_
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c| 6 +++---
drivers/gpu/drm/drm_atomic_helper.c | 39 +
drivers/gpu/drm/drm_blend.c | 3 +--
3 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_
After atomic commit, these macros should be used in place of
get_existing_state. Also after commit get_xx_state should no longer
be used because it may not have the required locks.
Signed-off-by: Maarten Lankhorst
---
include/drm/drm_atomic.h | 99
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_blend.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 5c45d0852608..78cf9f6cae08 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/d
On Mon, Jan 09, 2017 at 09:42:22AM -0800, Dave Hansen wrote:
> On 01/09/2017 08:59 AM, Daniel Vetter wrote:
> > On Mon, Jan 9, 2017 at 5:50 PM, Dave Hansen
> > wrote:
> >> On 01/09/2017 08:41 AM, Daniel Vetter wrote:
> >>> On Mon, Jan 9, 2017 at 2:40 PM, Dave Hansen
> >>> wrote:
> Well, no
On Mon, Jan 09, 2017 at 07:56:24PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank is mostly CRTC specific and implemented as part of CRTC
> driver. So having vblank hooks in struct drm_crtc_funcs should
> generally help to reduce code from client drivers in implementing
> drm_driver's
On Mon, Jan 09, 2017 at 11:50:59AM -0500, Sean Paul wrote:
> On Mon, Jan 9, 2017 at 9:31 AM, Peter Ujfalusi
> wrote:
> > Instead of scheduling the work to handle the initial delayed event, use 1s
> > delay.
> >
> > This delay should not be needed, but Optimus/nouveau will fail in a
> > mysterious
On Tue, Jan 10, 2017 at 11:40:59AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2017 at 11:50:59AM -0500, Sean Paul wrote:
> > On Mon, Jan 9, 2017 at 9:31 AM, Peter Ujfalusi
> > wrote:
> > > Instead of scheduling the work to handle the initial delayed event, use 1s
> > > delay.
> > >
> > > This
On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color depths
> greater than 24 bits per pixel. The spec explicitly states, "All Deep
> Color modes are optional though if an HDMI Source or Sink supports any
> Deep Color mo
On Mon, Jan 09, 2017 at 06:38:15PM +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
> psr2 enable sequence.
> Program Transcoder EDP VSC DIP header with a valid setting for PSR2
> and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable header
> p
On Thu, Jan 05, 2017 at 02:46:06PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 05-01-2017 11:46, Ville Syrjälä wrote:
> > On Thu, Jan 05, 2017 at 10:07:45AM +, Jose Abreu wrote:
> >> Hi Ville,
> >>
> >>
> >> On 04-01-2017 16:36, Ville Syrjälä wrote:
> >>> On Wed, Jan 04, 2017 at 04:15:0
In case no connector is found while creating the fbdev, gives the
possibility to specify the default fbdev size by firstly checking if the
command line is defining a preferred mode. Else go into fallback and set
1024x768 fbdev size as it was already done.
Cc: Tomi Valkeinen
Signed-off-by: Vincent
On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> I noticed that the VT switch doesn't work any longer with a Dell
> laptop with 1366x768 eDP when the machine is connected with a DP
> monitor. It behaves as if VT were switched, but the graphics remain
> frozen. Actually the keyboard
* Spec says that if any deep color mode is supported at all,
> > - * then deep color 36 bit must be supported.
> > - */
> > - if (!(hdmi[6] & DRM_EDID_HDMI_DC_36)) {
> > - DRM_DEBUG("%s: HDMI sink should do DC_36, but does not!\n",
> > - connector->name);
> > - }
> > }
> >
> > static void
> > @@ -3895,6 +3905,7 @@ static void drm_add_display_info(struct
> drm_connector *connector,
> > /* driver figures it out in this case */
> > info->bpc = 0;
> > info->color_formats = 0;
> > + info->edid_hdmi_dc_modes = 0;
> > info->cea_rev = 0;
> > info->max_tmds_clock = 0;
> > info->dvi_dual = false;
> > --
> > 2.11.0
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/22794c37/attachment-0001.html>
On Tue, 10 Jan 2017 12:28:36 +0100,
Ville Syrjälä wrote:
>
> On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > I noticed that the VT switch doesn't work any longer with a Dell
> > laptop with 1366x768 eDP when the machine is connected with a DP
> > monitor. It behaves as if VT w
On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote:
> In case no connector is found while creating the fbdev, gives the
> possibility to specify the default fbdev size by firstly checking if the
> command line is defining a preferred mode. Else go into fallback and set
> 1024x768 fbdev
be needed ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/0394d537/attachment.html>
| 164 +++---
> drivers/gpu/drm/omapdrm/omap_irq.c | 242
> +++--
> drivers/gpu/drm/omapdrm/omap_plane.c | 24 --
> include/uapi/drm/Kbuild| 1 +
> 17 files changed, 441 insertions(+), 481 de
On Mon, Jan 9, 2017 at 8:29 PM, Shawn Guo wrote:
> From: Shawn Guo
>
> It enables VOU VL (Video Layer) to support overlay plane with scaling
> function. VL0 has some quirks on scaling support. We choose to skip it
> and only adds VL1 and VL2 into DRM core for now.
>
> Function zx_plane_atomic_d
On Tue, Jan 10, 2017 at 09:46:26PM +1000, Dave Airlie wrote:
> On 10 Jan. 2017 19:50, "Daniel Vetter" wrote:
>
> On Tue, Jan 10, 2017 at 12:12:30PM +1000, Dave Airlie wrote:
> > On runtime resume, nouveau can try and take the mode_config
> > mutex in the poll reenable, however a poll can race wit
On Tue, Jan 10, 2017 at 12:36:50PM +0100, Takashi Iwai wrote:
> On Tue, 10 Jan 2017 12:28:36 +0100,
> Ville Syrjälä wrote:
> >
> > On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > > I noticed that the VT switch doesn't work any longer with a Dell
> > > laptop with 1366x768 eDP w
Hi Chris, Laurent,
On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM range
manager selftests fail with:
drm_mm: Testing DRM range manger (struct drm_mm), with
random_seed=0x83a9b910 max_iterations=8192 max_prime=128
drm_mm: igt_sanitycheck - ok!
drm_mm: node has wrong color,
On Tue, 10 Jan 2017 13:41:42 +0100,
Daniel Vetter wrote:
>
> On Tue, Jan 10, 2017 at 12:36:50PM +0100, Takashi Iwai wrote:
> > On Tue, 10 Jan 2017 12:28:36 +0100,
> > Ville Syrjälä wrote:
> > >
> > > On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> > > > I noticed that the VT swi
On Tue, Jan 10, 2017 at 01:41:54PM +0100, Geert Uytterhoeven wrote:
> Hi Chris, Laurent,
>
> On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM range
> manager selftests fail with:
>
> drm_mm: Testing DRM range manger (struct drm_mm), with
> random_seed=0x83a9b910 max_iterations=8192
archives/dri-devel/attachments/20170110/daebc924/attachment-0001.html>
This patch adds pm_runtime_get/put calls to notify device core when MIC
device is really in use. This is needed to let power domain with this
device to be turned off when display is turned off.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 17 -
1
On Tue, Jan 10, 2017 at 12:33:35PM +0100, Ernst Sjöstrand wrote:
> Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm
> confusing the transport layer with the presentation capabilities...?
> Here are 201 monitors that claim 10bpc:
> http://pricespy.co.uk/category.php?l=s3008
On 01/10/2017 12:39 PM, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote:
>> In case no connector is found while creating the fbdev, gives the
>> possibility to specify the default fbdev size by firstly checking if the
>> command line is defining a preferred m
On Tue, 10 Jan 2017, Ville Syrjälä wrote:
> On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
>> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color depths
>> greater than 24 bits per pixel. The spec explicitly states, "All Deep
>> Color modes are optional though if a
Hi,
here are the last two patches that remain to be merged in this series,
rebased on today's drm-tip.
Thanks,
Tomeu
Tomeu Vizoso (2):
drm/i915: Use new CRC debugfs API
drm/i915: Put "cooked" vlank counters in frame CRC lines
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
Reviewed-by: Robert Foss
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 fi
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong v
Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
replace the old for_each_xxx_in_state ones. This is useful for >1 flip
depth and getting rid of all xxx->state dereferences.
This requires extra fixups done when committing a state after
duplicating, which in general isn't valid
On Tue, Jan 10, 2017 at 12:45:04PM +, Chris Wilson wrote:
> On Tue, Jan 10, 2017 at 01:41:54PM +0100, Geert Uytterhoeven wrote:
> > Hi Chris, Laurent,
> >
> > On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM range
> > manager selftests fail with:
> >
> > drm_mm: Testing DRM rang
On Tue, Jan 10, 2017 at 02:51:17PM +0100, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 12:45:04PM +, Chris Wilson wrote:
> > On Tue, Jan 10, 2017 at 01:41:54PM +0100, Geert Uytterhoeven wrote:
> > > Hi Chris, Laurent,
> > >
> > > On R-Car Gen2 (Koelsch) and Gen3 (Salvator-X), the new DRM ran
On Tue, Jan 10, 2017 at 03:39:42PM +0200, Jani Nikula wrote:
> On Tue, 10 Jan 2017, Ville Syrjälä wrote:
> > On Thu, Jan 05, 2017 at 05:45:23PM -0600, Nicholas Sielicki wrote:
> >> As per the HDMI 1.3 and 1.4 spec, "deep color modes" are color depths
> >> greater than 24 bits per pixel. The spec
Hello Chris Wilson,
The patch 560b32842912: "drm: kselftest for drm_mm and eviction" from
Dec 22, 2016, leads to the following static checker warning:
drivers/gpu/drm/selftests/test-drm_mm.c:1277 evict_everything()
warn: calling list_del() inside list_for_each
drivers/gpu/drm/sel
It was only needed to protect the connector_list walking, see
commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter
Date: Thu Jul 9 23:44:26 2015 +0200
drm/probe-helper: Grab mode_config.mutex in poll_init/enable
Unfortunately the commit message of that patch fails to ment
On Tue, Jan 10, 2017 at 05:17:46PM +0300, Dan Carpenter wrote:
> Hello Chris Wilson,
>
> The patch 560b32842912: "drm: kselftest for drm_mm and eviction" from
> Dec 22, 2016, leads to the following static checker warning:
>
> drivers/gpu/drm/selftests/test-drm_mm.c:1277 evict_everything()
>
drivers/gpu/drm/selftests/test-drm_mm.c:1277 evict_everything()
warn: calling list_del() inside list_for_each
The list_del() inside the error handling in the eviction loop is
overkill. We have to undo the eviction scan to return the drm_mm back to
a recoverable state, so have to it
ee to queue up for 4.11 instead.
thanks,
Gerd
The following changes since commit
a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kraxel.org/linux tags/drm-qemu-20170110
for you to fetch changes
On Tue, Jan 10, 2017 at 03:29:10PM +0100, Daniel Vetter wrote:
> It was only needed to protect the connector_list walking, see
>
> commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
> Author: Daniel Vetter
> Date: Thu Jul 9 23:44:26 2015 +0200
>
> drm/probe-helper: Grab mode_config.mutex in p
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/3b31b7f8/attachment.html>
On Tue, Jan 10, 2017 at 12:26:53PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 10-01-2017 11:16, Ville Syrjälä wrote:
> > On Thu, Jan 05, 2017 at 02:46:06PM +, Jose Abreu wrote:
> >>
>
> [snip]
>
> >> The pixel clock rate is half of the TMDS character rate in 4:2:0
> >> (in 24 bit), but
On Tue, Jan 10, 2017 at 05:33:15PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 10, 2017 at 12:26:53PM +, Jose Abreu wrote:
> > Hi Ville,
> >
> >
> > On 10-01-2017 11:16, Ville Syrjälä wrote:
> > > On Thu, Jan 05, 2017 at 02:46:06PM +, Jose Abreu wrote:
> > >>
> >
> > [snip]
> >
> > >>
On Tue, Jan 10, 2017 at 02:43:05PM +0100, Tomeu Vizoso wrote:
> Use drm_accurate_vblank_count so we have the full 32 bit to represent
> the frame counter and userspace has a simpler way of knowing when the
> counter wraps around.
>
> Signed-off-by: Tomeu Vizoso
> Reviewed-by: Emil Velikov
> Revi
On Tue, Jan 10, 2017 at 05:54:57PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 10, 2017 at 02:43:05PM +0100, Tomeu Vizoso wrote:
> > Use drm_accurate_vblank_count so we have the full 32 bit to represent
> > the frame counter and userspace has a simpler way of knowing when the
> > counter wraps arou
On Tue, Jan 10, 2017 at 03:17:44PM +, Chris Wilson wrote:
> On Tue, Jan 10, 2017 at 03:29:10PM +0100, Daniel Vetter wrote:
> > It was only needed to protect the connector_list walking, see
> >
> > commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
> > Author: Daniel Vetter
> > Date: Thu Jul 9
ktop.org/archives/dri-devel/attachments/20170110/05406261/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/aa2c00ed/attachment.html>
On Mon, Jan 09, 2017 at 11:20:57AM -0800, Jason Ekstrand wrote:
> On Thu, Jan 5, 2017 at 7:14 AM, wrote:
>
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engine
> > the l
On Tue, Jan 10, 2017 at 05:34:08PM +0100, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 03:17:44PM +, Chris Wilson wrote:
> > On Tue, Jan 10, 2017 at 03:29:10PM +0100, Daniel Vetter wrote:
> > > -void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
> > > +void drm_kms_helper_poll_ena
On Tue, Jan 10, 2017 at 05:01:08PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> [snip]
>
> >> Are you going to update all the userspace clients? Exposing HDMI 2.0
> >> modes only for your favorite client doesn't sound like a good plan to
> >> me.
> >>
> >> If we simply compute from a specific mode
archives/dri-devel/attachments/20170110/0801e0c6/attachment.html>
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/2d119a10/attachment.html>
On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand wrote:
> Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm
> confusing the transport layer with the presentation capabilities...?
> Here are 201 monitors that claim 10bpc:
> http://pricespy.co.uk/category.php?l=s300859434&o=
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/f88a6815/attachment.html>
On Tue, Jan 10, 2017 at 12:27:45PM -0500, Alex Deucher wrote:
> On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand wrote:
> > Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm
> > confusing the transport layer with the presentation capabilities...?
> > Here are 201 monitors
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/1399c85d/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170110/14c47a6b/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=191281
--- Comment #4 from Johannes Hirte ---
I can confirm that
https://lists.freedesktop.org/archives/amd-gfx/2017-January/004537.html fixes
boot for me. Tested on top of linux-4.10.0-rc3-00029-gbd5d7428f5e5
--
You are receiving this mail because:
Y
https://bugzilla.kernel.org/show_bug.cgi?id=191291
--- Comment #4 from Johannes Hirte ---
Attaching dmesg and Xorg.log from kernel 4.10.0-rc3-00029-gbd5d7428f5e5
I've booted the sytem, logged into KDE Plasma session logged out and the cursor
was gone under sddm. Logs were taken from console afte
https://bugzilla.kernel.org/show_bug.cgi?id=191291
--- Comment #5 from Johannes Hirte ---
Created attachment 251141
--> https://bugzilla.kernel.org/attachment.cgi?id=251141&action=edit
dmesg-4.10.0-rc3-00029-gbd5d7428f5e5
--
You are receiving this mail because:
You are watching the assignee o
https://bugzilla.kernel.org/show_bug.cgi?id=191291
--- Comment #6 from Johannes Hirte ---
Created attachment 251151
--> https://bugzilla.kernel.org/attachment.cgi?id=251151&action=edit
Xorg.0.log-4.10.0-rc3-00029-gbd5d7428f5e5
--
You are receiving this mail because:
You are watching the assig
ves/dri-devel/attachments/20170110/6f8fc808/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=192271
Bug ID: 192271
Summary: kernel 4.9 hangs during shutdown or reboot
Product: Drivers
Version: 2.5
Kernel Version: 4.9.2
Hardware: x86-64
OS: Linux
Tree: Mainli
On Tue, Jan 10, 2017 at 12:46 PM, Ville Syrjälä
wrote:
> On Tue, Jan 10, 2017 at 12:27:45PM -0500, Alex Deucher wrote:
>> On Tue, Jan 10, 2017 at 6:33 AM, Ernst Sjöstrand
>> wrote:
>> > Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm
>> > confusing the transport laye
& DRM_EDID_HDMI_DC_36)) {
> >> >> > + DRM_DEBUG("%s: HDMI sink should do DC_36, but does
> >> >> > not!\n",
> >> >> > + connector->name);
> >> >> > + return;
> >> >> > + }
> >> >> > +
> >> >> > +
> >> >> > DRM_DEBUG("%s: Assigning HDMI sink color depth as %d bpc.\n",
> >> >> > connector->name, dc_bpc);
> >> >> > info->bpc = dc_bpc;
> >> >> > + info->edid_hdmi_dc_modes = modes;
> >> >> >
> >> >> > /*
> >> >> >* Deep color support mandates RGB444 support for all video
> >> >> > @@ -3823,15 +3842,6 @@ static void drm_parse_hdmi_deep_color_
> info(struct
> >> >> > drm_connector *connector,
> >> >> > DRM_DEBUG("%s: HDMI sink does YCRCB444 in deep
> color.\n",
> >> >> > connector->name);
> >> >> > }
> >> >> > -
> >> >> > - /*
> >> >> > - * Spec says that if any deep color mode is supported at all,
> >> >> > - * then deep color 36 bit must be supported.
> >> >> > - */
> >> >> > - if (!(hdmi[6] & DRM_EDID_HDMI_DC_36)) {
> >> >> > - DRM_DEBUG("%s: HDMI sink should do DC_36, but does
> >> >> > not!\n",
> >> >> > - connector->name);
> >> >> > - }
> >> >> > }
> >> >> >
> >> >> > static void
> >> >> > @@ -3895,6 +3905,7 @@ static void drm_add_display_info(struct
> >> >> > drm_connector *connector,
> >> >> > /* driver figures it out in this case */
> >> >> > info->bpc = 0;
> >> >> > info->color_formats = 0;
> >> >> > + info->edid_hdmi_dc_modes = 0;
> >> >> > info->cea_rev = 0;
> >> >> > info->max_tmds_clock = 0;
> >> >> > info->dvi_dual = false;
> >> >> > --
> >> >> > 2.11.0
> >> >>
> >> >> --
> >> >> Ville Syrjälä
> >> >> Intel OTC
> >> >> ___
> >> >> dri-devel mailing list
> >> >> dri-devel at lists.freedesktop.org
> >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> >
> >> >
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> >
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170110/24b33a5e/attachment-0001.html>
1 - 100 of 131 matches
Mail list logo
