On Mon, Aug 3, 2015 at 7:24 PM, Linus Torvalds
wrote:
>> However, I'm
>> still seeing a large number of drm/i915 related warning messages and
>> other kernel kvetching.
>
> I suspect I can live with that for now. The lockdep one looks like
> it's mainly an initialization issue
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/7e27e84a/attachment.html>
On Tuesday, August 04, 2015 12:05:14 AM Daniel Vetter wrote:
> On Mon, Aug 3, 2015 at 7:24 PM, Linus Torvalds
> wrote:
> >> However, I'm
> >> still seeing a large number of drm/i915 related warning messages and
> >> other kernel kvetching.
> >
> > I suspect I can live with tha
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/33a02ac2/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/682beefe/attachment.html>
On 08/03/2015 04:04 PM, Rob Clark wrote:
> On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda wrote:
>> Hi,
>>
>> On 07/31/2015 04:48 PM, Rob Clark wrote:
>>> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
>>> wrote:
Hi Rob,
On Fri, 31 Jul 2015 08:13:59 -0400
Rob Clark wrote:
>>
On Tue, 28 Jul 2015 15:59:17 +0200
Jean-Francois Moine wrote:
> Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates
> the checksum of the frame and breaks the second calculation which is
> done in tda998x_write_if(). Then the HDMI AVI frame is wrong and
> the display device doe
easy. Perhaps a more verbose description could be provided in
done in the DRM DocBook, along with other documentation about atomic
mode-setting.
Irrespective of that, this makes sense, so:
Acked-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/49015961/attachment.sig>
...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/bd6e44bd/attachment.sig>
For the series:
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote:
> We've had a few issues with atomic where subtle bugs in the encoder
> picking logic lead to accidental self-stealing of the encoder,
> resulting in a NULL connector_state->crtc in
t;base.id,
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/ebba5338/attachment.sig>
On Fri, Jul 31, 2015 at 06:06:45PM -0300, Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
>
> Keeping the arguments list inside the str
On Tue, Aug 04, 2015 at 11:56:08AM +0300, Ander Conselvan De Oliveira wrote:
> For the series:
>
> Reviewed-by: Ander Conselvan de Oliveira
Thanks for the review.
-Daniel
>
>
> On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote:
> > We've had a few issues with atomic where subtle bugs in t
to provide You more details if needed.
--
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/20150804/c77d07d4/attachment.html>
On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This functions was just hiding the encoder and connector creation in
> a way that was less clean than if we get rid of it. For example,
> exynos_encoder ops had .create_connector() defined only because we were
> hand
On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> only a drm_encoder member and the internal exynos_drm_encoders ops that
> was directly mapped to the drm_encoder helper funcs.
>
> So now e
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/218023a5/attachment-0001.html>
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.
Signed-off-by:
Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.
Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
* struct my_struct - s
On Tue, Aug 4, 2015 at 1:16 AM, Andrzej Hajda wrote:
> On 08/03/2015 04:04 PM, Rob Clark wrote:
>> On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda wrote:
>>> Hi,
>>>
>>> On 07/31/2015 04:48 PM, Rob Clark wrote:
On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
wrote:
> Hi Rob,
>
>
From: Geert Uytterhoeven
Hi,
If CONFIG_MAGIC_SYSRQ is not set:
drivers/gpu/drm/drm_fb_helper.c:390:13: warning:
'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
static bool drm_fb_helper_force_kernel_mode(void)
^
As just silencing th
From: Geert Uytterhoeven
If CONFIG_MAGIC_SYSRQ is not set:
drivers/gpu/drm/drm_fb_helper.c:390:13: warning:
'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
static bool drm_fb_helper_force_kernel_mode(void)
^
Move drm_fb_helper_force_kernel_m
From: Geert Uytterhoeven
As of commit 5ea1f752ae04be40 ("drm: add
drm_fb_helper_restore_fbdev_mode_unlocked()"),
drm_fb_helper_restore_fbdev_mode() is no longer public, and drivers
should call drm_fb_helper_restore_fbdev_mode_unlocked() from their
->lastclose callbacks instead.
Update the docume
On Tue, Aug 04, 2015 at 03:22:09PM +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> Hi,
>
> If CONFIG_MAGIC_SYSRQ is not set:
>
> drivers/gpu/drm/drm_fb_helper.c:390:13: warning:
> 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
> static
may just close the bug.
--
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/20150804/b093b39c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=100351
--- Comment #5 from yaroslav.sapozhnik at gmail.com ---
Still there with kernel 4.1.3-200.fc22.x86_64
--
You are receiving this mail because:
You are watching the assignee of the bug.
good thing.
--
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/20150804/0eb5d062/attachment.html>
Hi Inki,
2015-08-04 Inki Dae :
> On 2015ë
08ì 04ì¼ 04:09, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> > only a drm_encoder member and the internal exynos_drm_encoders ops that
> > was directly mapped t
Hi Linus,
Special pull request for mst fixes since most of the patches touch code
outside of i915 proper. DRM parts have also been reviewed by Thierry
(nvidia) since Dave's enjoying vacations.
Cheers, Daniel
The following changes since commit 74d33293e467df61de1b1d8b2fbe29e550dec33b:
Linux 4
On Mon, Aug 03, 2015 at 12:25:11PM -0400, Theodore Ts'o wrote:
> On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote:
> >
> > Ok I updated fixes-stuff with just 2 patches which seem to be enough to
> > fix it. Plus a patch to convert Linus' hack into something we can keep
> > plus a driv
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150804/c6123a50/attachment.html>
On 07/31/2015 06:02 PM, Chris Wilson wrote:
>
> The first problem is that llc does not guarrantee that the buffer is
> cache coherent with all aspects of the GPU. For scanout and similar
> writes need to be WC.
>
> if (obj->has_framebuffer_references) would at least catch where the fb
> is made bef
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #18 from gitne at excite.co.jp ---
Just FYI:
I have just tested kernel version 4.0.8. Unfortunately, the problem still
persists. Additionally, since kernel version 3.15.7 the machine does not power
down after swapping the hibernation da
33 matches
Mail list logo
