https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #12 from klod ---
I'm sorry, I'm very busy these days. I will try that when I have time
--
You are receiving this mail because:
You are watching the assignee of the bug.
GPU reset messages even on startup.
--
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/20140409/9f906829/attachment-0001.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/4413163d/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
Alex Deucher changed:
What|Removed |Added
Attachment #131601|0 |1
is obsolete|
t
> > better.
> >
> > Here your max is 100. ref: 10, post 10 >>>> 10 * 10 = 100 max.
>
> Yes correct.
Thanks for explaining this so clearly.
Garrett
--
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/20140409/7719241c/attachment.html>
.
--
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/20140409/ed7c5e1e/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/0c4ee8fd/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
Alex Deucher changed:
What|Removed |Added
Attachment #131741|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #22 from Tom Yan ---
Do you have any case that the code would do something positive? Or ultimately,
would you consider removing the code upstream?
--
You are receiving this mail because:
You are watching the assignee of the bug.
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/8283d720/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #23 from Tom Yan ---
Btw, is it something not implemented yet or a bug, that it won't do the
modesetting later if no device plugged before boot? Why does it have to go
1024x768? I mean, why does it require a device to initialize "dynam
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #24 from Alex Deucher ---
(In reply to Tom Yan from comment #22)
> Do you have any case that the code would do something positive? Or
> ultimately, would you consider removing the code upstream?
It works for the vast majority of users
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #25 from Alex Deucher ---
(In reply to Tom Yan from comment #23)
> Btw, is it something not implemented yet or a bug, that it won't do the
> modesetting later if no device plugged before boot? Why does it have to go
> 1024x768? I mean,
On Tue, Apr 08, 2014 at 10:21:44AM -0700, Ben Widawsky wrote:
> I am not convinced this is the correct solution. At least the way we
> used this interface, it isn't meant to ever fail. I also didn't look
> into exactly why we depend an ENOSPC return. That sounds fragile to me,
> especially for a p
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140409/3c85421d/attachment.html>
.
Please file separate bugs for the shader compile failures.
--
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/20140409/a4fc5253/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #26 from Tom Yan ---
(In reply to Alex Deucher from comment #24)
> It works for the vast majority of users and removing it would break unplug
> and replug of DP displays. Without that code you would have to manually
> disable and re-e
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #27 from Tom Yan ---
(In reply to Alex Deucher from comment #25)
> (In reply to Tom Yan from comment #23)
> > Btw, is it something not implemented yet or a bug, that it won't do the
> > modesetting later if no device plugged before boo
by: Eric Anholt
Thanks. I don't have the necessary permissions to push this, can
somebody else help out here?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
&
vel/attachments/20140409/30a0e650/attachment.html>
el/attachments/20140409/87ae3888/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/e30db3e5/attachment.html>
Hi Tomasz,
On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
> Add exynos-simple-phy driver to support a single register
> PHY interfaces present on Exynos4 SoC.
>
> Signed-off-by: Tomasz Stanislawski
> ---
> .../devicetree/bindings/phy/samsung-phy.txt| 24 +++
> drivers/phy/Kconfig
Hi Tomasz,
On 9 April 2014 14:07, Andrzej Hajda wrote:
> Hi Tomasz,
>
> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>> Add exynos-simple-phy driver to support a single register
>> PHY interfaces present on Exynos4 SoC.
>>
>> Signed-off-by: Tomasz Stanislawski
>> ---
>> .../devicetree/bin
Hi,
On 09/04/14 11:12, Rahul Sharma wrote:
> Idea looks good. How about keeping compatible which is independent
> of SoC, something like "samsung,exynos-simple-phy" and provide Reg
> and Bit through phy provider node. This way we can avoid SoC specific
> hardcoding in phy driver and don't need to
Hi Tomasz,
On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
> The HDMIPHY (physical interface) is controlled by a single
> bit in a power controller's regiter. It was implemented
> as clock. It was a simple but effective hack.
This power controller register has also bits to control HDMI clock
d
Hi Andrzej,
On 9 April 2014 16:00, Andrzej Hajda wrote:
> Hi Tomasz,
>
> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>> The HDMIPHY (physical interface) is controlled by a single
>> bit in a power controller's regiter. It was implemented
>> as clock. It was a simple but effective hack.
>
>
Hi Andrzej,
This issue could be solved by exporting a regmap from PMU driver
or Exynos clock provider for the usage by exynos-simple-phy.
The operations on PHYs from exynos-simple-phy provider would
be chained to PMU driver and protected by a spinlock in the regmap.
Luckily, the divider is not use
Hi Rahul,
On 04/09/2014 11:12 AM, Rahul Sharma wrote:
> Hi Tomasz,
>
> On 9 April 2014 14:07, Andrzej Hajda wrote:
>> Hi Tomasz,
>>
>> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>>> Add exynos-simple-phy driver to support a single register
>>> PHY interfaces present on Exynos4 SoC.
>>>
>
From: Thierry Reding
Hi,
This series adds libdrm-tegra with a very lightweight API on top of the
kernel interfaces. Most of the functions provided here have been in use
in various driver efforts in different incarnations. This is an attempt
to consolidate, so I'm looking for review comments espe
From: Thierry Reding
Add the libdrm_tegra helper library to encapsulate Tegra-specific
interfaces to the DRM.
Furthermore, Tegra is added to the list of supported chips in the
modetest and vbltest programs.
Signed-off-by: Thierry Reding
Signed-off-by: Erik Faye-Lund
Signed-off-by: Thierry Red
From: Thierry Reding
Checks whether or not the compiler supports the -fvisibility option. If
so it sets the VISIBILITY_CFLAGS variable which can be added to the per
directory AM_CFLAGS where appropriate.
By default all symbols will be hidden via the VISIBILITY_CFLAGS. The
drm_public macro can be
From: Thierry Reding
This test opens a device, dumps the version information and checks that
a Tegra DRM context can be opened on it.
Signed-off-by: Thierry Reding
---
Changes in v2:
- fix in-tree build failure
configure.ac| 1 +
tests/Makefile.am | 4
tests/tegra/.gi
From: Thierry Reding
These functions can be used to open channels to engines, manage job
submissions, create push buffers to store command streams in and wait
until jobs have been completed.
Signed-off-by: Thierry Reding
---
Changes in v2:
- automatically allocate buffer objects as required by
From: Thierry Reding
This library provides helpers for common functionality needed by test
programs.
Signed-off-by: Thierry Reding
---
Changes in v2:
- fix a couple of memory leaks and get rid of some unneeded code
tests/tegra/Makefile.am | 10 +-
tests/tegra/drm-test-tegra.c | 137
From: Thierry Reding
This test uses the IOCTLs for job submission and fences to fill a sub-
region of the screen to a specific color using gr2d.
Signed-off-by: Thierry Reding
---
Changes in v2:
- free framebuffer when done
tests/tegra/.gitignore | 1 +
tests/tegra/Makefile.am | 1 +
test
From: Thierry Reding
Fixes a few complaints raised by valgrind when running the Tegra tests.
Signed-off-by: Thierry Reding
---
xf86drmMode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index a6bb2ee44576..861248b7c2fc 100644
--- a/xf86drmMode.c
+++ b/xf8
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/b46163db/attachment.html>
Hello Andrzej,
On 09.04.2014 10:37, Andrzej Hajda wrote:
>> +static int exynos_phy_probe(struct platform_device *pdev)
>> +{
>> +const struct of_device_id *of_id = of_match_device(
>> +of_match_ptr(exynos_phy_of_match), &pdev->dev);
>> +const u32 *offsets = of_id->data;
>> +
https://bugzilla.kernel.org/show_bug.cgi?id=46711
--- Comment #2 from Valentin Popa ---
Can someone reopen this bug since the issue still reproduces.
--
You are receiving this mail because:
You are watching the assignee of the bug.
violating the contrains.
--
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/20140409/d0e70840/attachment.html>
Surely these two panels have a physical size?
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/20140409/1168cba1/attachment-0001.sig>
From: Thierry Reding
The version of the drm_tegra_submit structure that was merged all the
way back in 3.10 contains a pad field that was originally intended to
properly pad the following __u64 field. Unfortunately it seems like a
different field was dropped during review that caused this padding
cc: stable to make sure that even once you release userspace you won't
get angry bug reports?
-Daniel
On Wed, Apr 9, 2014 at 2:39 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> The version of the drm_tegra_submit structure that was merged all the
> way back in 3.10 contains a pad field th
;
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/3721b89e/attachment.html>
invalid.
--
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/20140409/72374c56/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/f04fba03/attachment.html>
u 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/20140409/a32f25af/attachment.html>
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/20140409/2343d443/attachment.html>
interesting.
--
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/20140409/a570e042/attachment.html>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/c9bb53fd/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/6658cb0b/attachment.html>
This adds 3 more functions to deal with rcu.
reservation_object_wait_timeout_rcu() will wait on all fences of the
reservation_object, without obtaining the ww_mutex.
reservation_object_test_signaled_rcu() will test if all fences of the
reservation_object are signaled without using the ww_mutex.
The following series implements small updates to the fence api.
I've found them useful when implementing the fence API in ttm and i915.
The last patch enables RCU on top of the api. I've found this less
useful, but it was the condition on which Thomas Hellstrom was ok
with converting TTM to fence,
Smatch complains that we are reading beyond the end of the array here:
drivers/gpu/drm/panel/panel-s6e8aa0.c:852 s6e8aa0_read_mtp_id()
warn: buffer overflow 's6e8aa0_variants' 4 <= 4
We set the error code, so it's not harmful but it looks like a return
was intended here so lets ad
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/20140409/4c17fe73/attachment.html>
Move the list of shared fences to a struct, and return it in
reservation_object_get_list().
Add reservation_object_reserve_shared(), which reserves space
in the reservation_object for 1 more shared fence.
reservation_object_add_shared_fence() and
reservation_object_add_excl_fence() are used to as
s://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743659
--
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/20140409/e71c7432/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/9b12c7f5/attachment.html>
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/20140409/2d5100ea/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/3396cd2a/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/0f4b6c58/attachment.html>
e 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/20140409/5d91f190/attachment.html>
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/5b59415b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/c03c7dc5/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140409/f26d2c37/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
Tom Yan changed:
What|Removed |Added
Kernel Version|3.13.5 |3.13.8
--
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #28 from Tom Yan ---
(In reply to Alex Deucher from comment #24)
> In your case we need to find out why it's not working properly for you. You
> mentioned that it works properly in the console but not in X. That sounds
> like maybe y
Hi Thomas
On Tue, Apr 8, 2014 at 7:11 AM, Thomas Hellstrom
wrote:
> Hi, David,
>
> Are there any dev_mapping changes in 3.15 that could cause this?
> Do we know what happens to vma->vm_file->f_mapping during fork?
Sorry, I was traveling. Yes, there have been changes, but I converted
all drivers
https://bugzilla.kernel.org/show_bug.cgi?id=46711
Michal Suchanek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|OBSOLETE
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/754833ab/attachment.html>
Hi, David!
Thanks for the reply.
Actually I just got CC'd on the Fedora Bug. I haven't seen this either,
so I can't provide more info...
What I was thinking was that maybe after a fork, vma->vm_file->f_mapping
of the child process wasn't set to the same value as the
parent...
/Thomas
On 04/0
https://bugzilla.kernel.org/show_bug.cgi?id=46711
Thomas Hellstrom changed:
What|Removed |Added
CC||thellstrom at vmware.com
--- Comment #
port.cgi?bug=743659
--
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/20140409/c4981724/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #29 from Alex Deucher ---
Created attachment 131821
--> https://bugzilla.kernel.org/attachment.cgi?id=131821&action=edit
reverse hpd polarity
It sounds like your board by have the hpd pin polarity reversed (so plug events
looks like
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/6b56a160/attachment-0001.html>
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/e2f781a5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140409/13c2bfe5/attachment.html>
Hi
On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer wrote:
> How do you keep these promises on network and FUSE file systems?
I don't. This is shmem only.
Thanks
David
r app to take responsibility for
the power save state and also to drop the ball.
--
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/attachmen
https://bugzilla.kernel.org/show_bug.cgi?id=46711
Alan changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Wed, Apr 09, 2014 at 07:25:37AM +0100, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 10:21:44AM -0700, Ben Widawsky wrote:
> > I am not convinced this is the correct solution. At least the way we
> > used this interface, it isn't meant to ever fail. I also didn't look
> > into exactly why we de
28807] pciehp :00:03.0:pcie04: Cannot add device at :02:00
--
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/20140409/
Kernel 3.14.0-12041-g75ff24f from 9.4.2014 introduces the following
on the console (driver is i915):
[drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder B FIFO underrun
In syslog
457e77b2 effectively replaces (... & 0xff00) << 8 with (... >> 8) << 8.
Which does not do the same and breaks boot on my machine.
Restore the old behaviour and remove the unnecessary cast.
Signed-off-by: Andreas Noever
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 2 +-
1 file chang
Hi,
Shawn Guo wrote:
> On Mon, Apr 07, 2014 at 02:44:45PM +0200, Denis Carikli wrote:
> > The imx-drm driver can't use the de-active and
> > pixelclk-active display-timings properties yet.
> >
> > Instead the data-enable and the pixel data clock
> > polarity are hardcoded in the imx-drm driver.
>
Hi Dave,
this is the fives pull request for radeon changes. I thought number four
would be the last one with new stuff, but it turned out that Alex has
other things in mind.
So this request contains Alex's update to send bare addresses to
properly reset the I2C over DP AUX bus as well as the n
Signed-off-by: Micah Richert
---
drivers/gpu/drm/msm/msm_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 16f643a..885cf56 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/m
89 matches
Mail list logo
