On 30 August 2013 12:29, Rahul Sharma wrote:
> Exynos hdmiphy operations and configs are kept inside
> the hdmi driver. Hdmiphy related code is tightly coupled
> with hdmi IP driver.
>
> This patche moves hdmiphy related code to hdmiphy driver.
> It will help in cleanly supporting the hdmiphy vari
On 09/08/13 20:14, Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the third RFC of the Common Display Framework.
Hi,
I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
some notes here about what I've discovered or how I see things. Some of these I
have mentioned ear
On Tue, 01 Oct 2013, Dave Airlie wrote:
> Did you compile or boot this? I get a warning since you are using edid
> uninitialised, I guess you meant to duplicate intel_connector->edid.
Hi Dave, quite embarrassing, I thought I did, obviously didn't. Updated
patch follows.
BR,
Jani.
>
> Dave.
>
v2: duplicate intel_connector->edid, not uninitialized edid (Dave Airlie).
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 561436
> > > That looks quite strange. I guess the kernel should map the ROM at the
> > > address OpenBoot/OF assigned to it. ( 1002 ).
> >
> > The address you see is a raw physical I/O address, which is a concatenation
> > of the I/O window physical address for that PCI controller and the
> > PCI bu
https://bugs.freedesktop.org/show_bug.cgi?id=69983
--- Comment #6 from Michel Dänzer ---
Have you tried a clean build, i.e. after at least make clean?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
Jerome, Konrad
Forgive an ignorant question, but it appears like both Nouveau and
Radeon may use pci_map_page() when populating TTMs on
pages obtained using the ordinary (not DMA pool). These pages will, if I
understand things correctly, not be pages allocated with
DMA_ALLOC_COHERENT.
From wh
Am Dienstag, den 01.10.2013, 12:16 +0200 schrieb Thomas Hellstrom:
> Jerome, Konrad
>
> Forgive an ignorant question, but it appears like both Nouveau and
> Radeon may use pci_map_page() when populating TTMs on
> pages obtained using the ordinary (not DMA pool). These pages will, if I
> understa
https://bugs.freedesktop.org/show_bug.cgi?id=69983
--- Comment #7 from Chris Rankin ---
(In reply to comment #6)
> Have you tried a clean build, i.e. after at least make clean?
When I bisected this, I was performing "make distclean" each time.
--
You are receiving this mail because:
You are th
On 10/01/2013 12:34 PM, Lucas Stach wrote:
Am Dienstag, den 01.10.2013, 12:16 +0200 schrieb Thomas Hellstrom:
Jerome, Konrad
Forgive an ignorant question, but it appears like both Nouveau and
Radeon may use pci_map_page() when populating TTMs on
pages obtained using the ordinary (not DMA pool).
https://bugs.freedesktop.org/show_bug.cgi?id=69983
--- Comment #8 from Jos van Wolput ---
(In reply to comment #6)
> Have you tried a clean build, i.e. after at least make clean?
Yes, I did make clean to get a clean build.
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=69961
--- Comment #4 from samit vats ---
I am getting segmentation fault on startx after building glamor with
--enable-xv
Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x55f4f8]
1: /usr/bin/X (0x40+0x1631b9) [0x5631b9]
2: /lib/x86_64-linux-gnu/
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #17 from Pinak Ahuja ---
Would it be useful to look into the clock calculation code or is my BIOS buggy?
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
Am Dienstag, den 01.10.2013, 13:13 +0200 schrieb Thomas Hellstrom:
> On 10/01/2013 12:34 PM, Lucas Stach wrote:
> > Am Dienstag, den 01.10.2013, 12:16 +0200 schrieb Thomas Hellstrom:
> >> Jerome, Konrad
> >>
> >> Forgive an ignorant question, but it appears like both Nouveau and
> >> Radeon may use
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #140 from Alex Deucher ---
(In reply to comment #139)
>
> I tried exiting early out of a few other functions like rv6xx_dpm_init, but
> haven't had any better results. I put a printk statement in _init, which
> never got printed.. C
CC drivers/gpu/drm/drm_edid_load.o
drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
include/linux/err.h:39:17: warning: ‘edid’ may be used uninitialised in this
function [-Wuninitialized]
drivers/gpu/drm/drm_edid_load.c:141:22: note: ‘edid’ was declared here
In the pr
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #11 from Alex Deucher ---
(In reply to comment #10)
> Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
>
Not exactly. Mclk is tied to vddci (memory interface voltage), but both mclk
and sclk (and the core
From: Ville Syrjälä
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
Si
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #12 from Alexandre Demers ---
(In reply to comment #11)
> (In reply to comment #10)
> > Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
> >
>
> Not exactly. Mclk is tied to vddci (memory interface voltage
On Thu, Sep 26, 2013 at 08:05:58PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> VGA whack-a-mole!
>
> We need VGA to be disabled whenever our driver is working. So even
> without reproducible bugs this patch makes sense, but we do have a bug
> solved by this patch.
>
> If you boot a Hasw
On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The consoles who need to do something when unbinding or binding can
> optionally implement these functions.
>
> The current problem I'm trying to solve is that when i915+fbcon is
> loaded on Haswell, if we dis
On Tue, Oct 01, 2013 at 12:16:16PM +0200, Thomas Hellstrom wrote:
> Jerome, Konrad
>
> Forgive an ignorant question, but it appears like both Nouveau and
> Radeon may use pci_map_page() when populating TTMs on
> pages obtained using the ordinary (not DMA pool). These pages will,
> if I understand
On Tue, Oct 1, 2013 at 4:54 PM, LECOUSIN Etienne wrote:
> I’m very interrested by Diamen Lespiau’s work on intel 3D support,
> including intel-gpu-tools and drm.
>
> I’ve seen that his work will be merged in the next linux kernel revision,
> is that mean that it will be for the 3.12 final ker
https://bugs.freedesktop.org/show_bug.cgi?id=64649
Kai changed:
What|Removed |Added
Attachment #79573|0 |1
is obsolete||
On Mon, Sep 30, 2013 at 01:41:13PM +0100, Damien Lespiau wrote:
> The kernel series has been pushed to drm-intel, the libdrm patches should
> follow if there isn't any objection.
Swiftly pushed.
--
Damien
___
dri-devel mailing list
dri-devel@lists.free
On Tue, Oct 01, 2013 at 02:06:13PM +0100, Chris Wilson wrote:
> CC drivers/gpu/drm/drm_edid_load.o
> drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
> include/linux/err.h:39:17: warning: ‘edid’ may be used uninitialised in this
> function [-Wuninitialized]
> drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=69922
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
On Tue, Oct 01, 2013 at 06:49:42PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 01, 2013 at 02:06:13PM +0100, Chris Wilson wrote:
> > CC drivers/gpu/drm/drm_edid_load.o
> > drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
> > include/linux/err.h:39:17: warning: ‘edid’ may
https://bugs.freedesktop.org/show_bug.cgi?id=69961
--- Comment #5 from Michel Dänzer ---
(In reply to comment #4)
> I am getting segmentation fault on startx after building glamor with
That looks like https://bugs.freedesktop.org/show_bug.cgi?id=69463#c7 though,
not related to the glamor_xv_init
On 09/30/2013 01:27 PM, Peter Hurley wrote:
On 09/03/2013 09:45 PM, Ben Skeggs wrote:
Well, we can't just go around breaking stuff deliberately for the
people still using them!
I've blacklisted them myself and merged the patch.
Ben,
This patch causes my dual-head Quadro FX570 (G84) to fail t
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #13 from Alexandre Demers ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
> > >
> >
> > Not exactly. Mclk is t
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
> From: Mayuresh Kulkarni
>
> This far we have enabled gr2d clock on device probe and disabled
> it on device deinitialisation. This patch adds runtime pm support
> for the hardware unit allowing dynamic power management. If pm
> runtime is not enabl
On Tue, Oct 01, 2013 at 04:47:04PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 26, 2013 at 08:05:58PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > VGA whack-a-mole!
> >
> > We need VGA to be disabled whenever our driver is working. So even
> > without reproducible bugs this patch make
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
> From: Mayuresh Kulkarni
>
> This patch adds runtime pm support for host1x hardware unit. This
> allows host1x clock to be turned off when it is idle. If pm runtime
> is not configured, we enable host1x clock in device probe and disable
> it in remo
https://bugs.freedesktop.org/show_bug.cgi?id=65611
--- Comment #5 from Christian König ---
(In reply to comment #4)
> Still didn't work properly though as XBMC seems to not bother asking the
> driver what it can do and just blindly assumes that every format is
> available...
Which is pretty much
https://bugzilla.kernel.org/show_bug.cgi?id=60858
--- Comment #18 from Christian König ---
(In reply to Pinak Ahuja from comment #17)
> Would it be useful to look into the clock calculation code or is my BIOS
> buggy?
The calculation seems to be fine, it's either your BIOS that has incorrect
inf
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #141 from Bryan Quigley ---
In /r600_dpm.c - void r600_start_dpm(struct radeon_device *rdev)
+ //return; //returning here works
r600_enable_sclk_control(rdev, true);
+ return; //returning here doesn't.
Will jus
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #142 from Bryan Quigley ---
- r600_enable_sclk_control(rdev, true);
+ r600_enable_sclk_control(rdev, false);
Does indeed fix it.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #143 from Alex Deucher ---
(In reply to comment #142)
> - r600_enable_sclk_control(rdev, true);
> + r600_enable_sclk_control(rdev, false);
> Does indeed fix it.
Unfortunately, that disables dynamic engine scaling which on
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #25 from pasqual milvaques ---
Is there any provision about when the patches will be included in the stable
kernel? 3.11.3 is out today and doesn't contain the fix
Thanks
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=69671
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=63599
--- Comment #29 from wojtek ---
Created attachment 86938
--> https://bugs.freedesktop.org/attachment.cgi?id=86938&action=edit
sumo2.patch
simple patch that's fix problem on my system :)
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #22 from Alex Deucher ---
Created attachment 86939
--> https://bugs.freedesktop.org/attachment.cgi?id=86939&action=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=70019
Priority: medium
Bug ID: 70019
Assignee: dri-devel@lists.freedesktop.org
Summary: [RV670] GPU lockup and screen garbage on splash screen
and in GNOME
Severity: critical
C
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #1 from Nikolay Amiantov ---
Created attachment 86942
--> https://bugs.freedesktop.org/attachment.cgi?id=86942&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #2 from Nikolay Amiantov ---
Created attachment 86943
--> https://bugs.freedesktop.org/attachment.cgi?id=86943&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #3 from Nikolay Amiantov ---
Also, it was running with dpm=1 aspm=0 now, but disabling dpm (or removing all
options, which should be the same) doesn't help a bit. ASPM option was tried
just in case.
--
You are receiving this mail be
This set adds some missing devicetree nodes to the exynos5250-snow file as well
as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in
the exynos5250-snow board.
Sean
Sean Paul (5):
ARM: dts: Add fimd display-timings for exynos5250-snow
ARM: dts: Add dp-controller node
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-snow.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.d
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
d
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul
---
drivers/gpu/
This patch adds a node for the ptn3460 DP-LVDS chip in the
exynos5250-snow board dts file.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #4 from Nikolay Amiantov ---
One last thing: everything seems okay at login screen, but not before and
after, and from logs it looks like GPU is resetting successfully. Also,
consoles work.
--
You are receiving this mail because:
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=70019
--- Comment #5 from Alex Deucher ---
Might be a duplicate of bug 69983. Does reverting to an older version of mesa
fix the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=56081
--- Comment #13 from wojtek ---
you can try
https://bugs.freedesktop.org/show_bug.cgi?id=63599#c29
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #13 from Adam Honse ---
To follow up with my previous comment, I tried disabling the discrete GPU. In
my case I disable it AFTER the radeon module is loaded (because doing it the
other way around causes errors that lag the machine to
https://bugs.freedesktop.org/show_bug.cgi?id=69689
--- Comment #4 from Johannes Jordan ---
I still have the problem and I can reproduce it. I am very willing to help in
debugging the issue if you give me directions.
--
You are receiving this mail because:
You are the assignee for the bug.
_
On 10/01/2013 09:14 PM, Stephen Warren wrote:
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
@@ -327,11 +336,48 @@ static int __exit gr2d_remove(struct platform_device
*pdev)
host1x_syncpt_free(gr2d->c
On 10/01/2013 09:17 PM, Stephen Warren wrote:
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
From: Mayuresh Kulkarni
This patch adds runtime pm support for host1x hardware unit. This
allows host1x clock to be turned off when it is idle. If pm runtime
is not configured, we enable host1x clock i
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #14 from Alexandre Demers ---
Created attachment 86945
--> https://bugs.freedesktop.org/attachment.cgi?id=86945&action=edit
A small simplification to low state adjustment
This doesn't solve the problem, but it simplifies a bit the
62 matches
Mail list logo
