This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin
Signed-off-by: Ilia Mirkin
---
The actual testing
From: Mark Brown
Ensure that all externally accessed functions are correctly prototyped
when defined in each file by making sure the headers with the protoypes
are included in the file with the definition.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 1 +
drive
Convert drivers/gpu/drm class to use dev_pm_ops for power management and
remove Legacy PM ops hooks. With this change, drm class registers
suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy
class->suspend/resume. When __device_suspend() runs call-backs, it will
find class->pm ops
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
Hi guys,
I recently got the rMBP 10,1 model, it has two graphic cards:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M
Mac Edition] (rev a1)
I'm running linux
On 07/01/2013 10:30 PM, Daniel Drake wrote:
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we
On 07/01/2013 11:55 PM, Rob Clark wrote:
On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
wrote:
- TDA998x irq handling - ignored
- TDA998x sync fix - ignored
At least the sync fix, looks like I missed it (it probably is a good
idea to CC me if you want me to look at it). Looks like th
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek wrote:
> On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter wrote:
>> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote:
>>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell
>>> wrote:
Hi all,
Changes since 20130628:
The regula
2013/6/28 Joshua C. :
> 2013/6/27 Alex Deucher :
>> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. wrote:
>>> 2013/6/26 Deucher, Alexander :
> -Original Message-
> From: Joshua C. [mailto:joshua...@gmail.com]
> Sent: Wednesday, June 26, 2013 1:52 PM
> To: dri-devel@li
On 07/02/13 03:57, Daniel Drake wrote:
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it. Yo
On Tue, Jul 02, 2013 at 09:21:32PM +0900, Inki Dae wrote:
> > Ensure that all externally accessed functions are correctly prototyped
> > when defined in each file by making sure the headers with the protoypes
> > are included in the file with the definition.
> I don't see why this patch is needed
Dear all,
Recently I've come across this article about a probable fix for my
laptop's black screen on boot:
http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_death_on_machines_with_Intel_HD_video.html
I've tried the fix and it works perfectly so I'm contacting you as
di
Hi,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not "hotpluggable" - it is not possible for the drm_device
to be initialised without an
On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrjälä wrote:
> On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> > wrote:
> > > | Default Colorimetry
> > > |
> > > | ...
> > > |
> > > | 480p, 480i, 576p, 576i, 240p and
On Tue, 2 Jul 2013 11:43:59 -0600
Daniel Drake wrote:
> Hi,
Hi Daniel,
> I'm looking into implementing devicetree support in armada_drm and
> would like to better understand the best practice here.
>
> Adding DT support for a DRM driver seems to be complicated by the fact
> that DRM is not "ho
On Tue, Jul 02, 2013 at 11:43:59AM -0600, Daniel Drake wrote:
> exynos seems to take a the same approach. Components are separate in
> the device tree, and each component is implemented as a platform
> driver or i2c driver. However all the drivers are built together in
> the same module, and the mo
On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> I will point out that relying on driver probing orders has already been
> stated by driver model people to be unsafe. This is why I will not
> adopt such a solution for my driver; it is a bad design.
Just to clarify, what you're objecting to
On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
> On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> > I will point out that relying on driver probing orders has already been
> > stated by driver model people to be unsafe. This is why I will not
> > adopt such a solution for my
On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
> It seems that you did not look at the NVIDIA Tegra driver (I got its
> general concept for my own driver, but I used a simple atomic counter):
>
> - at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
> the DT
On 07/02/2013 09:19 PM, Russell King wrote:
On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
It seems that you did not look at the NVIDIA Tegra driver (I got its
general concept for my own driver, but I used a simple atomic counter):
- at probe time, the main driver (drivers
On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself shou
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a
On 07/02/2013 11:04 PM, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
wrote:
I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them by default (status = "disabled"
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
> Have you also considered how suspend/resume works in such a place,
> where every driver is independent? The ChromeOS guys have bitched
> before about the exynos driver which is has lots of sub-drivers, how
> do you control the s/r order
On Tue, Jul 02, 2013 at 11:14:45PM +0100, Russell King wrote:
> On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
> > Have you also considered how suspend/resume works in such a place,
> > where every driver is independent? The ChromeOS guys have bitched
> > before about the exynos drive
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> Behalf Of Russell King
> Sent: Wednesday, July 03, 2013 4:08 AM
> To: Daniel Drake
> Cc: Jean-François Moine; devicetree-d
From: YoungJun Cho
When IOMMU is not supported, buf->pages has to be allocated to
assign the result of phys_to_page() which return type is struct
page *. So it is sufficient to allocate buf->pages with the size
of multiple struct page pointers.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-W
From: YoungJun Cho
If the type of object is pointer array, the drm_calloc_large() is
more suitable than kzalloc() for its allocation function. And uses
drm_free_large() instead of kfree() also.
Signed-off-by: YoungJun Cho
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/
There were duplicated error handling routines during allocating
pages in lowlevel_buffer_allocate() and g2d_userptr_get_dma_addr().
Also unnecessary NULL assignments for variable used not any more
are removed from g2d_userptr_get_dma_addr() and
g2d_userptr_put_dma_addr().
Signed-off-by: Seung-Woo
On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> Hi guys,
>
> I recently got the rMBP 10,1 model, it has two graphic cards:
>
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Cor
Alex Deucher wrote, on 07/03/2013 00:49:
> On Tue, Jul 2, 2013 at 4:34 PM, Jörg-Volker Peetz wrote:
>> Alex Deucher wrote, on 07/02/2013 22:17:
>>> On Tue, Jul 2, 2013 at 4:15 PM, Jörg-Volker Peetz wrote:
Alex Deucher wrote, on 07/02/2013 21:46:
> On Tue, Jul 2, 2013 at 10:09 AM, Jörg-Vo
https://bugs.freedesktop.org/show_bug.cgi?id=66519
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=66519
--- Comment #5 from Christian König ---
Created attachment 81945
--> https://bugs.freedesktop.org/attachment.cgi?id=81945&action=edit
Debugging patch
Please try the attached patch, it shouldn't fix the issue but instead outputs
some debug mess
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> Behalf Of Sebastian Hesselbarth
> Sent: Wednesday, July 03, 2013 6:41 AM
> To: Daniel Drake
> Cc: Jean-Francois Moine; dev
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
> > video {
> > /* Single video card w/ multiple lcd controllers */
> > card0 {
> > compatible = "marvell,armada-510-display";
> > reg = <0 0x3f00 0x100>; /* video-mem hole */
> > /* later:
There are two break statements in a row.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
index 3be7b95..f1c0767 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
+++ b/drivers/gpu/
> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
> Sent: Wednesday, July 03, 2013 6:09 PM
> To: Sascha Hauer
> Cc: Inki Dae; 'Daniel Drake'; 'Jean-Francois Moine'; devicetree-
> disc...@lists.ozlabs.org; 'Russell King'; dri-devel@lists.freedeskto
Fixes parallel piglit runs on fermi with boot clock speeds.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 1e753b0..460dd00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouvea
https://bugs.freedesktop.org/show_bug.cgi?id=66519
--- Comment #6 from Justin Piszcz ---
attach(In reply to comment #5)
> Created attachment 81945 [details] [review]
> Debugging patch
>
> Please try the attached patch, it shouldn't fix the issue but instead
> outputs some debug messages ("IH: CP
https://bugs.freedesktop.org/show_bug.cgi?id=66519
--- Comment #7 from Justin Piszcz ---
Created attachment 81952
--> https://bugs.freedesktop.org/attachment.cgi?id=81952&action=edit
dmesg with patch
--
You are receiving this mail because:
You are the assignee for the bug.
___
Hi Dave,
Pile of fixes for 3.11. A bit large in patch count, but that's simply due
to two fixes being split up into really small parts. Also I've included a
few more vlv patches than I'd have included for other platforms. But since
vlv is officially supported for the first time only in 3.11 that s
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
> >
> > +1 for not encoding the projected usecase of the graphics subsystem into
> > the devicetree. Whether the two LCD controllers shall be used together
> > or separatel
> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
> Sent: Wednesday, July 03, 2013 7:53 PM
> To: Russell King
> Cc: Inki Dae; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-Francois Moine';
> devicetree-disc...@lists.ozlabs.org; dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=66519
--- Comment #8 from Christian König ---
Please do a "make clean" then and fully recompile your kernel.
The kernel makefile doesn't recognize it when you change the firmware on the
disk and still builds the old firmware file into the kernel.
--
Am Dienstag, den 02.07.2013, 18:46 -0700 schrieb Stéphane Marchesin:
> On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie wrote:
> > On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer wrote:
> >> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
> >>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Seba
On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote:
> Hi Chris,
>
> > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > > Hi guys,
> > >
> > > I recently got the rMBP 10,1 model, it has two graphic cards:
> > >
> > > 00:02.0 VGA compatible controller: Intel Corporation 3r
https://bugs.freedesktop.org/show_bug.cgi?id=64850
--- Comment #20 from Jakob Nixdorf ---
Just FYI:
This bug is still present with kernel 3.10.0 and the newest firmware from git.
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Wed, Jul 3, 2013 at 3:14 AM, Jörg-Volker Peetz wrote:
> Alex Deucher wrote, on 07/03/2013 00:49:
>> On Tue, Jul 2, 2013 at 4:34 PM, Jörg-Volker Peetz wrote:
>>> Alex Deucher wrote, on 07/02/2013 22:17:
On Tue, Jul 2, 2013 at 4:15 PM, Jörg-Volker Peetz wrote:
> Alex Deucher wrote, on
https://bugs.freedesktop.org/show_bug.cgi?id=66519
--- Comment #9 from Justin Piszcz ---
(In reply to comment #8)
> Please do a "make clean" then and fully recompile your kernel.
>
> The kernel makefile doesn't recognize it when you change the firmware on the
> disk and still builds the old firm
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Tuesday, July 02, 2013 3:41 PM
To: Justin Piszcz
Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org
Subject: Re: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error
initializing UVD (-1).
Pl
On Wed, Jul 3, 2013 at 2:39 AM, Ruslan N. Marchenko wrote:
> Am 01.07.2013 23:01, schrieb alexdeuc...@gmail.com:
>>
>> From: Alex Deucher
>>
>> Hi Dave,
>>
>> A few more patches for 3.11:
>> - add debugfs interface to check current DPM state
>> - Fix a bug that caused problems with DPM on BTC+ asi
https://bugs.freedesktop.org/show_bug.cgi?id=66519
Alex Deucher changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66519
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #10 from Christian
https://bugs.freedesktop.org/show_bug.cgi?id=66551
Priority: medium
Bug ID: 66551
Assignee: dri-devel@lists.freedesktop.org
Summary: System hang when DPM enabled on rs780.
Severity: normal
Classification: Unclassified
OS: Al
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #6 from Christian König ---
(In reply to comment #5)
> Pretty sure the instability has nothing to do with this.
Good to know, well at least this bug loses a bit priority then.
> As far as I can tell, this would happen whenever the s
https://bugs.freedesktop.org/show_bug.cgi?id=66473
--- Comment #1 from Andy Furniss ---
It seems that this only happens on the second mem sleep - so to trigger it
looks like I need to boot with tv off, turn on tv but not enaable, sleep and
resume, then sleep again will give oops.
--
You are rec
Hi Dave,
On Wednesday 03 July 2013 10:17:34 Dave Airlie wrote:
> On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart wrote:
> > On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Release because I want the cursor ioctls released,
> >
On Wed, Jul 3, 2013 at 3:20 PM, Laurent Pinchart
wrote:
> Hi Dave,
>
> On Wednesday 03 July 2013 10:17:34 Dave Airlie wrote:
>> On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart wrote:
>> > On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Priority: medium
Bug ID: 66558
Assignee: dri-devel@lists.freedesktop.org
Summary: RS690: 3D artifacts when playing SuperTuxKart
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #1 from Björn Beutel ---
Created attachment 81978
--> https://bugs.freedesktop.org/attachment.cgi?id=81978&action=edit
glxinfo output
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #2 from Björn Beutel ---
Created attachment 81979
--> https://bugs.freedesktop.org/attachment.cgi?id=81979&action=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Alex Deucher changed:
What|Removed |Added
Attachment #81975|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #3 from Alex Deucher ---
Is this a regression? If so, can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=66349
--- Comment #1 from Vadim Girlin ---
Please attach the output with "R600_DEBUG=sb,ps,vs".
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #4 from Björn Beutel ---
Created attachment 81980
--> https://bugs.freedesktop.org/attachment.cgi?id=81980&action=edit
Patch that sets the needed CS buffer size in "r300_render_draw_elements"
The attached patch solves the problem f
https://bugs.freedesktop.org/show_bug.cgi?id=66558
--- Comment #5 from Björn Beutel ---
@Alex Deucher:
AFAIK, that bug has been in r300g from its very beginnings (in contrast to
r300c).
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66349
--- Comment #2 from Thomas Lindroth ---
Created attachment 81982
--> https://bugs.freedesktop.org/attachment.cgi?id=81982&action=edit
output with R600_DEBUG=sb,ps,vs
Steam also use opengl to draw it's UI so some of these shaders comes from it.
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(),
From: Chris Wilson
Clients like i915 needs to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation o
From: Alex Deucher
Hi Dave,
A few more DPM fixes.
The following changes since commit 7982128c3d447df27db963af67bc6b8dc7efb1de:
drm/radeon/dpm: add debugfs support for SI (2013-07-01 16:09:06 -0400)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/linux drm-next-
Hi Joonyoung,
Thank you for the patches.
On Friday 28 June 2013 14:24:43 Joonyoung Shim wrote:
> Hello,
>
> This is the second version patchset.
>
> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
> dma_buf. We can use prime helpers for dma_buf by commit
> 89177644a7b63
Working on KMS support on OpenBSD/sparc64, I ended up with the initial
framebuffer on a Sun XVR-100 card (Radeon 7000/VE, RV100 with
OpenFirmware) being tiled when none of the tiling flags were set.
Tracked it down to an issue with r100_set_surface_reg(). The tiling
bits on these older chips are a
https://bugzilla.kernel.org/show_bug.cgi?id=60381
Summary: AMD Radeon 7770 Ghz edition Crash with DPM active
Product: Drivers
Version: 2.5
Kernel Version: 3.10.0-next-20130703
Platform: All
OS/Version: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #1 from rafael castillo 2013-07-04 00:38:04
---
Created an attachment (id=106741)
--> (https://bugzilla.kernel.org/attachment.cgi?id=106741)
glxinfo
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #2 from rafael castillo 2013-07-04 00:38:24
---
Created an attachment (id=106751)
--> (https://bugzilla.kernel.org/attachment.cgi?id=106751)
lspci
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
-
https://bugzilla.kernel.org/show_bug.cgi?id=60381
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #3 f
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #4 from rafael castillo 2013-07-04 01:11:51
---
thanks for your response, im attaching the vbios info but im unable to get an
dmesg output in the moment of the crash since it kicks in kms load and
hangs[keyboard keys blinking] an
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #5 from rafael castillo 2013-07-04 01:12:10
---
Created an attachment (id=106781)
--> (https://bugzilla.kernel.org/attachment.cgi?id=106781)
vbios.rom
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
-
> I certainly don't pull patches in from others to it very often, and
> modetest I generally blame on jbarnes.
>
Speaking of forgotten patches, could someone with the commit access please
pick up this one:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030852.html
ATI DDX already
> -Original Message-
> From: Russell King [mailto:r...@arm.linux.org.uk]
> Sent: Wednesday, July 03, 2013 9:05 PM
> To: Inki Dae
> Cc: 'Sebastian Hesselbarth'; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-
> Francois Moine'; devicetree-disc...@lists.ozlabs.org; dri-
> de...@lists.freedesktop.org
Alex Deucher wrote, on 07/03/2013 00:49:
> On Tue, Jul 2, 2013 at 4:34 PM, Jörg-Volker Peetz wrote:
>> Alex Deucher wrote, on 07/02/2013 22:17:
>>> On Tue, Jul 2, 2013 at 4:15 PM, Jörg-Volker Peetz wrote:
Alex Deucher wrote, on 07/02/2013 21:46:
> On Tue, Jul 2, 2013 at 10:09 AM, Jörg-Vo
On 07/03/13 08:55, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
Have you also considered how suspend/resume works in such a place,
where every driver is independent? The ChromeOS guys have bitched
before about the exynos driver which is has lots of sub-drivers
On 07/03/13 11:02, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = "marvell,armada-510-display";
reg = <0 0x3f00 0x100>; /* video
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
> > > video {
> > > /* Single video card w/ multiple lcd controllers */
> > > card0 {
> > > compatible = "marvell,armada-510-display";
> > > reg = <0 0x3
On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
> That's not whether we can write device driver or not. dtsi is common spot in
> other subsystems. Do you think the cardX node is meaningful to other
> subsystems?
Yes, because fbdev could also use it to solve the same problem which we're
h
On 07/03/13 11:53, Russell King wrote:
On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
That's not whether we can write device driver or not. dtsi is common spot in
other subsystems. Do you think the cardX node is meaningful to other
subsystems?
Yes, because fbdev could also use it to
On 07/03/13 11:52, Russell King wrote:
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = "marvell,armada-510-dis
On 07/03/13 13:43, Inki Dae wrote:
I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.
So, of course, lcd controller nodes and dcon are part of dove.dtsi
because they are physically available on every D
Hi Chris,
> On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > Hi guys,
> >
> > I recently got the rMBP 10,1 model, it has two graphic cards:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> > processor Graphics Controller (rev 09)
> > 01:00.0 VGA compati
On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
> But honestly, I see no way around it and it is the only way
> to allow to even have the decision for one or two cards at all.
> There is no way for auto-probing the users intention...
It's not _just_ about the users intention
On 07/03/13 13:32, Russell King wrote:
On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
But honestly, I see no way around it and it is the only way
to allow to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention...
Russ
Dear Chris Wilson,
> On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote:
> > Hi Chris,
> >
> > > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > > > Hi guys,
> > > >
> > > > I recently got the rMBP 10,1 model, it has two graphic cards:
> > > >
> > > > 00:02.0 VGA compa
On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote:
> In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
> and lcd1 drivers which are placed in drivers/video/backlight/.
No, that's totally wrong. Framebuffer drivers are not backlights.
Framebuffer drivers go in driv
On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer wrote:
> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
>> > I am against a super node which contains lcd and dcon/ire nodes. You can
>> > enable those devices on a
Hi Dave,
On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Release because I want the cursor ioctls released,
> also haswell and radeon ids.
Any chance to get the "[PATCH v6 00/23] modetest enhancements" series included
in the next release
Hi David,
On Monday 01 July 2013 20:32:57 David Herrmann wrote:
> Hi
>
> I picked up the initial work from Dave [1], fixed several bugs, rewrote the
> drm_mm node handling and adjusted the different drivers.
> The series tries to replace the VMA-offset managers from GEM and TTM with a
> single un
ri-devel
> >>
> >> --
> >> Ville Syrj?l?
> >> Intel OTC
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/a130c657/attachment-0001.html>
On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart
wrote:
> Hi Dave,
>
> On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Release because I want the cursor ioctls released,
>> also haswell and radeon ids.
>
> Any chance to get the "[PATCH
Applied.
Thanks,
Inki Dae
2013/7/1 Seung-Woo Kim :
> From: YoungJun Cho
>
> The exynos_drm_gem_create() only calls drm_gem_object_release()
> when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains
> as a leak, which is allocated in exynos_drm_gem_init().
> So this patch fixes it not t
1 - 100 of 168 matches
Mail list logo
