On Wed, Apr 23, 2014 at 10:22 PM, Pavel Machek wrote:
> After update to 3.15-rc2, only top 20% of screen works on X.
>
> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> Integrated Graphics Controller (rev 03)
>
> 00:02.1 Display controller: Intel Corporation 4 Series Chipse
Hi!
After update to 3.15-rc2, only top 20% of screen works on X.
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
Subsyst
On Wed, Apr 23, 2014 at 10:04:00AM -0700, Matt Roper wrote:
> Pull the parameter checking from drm_primary_helper_update() out into
> its own function; drivers that provide their own setplane()
> implementations rather than using the helper may still want to share
> this parameter checking logic.
>
ives/dri-devel/attachments/20140423/ff641e25/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/32d89040/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/73a14bdc/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/5c84b337/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/c9b78537/attachment.html>
On Wed, Apr 23, 2014 at 11:26:04AM -0700, Matt Roper wrote:
> On Wed, Apr 23, 2014 at 08:03:50PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote:
> > > The DRM core setplane code should check that the plane is usable on the
> > > specified CRTC before call
is 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/20140423/7038db9b/attachment.html>
I tried it with "NoAccel" "False" and "AccelMethod"
"glamor" but it just freezes my X on startup. :)
--Maik
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
&
On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote:
> The DRM core setplane code should check that the plane is usable on the
> specified CRTC before calling into the driver.
>
> Prior to this patch, a plane's possible_crtcs field was purely
> informational for userspace and was never actu
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
> So, maybe you would like to finally address *my* point about TDA998x
> and your solution in a way that provides a satisfactory answer. *Show*
> how it can be done, or *outline* how it can be done.
Let me be absolutely cle
On Wednesday 23 April 2014 07:54:17 Dave Airlie wrote:
> On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds
> wrote:
> > Dave, mind sending me a pull request for drm fixes?
> >
> > There's now at least these two:
> >
> > - "drm/radeon/aux: fix hpd assignment for aux bus"
> > - "drm/radeon: use fixe
On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote:
> On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
> > Yes, I know that you're desperate to play that down, but you can't get
>
> Not true. I only try to find the best solution and the approach with
> multiple re-probing just to
The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:
- The core holds a reference for both the new and the old fb (i
Hi Jean-Jacques,
Am Freitag, den 18.04.2014, 11:45 +0200 schrieb Jean-Jacques Hiblot:
> Hi,
>
> this patch serie implements a simple DRM driver for the ATMEL High end LCD
> controller found in the SAMA5 familly. It's based on the tilcdc driver.
> It uses the cma_helper for memory and fbdev stuff.
Dave Airlie wrote:
> On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds
> wrote:
>> Dave, mind sending me a pull request for drm fixes?
>>
>> There's now at least these two:
>>
>> - "drm/radeon/aux: fix hpd assignment for aux bus"
>> - "drm/radeon: use fixed PPL ref divider if needed"
>>
>> that
On Wed, Apr 23, 2014 at 4:45 PM, Matt Roper
wrote:
>> @@ -177,22 +176,7 @@ int drm_primary_helper_update(struct drm_plane *plane,
>> struct drm_crtc *crtc,
>> set.connectors = connector_list;
>> set.num_connectors = num_connectors;
>>
>> - /*
>> - * set_config() adjusts crtc
On Wed, 23 Apr 2014, Thierry Reding wrote:
> From: Thierry Reding
>
> Commit 9dc4056026e0 (drm/dp: let drivers specify the name of the I2C-
> over-AUX adapter) introduced a new field but didn't add the proper
> kernel-doc for it.
Thanks for fixing this.
Reviewed-by: Jani Nikula
> Signed-off-b
On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
> On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
>> On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
>>> On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the dev
On Wed, Apr 23, 2014 at 03:40:46PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> To implement hotplug detection in a race-free manner, drivers must call
> drm_kms_helper_poll_init() before hotplug events can be triggered. Such
> events can be triggered right after any of the encoders or
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/20140423/59e30fdd/attachment.html>
From: Thierry Reding
Commit 9dc4056026e0 (drm/dp: let drivers specify the name of the I2C-
over-AUX adapter) introduced a new field but didn't add the proper
kernel-doc for it.
Signed-off-by: Thierry Reding
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/inc
merged patch.
--
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/20140423/6bf80fd7/attachment.html>
Book? Afaik kerneldoc
> > > unfortunately lacks any form of markup, at least afaik :(
> >
> > I must admit I didn't check. I'll make sure I do that before sending out
> > the next version.
>
> If it looks ugly I'm ok as-is, just wondered. Kerneldoc is
eon and test it
--
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/20140423/034d0931/attachment-0001.html>
From: Thierry Reding
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the drm_fb_helper_hotplu
h the entire split-up of these core drm functions is
> still a bit messy, so I don't mind if it's a bit inconsistent really. We
> can do the suffling when someone bothers with the kerneldoc for all of
> them and pulls it into the drm docbook.
I ended up doing exactly that when I wrote the drm_set_unique() docbook
pieces and I've sent out patches based on top of v2 of this patch just
now.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/845e6645/attachment.sig>
From: Thierry Reding
With the recent addition of the drm_set_unique() function, devices can
now be registered without requiring a drm_bus. Add a brief description
to the DRM docbook to show how that can be achieved.
Signed-off-by: Thierry Reding
---
Documentation/DocBook/drm.tmpl | 29
From: Thierry Reding
Describe how devices are registered using the drm_*_init() functions.
Adding this to docbook requires a largish set of changes to the comments
in drm_{pci,usb,platform}.c since they are doxygen-style rather than
proper kernel-doc and therefore mess with the docbook generation
From: Thierry Reding
Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().
Signed-off-by: Thierry Reding
---
Changes
On 04/23/2014 02:55 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
>> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
>>> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patc
In Matt Ropers primary plane series a set of prep patches like
commit af2b653bfb4ef40931b4d101ca842ce0c5da57ef
Author: Matt Roper
Date: Tue Apr 1 15:22:32 2014 -0700
drm/i915: Restrict plane loops to only operate on overlay planes (v2)
ensured that all exisiting users of the mode_config->
On Wed, Apr 23, 2014 at 11:07 AM, Alexandre Courbot
wrote:
> On 04/22/2014 07:40 PM, Thierry Reding wrote:
>>
>> * PGP Signed by an unknown key
>>
>>
>> On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote:
>> [...]
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a
Hi Andrzej,
On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> > On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> >> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> >>> This patch adds DT bindings for s6e3fa0 panel.
> >>> The bindin
On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> This patch adds DT bindings for s6e3fa0 panel.
>>> The bindings describes panel resources, display timings and cpu timings.
>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/5eb0751b/attachment.html>
Hi Andrzej,
On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> > This patch adds DT bindings for s6e3fa0 panel.
> > The bindings describes panel resources, display timings and cpu timings.
> >
> > Changelog v2:
> > - Adds unit address (comment
This adds 4 more functions to deal with rcu.
reservation_object_get_fences_rcu() will obtain the list of shared
and exclusive fences without obtaining the ww_mutex.
reservation_object_wait_timeout_rcu() will wait on all fences of the
reservation_object, without obtaining the ww_mutex.
reservatio
Hi
On Wed, Apr 23, 2014 at 10:40 AM, Daniel Vetter wrote:
> On Wed, Apr 23, 2014 at 09:17:16AM +0200, Thierry Reding wrote:
>> On second thought, wouldn't this be better located in drm_stub.c? It
>> isn't really related to the IOCTL code except that one of the IOCTLs now
>> uses the information s
Hi again Andrzej,
On 04/23/2014 10:01 AM, YoungJun Cho wrote:
> Hi Andrzej
>
> Thank you for comments.
>
> On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
>> Hi YoungJun,
>>
>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>>> Some phy control registers are not kept after software reset.
>>> So this pa
On Wed, Apr 23, 2014 at 12:26:53PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Next pull request, this time more of the drm de-midlayering work. The big
> thing is that his patch series here removes everything from drm_bus except
> the set_busid callback. Thierry has a few more patches on top of th
Hi Dave,
Next pull request, this time more of the drm de-midlayering work. The big
thing is that his patch series here removes everything from drm_bus except
the set_busid callback. Thierry has a few more patches on top of this to
make that one optional to.
With that we can ditch all the non-pci
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
>
> Changelog v2:
> - Declares delay, size properties in probe routine instead of DT
> Changelog v3:
> - Moves CPU timings relevant properties from FIMD DT
>
https://bugzilla.kernel.org/show_bug.cgi?id=74401
Ja?a Bartelj changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Apr 23, 2014 at 08:03:50PM +0200, Daniel Vetter wrote:
> On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote:
> > The DRM core setplane code should check that the plane is usable on the
> > specified CRTC before calling into the driver.
> >
> > Prior to this patch, a plane's possibl
On 04/22/2014 07:40 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
> [...]
>> +
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu timings.
>
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properties (c
On Wed, Apr 23, 2014 at 09:17:16AM +0200, Thierry Reding wrote:
> On Tue, Apr 22, 2014 at 05:48:07PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Add a helper function that allows drivers to statically set t
On Wed, Apr 23, 2014 at 09:27:58AM +0200, Thierry Reding wrote:
> On Tue, Apr 22, 2014 at 10:44:20PM +0200, Daniel Vetter wrote:
> [...]
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 589e865832cd..7cf407bbfed5 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/d
The ->disable_plane hook always had a return value, but only since the
introduction of primary planes was there any implementation that
actually failed.
So handle such failures correctly.
Note that drm_plane_force_disable is special: In the modeset cleanup
case we first disable all crtc, so prima
The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:
- The core holds a reference for both the new and the old fb (i
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
> from the one in Exynos4 SoC.
>
> In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
> and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
> So this
Hi Andrzej
Thank you for comment.
On 04/22/2014 11:02 PM, Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> This patch adds DT bindings for s6e3fa0 panel.
>> The bindings describes panel resources, display timings and cpu timings.
>>
>> Changelog v2:
>> - Adds unit address (co
Hi Thierry
Thank you for the comments.
On 04/22/2014 04:34 PM, Thierry Reding wrote:
> On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote:
> [...]
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index 7209df1..244d197 100644
>> --- a/include/drm/drm_mipi_dsi.h
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
V
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.
Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually verified at the
kernel level (aside from the primary plane helper
Hi Andrzej
Thank you for comments.
On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
> Hi YoungJun,
>
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
>> Some phy control registers are not kept after software reset.
>> So this patch makes the clocks containing phy control to be set
>> after software rese
something after the panel has been enabled
and we'll have to introduce .post_enable() and .pre_disable() functions.
And worse, what if somebody needs something to be done between
.pre_enable() and .enable()? .post_pre_enable()? Where does it end?
According to the above description the only reason why we need this is
to avoid visible glitches when the panel is already on, but the video
stream hasn't started yet. If that's the only reason why we need this,
then perhaps adding a way for a panel to expose the associated backlight
would be better?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/380c83b6/attachment.sig>
On 04/23/2014 05:45 AM, YoungJun Cho wrote:
> Hi again Andrzej,
>
> On 04/23/2014 10:01 AM, YoungJun Cho wrote:
>> Hi Andrzej
>>
>> Thank you for comments.
>>
>> On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
>>> Hi YoungJun,
>>>
>>> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
Some phy control
On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote:
> On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
> [...]
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
>
t did not updated DT bindings.
I've been working on a patch to support both *-gpios and *-gpio variants
with the GPIO descriptor framework. *-gpios makes sense if there can
indeed be several, but for something like hotplug detection I don't
think there's a reason to require the pl
On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote:
> Hi Thierry,
>
>
> On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding
> wrote:
> > On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote:
> >> Most of the panels need an init sequence as mentioned below:
> >> -- poweron LCD uni
adeon/radeon_device.c | 11 ++-
> include/drm/drmP.h | 2 +-
> 4 files changed, 19 insertions(+), 16 deletions(-)
Looks good:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/ba02a92b/attachment.sig>
ype: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/bc29b1c4/attachment.sig>
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/c7a12b87/attachment.html>
ction. Logically I think it belongs
with the likes of drm_dev_alloc() and drm_dev_register().
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/88e318bb/attachment.sig>
ok sane in the generated DocBook? Afaik kerneldoc
> unfortunately lacks any form of markup, at least afaik :(
I must admit I didn't check. I'll make sure I do that before sending out
the next version.
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/dc7ba188/attachment.sig>
On Wed, Apr 23, 2014 at 05:37:30PM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new rule
part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-count-in-uvd_v1_0_ring_test.patch
Type: text/x-patch
Size: 1035 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/18ddbecc/attachment-0001.bin>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/0d0e02f1/attachment.html>
On Wed, Apr 23, 2014 at 8:36 AM, Daniel Vetter
wrote:
> Hm, that's indeed a bit fishy. Otoh I don't understand how this blows
> up with existing userspace since we should only hit this if userspace
> does an explicit disable call on the primary plane through the ioctl.
> It's a bug for sure thoug
On Wed, Apr 23, 2014 at 3:08 AM, Matt Roper
wrote:
> On Tue, Apr 22, 2014 at 04:19:45PM +0200, Daniel Vetter wrote:
>> The introduction of primary planes has apparently caused a bit of fb
>> refcounting fun for people. That makes it a good time to clean up the
>> arcane rules and slight differenc
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/7682cbc0/attachment.html>
On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds
wrote:
> Dave, mind sending me a pull request for drm fixes?
>
> There's now at least these two:
>
> - "drm/radeon/aux: fix hpd assignment for aux bus"
> - "drm/radeon: use fixed PPL ref divider if needed"
>
> that look like fairly fatal regression
On Wed, Apr 23, 2014 at 03:15:32PM +0200, Daniel Vetter wrote:
> In Matt Ropers primary plane series a set of prep patches like
>
> commit af2b653bfb4ef40931b4d101ca842ce0c5da57ef
> Author: Matt Roper
> Date: Tue Apr 1 15:22:32 2014 -0700
>
> drm/i915: Restrict plane loops to only operate
On Wed, Apr 23, 2014 at 10:30:05AM +0200, Daniel Vetter wrote:
> The ->disable_plane hook always had a return value, but only since the
> introduction of primary planes was there any implementation that
> actually failed.
>
> So handle such failures correctly.
>
> Note that drm_plane_force_disabl
On Wed, Apr 23, 2014 at 10:30:04AM +0200, Daniel Vetter wrote:
> The introduction of primary planes has apparently caused a bit of fb
> refcounting fun for people. That makes it a good time to clean up the
> arcane rules and slight differences between ->update_plane and
> ->set_config. The new rule
https://bugzilla.kernel.org/show_bug.cgi?id=73521
Aaron Lu changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
gt; if (ctx->vblank_on)
> schedule_work(&ctx->work);
> --
> 1.7.10.4
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/530db239/attachment.html>
= exynos_drm_load,
> .unload = exynos_drm_unload,
> .suspend= exynos_drm_suspend,
> --
> 1.8.1.2
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/99449fd9/attachment.html>
description||STREET crash
--
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/20140423/6a5e92a2/attachment-0
description||Edition)
--
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/20140423/fb679e6a/attachment.html>
description||Edition)
--
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/20140423/f14f3cc9/attachment.html>
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/20140423/ec07633c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/26c0a749/attachment.html>
87 matches
Mail list logo