P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.
Signed-off-by: Randy Li
drm
---
Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently,
the VOP(video output mixer) found on RK3288 and future support
those 10 bits pixel formats are input. Also the decoder on RK3288
could use them as output.
The fourcc is not enough to store the endian information for those
pixel
On 01/04/2017 11:56 PM, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
>> per channel video format. Rockchip's vop support this
>> video format(little endian only) as the input video format.
>>
>>
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decode
a well-defined interface, so
the software doesn't need to know
:: The code at line 5 was first introduced by commit
:: f7018c21350204c4cf628462f229d44d03545254 video: move fbdev to
drivers/video/fbdev
:: TO: Tomi Valkeinen
:: CC: Tomi Valkeinen
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18633 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/3e83c6a4/attachment-0001.gz>
.
--
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/20170105/3fab988f/attachment.html>
Hi Jose,
On Tuesday 20 Dec 2016 15:01:52 Jose Abreu wrote:
> On 20-12-2016 13:11, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote:
> >> On 20-12-2016 01:33, Laurent Pinchart wrote:
> >>> Detect the PHY type and use it to handle the PHY type-specific SVSRET
> >>> signal
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/usb/Kconfig:39:error: recursive dependency detected!
drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETO
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/48876051/attachment.html>
iving 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/20170105/6ef97f56/attachment.html>
iving 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/20170105/265816ef/attachment.html>
.
--
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/20170105/5167c824/attachment.html>
The issue was recorded in fd.o bug 27501, not 25701.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ra
application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/ffbb710e/attachment.sig>
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed
Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.
Signed-off-by: Hoegeun Kw
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
.../bindings/display/panel/
The OF graph is not necessary because the panel is a child of
dsi. therefore, the parse_dt function of dsi does not need to
check the remote_node connected to the panel. and the whole
parse_dt function should be refactored later.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2
On 04.01.2017 15:44, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee
On 05.01.2017 07:45, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> T
On Wed, Dec 28, 2016 at 9:37 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_
On Wed, Dec 28, 2016 at 9:37 PM, Shawn Guo wrote:
> 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 control
On Wed, Dec 28, 2016 at 9:37 PM, Shawn Guo wrote:
> 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
> cur
On Fri, Dec 30, 2016 at 4:57 AM, Marek Szyprowski
wrote:
> Analogix_dp_bind() can be called from component framework, which doesn't
> guarantee proper runtime PM state of the device during bind operation,
> so ensure that device is runtime active before doing any register access.
> This ensures th
2017ë
01ì 05ì¼ 15:55ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 04.01.2017 15:44, Rob Herring wrote:
>> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>> driver. This panel has 1440x2560 resolution in 5.7-inch ph
On Wed, Jan 04, 2017 at 03:26:48PM -0500, Alex Deucher wrote:
> On Wed, Jan 4, 2017 at 11:11 AM, Daniel Vetter wrote:
> > On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote:
> >> I was lazy, rectify that! Also align with drm_atomic_state_get/put for
> >> ocd.
> >>
> >> v2: Git add helps
On Wed, Jan 04, 2017 at 04:36:50PM +, Grodzovsky, Andrey wrote:
> > > +/**
> > > + * drm_atomic_helper_page_flip - execute a legacy page flip
> > > + * @crtc: DRM crtc
> > > + * @fb: DRM framebuffer
> > > + * @event: optional DRM event to signal upon completion
> > > + * @flags: flip flags for
On Wed, Jan 04, 2017 at 02:24:51PM -0800, Randy Dunlap wrote:
> On 01/04/17 11:29, Jani Nikula wrote:
> > On Wed, 04 Jan 2017, Daniel Vetter wrote:
> >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> >>> From: Randy Dunlap
> >>>
> >>> Fix build errors in nouveau driver when CONFI
On Thu, Jan 05, 2017 at 03:54:54AM +, Pandiyan, Dhinakaran wrote:
> On Wed, 2017-01-04 at 19:20 +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote:
> > > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> > > > Link bandwidth is sha
On Thu, 05 Jan 2017, Lyude wrote:
> Until now, it seems we've been erroneously enabling limited color ranges
> for the vast majority of DisplayPort monitors. I noticed this after
> writing a frame dump comparison test for the Chamelium and noticing that
> every i915 device I had was failing, while
On Wed, Jan 04, 2017 at 02:00:53PM +0200, Peter Ujfalusi wrote:
> Instead of scheduling the work to handle the initial delayed event, use 1s
> delay.
>
> When the delayed event is handled w/o delay - in a similar matter when the
> poll had been initialized before drm_helper_probe_single_connector_
On Wed, Jan 04, 2017 at 01:44:56PM -0200, Fabio Estevam wrote:
> 'ret' is never used in tve_enable/tve_disable(), so just
> remove it.
>
> Signed-off-by: Fabio Estevam
Applied to drm-misc, thx.
-Daniel
> ---
> drivers/gpu/drm/imx/imx-tve.c | 11 +++
> 1 file changed, 3 insertions(+), 8
On Wed, Jan 04, 2017 at 07:15:34PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:24, Ville Syrjälä wrote:
> > From: Ville Syrjälä
> >
> > Allow drivers to return a custom drm_format_info structure for special
> > fb layouts. We'll use this for the compression control surface in i915.
> >
>
On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> No matter what we do here, the question remains what to do with
> Chamelium. Changing the color range is really a workaround for
> Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.
Can we just set a non-CEA mode/edid
help confirm.
--
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/20170105/e1ad4985/attachment-0001.html>
roblem to openSuse.
--
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/20170105/642a40cc/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/1e2fdec2/attachment.html>
Hi,
On 5 January 2017 at 08:52, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
>> No matter what we do here, the question remains what to do with
>> Chamelium. Changing the color range is really a workaround for
>> Chamelium, not a fix. Using CEA range is perf
2017ë
01ì 02ì¼ 17:39ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> In case of HW trigger mode, sysreg register should be configured to
> enable TE functionality. The patch refactors also trigger setup function.
>
> Signed-off-by: Andrzej Hajda
> ---
> v2: fixed bitop operator (thanks Ilia)
> ---
>
On 05.01.2017 11:05, Inki Dae wrote:
>
> 2017ë
01ì 02ì¼ 17:39ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> In case of HW trigger mode, sysreg register should be configured to
>> enable TE functionality. The patch refactors also trigger setup function.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> v2:
2017ë
01ì 05ì¼ 19:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 05.01.2017 11:05, Inki Dae wrote:
>>
>> 2017ë
01ì 02ì¼ 17:39ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> In case of HW trigger mode, sysreg register should be configured to
>>> enable TE functionality. The patch refactors also trig
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Change for V7:
- Fixed the mode_set callback function of mic device driver.
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2
Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.
Signed-off-by: Hoegeun Kw
The OF graph is not necessary because the panel is a child of
dsi. therefore, the parse_dt function of dsi does not need to
check the remote_node connected to the panel. and the whole
parse_dt function should be refactored later.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_
On Thu, 05 Jan 2017, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
>
Hi Randy,
Thanks for the update.
On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> The formats added by this patch are:
> V4L2_PIX_FMT_P010
> V4L2_PIX_FMT_P010M
> V4L2_PIX_FMT_P016
> V4L2_PIX_FMT_P016M
> Currently, none of driver uses those format, but some video
On 05.01.2017 11:19, Inki Dae wrote:
>
> 2017ë
01ì 05ì¼ 19:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> On 05.01.2017 11:05, Inki Dae wrote:
>>> 2017ë
01ì 02ì¼ 17:39ì Andrzej Hajda ì´(ê°) ì´ ê¸:
In case of HW trigger mode, sysreg register should be configured to
enable TE func
Hi Jani,
On Thu, 05 Jan 2017 12:24:13 +0200 Jani Nikula
wrote:
>
> Daniel reverted it in drm-misc.
OK, thanks.
--
Cheers,
Stephen Rothwell
2017ë
01ì 05ì¼ 19:35ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 05.01.2017 11:19, Inki Dae wrote:
>>
>> 2017ë
01ì 05ì¼ 19:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> On 05.01.2017 11:05, Inki Dae wrote:
2017ë
01ì 02ì¼ 17:39ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> In case of HW tri
|--- |FIXED
--
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/20170105/95bf2eb5/attachment.html>
Use CRC API to retrieve the 3 crc values from hardware.
Signed-off-by: Benjamin Gaignard
---
This patch should be applied on top of drm-misc branch where Tomeu
has change crc.lock.
I think that wake_up_interruptible() could also be call at the end
of drm_crtc_add_crc_entry() to avoid putting it
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/6bbb7388/attachment-0001.html>
Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
Here's a bunch of drm/i915 fixes for v4.10-rc3. It includes GVT-g fixes,
which apparently have a conflict with Alex's (Cc'd) upcoming vfio
changes [1]. So heads up.
My new year's resolution is to start using signed tags for pulls. If
tha
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/a2bcfee5/attachment.html>
On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker
>
> This adds fourcc codes for 16bit planes required for DRM buffer
> export to mesa.
>
> Signed-off-by: Rainer Hochecker
Reviewed-by: Ville Syrjälä
> ---
> include/uapi/drm/drm_fourcc.h | 7 +++
On Wed, 04 Jan 2017, Thomas Hellstrom wrote:
> What is the general opinion about out-of-tree static analyzer
> annotations in drm driver code, for example comments like
>
> /* coverity[missing_lock] */
>
> which typically squelches false positives in constructors or destructors
> of refcounted str
Hi Jose,
On Thursday 05 Jan 2017 10:33:55 Jose Abreu wrote:
> On 05-01-2017 00:15, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 15:01:52 Jose Abreu wrote:
> >> On 20-12-2016 13:11, Laurent Pinchart wrote:
> >>> On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote:
> On 20-12-2016 01:33, Lau
Hi,
Could you please add:
git://github.com/bzolnier/linux.git fbdev-for-next
To the linux-next tree?
Linus has recently accepted u pull request from the fbdev-v4.10-rc2
tag that added fbdev subsystem back into Maintained mode (with me as
Maintainer).
Thanks!
Best regards,
--
Bartlomiej Zolni
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:01PM +, Jose Abreu wrote:
> >>
>
> [snip]
>
> >>> Why does userspace need to know this? My thinking has been that the
> >>> driver wou
TML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/02395b95/attachment.html>
|--- |FIXED
--
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/20170105/12fb7c93/attachment.html>
Hi,
On 01/05/2017 12:38 PM, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Thomas Hellstrom wrote:
>> What is the general opinion about out-of-tree static analyzer
>> annotations in drm driver code, for example comments like
>>
>> /* coverity[missing_lock] */
>>
>> which typically squelches false posi
On 05.01.2017 11:20, Hoegeun Kwon wrote:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
>
> Signed-off-by: H
Hi Jose,
On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> > On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> >> Instead of spreading version-dependent PHY power handling code around,
> >> group it in two functions to powe
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/3049ad9b/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/907e3e07/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20170105/dfa07dac/attachment.html>
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs.
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.
Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store t
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files c
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +
1 fil
This backpointer allows DP helpers to access the connector it's being
used for.
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 55bbeb0ff594..4fa77b434594 100644
---
Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.
v2: Reuse drm_crtc_wait_one_vblank
Update l
Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
>> From: Rainer Hochecker
>>
>> This adds fourcc codes for 16bit planes required for DRM buffer
>> export to mesa.
>>
>> Signed-off-by: Rainer Hochecker
> Reviewed-by: Ville Syrjäl
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/286f8e56/attachment.html>
On Mon, Jan 02, 2017 at 01:59:10PM +0100, Tomeu Vizoso wrote:
> Don't return from the open() call on the crc/data file until the HW has
> produced a first frame, as there's great variability in when the HW is
> able to do that and userspace shouldn't have to guess when this specific
> HW is ready t
On Thu, Jan 05, 2017 at 12:12:36PM +0100, Benjamin Gaignard wrote:
> Use CRC API to retrieve the 3 crc values from hardware.
>
> Signed-off-by: Benjamin Gaignard
> ---
> This patch should be applied on top of drm-misc branch where Tomeu
> has change crc.lock.
>
> I think that wake_up_interruptib
On Wed, Jan 04, 2017 at 08:25:23PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:32, Ville Syrjälä 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 locat
On Wed, Jan 04, 2017 at 05:14:04PM -0200, Paulo Zanoni wrote:
> Em Qua, 2017-01-04 Ã s 20:42 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved
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 location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
Hi Daniel
I come to the conclusion that (only) Atomic Weston will solve all of my
troubles, so let's forget these patches (and work for atomic weston).
By the way, is the expected behavior (Vblank - sync'ed or not) of
drmModeSetPlane() described anywhere? The last time I browsed the
related d
Hi Jose,
On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> On 05-01-2017 12:29, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>
Hi,
recently I noticed that VT console doesn't work any longer when I dock
a Dell E7270 laptop with a DP monitor. The bug detail is like this:
At first, I boot the laptop without dock. I can switch between X and
VT via ctrl-alt-F1, so far. Then I dock it to a docking station
connected with a D
hour, but we
typically leave it overnight and find it hung in the morning).
--
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/atta
On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> Hi,
>
> recently I noticed that VT console doesn't work any longer when I dock
> a Dell E7270 laptop with a DP monitor. The bug detail is like this:
>
> At first, I boot the laptop without dock. I can switch between X and
> VT via
On Thu, 05 Jan 2017 16:59:31 +0100,
Ville Syrjälä wrote:
>
> On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> > Hi,
> >
> > recently I noticed that VT console doesn't work any longer when I dock
> > a Dell E7270 laptop with a DP monitor. The bug detail is like this:
> >
> > At
On 04/01/2017 18:42, ville.syrjala at linux.intel.com 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 location of the color control surfae (CCS) which describes
On Thu, Jan 05, 2017 at 05:19:58PM +0100, Takashi Iwai wrote:
> On Thu, 05 Jan 2017 16:59:31 +0100,
> Ville Syrjälä wrote:
> >
> > On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote:
> > > Hi,
> > >
> > > recently I noticed that VT console doesn't work any longer when I dock
> > > a D
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/358aa55a/attachment.html>
On Mon, Jan 02, 2017 at 05:01:03PM +0530, vathsala nagaraju wrote:
> PSR1 and PSR2 enable sequence are mutually exclusive.
> Register SRD_PERF_COUNT increments while system is in psr1.
> This register is not valid for psr2.while in psr2,SRD_PERF_COUNT
> is always 0.
> Reporting psr perfcount from S
On 17-01-05 16:24:56, Tvrtko Ursulin wrote:
>
>On 04/01/2017 18:42, ville.syrjala at linux.intel.com 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 location of
OK, so I got this far, although I stuffed two patches in the middle
(which I should probably pull to the beginning and did this one patch
differently.
I've not really tested the result yet, will attempt to do so tomorrow.
Please have a look at the current state of things here:
git://git.kern
I like this live status!
On Mon, Jan 02, 2017 at 05:01:02PM +0530, vathsala nagaraju wrote:
> Reports live state of PSR2 form PSR2_STATUS register.
> bit field 31:28 gives the live state of PSR2.
> It can be used to check if system is in deep sleep,
> selective update or selective update standby
On Mon, Jan 02, 2017 at 05:01:01PM +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
> is implemented,this restriction is removed so that psr2
> can work on panels without y cordinate support.
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-o
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170105/4a9310bb/attachment.html>
org/archives/dri-devel/attachments/20170105/d2b796a8/attachment.html>
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/20170105/c9d036a5/attachment.html>
1 - 100 of 152 matches
Mail list logo
