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 10:34
---
+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>
memory.
--
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>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/90a084e9/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/503c9ca8/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/792f0a53/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/b39ae533/attachment.html>
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 sg-lists,
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/12053d11/attachment-0001.html>
0.5.0-devel (git-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>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/077638e5/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150202/06c3a2ce/attachment.html>
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>
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 bl
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 having an array of strings indexe
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
--- a/xf86dr
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 insertions
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 m
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 R
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 ad
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 n
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
heckouts 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>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/83c3651e/attachment.html>
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 fr
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 fr
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
>>> ---
>>> inclu
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 Car
ktop.org/archives/dri-devel/attachments/20150202/da8831f1/attachment-0001.html>
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 i
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, each
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
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 initiali
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>
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 ch
+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
> cloc
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:
>> >
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150202/b4e855c6/attachment.html>
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 Canillas
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: Javier Martinez Canillas
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 deletions
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 +
1 file changed,
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 a/arch/arm/boot/dts/exy
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 a/arch/arm/boot/
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
arch/arm/boot/dts/exynos4
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 .
Signed
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
---
.../devicetree/bindings/powe
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 samsung/for-nex
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 ini
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");
>> + re
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 exyno
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
>
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
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. However
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, Ru
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 rea
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 a7
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 suspending. This patch add
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(&hdmi->audio_mute
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 (hdmi->audio_en
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 Ursuli
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
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 scatterlis
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150202/b84f5c01/attachment.html>
it/s and 69.0 kbit/s.
At 16 bytes per request, we're using 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>
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 +++
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
---
Change
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 a/include/uapi/drm/i
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 a
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
>>> --
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,
>
>
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, b
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 user
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:
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 seem
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 instead
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 compl
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
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:
>> 1):
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 desired/e
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
ommend 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-deve
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 m
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
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 files
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
---
xf86drm.c
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, &sbuf);
sprintf(primary_node, "/dev/dri/card%d",
((sbuf.st_
87 matches
Mail list logo
