https://bugzilla.kernel.org/show_bug.cgi?id=91571
Alberto Salvia Novella changed:
What|Removed |Added
URL||https://bugs.launchpad.net/
https://bugzilla.kernel.org/show_bug.cgi?id=91571
Bug ID: 91571
Summary: AMD graphics hardware hangs with an homogeneous
coloured screen or blank screen, and with chirp coming
from the graphics card
Product: Drivers
On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the cursor
drm_plane_helper_{update,disable} are not specific to primary planes;
fix some copy/paste summaries to avoid confusion.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
Add a transitional helper for planes' .set_property() entrypoint,
similar to what we already have for .update_plane() and
.disable_plane(). This allows drivers that are still in the process of
transitioning to implement and exercise the .atomic_set_property()
driver entrypoint that will eventually
By default, both output ports 0 (I2S) and 1 (S/PDIF) are defined.
A graph of port permits to define only the really connected ports of
the board and to identify the remote ends.
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/sound/mvebu-audio.txt | 30
sound
client beta.
[2015-01-19 20:27:38] Verifying installation...
[2015-01-19 20:27:38] Verification complete
[2015-01-19 20:31:30] Shutdown
As you can see, i can't do nothing with it. So i will begin building 32 bit
version of apitrace. Stay tuned.
--
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/20150119/f06e50ad/attachment-0001.html>
a single
> > Tested-by? Is that as good as it's going to get?
>
> I've been using this series on top of exynos-drm for more than a month and it
> works fine for me so..
>
> Tested-by: Gustavo Padovan
Same here, just test-booted on my snow with just these patch on top of
3.19-rc5 and got a nicely working display.
Tested-by: Sjoerd Simons
--
Sjoerd Simons
Collabora Ltd.
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/f0d3ea45/attachment.bin>
When the DAIs are created from a graph of ports, their types are not tied
to their ID.
Signed-off-by: Jean-Francois Moine
---
sound/soc/kirkwood/kirkwood-i2s.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c
b/sound/soc/kirkwood/kirkwood
> As the if (CISLAND_MINIMUM_ENGINE_CLOCK !=
> CISLAND_MINIMUM_ENGINE_CLOCK) is never
> satisfied - the entire else branch is never going to be executed and could be
> removed - provided this is not simply a bug and needs to be fixed...
>
> Patch is against 3.19.0-rc5 -next-20150119
>
>
This patch prepares the driver to the creation of the DAIs from a graph
of ports.
Signed-off-by: Jean-Francois Moine
---
sound/soc/kirkwood/kirkwood-i2s.c | 108 ++
sound/soc/kirkwood/kirkwood.h | 1 +
2 files changed, 40 insertions(+), 69 deletions(-)
Hello Thierry,
On 01/19/2015 05:30 PM, Thierry Reding wrote:
>>
>> I know you probably are very busy but it would be great if you can take a
>> look
>> to this series to avoid another kernel release to be missed since we are
>> already
>> at v3.19-rc5.
>>
>> Only this version was posted 2 mont
From: Michel Dänzer
If the image size would ever read as 0, pci_get_rom_size could keep
processing the same image over and over again.
Reported-by: Federico
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer
---
v2:
* Use unsigned instead of u16 for the local length variable (not su
well it
will.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/bb07cee3/attachment.sig>
From: Inki Dae
This patch adds MIPI-DSI and MIPI-DSI based S6E63J0X03 AMOLED panel
device nodes for Exynos3250 Rinato board.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Acked-by: Kyungmin Park
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary DT properties of flip-*
a
From: Inki Dae
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320Ã320 resolution in 1.63-inch physical panel. This panel is used in
Samsung Galaxy Gear 2.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
From: Inki Dae
This patch adds fimd device node which is a display controller
for Exynos3250 Rinato board.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Acked-by: Kyungmin Park
---
Changes for v2:
- None
Changes for v3:
- None
arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
til start == start_s.
As an aside, there is currently some refcounting code (e.g. in the DPMS off
and/or framebuffer final-unref paths if I remember correctly) which assumes
that waiting one vblank is enough to be able to unpin resources. Obviously,
as this patch shows, this is not actually true. T
2015-01-19 Thierry Reding :
> On Mon, Jan 19, 2015 at 11:27:52AM +0100, Javier Martinez Canillas wrote:
> > Hello Thierry,
> >
> > On 01/05/2015 02:50 PM, Thierry Reding wrote:
> > > On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote:
> > >> >
> > >> > Ajay's series don't apply cleanly
p.org/archives/dri-devel/attachments/20150119/8f16582d/attachment.sig>
Allow mesa/dri2 to implement GLX_EXT_buffer_age by reporting the sbc of
when the current back buffer was defined. As this may require ddx
support, only set the value if enabled by the ddx and report the new
semantics via a DRI2GetParam request.
Signed-off-by: Chris Wilson
---
configure.ac
On Mon, Jan 19, 2015 at 11:00:40AM +, Chris Wilson wrote:
> @@ -1104,6 +1107,8 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
> CARD64 target_msc,
> * it as early as possible, just to be sure.
> */
> *swap_target = pPriv->swap_count + pPriv->swapsPending + 1;
> +i
-next-20150119
Patch was only compile tested with x86_64_defconfig + CONFIG_DRM=m,
CONFIG_DRM_RADEON=m
drivers/gpu/drm/radeon/ci_dpm.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index f373a81
On Mon, Jan 19, 2015 at 3:53 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> If the image size would ever read as 0, pci_get_rom_size could keep
> processing the same image over and over again.
>
> Reported-by: Federico
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer
Revie
On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> On 19/01/2015 10:08, Ville Syrjälä wrote:
> > On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> >> Matt, all,
> >>
> >> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> >> very unusual way,
https://bugzilla.kernel.org/show_bug.cgi?id=91551
--- Comment #1 from dura ---
Created attachment 163821
--> https://bugzilla.kernel.org/attachment.cgi?id=163821&action=edit
eld with bogus nv50_display.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=91551
Bug ID: 91551
Summary: nouveau HDMI audio regression
Product: Drivers
Version: 2.5
Kernel Version: 3.18.2
Hardware: All
OS: Linux
Tree: Mainline
St
On 19/01/2015 10:08, Ville Syrjälä wrote:
> On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
>> Matt, all,
>>
>> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
>> very unusual way, as if it has a lot of inertia. It will lag behind and
>> then overshoot t
an 720p resolution video playback
--
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/20150119/507e1bfc/attachment.html>
Hello Thierry,
On 01/05/2015 02:50 PM, Thierry Reding wrote:
> On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote:
>> >
>> > Ajay's series don't apply cleanly anymore because it has been a while since
>> > he posted it but he can rebase on top of 3.19-rc1 once it is released and
>> > re-
On Sat, Jan 17, 2015 at 02:06:35AM -0800, Jeremiah Mahler wrote:
> Matt, all,
>
> Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a
> very unusual way, as if it has a lot of inertia. It will lag behind and
> then overshoot the expected position.
>
> I reproduced this bug o
On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> There's also an issue in (most) X drivers which exaberates this
> issues: When changing the cursor buffer the X cursor code does a a)
> disable cursor b) update cursor image c) enable cursor cycle.
Notably not -intel on which the bug
Within the DRI2GetBuffers return packet there is a 4-byte field that is
currently unused by any driver, i.e. flags. With the co-operation of a
suitably modified X server, we can pass the last SBC on which the buffer
was defined (i.e. the last SwapBuffers for which it was used) and 0 if
it is fresh
As the SBC from the reply from SwapBuffers is not used immediately and
can be easily determined by counting the new of SwapBuffers requests
made by the client, we can defer the synchronisation point to the
pending GetBuffers round trip. (We force the invalidation event in order
to require the GetBu
Available since the inclusion of dri2proto 1.4 is a DRI2 request to
query and set certain parameters about the X/DDX configuration. This
implements the getter request.
Signed-off-by: Chris Wilson
---
src/glx/dri2.c | 29 +
src/glx/dri2.h | 4
2 files changed, 33
For enable BufferAge support, we just have to be not using the
DRI2Buffer->flags field for any purpose (i.e. it is always expected to
be 0, as it is now) and to be sure to swap the flags field whenever we
exchange buffers. As nouveau does not exactly support TripleBuffer, we
don't have to worry abo
For BufferAge support, we just have to guarrantee that we were not using
the DRI2Buffer->flags field for anything else (i.e. it is always 0) and
then to make sure that we exchange the flags field after buffer
exchanges. radeon does not support TripleBuffering so we do not have to
worry about perser
Allow mesa/dri2 to implement GLX_EXT_buffer_age by reporting the sbc of
when the current back buffer was defined. As this may require ddx
support, only set the value if enabled by the ddx and report the new
semantics via a DRI2GetParam request.
Signed-off-by: Chris Wilson
---
configure.ac
Allow the DDXes to opt-in and handle swap-interval=0 requests for
themselves, for example by using asynchronous pageflips, rather than
forcing a blit. This has the important side-effect of also
disambiguating CopyRegion calls to always be client requests.
References: http://lists.x.org/archives/xo
Since the introduction of DRI2GetBuffersWithFormat, the old
DRI2GetBuffers interface would always recreate all buffers all the time
as it was no longer agnostic to the format value being set by the DDXes.
This causes an issue with clients intermixing the two requests,
rendering any sharing or cachi
In order for X/DDX to reuse a driver specific field of the DRI2GetBuffers
reply, we need to declare the change in semantics. To indicate that the
flags field now continues the last swap buffers count instead, we
introduce the has-buffer-age parameter.
Signed-off-by: Chris Wilson
---
configure.ac
In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the
last swap buffer count that the back buffer was defined for. For
simplicity, we can reuse an existing field in the DRI2GetBuffers reply
that is not used by current drivers, the flags. Since we change the
interpretation of this
Thanks for the fix.
Tested-by: Rodrigo Vivi
On Mon, Jan 19, 2015 at 8:31 AM, Matt Roper
wrote:
> When commiting a plane update where the framebuffer doesn't change, we
> can skip the prepare_fb/cleanup_fb steps. This also allows us to avoid
> an unnecessary vblank wait at the end of the opera
Hi Fabio,
thank you for the patch.
Am Samstag, den 17.01.2015, 19:49 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam
>
> In the case of errors we should propagate them.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Fixed a typo on my FSL address
>
> drivers/gpu/drm/imx/i
On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > There's also an issue in (most) X drivers which exaberates this
> > issues: When changing the cursor buffer the X cursor code does a a)
> > disable cursor b) update cur
When commiting a plane update where the framebuffer doesn't change, we
can skip the prepare_fb/cleanup_fb steps. This also allows us to avoid
an unnecessary vblank wait at the end of the operation when we're just
moving a plane and not changing its image (e.g., for a cursor).
At the moment, i915
XT]
--
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/20150119/026c7468/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/c93855e5/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/f0a890eb/attachment.html>
/apitrace/apitrace/wiki/Steam
--
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/20150119/259ec3a1/attachment-0001.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/27f10c8f/attachment.html>
is in the GLSL compiler code.
--
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/20150119/72df63a7/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150119/0c930395/attachment.html>
ould also try googling for more information about creating apitraces with
Steam games.
--
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/atta
Fixes a case where we call vmw_fifo_idle() from within a wait function with
task state !TASK_RUNNING, which is illegal.
In addition, make the locking fine-grained, so that it is performed once
for every read- and write operation. This is of course more costly, but we
don't perform much register ac
55 matches
Mail list logo
