-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5bc3b3db/attachment-0001.html>
cases no
lockup.
Debian.
--
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/20140902/c8f8d4ae/attachment.html>
ompile dummy pixel shader on demand
--
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/20140902/c962061c/attachment.html>
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/20140902/f6c46ab5/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140902/aab28d5e/attachment.html>
ktop.org/archives/dri-devel/attachments/20140902/703ce3ab/attachment.html>
On Fri, Aug 08, 2014 at 04:23:39PM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal
>
> Rename the defines to have levels instead of values for vswing and pre-emph
> levels as the values may differ in other scenarios like low vswing of eDP 1.4
> where the values are different.
> Upd
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/04ef717e/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/20140902/17589b2c/attachment.html>
Hi Ville,
went through the vblank rework patch set, mostly looks good to me. I
couldn't find any bugs in the code. A first quick test-run on my old
Intel GMA-950 (Gen 3'ish i think?) also didn't show apparent problems
with the OML_sync_control functions. I'll try to test more carefully
with th
co: 15703 MB
Software Instalado:
Informes de fallos recientes:
--
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/20140902/a7a56f40/attachment-0001.html>
ck turns off mst so might be useful as a workaround,
but I should be able to fix this once I sit down at my desk.
Dave.
-- next part --
A non-text attachment was scrubbed...
Name: i915-mst-hack.patch
Type: text/x-patch
Size: 332 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/b1b0b559/attachment.bin>
ps,vs ?
I suppose you mean RADEON_DEBUG=fp,vp?
--
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/20140902/603994d1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=30102
Alex Perez changed:
What|Removed |Added
CC||aperez at alexperez.com
--- Comment #11 from
uce the lockup with the trace:
http://pkgbuild.com/~lcarlier/trace/Sam3.tar.xz
--
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/attachment
nts/20140902/4671df24/attachment.html>
Am Dienstag, den 02.09.2014, 09:00 -0300 schrieb Fabio Estevam:
> Hi Philipp,
>
> On Tue, Sep 2, 2014 at 6:29 AM, Philipp Zabel
> wrote:
> > Hi Fabio,
> >
> > Am Dienstag, den 02.09.2014, 00:37 -0300 schrieb Fabio Estevam:
> >> From: Fabio Estevam
> >>
> >> Let's only define DEBUG for debugging
viously you can't rename the temps
which are supposed to contain inputs.
--
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/20140902/4535d895/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/58b390b8/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/845815e0/attachment.html>
think there are no input registers in this case (there's a NumInputs = 0
somewhere in the backtrace) so there aren't any pre-allocated nodes 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/20140902/530fbe44/attachment-0001.html>
..
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/993b560a/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/380d1fdd/attachment.html>
From: Clint Taylor
Enable 2x pixel replication for modes the mode flag DBLCLK to double
horizontal timings and pixel clock across TMDS.
Signed-off-by: Clint Taylor
Cc: Daniel Vetter
Cc: Ville Syrj?l?
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_hdmi.c | 15 ---
1
From: Clint Taylor
Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 curr
From: Clint Taylor
Split original drm_edid.c changes and intel_hdmi.c HDMI pixel
replciation changes into separate patches.
Clint Taylor (2):
drm/edid: Reduce horizontal timings for pixel replicated modes
drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes
drivers/gpu/d
On 30.08.2014 22:59, Mikael Pettersson wrote:
> Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> after a while in X + firefox. This still occurs with yesterday's HEAD
> of Linus' repo. 3.16 and ealier kernels are fine.
>
> I ran a bisect, which identified:
>
> commi
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning proc
From: Gustavo Padovan
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_drv.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/
From: Gustavo Padovan
At this point of the code the obj var is already NULL, so we don't
need to set it again to NULL.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/
From: Derek Foreman
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/b06b0866/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/20140902/c950bc65/attachment.html>
> How does this patch look?
Looks better now, yes. This patch is Reviewed-by: Christian K?nig
The next one we need to take a look at is "drm/radeon: use rcu waits in
some ioctls":
> @@ -110,9 +110,12 @@ static int radeon_gem_set_domain(struct
> drm_gem_object *gobj,
> }
> if (d
Process should not have access to ipp nodes created by another
process. The patch adds necessary checks.
It also simplifies lookup for command node.
Signed-off-by: Andrzej Hajda
---
v3:
- added file check from previous commit
- simplified c_node lookup
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c
Since file pointer is preserved in c_node passing it
as argument in node functions is redundant.
Signed-off-by: Andrzej Hajda
---
v3:
- file check moved to next patch
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/driv
Op 02-09-14 om 11:52 schreef Christian K?nig:
> Am 02.09.2014 um 11:12 schrieb Maarten Lankhorst:
>> Op 02-09-14 om 10:51 schreef Christian K?nig:
>>> Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
Hey,
On 01-09-14 18:21, Christian K?nig wrote:
> Am 01.09.2014 um 15:33 schrieb
On 2 September 2014 14:05, Theodore Ts'o wrote:
> I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
> longer see the my Dell 30" monitor when it is connected via the
> docking station using a Displayport connector. This worked using 3.16
> kernel.
>
> If I connect to the monitor
MESA call
Rendered 150 frames in 2.68355 secs, average of 55.8961 fps
[aaron at Aaron-Arch Chromiumapitrace]$
--
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/20140902/863aa57f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82581
Christoph Haag changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5ff39af6/attachment.html>
n I modify some
code in order to achieve this? Or is there a way to influence the order in
which the connectors are initialized?
Best regards,
Andreas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/af03dd3e/attachment.html>
again.
--
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/20140902/71f04669/attachment.html>
Am 02.09.2014 um 11:12 schrieb Maarten Lankhorst:
> Op 02-09-14 om 10:51 schreef Christian K?nig:
>> Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
>>> Hey,
>>>
>>> On 01-09-14 18:21, Christian K?nig wrote:
Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
> Hey,
>
> Op 01-09-14
Hi Fabio,
Am Dienstag, den 02.09.2014, 00:37 -0300 schrieb Fabio Estevam:
> From: Fabio Estevam
>
> Let's only define DEBUG for debugging purpose and not by default to avoid
> printing debugging message unnecessarily.
>
> Signed-off-by: Fabio Estevam
> ---
> Russell,
>
> Are you still collect
Op 02-09-14 om 10:51 schreef Christian K?nig:
> Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
>> Hey,
>>
>> On 01-09-14 18:21, Christian K?nig wrote:
>>> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
Hey,
Op 01-09-14 om 14:31 schreef Christian K?nig:
> Please wait a secon
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/db6c9af2/attachment.html>
There are several different models of N116BGE. According to the commit
that added innolux_n116bge_mode [0], this N116BGE is for the eDP variety.
[0] commit 0a2288c06aab73c966e82045c8f20b0e713baf2a
Author: Thierry Reding
Date: Thu Jul 3 14:02:59 2014 +0200
drm/panel: simple: Add Innolux N
Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
> Hey,
>
> On 01-09-14 18:21, Christian K?nig wrote:
>> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
>>> Hey,
>>>
>>> Op 01-09-14 om 14:31 schreef Christian K?nig:
Please wait a second with that.
I didn't had a chance to test thi
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/8471ad9b/attachment.html>
Michel D?nzer writes:
> On 30.08.2014 22:59, Mikael Pettersson wrote:
> > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> > after a while in X + firefox. This still occurs with yesterday's HEAD
> > of Linus' repo. 3.16 and ealier kernels are fine.
> >
> > I ra
The quite-recently-added analog-tv-connector bindings say that the
compatible string for composite video connector is
"composite-connector". That string is also used in the omap3-n900.dts
file. However, the connector driver uses "composite-video-connector", so
this has never worked.
While changing
For debug purposes it is useful to know how far away the generated pixelclock is
from the desired rate, so print the amount of error.
After adding this patch and with debug enabled we have:
imx-ipuv3 240.ipu: disp 0: panel size = 1920 x 1080
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 2
SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry.
Signed-off-by: Fabio Estevam
---
drivers/gpu/ipu-v3/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index 2f228a2..8696d20 100644
--- a
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140902/2e7c76f6/attachment-0001.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/4b27f8c3/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/519abe7a/attachment.html>
In order to support the "enable GPIO" available in many panel devices,
this commit adds a proper devicetree binding.
By providing an enable GPIO in the devicetree, the driver can now turn
off and on the panel device, and/or the backlight device. Both the
backlight and the GPIO are optional propert
Instead of setting an initial value for the return code, set it explicitly
on each error path. This is just a cosmetic cleanup, as preparation for the
enable GPIO support.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +++-
1 file chang
The current backlight support is broken; the driver expects a backlight-class
in the panel devicetree node. Fix this by implementing it properly, getting
an optional backlight from a phandle.
This shouldn't cause any backward-compatibility DT issue because the current
implementation doesn't work a
Using the managed variant to allocate the resource makes the code simpler
and less error-prone.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilc
Just a cosmetic cleanup.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 8f88bfd..4b36e68 100644
--- a/dri
Just a trivial cleanup to remove the variable.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index d581c53..
This commit adds the missing calls to of_node_put to release the node
that's currently held by the of_get_child_by_name() call in the panel
info parsing code.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 3 +++
1 file changed, 3 insertio
The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs in tilcdc_load().
To fix it, this commit adds proper labels to bail out at the different
stages in the load fu
Dave,
I'm resending this, hoping it can be pushed for v3.18. The patchset was
ready for v3.17, but it got no maintainer feedback or review. Maybe it fell
through some crack?
Just for reference, here goes the details about this series and why it's
needed:
This patchset adds the required changes t
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/93d8c8a2/attachment.html>
run
Valley repeatedly?
--
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/20140902/5400e7f3/attachment-0001.html>
bed...
Name: drm-debug.xz
Type: application/octet-stream
Size: 27396 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5850058d/attachment-0001.obj>
Hi Philipp,
On Tue, Sep 2, 2014 at 6:29 AM, Philipp Zabel wrote:
> Hi Fabio,
>
> Am Dienstag, den 02.09.2014, 00:37 -0300 schrieb Fabio Estevam:
>> From: Fabio Estevam
>>
>> Let's only define DEBUG for debugging purpose and not by default to avoid
>> printing debugging message unnecessarily.
>>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/88bf3d21/attachment.html>
Showing who is the current master is useful for trying to decypher
errors when trying to acquire master (e.g. a race with X taking over
from plymouth). By including the process name as well as the pid
simplifies the task of grabbing enough information remotely at the point
of error.
v2: Add the co
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/f9add177/attachment.html>
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
> On 2 September 2014 14:05, Theodore Ts'o wrote:
> > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
> > longer see the my Dell 30" monitor when it is connected via the
> > docking station using a Displayport connecto
pam?ti (SIGSEGV)
--
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/20140902/8ff645c8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83731
Bug ID: 83731
Summary: dpm still not working on radeon TURKS 1002:6840
Product: Drivers
Version: 2.5
Kernel Version: 3.17-rc
Hardware: All
OS: Linux
Tree: Main
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c880db1a/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/20140902/3023e657/attachment-0001.html>
ving 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/20140902/eba6ccac/attachment.html>
Mesa 10.1 is stable for you as well? And if so, bisect?
--
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/20140902/d961f450/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c3a81b87/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/b2a474d6/attachment.html>
mime type||
--
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/20140902/be652fd2/attachment.html>
From: Fabio Estevam
Let's only define DEBUG for debugging purpose and not by default to avoid
printing debugging message unnecessarily.
Signed-off-by: Fabio Estevam
---
Russell,
Are you still collecting ipu-v3 patches?
./scripts/get_maintainer.pl does not provide too many hints on who should
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/a0639b83/attachment-0001.html>
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
longer see the my Dell 30" monitor when it is connected via the
docking station using a Displayport connector. This worked using 3.16
kernel.
If I connect to the monitor using the mini-display, by passing the
docking station, thin
86 matches
Mail list logo
