[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

On 02/02/2015 08:09 AM, Russell King - ARM Linux wrote: > On Mon, Feb 02, 2015 at 07:32:05AM -0500, Yang Kuankuan wrote: >> On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote: >>> On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote: Hi ykk, On Sat, Jan 31, 2015 at

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

--- +1 here -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/c05864ce/attachment-0001.html>

[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur

ory. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/644ebe3e/attachment.html>

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/90a084e9/attachment.html>

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/503c9ca8/attachment.html>

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/792f0a53/attachment.html>

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

e assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/b39ae533/attachment.html>

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: > >> My initial thought is for dma-buf to not try to prevent something than > >> an exporter can actually do.. I think the scenario you describe could > >> be handled by two

[Bug 88925] GPU lockup in XCOM with R270X

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/12053d11/attachment-0001.html>

[Bug 88925] GPU lockup in XCOM with R270X

af8fd69) * xf86-video-ati 7.5.0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/9659c1d1/attachment.html>

[Bug 88886] GPU fault detected on luxmark the Room test with AMD Tahiti

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/077638e5/attachment.html>

[Bug 88886] GPU fault detected on luxmark the Room test with AMD Tahiti

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150202/06c3a2ce/attachment.html>

[Bug 88886] GPU fault detected on luxmark luxball HDR test with AMD Tahiti

s the Room. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/4b36eb56/attachment.html>

Fwd: 3.18.3->4 : external monitor is black after wakeup of a docked system after s2ram

In the mean while I have to correct it - it is reliable. So something between 3.18.3 and 3.18.4 break a docking system configuration in that manenr, that after resume the external (iand internal X11 screen) is black. Forwarded Message Subject: 3.18.3->4 : external monitor is

[PATCH] drm/modes: Print the mode status in human readable form

From: Ville Syrjälä Currently when a mode is rejected the reason is printed as a raw number. Having to manually decode that to a enum drm_mode_status value is tiresome. Have the code do the decoding instead and print the result in a human readable format. Just

[PATCH 2/2] Add new drmOpenOnceWithType function (v2)

v2: call drmOpenOnceWithType in drmOpenOnce, and drop unused param for drmOpenOnceWithType Signed-off-by: Jammy Zhou --- xf86drm.c | 12 ++-- xf86drm.h | 1 + 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 810edfa..b5d7686 100644 ---

[PATCH 1/2] Add new drmOpenWithType function (v3)

v2: Add drmGetMinorBase, and call drmOpenWithType in drmOpen v3: Pass 'type' to drmOpenByBusid and drmOpenDevice in drmOpenByName Signed-off-by: Jammy Zhou --- xf86drm.c | 63 --- xf86drm.h | 9 - 2 files changed, 56

[RFC PATCH 0/2] Add drmOpenWithType and drmOpenOnceWithType

For DRM render nodes, they are opened with the 'open' system call directly by components such as mesa, etc now, and the minor number should be specified with the new drmOpenRender function. The following two patches add two new functions to open DRM device with the specified node type, and the

DELL Latitude e5540 Intel 4400 3rd display problem

Dear Developers/Support! I can't configure the 2nd or 3rd display on my Dell Latitude e5540 notebook and Dell NB Port Replicator. I tried to connect DVI, DP and VGA to Port Replicator and it is working only in mirror mode. The only way to use 2 external display if I connect the DVI or DP to Port

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 02, 2015 at 04:42:32PM +, Tvrtko Ursulin wrote: > > On 02/02/2015 04:32 PM, Rob Clark wrote: > >On Mon, Feb 2, 2015 at 4:41 AM, Daniel Vetter wrote: > >>On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin > >>> > >>>To be used from the new

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote: > On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux > wrote: > > On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote: > >> Quite possibly for some of these edge some of cases, some of the > >> dma-buf exporters are going to

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Mon, Feb 2, 2015 at 4:46 PM, Russell King - ARM Linux wrote: > On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: >> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: >> >> My initial thought is for dma-buf to not try to prevent something than >> >> an exporter can actually do.. I

[Bug 88886] GPU fault detected on luxmark luxball HDR test with AMD Tahiti

uts of Mesa, so it will build. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/4003153e/attachment.html>

[Bug 88886] GPU fault detected on luxmark luxball HDR test with AMD Tahiti

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/83c3651e/attachment.html>

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 02, 2015 at 10:23:57AM +, Tvrtko Ursulin wrote: > > On 02/02/2015 09:58 AM, Daniel Vetter wrote: > >On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote: > >>On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin > >>> > >>>To be used

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 02, 2015 at 10:23:57AM +, Tvrtko Ursulin wrote: > > On 02/02/2015 09:58 AM, Daniel Vetter wrote: > >On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote: > >>On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin > >>> > >>>To be used

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On 02/02/2015 04:32 PM, Rob Clark wrote: > On Mon, Feb 2, 2015 at 4:41 AM, Daniel Vetter wrote: >> On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> To be used from the new addfb2 extension. >>> >>> Signed-off-by: Tvrtko Ursulin >>> --- >>>

[RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

Hi Mauro, On Mon, 02 Feb 2015 12:57:55 -0200 Mauro Carvalho Chehab wrote: > Em Tue, 6 Jan 2015 12:43:35 +0100 > Boris Brezillon escreveu: > > > Add RGB444_1X12 and RGB565_1X16 format definitions and update the > > documentation. > > > > Signed-off-by: Boris Brezillon > > Acked-by: Mauro

[Bug 88921] X fails to start on QEMU/KVM with cirrus KMS since 3.19-rc

org/archives/dri-devel/attachments/20150202/da8831f1/attachment-0001.html>

[PATCH v2 05/12] drm: rockchip/vop: filter interlace display mode

Hi ykk, On Fri, Jan 30, 2015 at 7:29 PM, Yakir Yang wrote: > RK3288's VOP do not support INTERLACE display mode, so we should > remove those modes out of mode_ok list. > > Signed-off-by: Yakir Yang Reviewed-by: Daniel Kurtz Can you move this patch out of your hdmi audio patch set, and send

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote: >> My initial thought is for dma-buf to not try to prevent something than >> an exporter can actually do.. I think the scenario you describe could >> be handled by two sg-lists, if the exporter was clever enough. > > That's already needed,

[PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

Hi, On Fri, Jan 30, 2015 at 9:29 PM, Russell King - ARM Linux wrote: > On Fri, Jan 30, 2015 at 10:37:19AM -0500, Rob Clark wrote: >> On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar >> wrote: >> I'll also need to update the new bridge in the msm edp code.. >> although that isn't such a big deal if

[PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

Hi Rob, On Fri, Jan 30, 2015 at 9:07 PM, Rob Clark wrote: > On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar > wrote: >> Currently, third party bridge drivers(ptn3460) are dependent >> on the corresponding encoder driver init, since bridge driver >> needs a drm_device pointer to finish drm

[Bug 88891] Errors upon/resuming hibernation.

. For the record, the problem persists. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/6b194d4e/attachment.html>

[PATCH -v2] drm/exynos: track vblank events on a per crtc basis

On 01/31/2015 02:17 AM, Gustavo Padovan wrote: > 2015-01-30 Daniel Vetter : > >> On Fri, Jan 30, 2015 at 03:57:53PM +, Daniel Stone wrote: >>> Hi, >>> >>> On 30 January 2015 at 14:30, Gustavo Padovan wrote: 2015-01-30 Joonyoung Shim : > We will lose unfinished prior events by this

[PATCH] drm/exynos: don' disable hdmi clocks for exynos5420

+Cc dri-devel ML, Hi, On 01/31/2015 06:45 AM, Gustavo Padovan wrote: > From: Prathyush K > > When VPLL clock of less than 140 MHz was used and all the three > clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs > during S2R when HDMI is connected. Since we want to use a vpll >

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 2, 2015 at 11:59 AM, Daniel Vetter wrote: > On Mon, Feb 02, 2015 at 04:42:32PM +, Tvrtko Ursulin wrote: >> >> On 02/02/2015 04:32 PM, Rob Clark wrote: >> >On Mon, Feb 2, 2015 at 4:41 AM, Daniel Vetter wrote: >> >>On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: >>

[Bug 88891] Errors upon/resuming hibernation.

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150202/b4e855c6/attachment.html>

[PATCH v5 9/9] drm/exynos: add support for 'hdmi' clock

Mixed need to have hdmi clock enabled to properly perform power on/off sequences, so add handling of this clock directly to the mixer driver. Dependency between hdmi clock and mixer module has been observed on Exynos4 based boards. Suggested-by: Andrzej Hajda Reviewed-by: Javier Martinez

[PATCH v5 8/9] ARM: dts: exynos5250: add display power domain

From: Andrzej Hajda The patch adds domain definition and references to it in appropriate devices. Signed-off-by: Andrzej Hajda [mszyprow: rebased onto generic power domains dt bindings] Signed-off-by: Marek Szyprowski Tested-by: Javier Martinez Canillas Reviewed-by:

[PATCH v5 7/9] ARM: dts: Exynos: add 'hdmi' clock to mixer nodes

Mixed block needs to control hdmi clock to properly perform power on/off operation, so add 'hdmi' clock also to mixer nodes. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos5250.dtsi | 5 +++-- arch/arm/boot/dts/exynos5420.dtsi | 5 +++-- 2 files changed, 6 insertions(+), 4

[PATCH v5 6/9] ARM: dts: exynos4210-universal_c210: enable hdmi support

From: Tomasz Stanislawski This patch adds configuration of hw modules required to enable HDMI support on Universal C210 board. Signed-off-by: Tomasz Stanislawski Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos4210-universal_c210.dts | 57

[PATCH v5 5/9] ARM: dts: exynos4412-odroid: enable hdmi support

This patch adds nodes specific to Exynos4412 based Odroid X/X2/U2/U3 boards required for enabling HDMI display. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 44 + 1 file changed, 44 insertions(+) diff --git

[PATCH v5 4/9] ARM: dts: exynos4: add dependency between TV and LCD0 power domains

TV Mixer needs both TV and LCD0 domains enabled to be fully operational. This dependency is modelled by making TV power domains a sub-domain of LCD0 power domain. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos4.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v5 3/9] ARM: dts: exynos4: add hdmi related nodes

This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules found in Exynos 4210 and 4x12 SoCs. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos4.dtsi| 40 +++ arch/arm/boot/dts/exynos4210.dtsi | 8

[PATCH v5 2/9] ARM: Exynos: add support for sub-power domains

This patch adds support for making one power domain a sub-domain of other domain. This is useful for modeling power dependences for devices like TV Mixer or Camera ISP, which needs to have more than one power domain enabled to be operational. Based on previous work by Amit Daniel Kachhap .

[PATCH v5 1/9] PM / Domains: Add a note about power domain subdomains

This patch adds a note on defining subdomains to generic PM domain binding documentation to let power domain providers use common approach for defining power domain hierarchy. Signed-off-by: Marek Szyprowski Acked-by: Geert Uytterhoeven Reviewed-by: Ulf Hansson ---

[PATCH v5 0/9] Enable HDMI support on Exynos platforms

Hi all, This is yet another update on patchset, which enables HDMI support for Exynos based platforms. Beside DTS changes, this patchset adds parent domain support for Exynos PM domains and add support for 'hdmi' clock directly to Exynos DRM mixer driver. The patchset is based on

[PATCH 6/6] drm/exynos: do not copy adjusted mode into mode during crtc mode_set

Hi, On 01/30/2015 11:44 PM, Gustavo Padovan wrote: > Hi Joonyoung, > > 2015-01-30 Joonyoung Shim : > >> Hi, >> >> On 01/23/2015 09:43 PM, Gustavo Padovan wrote: >>> From: Daniel Kurtz >>> >>> The 'mode' is the modeline information which specifies the ideal mode >>> requested by the mode set

[PATCH v4 9/9] drm/exynos: add support for 'hdmi' clock

Hello, On 2015-01-22 14:00, Fabio Estevam wrote: > On Tue, Jan 20, 2015 at 10:16 AM, Marek Szyprowski > wrote: > >> + mixer_res->hdmi = devm_clk_get(dev, "hdmi"); >> + if (IS_ERR(mixer_res->hdmi)) { >> + dev_err(dev, "failed to get clock 'hdmi'\n"); >> +

[PATCH 5/6] drm/exynos: remove struct *_win_data abstraction on planes

Hi, On 01/30/2015 11:42 PM, Gustavo Padovan wrote: > Hi Joonyoung, > > 2015-01-30 Joonyoung Shim : > >> +Cc Inki, >> >> Hi, >> >> On 01/23/2015 09:42 PM, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> struct {fimd,mixer,vidi}_win_data was just keeping the same data >>> as struct

[RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats

Em Mon, 02 Feb 2015 16:32:07 +0100 Boris Brezillon escreveu: > Hi Mauro, > > On Mon, 02 Feb 2015 12:57:55 -0200 > Mauro Carvalho Chehab wrote: > > > Em Tue, 6 Jan 2015 12:43:35 +0100 > > Boris Brezillon escreveu: > > > > > Add RGB444_1X12 and RGB565_1X16 format definitions and update the >

[PATCH RFC v8 00/21] Add support for i.MX MIPI DSI DRM driver

Correct Philipp's email address in the Cc list. Liu Ying On Mon, Feb 02, 2015 at 10:17:45AM +0800, Liu Ying wrote: > Hi, > > This version has been submitted for a while. > And, it looks there is no comments on this version. > Can the maintainers consider to take this? > > Mike, any comments on

[PATCH 3/6] drm/exynos: Remove exynos_plane_dpms() call with no effect

On 01/30/2015 11:36 PM, Gustavo Padovan wrote: > 2015-01-30 Joonyoung Shim : > >> +Cc Inki, >> >> Hi, >> >> On 01/23/2015 09:42 PM, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback >>> from the underlying layer.

[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

On Mon, Feb 02, 2015 at 07:32:05AM -0500, Yang Kuankuan wrote: > On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote: > >On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote: > >>Hi ykk, > >> > >>On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan > >>wrote: > >>>On 01/31/2015 06:48 AM,

[PATCH] drm/modes: Print the mode status in human readable form

On Mon, Feb 2, 2015 at 12:13 PM, wrote: > From: Ville Syrjälä > > Currently when a mode is rejected the reason is printed as a raw number. > Having to manually decode that to a enum drm_mode_status value is > tiresome. Have the code do the decoding instead and print the result > in a human

[pull] radeon drm-fixes-3.19

Hi Dave, One last round of fixes for radeon for 3.19: - fix some fallout from the reservation object integration on the test/benchmark options - fix a crash in the gpu vm code if gfx init fails - fix a pll issue that leads to a blank screen on older IGP parts The following changes since commit

[PATCH -v2] drm/exynos: do not disable hdmi clocks for exynos5420

From: Prathyush K When VPLL clock of less than 140 MHz was used and all the three clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs during S2R when HDMI is connected. Since we want to use a vpll clock of 70.5 MHz, we cannot disable these 3 clocks before

[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

Hi ykk, On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan wrote: > > On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote: >> >>> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi) >>> +{ >>> + if (hdmi->audio_enable) >>> + return; >>> + >>> + mutex_lock(>audio_mutex);

[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote: > Hi ykk, > > On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan wrote: > > > > On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote: > >> > >>> +void hdmi_audio_clk_enable(struct dw_hdmi *hdmi) > >>> +{ > >>> + if

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 2, 2015 at 10:58 AM, Daniel Vetter wrote: > On Mon, Feb 02, 2015 at 10:23:57AM +, Tvrtko Ursulin wrote: >> >> On 02/02/2015 09:58 AM, Daniel Vetter wrote: >> >On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote: >> >>On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 2, 2015 at 4:41 AM, Daniel Vetter wrote: > On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: >> From: Tvrtko Ursulin >> >> To be used from the new addfb2 extension. >> >> Signed-off-by: Tvrtko Ursulin >> --- >> include/uapi/drm/i915_drm.h | 13 + >> 1 file

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

Hi Russell, On 30 January 2015 at 00:56, Russell King - ARM Linux wrote: > On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote: >> Quite possibly for some of these edge some of cases, some of the >> dma-buf exporters are going to need to get more clever (ie. hand off >> different

[Bug 88877] Invisible Chrome windows on radeonsi with KWin compositing

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/b84f5c01/attachment.html>

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

236 to 248 bit times for every 16 bytes of EDID. This is 1.84 to 1.94 bit times per payload bit transferred, for a payload bit rate between 516.1 kbit/s and 542.3 kbit/s. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/ba6d5cbf/attachment.sig>

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote: > On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > To be used from the new addfb2 extension. > > > > Signed-off-by: Tvrtko Ursulin > > --- > > include/uapi/drm/i915_drm.h | 13

[PATCH v3] drm/rockchip: vop: power off until vop standby take effect

Vop standby will take effect at end of current frame, if dsp_hold_valid_irq happen, it means vop standby complete. we must wait standby complete when we want to disable aclk, if not, memory bus maybe dead. Reviewed-by: Heiko Stuebner Reviewed-by: Daniel Kurtz Signed-off-by: Mark Yao ---

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > To be used from the new addfb2 extension. > > Signed-off-by: Tvrtko Ursulin > --- > include/uapi/drm/i915_drm.h | 13 + > 1 file changed, 13 insertions(+) > > diff --git

[PATCH] drm/rockchip: vop: power off until vop standby take effect

On 2015年02月02日 10:07, Daniel Kurtz wrote: > Hi Mark, Heiko, > > On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao wrote: >> Vop standby will take effect end of current frame, >> if dsp_hold_valid_irq happen, it means vop standby complete. >> >> we must wait standby complete when we want to disable

[Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers

On 02/02/2015 09:58 AM, Daniel Vetter wrote: > On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote: >> On Fri, Jan 30, 2015 at 05:36:54PM +, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> To be used from the new addfb2 extension. >>> >>> Signed-off-by: Tvrtko Ursulin >>>

[PATCH RFC v8 00/21] Add support for i.MX MIPI DSI DRM driver

Hi, This version has been submitted for a while. And, it looks there is no comments on this version. Can the maintainers consider to take this? Mike, any comments on patch 01/21? It's a clock driver change. Regards, Liu Ying On Wed, Dec 31, 2014 at 04:23:18PM +0800, Liu Ying wrote: > Hi, > >

[PATCH] drm/rockchip: fix clk enable disable mismatch in vop_crtc_mode_set

On Sat, Jan 31, 2015 at 5:43 PM, Heiko Stübner wrote: > Am Samstag, 31. Januar 2015, 13:43:23 schrieb Daniel Kurtz: >> Hi Heiko, >> >> On Sat, Jan 31, 2015 at 3:28 AM, Heiko Stübner wrote: >> > The function disables the dclk at the beginning, so don't simply return >> > when an error happens,

[PULL] drm-amdkfd-fixes

Hi Dave, Final pull request for 3.19. Three small fixes that came up during last week, nothing scary: - Accidently incremented a counter instead of decrementing it (copy-paste error) - Module parameter of max num of queues must be at least 1 and not 0 - Don't do BUG() as a result from wrong

[PATCH] drm/rockchip: vop: power off until vop standby take effect

Hi Mark, Heiko, On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao wrote: > Vop standby will take effect end of current frame, > if dsp_hold_valid_irq happen, it means vop standby complete. > > we must wait standby complete when we want to disable aclk, > if not, memory bus maybe dead. > > Signed-off-by:

Kernel 3.19rc6 flooding intel_check_page_flip warnings when using compton

On 02/02/2015 01:35 AM, Sakari Kapanen wrote: > I don't see this on the current stable 3.18.5 kernel. The first time I > saw this was on 3.19rc3 when I tried it due to another bug in the 3.18 > series. I haven't gone through all the 3.19 release candidates, but > the behaviour with 3.19rc6

[PATCH v2] drm/rockchip: vop: power off until vop standby take effect

Vop standby will take effect end of current frame, if dsp_hold_valid_irq happen, it means vop standby complete. we must wait standby complete when we want to disable aclk, if not, memory bus maybe dead. Reviewed-by: Heiko Stuebner Signed-off-by: Mark Yao --- Changes in v2: - use WARN_ON

[PATCH] drm/rockchip: vop: power off until vop standby take effect

On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote: > On 2015年02月02日 10:07, Daniel Kurtz wrote: > >Hi Mark, Heiko, > > > >On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao wrote: > >>Vop standby will take effect end of current frame, > >>if dsp_hold_valid_irq happen, it means vop standby

[PATCH] drm/rockchip: vop: power off until vop standby take effect

On 2015年01月31日 20:49, Heiko Stübner wrote: > Hi Mark, > > Am Samstag, 31. Januar 2015, 16:41:38 schrieb Mark Yao: >> Vop standby will take effect end of current frame, >> if dsp_hold_valid_irq happen, it means vop standby complete. >> >> we must wait standby complete when we want to disable

[PATCH v2 0/12] Those patches is used for dw_hdmi audio support

On 01/31/2015 07:00 AM, Russell King - ARM Linux wrote: > On Fri, Jan 30, 2015 at 06:23:51AM -0500, Yakir Yang wrote: >> We found Designware hdmi driver only support audio clock config, we can not >> play sound through it. >> To add Designware HDMI Audio support, we make those patch set: >>

[PATCH v2 01/12] drm: bridge/dw_hdmi: adjust n/cts setting order

On 01/31/2015 06:07 AM, Russell King - ARM Linux wrote: > On Fri, Jan 30, 2015 at 06:25:30AM -0500, Yakir Yang wrote: >> For Designerware HDMI, the following write sequence is recommended: >> 1. aud_n3 (set bit ncts_atomic_write if desired) >> 2. aud_cts3 (set CTS_manual and CTS value if

[PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote: > On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote: >> Hi ykk, >> >> On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan >> wrote: >>> On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote: > +void hdmi_audio_clk_enable(struct

[Bug 88877] Invisible Chrome windows on radeonsi with KWin compositing

d against using that, because it doesn't have proper Present extension support. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachme

[PATCH v2 05/12] drm: rockchip/vop: filter interlace display mode

On 02/02/2015 03:00 AM, Daniel Kurtz wrote: > Hi ykk, > > On Fri, Jan 30, 2015 at 7:29 PM, Yakir Yang wrote: >> RK3288's VOP do not support INTERLACE display mode, so we should >> remove those modes out of mode_ok list. >> >> Signed-off-by: Yakir Yang > > Reviewed-by: Daniel Kurtz > > Can you

Kernel 3.19rc6 flooding intel_check_page_flip warnings when using compton

Dear maintainers, On an Asus Zenbook UX32VD laptop with an i5-3317U CPU and Intel HD4000 graphics, I'm experiencing the following with the latest 3.19rc6 mainline kernel (built from the Arch Linux AUR package: https://aur.archlinux.org/packages/linux-mainline/ ). The problem is related to the

[PATCH 2/2] libdrm: add drmGetNodeType() helper

The add a simple helper which returns the node type of the opened fd. Likely to be used in conjunction with the previous two helpers. Cc: Daniel Vetter Cc: David Herrmann Signed-off-by: Emil Velikov --- xf86drm.c | 43 +++ xf86drm.h | 7 +++ 2

[PATCH 1/2] drm: add drmGet{Device, Render}NameFrom{Render, Device}Fd helpers

Currently most places assume reliable primary <> render node mapping. Although this may work in some cases, it is not correct. Add a couple of helpers that hide the details and safes all the guesswork for the user. Cc: Daniel Vetter Cc: David Herrmann Signed-off-by: Emil Velikov ---

[RFC PATCH 0/2] libdrm: Add master <> render node helpers

Hi all, As mentioned a couple of days ago at #dri-devel some(most) users of render nodes tend to rely on strict mapping between the primary and render node. I.e. something along the lines of fstat(render_fd, ); sprintf(primary_node, "/dev/dri/card%d", ((sbuf.st_rdev