Regression: drm/radeon: brightness control hard system lockup

[Eldad Zack]

On Mon, 7 Jan 2013, Alex Deucher wrote:
> On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack  wrote:
> >
> > Hi Alex,
> >
> > Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
> > finer grained reset for evergreen" introduced a hard system lockup to my
> > setup. I found it after bisecting, and confirmed it by reverting it on
> > the latest mainline ( 5f243b9 ).
> >
> > This:
> >
> >echo 7 > 
> > /sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0/brightness
> >
> > Causes a hard lock-up hard, i.e. immediate freeze, without any logs.
> >
> > See lspci output and kernel .config below.
> > If there's any more info I can provide, please let me know.
> 
> Do you normally see GPU resets when changing the backlight?  Please
> attach your dmesg output when changing the backlight with the patch
> reverted.

I see nothing. Just to make sure, I cleared the buffer, cycled through 
0-7 a couple of hunderd times (until the flicker annoyed), but I see no
messages at all.
Is there any debug config I should turn on?

Turning ACPI debugging on gives me no messages neither when I use the 
cycle script.

But I did find out something interesting enough, only because I 
happen to have sound debugging on, if I have a PCM stream open to a
USB device, and then change the backlight level, it seems to drop to
microframes, but it's not otherwise noticeable. Looks like setting the
backlight still does something weird with my hardware/config.

Below is a grep -i radeon from my boot dmesg.

Cheers,
Eldad

[0.301558] [drm] radeon defaulting to kernel modesetting.
[0.301626] [drm] radeon kernel modesetting enabled.
[0.301694] bus: 'pci': add driver radeon
[0.301716] bus: 'pci': driver_probe_device: matched device :01:00.0 
with driver radeon
[0.301718] bus: 'pci': really_probe: probing driver radeon with device 
:01:00.0
[0.302310] radeon :01:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)
[0.302390] radeon :01:00.0: GTT: 512M 0x4000 - 
0x5FFF
[0.303021] [drm] radeon: 1024M of VRAM memory ready
[0.303108] [drm] radeon: 512M of GTT memory ready.
[0.303378] radeon :01:00.0: irq 41 for MSI/MSI-X
[0.303390] radeon :01:00.0: radeon: using MSI.
[0.303485] [drm] radeon: irq initialized.
[0.304198] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[0.304414] Registering platform device 'radeon_cp.0'. Parent at platform
[0.304416] device: 'radeon_cp.0': device_add
[0.304421] bus: 'platform': add device radeon_cp.0
[0.304428] PM: Adding info for platform:radeon_cp.0
[0.304497] platform radeon_cp.0: firmware: using built-in firmware 
radeon/TURKS_pfp.bin
[0.304501] platform radeon_cp.0: firmware: using built-in firmware 
radeon/TURKS_me.bin
[0.304503] platform radeon_cp.0: firmware: using built-in firmware 
radeon/BTC_rlc.bin
[0.304506] platform radeon_cp.0: firmware: using built-in firmware 
radeon/TURKS_mc.bin
[0.304517] bus: 'platform': remove device radeon_cp.0
[0.304518] PM: Removing info for platform:radeon_cp.0
[0.338906] radeon :01:00.0: WB enabled
[0.338970] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0x880244a0fc00
[0.339064] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0x880244a0fc0c
[0.356604] device: 'radeon_bl0': device_add
[0.356616] PM: Adding info for No Bus:radeon_bl0
[0.407974] [drm] radeon atom DIG backlight initialized
[0.408039] [drm] Radeon Display Connectors
[0.410135] [drm] radeon: power management initialized
[0.822297] fbcon: radeondrmfb (fb0) is primary device
[1.585493] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[1.585546] radeon :01:00.0: registered panic notifier
[1.585601] [drm] Initialized radeon 2.28.0 20080528 for :01:00.0 on 
minor 0
[1.585658] driver: ':01:00.0': driver_bound: bound to device 'radeon'
[1.585661] bus: 'pci': really_probe: bound device :01:00.0 to driver 
radeon

[PATCH] drm: Only evict the blocks required to create the requested hole

[Daniel Vetter]

On Wed, Dec 19, 2012 at 04:51:06PM +, Chris Wilson wrote:
> Avoid clobbering adjacent blocks if they happen to expire earlier and
> amalgamate together to form the requested hole.
> 
> In passing this fixes a regression from
> commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
> Author: Daniel Vetter 
> Date:   Fri Feb 18 17:59:12 2011 +0100
> 
> drm: mm: track free areas implicitly
> 
> which swaps the end address for size (with a potential overflow) and
> effectively causes the eviction code to clobber almost all earlier
> buffers above the evictee.
> 
> v2: Check the original hole not the adjusted as the coloring may confuse
> us when later searching for the overlapping nodes. Also make sure that
> we do apply the range restriction and color adjustment in the same
> order for both scanning, searching and insertion.
> 
> v3: Send the version that was actually tested.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

Picked up for -fixes with bugzilla link and Norberts tested-by added,
thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=59089

--- Comment #1 from Alex Deucher  ---
Should be fixed with this mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935

-- 
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/20130107/63add791/attachment.html>

[Bug 58667] Random crashes on CAYMAN

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=58667

--- Comment #30 from Alex Deucher  ---
Should be fixed with this mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935

-- 
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/20130107/d8879463/attachment.html>

radeon CS parser refactoring

[Ilija Hadzic]

On Mon, Jan 7, 2013 at 7:21 PM, Marek Ol??k  wrote:
>
> IIRC, the radeon gallium drivers call abort() if they encounter an
> unsupported DRM version (that is UMS).
>

I am not familiar enough to comment, but my observation was that as
soon as I backed out to classic, the segfault went away. So I assumed
that the mismatch between the UMS and Gallium was the cause.

Anyway, it's a secondary issue for this thread.

-- Ilija

Fan control in nouveau driver with geforce 9600gt

[Ozan Çağlayan]

> We will be waiting a until one kernel is released before activating fan
> management by default.

So these fan stuff will be merged into 3.9?



-- 
Ozan ?a?layan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com

[PATCH 3/3] drm/radeon: fix error path in kpage allocation

[Ilija Hadzic]

Index into chunks[] array doesn't look right.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 45151c4..469661f 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -284,8 +284,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
p->chunks[p->chunk_ib_idx].kpage[1] = 
kmalloc(PAGE_SIZE, GFP_KERNEL);
if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {
-   kfree(p->chunks[i].kpage[0]);
-   kfree(p->chunks[i].kpage[1]);
+   kfree(p->chunks[p->chunk_ib_idx].kpage[0]);
+   kfree(p->chunks[p->chunk_ib_idx].kpage[1]);
return -ENOMEM;
}
}
-- 
1.8.1

[PATCH 2/3] drm/radeon: fix a bogus kfree

[Ilija Hadzic]

parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.

This patch fixes a kernel oops that can be provoked
in UMS mode.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/r600_cs.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..f8adb01 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2476,8 +2476,10 @@ static void r600_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
kfree(parser->relocs);
for (i = 0; i < parser->nchunks; i++) {
kfree(parser->chunks[i].kdata);
-   kfree(parser->chunks[i].kpage[0]);
-   kfree(parser->chunks[i].kpage[1]);
+   if (parser->rdev && (parser->rdev->flags & RADEON_IS_AGP)) {
+   kfree(parser->chunks[i].kpage[0]);
+   kfree(parser->chunks[i].kpage[1]);
+   }
}
kfree(parser->chunks);
kfree(parser->chunks_array);
-- 
1.8.1

[PATCH 1/3] drm/radeon: fix NULL pointer dereference in UMS mode

[Ilija Hadzic]

In UMS mode parser->rdev is NULL, so dereferencing
will cause an oops.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 396baba0..45151c4 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -279,7 +279,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
  p->chunks[p->chunk_ib_idx].length_dw);
return -EINVAL;
}
-   if ((p->rdev->flags & RADEON_IS_AGP)) {
+   if (p->rdev && (p->rdev->flags & RADEON_IS_AGP)) {
p->chunks[p->chunk_ib_idx].kpage[0] = 
kmalloc(PAGE_SIZE, GFP_KERNEL);
p->chunks[p->chunk_ib_idx].kpage[1] = 
kmalloc(PAGE_SIZE, GFP_KERNEL);
if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
@@ -583,7 +583,8 @@ static int radeon_cs_update_pages(struct radeon_cs_parser 
*p, int pg_idx)
struct radeon_cs_chunk *ibc = >chunks[p->chunk_ib_idx];
int i;
int size = PAGE_SIZE;
-   bool copy1 = (p->rdev->flags & RADEON_IS_AGP) ? false : true;
+   bool copy1 = (p->rdev && (p->rdev->flags & RADEON_IS_AGP)) ?
+   false : true;

for (i = ibc->last_copied_page + 1; i < pg_idx; i++) {
if (DRM_COPY_FROM_USER(p->ib.ptr + (i * (PAGE_SIZE/4)),
-- 
1.8.1

fix for crashes provoked by UMS mode

[Ilija Hadzic]

At Dave's request I ran some regression tests on my CS-refactoring
patches [1] against old UMS userspace. The tests have revealed
that the current kernel can be provoked into crashing in UMS mode
(and the problem is unrelated to refactoring of CS code; it has
been here before).

The following patches will fix the problem that I discovered
while testing (and they should probably go to drm-fixes branch).
First two patches are the fix for the acute problem, while
the third patch is a fix for an incidental finding uncovered
while debugging the problem.


[1] http://lists.freedesktop.org/archives/dri-devel/2013-January/032814.html

[PATCH] drm/exynos: Get HDMI version from device tree

[Sean Paul]

On Jan 7, 2013 5:32 PM, "Stephen Warren"  wrote:
>
> On 01/07/2013 01:43 PM, Sean Paul wrote:
> > Add a property to the hdmi node so we can specify the HDMI version in
> > the device tree instead of just defaulting to v1.4 with the existence of
> > the dt node.
>
> > diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>
> > @@ -11,6 +11,8 @@ Required properties:
> >   c) pin function mode.
> >   d) optional flags and pull up/down.
> >   e) drive strength.
> > +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
> > +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3
>
> Which device; the HDMI controller in the SoC, or the HDMI sink?
>

It's the controller.

> The HDMI sync reports what it supports in the EDID, so there shouldn't
> be a need to duplicate this in the device tree (besides, how can you
> know what the user plugged in without parsing the EDID?)
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130107/2c5c4a84/attachment.html>

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #54 from Michel D?nzer  ---
(In reply to comment #53)

Gerald, we can only support the open source drivers here. For fglrx issues
you'll have to turn to fglrx support resources.

-- 
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/20130107/3f9f5d84/attachment.html>

radeon CS parser refactoring

[Ilija Hadzic]

On Fri, 4 Jan 2013, Alex Deucher wrote:

> R6xx and r7xx are really all you need to worry about in this case.
> R1xx-r5xx UMS uses a different kernel interface for command submission
> and evergreen and later don't have UMS drm support.  UMS r6xx/r7xx
> support used the same kernel interface for command submission but the
> kernel side was much simpler.

OK, I have found an old machine with RV730 GPU and a known-working UMS: 
2.6.35 kernel, 6.13.2 DDX, 7.8.2 mesa (classic), 1.9 Xorg). I changed the 
kernel to the latest drm-next and ran tests with and without my 
CS-refactoring patches. Here are the results:

* It appears that drm-next in its current state is broken with regard
   to UMS (nothing to do with my patches, it was pre-broken to begin with).
   UMS provokes the kernel into a NULL-pointer dereference oops. Good news
   is that I have tracked down the crash and I will be sending the patches
   with the fix shortly.

* There are multiple patches that contributed to the breakage of UMS.
   I didn't bother pin-pointing them all, but one that I looked
   (6a7068b4) dates back to April 2012 so there are kernels out in
   distros that crash on UMS. That probably tells us how many UMS
   users are left out there :-). BTW, the reason UMS crashes is
   because parser->rdev is NULL in UMS mode so every patch that tries
   to dereference it (and shares the code path with UMS) will cause an
   oops (it will become clear when you see the patches).

* So, having fixed the above incidental finding, I got my machine
   with ancient UMS-userspace and a shiny latest drm-next kernel (plus
   my CS-refactoring patches plus my yet-to-be-sent UMS fixes) to
   work. My test consists of bringing up Gnome (it's Gnome 2 on that
   machine), running glxgears, sphereworld (an example code from
   OpenGL Superbible book), and OpenArena. Everything seems to work.

* Going back to KMS and retesting there, things still look good.

So this (with tests I did on Friday) should cover all the cases.

> Additionally, UMS requires the old
> non-gallium 3D drivers.  It sounds like some other change in the ddx
> broke UMS support for r6xx/r7xx.

The DDX segfault I reported on Friday was provoked by trying to run 
Gallium 3D driver on the top of UMS. Once I switched back to classic, the 
crash went away. So I guess the userspace crash was provoked by some 
obscure path that was never intended to be exercised. I don't think
it's worth investigating further.

-- Ilija

Regression: drm/radeon: brightness control hard system lockup

[Alex Deucher]

On Mon, Jan 7, 2013 at 4:33 PM, Eldad Zack  wrote:
>
> On Mon, 7 Jan 2013, Alex Deucher wrote:
>> On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack  wrote:
>> >
>> > Hi Alex,
>> >
>> > Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
>> > finer grained reset for evergreen" introduced a hard system lockup to my
>> > setup. I found it after bisecting, and confirmed it by reverting it on
>> > the latest mainline ( 5f243b9 ).
>> >
>> > This:
>> >
>> >echo 7 > 
>> > /sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0/brightness
>> >
>> > Causes a hard lock-up hard, i.e. immediate freeze, without any logs.
>> >
>> > See lspci output and kernel .config below.
>> > If there's any more info I can provide, please let me know.
>>
>> Do you normally see GPU resets when changing the backlight?  Please
>> attach your dmesg output when changing the backlight with the patch
>> reverted.
>
> I see nothing. Just to make sure, I cleared the buffer, cycled through
> 0-7 a couple of hunderd times (until the flicker annoyed), but I see no
> messages at all.
> Is there any debug config I should turn on?

Can you try adding a printk() in evergreen_asic_reset() and see if it
is somehow getting called when you change the brightness?  When you
use the apci backlight control, the radeon driver is not involved at
all.  They only way the driver would get involved is if the acpi
backlight control somehow caused the GPU to hang and then the driver
detected the hang and attempted to reset the GPU.  I don't see any
evidence of a GPU reset in your kernel log however.  Note that the
driver also registers native backlight contol.  Does that work any
better than acpi?

Alex

>
> Turning ACPI debugging on gives me no messages neither when I use the
> cycle script.
>
> But I did find out something interesting enough, only because I
> happen to have sound debugging on, if I have a PCM stream open to a
> USB device, and then change the backlight level, it seems to drop to
> microframes, but it's not otherwise noticeable. Looks like setting the
> backlight still does something weird with my hardware/config.
>
> Below is a grep -i radeon from my boot dmesg.
>
> Cheers,
> Eldad
>
> [0.301558] [drm] radeon defaulting to kernel modesetting.
> [0.301626] [drm] radeon kernel modesetting enabled.
> [0.301694] bus: 'pci': add driver radeon
> [0.301716] bus: 'pci': driver_probe_device: matched device :01:00.0 
> with driver radeon
> [0.301718] bus: 'pci': really_probe: probing driver radeon with device 
> :01:00.0
> [0.302310] radeon :01:00.0: VRAM: 1024M 0x - 
> 0x3FFF (1024M used)
> [0.302390] radeon :01:00.0: GTT: 512M 0x4000 - 
> 0x5FFF
> [0.303021] [drm] radeon: 1024M of VRAM memory ready
> [0.303108] [drm] radeon: 512M of GTT memory ready.
> [0.303378] radeon :01:00.0: irq 41 for MSI/MSI-X
> [0.303390] radeon :01:00.0: radeon: using MSI.
> [0.303485] [drm] radeon: irq initialized.
> [0.304198] [drm] enabling PCIE gen 2 link speeds, disable with 
> radeon.pcie_gen2=0
> [0.304414] Registering platform device 'radeon_cp.0'. Parent at platform
> [0.304416] device: 'radeon_cp.0': device_add
> [0.304421] bus: 'platform': add device radeon_cp.0
> [0.304428] PM: Adding info for platform:radeon_cp.0
> [0.304497] platform radeon_cp.0: firmware: using built-in firmware 
> radeon/TURKS_pfp.bin
> [0.304501] platform radeon_cp.0: firmware: using built-in firmware 
> radeon/TURKS_me.bin
> [0.304503] platform radeon_cp.0: firmware: using built-in firmware 
> radeon/BTC_rlc.bin
> [0.304506] platform radeon_cp.0: firmware: using built-in firmware 
> radeon/TURKS_mc.bin
> [0.304517] bus: 'platform': remove device radeon_cp.0
> [0.304518] PM: Removing info for platform:radeon_cp.0
> [0.338906] radeon :01:00.0: WB enabled
> [0.338970] radeon :01:00.0: fence driver on ring 0 use gpu addr 
> 0x4c00 and cpu addr 0x880244a0fc00
> [0.339064] radeon :01:00.0: fence driver on ring 3 use gpu addr 
> 0x4c0c and cpu addr 0x880244a0fc0c
> [0.356604] device: 'radeon_bl0': device_add
> [0.356616] PM: Adding info for No Bus:radeon_bl0
> [0.407974] [drm] radeon atom DIG backlight initialized
> [0.408039] [drm] Radeon Display Connectors
> [0.410135] [drm] radeon: power management initialized
> [0.822297] fbcon: radeondrmfb (fb0) is primary device
> [1.585493] radeon :01:00.0: fb0: radeondrmfb frame buffer device
> [1.585546] radeon :01:00.0: registered panic notifier
> [1.585601] [drm] Initialized radeon 2.28.0 20080528 for :01:00.0 on 
> minor 0
> [1.585658] driver: ':01:00.0': driver_bound: bound to device 'radeon'
> [1.585661] bus: 'pci': really_probe: bound device :01:00.0 to driver 
> radeon
>
>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57875

--- Comment #20 from Marek Ol??k  ---
FWIW, the extension specification looks good to me.

-- 
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/20130107/61070061/attachment.html>

[PATCH] drm/exynos: Get HDMI version from device tree

[Sean Paul]

On Mon, Jan 7, 2013 at 3:54 PM, Mitch Bradley  wrote:
> On 1/7/2013 10:43 AM, Sean Paul wrote:
>> Add a property to the hdmi node so we can specify the HDMI version in
>> the device tree instead of just defaulting to v1.4 with the existence of
>> the dt node.
>>
>> Signed-off-by: Sean Paul 
>> ---
>>  .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   19 
>> ++-
>>  2 files changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
>> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>> index 589edee..d1c7d91 100644
>> --- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>> +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>> @@ -11,6 +11,8 @@ Required properties:
>>   c) pin function mode.
>>   d) optional flags and pull up/down.
>>   e) drive strength.
>> +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
>> +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3
>
> a) This seems pretty generic, not at all samsung-specific, as the HDMI
> version numbering space is well-defined by the HDMI spec.
>
> b) It would be better to make it an integer property whose value
> encodes the version number, thus eliminating the need to add new
> properties as new HDMI versions appear.
>

Thanks for the quick review, Mitch.

How about:

- hdmi-version: 0=v1.3, 1=v1.4


>>
>>  Example:
>>
>> @@ -19,4 +21,5 @@ Example:
>>   reg = <0x1453 0x10>;
>>   interrupts = <0 95 0>;
>>   hpd-gpio = < 7 0xf 1 3>;
>> + samsung,supports-hdmi-1.4;
>>   };
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 2c46b6c..9834ae5 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -2444,7 +2444,6 @@ static struct platform_device_id hdmi_driver_types[] = 
>> {
>>  static struct of_device_id hdmi_match_types[] = {
>>   {
>>   .compatible = "samsung,exynos5-hdmi",
>> - .data   = (void *)HDMI_TYPE14,
>>   }, {
>>   /* end node */
>>   }
>> @@ -2498,16 +2497,18 @@ static int __devinit hdmi_probe(struct 
>> platform_device *pdev)
>>
>>   platform_set_drvdata(pdev, drm_hdmi_ctx);
>>
>> - if (dev->of_node) {
>> - const struct of_device_id *match;
>> - match = of_match_node(of_match_ptr(hdmi_match_types),
>> - pdev->dev.of_node);
>> - if (match == NULL)
>> - return -ENODEV;
>> - hdata->type = (enum hdmi_type)match->data;
>> - } else {
>> + if (!dev->of_node) {
>>   hdata->type = (enum hdmi_type)platform_get_device_id
>>   (pdev)->driver_data;
>> + } else if (of_get_property(dev->of_node, "samsung,supports-hdmi-1.4",
>> + NULL)) {
>> + hdata->type = HDMI_TYPE14;
>> + } else if (of_get_property(dev->of_node, "samsung,supports-hdmi-1.3",
>> + NULL)) {
>> + hdata->type = HDMI_TYPE13;
>> + } else {
>> + DRM_ERROR("Could not resolve HDMI version support\n");
>> + return -ENODEV;
>>   }
>>
>>   hdata->hpd_gpio = pdata->hpd_gpio;
>>

[PATCH 1/1] drm: Fix comment about drm_exit which has been replaced by drm_platform_exit in 2.6.39

[Philippe De Swert]

Trivial comment fix. Since drm_exit() was removed in 2.6.39 (commit 8410ea3b ). 
As such the comment
is incorrect. drm_put_dev() is now called from drm_platform_exit() or when the 
pci device is "unplugged".

Signed-off-by: Philippe De Swert 
---
 drivers/gpu/drm/drm_stub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 200e104..b39f591 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -445,7 +445,7 @@ static void drm_unplug_minor(struct drm_minor *minor)
 }

 /**
- * Called via drm_exit() at module unload time or when pci device is
+ * Called via drm_platform_exit() at module unload time or when pci device is
  * unplugged.
  *
  * Cleans up all DRM device, calling drm_lastclose().
-- 
1.7.9.5

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57875

--- Comment #19 from Stefan D?singer  ---
Are there any comments on the 2nd extension spec? If it looks good to you I'll
do some tests with the r200 and r500 GPUs I have to see how unclipped Z values
behave in fragment processing to make sure the extension doesn't guarantee
anything the HW cannot provide.

-- 
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/20130107/0954f4fe/attachment.html>

[PATCH] drm/exynos: Get HDMI version from device tree

[Sean Paul]

Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.

Signed-off-by: Sean Paul 
---
 .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   19 ++-
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
index 589edee..d1c7d91 100644
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
@@ -11,6 +11,8 @@ Required properties:
c) pin function mode.
d) optional flags and pull up/down.
e) drive strength.
+- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
+- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

 Example:

@@ -19,4 +21,5 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = < 7 0xf 1 3>;
+   samsung,supports-hdmi-1.4;
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..9834ae5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2444,7 +2444,6 @@ static struct platform_device_id hdmi_driver_types[] = {
 static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5-hdmi",
-   .data   = (void *)HDMI_TYPE14,
}, {
/* end node */
}
@@ -2498,16 +2497,18 @@ static int __devinit hdmi_probe(struct platform_device 
*pdev)

platform_set_drvdata(pdev, drm_hdmi_ctx);

-   if (dev->of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(of_match_ptr(hdmi_match_types),
-   pdev->dev.of_node);
-   if (match == NULL)
-   return -ENODEV;
-   hdata->type = (enum hdmi_type)match->data;
-   } else {
+   if (!dev->of_node) {
hdata->type = (enum hdmi_type)platform_get_device_id
(pdev)->driver_data;
+   } else if (of_get_property(dev->of_node, "samsung,supports-hdmi-1.4",
+   NULL)) {
+   hdata->type = HDMI_TYPE14;
+   } else if (of_get_property(dev->of_node, "samsung,supports-hdmi-1.3",
+   NULL)) {
+   hdata->type = HDMI_TYPE13;
+   } else {
+   DRM_ERROR("Could not resolve HDMI version support\n");
+   return -ENODEV;
}

hdata->hpd_gpio = pdata->hpd_gpio;
-- 
1.7.7.3

[PATCH] drm/exynos: Get HDMI version from device tree

[Stephen Warren]

On 01/07/2013 01:43 PM, Sean Paul wrote:
> Add a property to the hdmi node so we can specify the HDMI version in
> the device tree instead of just defaulting to v1.4 with the existence of
> the dt node.

> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

> @@ -11,6 +11,8 @@ Required properties:
>   c) pin function mode.
>   d) optional flags and pull up/down.
>   e) drive strength.
> +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
> +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

Which device; the HDMI controller in the SoC, or the HDMI sink?

The HDMI sync reports what it supports in the EDID, so there shouldn't
be a need to duplicate this in the device tree (besides, how can you
know what the user plugged in without parsing the EDID?)

[PATCH] drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks

[Maarten Lankhorst]

vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
configuration space is not restored correctly, resulting in MSI not working 
after switch.

Only useful item in dmesg is:

[   33.922807] radeon :01:00.0: Refused to change power state, currently in 
D3

I did some testing, dumping the difference in ms between first succesful switch
from D3 to D0, and it seems that there is slightly more than 20 ms difference 
when
the device is re-enabled through vga-switcheroo.

So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
working
on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 10 
ms.

Signed-off-by: Maarten Lankhorst 

---
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 5515921..211a1d1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -897,6 +897,25 @@ static void radeon_check_arguments(struct radeon_device 
*rdev)
 }

 /**
+ * radeon_switcheroo_quirk_long_wakeup - return true if longer d3 delay is
+ * needed for waking up.
+ *
+ * @pdev: pci dev pointer
+ */
+static bool radeon_switcheroo_quirk_long_wakeup(struct pci_dev *pdev)
+{
+
+   /* 6600m in a macbook pro */
+   if (pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
+   pdev->subsystem_device == 0x00e2) {
+   printk(KERN_INFO "radeon: quirking longer d3 wakeup delay\n");
+   return true;
+   }
+
+   return false;
+}
+
+/**
  * radeon_switcheroo_set_state - set switcheroo state
  *
  * @pdev: pci dev pointer
@@ -910,10 +929,19 @@ static void radeon_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switchero
struct drm_device *dev = pci_get_drvdata(pdev);
pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
if (state == VGA_SWITCHEROO_ON) {
+   unsigned d3_delay = dev->pdev->d3_delay;
+
printk(KERN_INFO "radeon: switched on\n");
/* don't suspend or resume card normally */
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
+
+   if (d3_delay < 20 && radeon_switcheroo_quirk_long_wakeup(pdev))
+   dev->pdev->d3_delay = 20;
+
radeon_resume_kms(dev);
+
+   dev->pdev->d3_delay = d3_delay;
+
dev->switch_power_state = DRM_SWITCH_POWER_ON;
drm_kms_helper_poll_enable(dev);
} else {

[PATCH 8/8] drm/exynos: fimd: add complete_scanout function

[Mandeep Singh Baines]

On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K  wrote:
> The wait_for_vblank interface is modified to the complete_scanout
> function in fimd. This patch adds the fimd_complete_scanout function
>

With this series, you have a race if the rmfb happens before the flip
has completed.

Why not just use reference counts as is done in the i915 driver: see unpin_work.
The reference counts also allow you to avoid blocking in rmfb.

Regards,
Mandeep

> Inside fimd_complete_scanout, we read the shadow register for each
> window and compare it with the dma address of the framebuffer. If
> the dma_address is in the shadow register, then the function waits
> for the next vblank and returns.
>
> Signed-off-by: Prathyush K 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32 
> +++-
>  include/video/samsung_fimd.h |  1 +
>  2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 3aeedf5..190ffde9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -46,6 +46,7 @@
>  #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)
>
>  #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
> +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) * 8)
>  #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 
> 8)
>  #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)
>
> @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device *dev)
> fimd_disable_vblank(dev);
>  }
>
> +static void fimd_complete_scanout(struct device *dev, dma_addr_t dma_addr,
> +   unsigned long size)
> +{
> +   struct fimd_context *ctx = get_fimd_context(dev);
> +   int win;
> +   bool in_use = false;
> +
> +   if (ctx->suspended)
> +   return;
> +
> +   for (win = 0; win < WINDOWS_NR; win++) {
> +   dma_addr_t dma_addr_in_use;
> +
> +   if (!ctx->win_data[win].enabled)
> +   continue;
> +
> +   dma_addr_in_use = readl(ctx->regs + VIDWx_BUF_START_S(win, 
> 0));
> +   if (dma_addr_in_use >= dma_addr &&
> +   dma_addr_in_use < (dma_addr + size)) {
> +   in_use = true;
> +   break;
> +   }
> +   }
> +
> +   if (in_use)
> +   fimd_wait_for_vblank(dev);
> +   return;
> +}
> +
>  static struct exynos_drm_manager_ops fimd_manager_ops = {
> .dpms = fimd_dpms,
> .apply = fimd_apply,
> .commit = fimd_commit,
> .enable_vblank = fimd_enable_vblank,
> .disable_vblank = fimd_disable_vblank,
> -   .wait_for_vblank = fimd_wait_for_vblank,
> +   .complete_scanout = fimd_complete_scanout,
>  };
>
>  static void fimd_win_mode_set(struct device *dev,
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index 7ae6c07..382eaec 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -274,6 +274,7 @@
>
>  /* Video buffer addresses */
>  #define VIDW_BUF_START(_buff)  (0xA0 + ((_buff) * 8))
> +#define VIDW_BUF_START_S(_buff)(0x40A0 + ((_buff) * 
> 8))
>  #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
>  #define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
>  #define VIDW_BUF_END1(_buff)   (0xD4 + ((_buff) * 8))
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv16 5/7] fbmon: add of_videomode helpers

[Rob Clark]

On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal  wrote:
> Hi Steffen,
>
> On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
>> On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
>
>> > This breaks DaVinci (da8xx_omapl_defconfig), following change was
>> > required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
>> > is not defined. There may be better solutions, following was the
>> > one that was used by me to test this series.
>
>> I just did a quick "make da8xx_omapl_defconfig && make" and it builds just 
>> fine.
>> On what version did you apply the series?
>> At the moment I have the series sitting on 3.7. Didn't try any 3.8-rcx yet.
>> But fixing this shouldn't be a problem.
>
> You are right, me idiot, error will happen only upon try to make use of
> of_get_fb_videomode() (defined in this patch) in the da8xx-fb driver
> (with da8xx_omapl_defconfig), to be exact upon adding,
>
> "video: da8xx-fb: obtain fb_videomode info from dt" of my patch series.
>
> The change as I mentioned or something similar would be required as
> any driver that is going to make use of of_get_fb_videomode() would
> break if CONFIG_OF_VIDEOMODE or CONFIG_FB_MODE_HELPERS is not defined.

Shouldn't the driver that depends on CONFIG_OF_VIDEOMODE and
CONFIG_FB_MODE_HELPERS, explicitly select them?  I don't really see
the point of having the static-inline fallbacks.

fwiw, using 'select' is what I was doing for lcd panel support for
lcdc/da8xx drm driver (which was using the of videomode helpers,
albeit a slightly earlier version of the patches):

https://github.com/robclark/kernel-omap4/commit/e2aef5f281348afaaaeaa132699efc2831aa8384

BR,
-R

>
> And testing was done over v3.8-rc2.
>
>> > > +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
>> >
>> > As _OF_VIDEOMODE is a bool type CONFIG, isn't,
>> >
>> > #ifdef CONFIG_OF_VIDEOMODE
>> >
>> > sufficient ?
>> >
>>
>> Yes, that is right. But I think IS_ENABLED is the preferred way to do it, 
>> isn't it?
>
> Now I realize it is.
>
> Regards
> Afzal

[PATCH] drm/exynos: move finish page flip to a common place

[Inki Dae]

Applied.

Thanks,
Inki Dae

2013/1/3 Rahul Sharma :
> This patch implements the exynos_drm_crtc_finish_pageflip in
> exynos_drm_crtc.c. This avoids the duplication of same code
> in mixer, fimd and vidi.
>
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Stephane Marchesin 
> ---
> This patch is based on branch "exynos-drm-next" at
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 30 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h |  1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 30 +
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c | 30 +
>  drivers/gpu/drm/exynos/exynos_mixer.c| 33 
> +++-
>  5 files changed, 36 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index d59a03a..e8894bc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -393,3 +393,33 @@ void exynos_drm_crtc_disable_vblank(struct drm_device 
> *dev, int crtc)
> exynos_drm_fn_encoder(private->crtc[crtc], ,
> exynos_drm_disable_vblank);
>  }
> +
> +void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc)
> +{
> +   struct exynos_drm_private *dev_priv = dev->dev_private;
> +   struct drm_pending_vblank_event *e, *t;
> +   struct timeval now;
> +   unsigned long flags;
> +
> +   DRM_DEBUG_KMS("%s\n", __FILE__);
> +
> +   spin_lock_irqsave(>event_lock, flags);
> +
> +   list_for_each_entry_safe(e, t, _priv->pageflip_event_list,
> +   base.link) {
> +   /* if event's pipe isn't same as crtc then ignore it. */
> +   if (crtc != e->pipe)
> +   continue;
> +
> +   do_gettimeofday();
> +   e->event.sequence = 0;
> +   e->event.tv_sec = now.tv_sec;
> +   e->event.tv_usec = now.tv_usec;
> +
> +   list_move_tail(>base.link, >base.file_priv->event_list);
> +   wake_up_interruptible(>base.file_priv->event_wait);
> +   drm_vblank_put(dev, crtc);
> +   }
> +
> +   spin_unlock_irqrestore(>event_lock, flags);
> +}
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> index 8ac3969..3e197e6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> @@ -18,5 +18,6 @@
>  int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
>  int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
>  void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
> +void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int crtc);
>
>  #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..6dda825 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -663,34 +663,6 @@ static struct exynos_drm_manager fimd_manager = {
> .display_ops= _display_ops,
>  };
>
> -static void fimd_finish_pageflip(struct drm_device *drm_dev, int crtc)
> -{
> -   struct exynos_drm_private *dev_priv = drm_dev->dev_private;
> -   struct drm_pending_vblank_event *e, *t;
> -   struct timeval now;
> -   unsigned long flags;
> -
> -   spin_lock_irqsave(_dev->event_lock, flags);
> -
> -   list_for_each_entry_safe(e, t, _priv->pageflip_event_list,
> -   base.link) {
> -   /* if event's pipe isn't same as crtc then ignore it. */
> -   if (crtc != e->pipe)
> -   continue;
> -
> -   do_gettimeofday();
> -   e->event.sequence = 0;
> -   e->event.tv_sec = now.tv_sec;
> -   e->event.tv_usec = now.tv_usec;
> -
> -   list_move_tail(>base.link, >base.file_priv->event_list);
> -   wake_up_interruptible(>base.file_priv->event_wait);
> -   drm_vblank_put(drm_dev, crtc);
> -   }
> -
> -   spin_unlock_irqrestore(_dev->event_lock, flags);
> -}
> -
>  static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
>  {
> struct fimd_context *ctx = (struct fimd_context *)dev_id;
> @@ -710,7 +682,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
> goto out;
>
> drm_handle_vblank(drm_dev, manager->pipe);
> -   fimd_finish_pageflip(drm_dev, manager->pipe);
> +   exynos_drm_crtc_finish_pageflip(drm_dev, manager->pipe);
>
> /* set wait vsync event to zero and wake up queue. */
> if (atomic_read(>wait_vsync_event)) {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 3260035..b192308 100644
> --- 

[PATCH] drm/exynos: fimd: modify condition in fimd resume

[Inki Dae]

2012/12/27 Prathyush K :
> If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
> call fimd_activate(false) and just returns. Similarily the check in

Right and that is our intension. pm suspend should be ignored because
fimd already became off.
And if we want for fimd to be pm suspended after pm runtime suspend
then we should register a callback that resumes (e.g., runtime-pm-get)
the device to pm notifier so that the PM_SLEEP suspends the device
forcibly again. And that seems quite inefficient' you are doing the
same task duplicated.

> fimd_resume should not resume if previously runtime_suspended.
> Instead the existing check does the opposite. So if fimd was not
> runtime suspended, suspend will turn off fimd but resume will not turn

Right, if the fimd wasn't turned off by runtime pm suspend and enerted
pm suspend then the fimd is turned off by pm suspend and then should
be turned on by pm resume again. Actully we have a same patch
internally but we didn't post it. Will apply it.

Thank,
Inki Dae


> it on.  This patch fixes this issue by reversing the condition.
>
> Signed-off-by: Prathyush K 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..9accd466 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1046,7 +1046,7 @@ static int fimd_resume(struct device *dev)
>  * of pm runtime would still be 1 so in this case, fimd driver
>  * should be on directly not drawing on pm runtime interface.
>  */
> -   if (pm_runtime_suspended(dev)) {
> +   if (!pm_runtime_suspended(dev)) {
> int ret;
>
> ret = fimd_activate(ctx, true);
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49021] VGA output: Attached monitor is not detected

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=49021


Niels Ole Salscheider  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




--- Comment #4 from Niels Ole Salscheider   
2013-01-07 13:32:32 ---
Fix is in 3.8-rc2

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[pull] radeon drm-fixes-3.8

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

   A few more fixes for DMA and a mac quick.

The following changes since commit eda85d6ad490923152544fba0473798b6cc0edf6:

  drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000)

are available in the git repository at:
  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8

Alex Deucher (2):
  drm/radeon: split r6xx and r7xx copy_dma functions
  drm/radeon: fix DMA CS parser for r6xx linear copy packet

Maarten Lankhorst (1):
  drm/radeon: add quirk for d3 delay during switcheroo poweron for apple 
macbooks

 drivers/gpu/drm/radeon/r600.c  |   10 ++--
 drivers/gpu/drm/radeon/r600_cs.c   |   31 +
 drivers/gpu/drm/radeon/radeon_asic.c   |4 +-
 drivers/gpu/drm/radeon/radeon_asic.h   |4 ++
 drivers/gpu/drm/radeon/radeon_device.c |   28 
 drivers/gpu/drm/radeon/rv770.c |   74 
 6 files changed, 135 insertions(+), 16 deletions(-)

ttm_write_lock uninterruptible sleep

[Maarten Lankhorst]

Op 06-01-13 20:01, Konstantin Belousov schreef:
> In ttm_write_lock(), for the interruptible sleep, the __ttm_write_lock()
> is used as the sleep predicate. On the other hand, for the
> uninterruptible case, __ttm_read_lock() is evaluated. It seems that
> the code was not changed since the initial import at the end of 2009.
> Shouldn't both cases use the same __ttm_write_lock() ?
>
Yes. :-)

~Maarten

[PATCH] drm/exynos: Get HDMI version from device tree

[Mitch Bradley]

On 1/7/2013 10:43 AM, Sean Paul wrote:
> Add a property to the hdmi node so we can specify the HDMI version in
> the device tree instead of just defaulting to v1.4 with the existence of
> the dt node.
> 
> Signed-off-by: Sean Paul 
> ---
>  .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   19 ++-
>  2 files changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> index 589edee..d1c7d91 100644
> --- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> @@ -11,6 +11,8 @@ Required properties:
>   c) pin function mode.
>   d) optional flags and pull up/down.
>   e) drive strength.
> +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
> +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

a) This seems pretty generic, not at all samsung-specific, as the HDMI
version numbering space is well-defined by the HDMI spec.

b) It would be better to make it an integer property whose value
encodes the version number, thus eliminating the need to add new
properties as new HDMI versions appear.

>  
>  Example:
>  
> @@ -19,4 +21,5 @@ Example:
>   reg = <0x1453 0x10>;
>   interrupts = <0 95 0>;
>   hpd-gpio = < 7 0xf 1 3>;
> + samsung,supports-hdmi-1.4;
>   };
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2c46b6c..9834ae5 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2444,7 +2444,6 @@ static struct platform_device_id hdmi_driver_types[] = {
>  static struct of_device_id hdmi_match_types[] = {
>   {
>   .compatible = "samsung,exynos5-hdmi",
> - .data   = (void *)HDMI_TYPE14,
>   }, {
>   /* end node */
>   }
> @@ -2498,16 +2497,18 @@ static int __devinit hdmi_probe(struct 
> platform_device *pdev)
>  
>   platform_set_drvdata(pdev, drm_hdmi_ctx);
>  
> - if (dev->of_node) {
> - const struct of_device_id *match;
> - match = of_match_node(of_match_ptr(hdmi_match_types),
> - pdev->dev.of_node);
> - if (match == NULL)
> - return -ENODEV;
> - hdata->type = (enum hdmi_type)match->data;
> - } else {
> + if (!dev->of_node) {
>   hdata->type = (enum hdmi_type)platform_get_device_id
>   (pdev)->driver_data;
> + } else if (of_get_property(dev->of_node, "samsung,supports-hdmi-1.4",
> + NULL)) {
> + hdata->type = HDMI_TYPE14;
> + } else if (of_get_property(dev->of_node, "samsung,supports-hdmi-1.3",
> + NULL)) {
> + hdata->type = HDMI_TYPE13;
> + } else {
> + DRM_ERROR("Could not resolve HDMI version support\n");
> + return -ENODEV;
>   }
>  
>   hdata->hpd_gpio = pdata->hpd_gpio;
> 

Regression: drm/radeon: brightness control hard system lockup

[Alex Deucher]

On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack  wrote:
>
> Hi Alex,
>
> Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
> finer grained reset for evergreen" introduced a hard system lockup to my
> setup. I found it after bisecting, and confirmed it by reverting it on
> the latest mainline ( 5f243b9 ).
>
> This:
>
>echo 7 > 
> /sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0/brightness
>
> Causes a hard lock-up hard, i.e. immediate freeze, without any logs.
>
> See lspci output and kernel .config below.
> If there's any more info I can provide, please let me know.


Do you normally see GPU resets when changing the backlight?  Please
attach your dmesg output when changing the backlight with the patch
reverted.

Alex

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Terje Bergström]

On 04.01.2013 22:25, Stephen Warren wrote:
> On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
> ...
>> I think we have now two ways to go forward with cons and pros:
>>  1) Keep host1x and tegra-drm as separate driver
>>+ Code almost done
>>- we need dummy device and dummy driver
>>- extra code and API when host1x creates dummy device and its passed
>> to tegra-drm
> 
> Just to play devil's advocate:
> 
> I suspect that's only a few lines of code.

Yes, that's true. There's some overhead, but there's not too many actual
code lines.

>>- tegra-drm device would need to be a child of host1x device. Having
>> virtual and real devices as host1x children sounds weird.
> 
> And I doubt that would cause problems.

True. It could become a problem if the driver just assumed that all
host1x children are actual hardware, but we could avoid that.

>>  2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
>> and whatever other personalities we wish would also be subcomponents of
>> host1x. host1x calls tegra-drm directly to handle preparation for drm
>> initialization. As they're in the same module, circular dependency is ok.
>>+ Simpler conceptually (no dummy device/driver)
>>+ Less code
>>- Proposal doesn't yet exist
> 
> But that said, I agree this approach would be very reasonable; it seems
> to me that host1x really is the main HW behind a DRM driver or a V4L2
> driver or ... As such, it seems quite reasonable for a single struct
> device to exist that represents host1x, and for the driver for that
> device to register both a DRM and a V4L2 driver etc. The code could
> physically be organized into separate modules, and under different
> Kconfig options for configurability etc.
> 
> But either way, I'll let you (Thierry and Terje) work out which way to go.

If we want separate modules, we'd need the dummy device & dummy driver
binding between them. We could also just put them in the same module.
It'd make DRM a requirement to host1x driver, but given the current
structure, I think that'd be reasonable. We could later make it more
configurable if needed. Does this now make tegra-drm and host1x too
dependent on each other? I'm not sure.

I also like the fact that we don't have to export APIs to include, but
we can (if we so choose) keep all tegra-drm-host1x-APIs in local header
files. As we have noted, the two drivers are tightly interconnected,
changing the APIs is easier if we can just work on the same directory
hierarchy.

Terje

[PATCH] drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks

[Alex Deucher]

On Mon, Jan 7, 2013 at 9:18 AM, Maarten Lankhorst
 wrote:
> vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
> configuration space is not restored correctly, resulting in MSI not working 
> after switch.
>
> Only useful item in dmesg is:
>
> [   33.922807] radeon :01:00.0: Refused to change power state, currently 
> in D3
>
> I did some testing, dumping the difference in ms between first succesful 
> switch
> from D3 to D0, and it seems that there is slightly more than 20 ms difference 
> when
> the device is re-enabled through vga-switcheroo.
>
> So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
> working
> on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 
> 10 ms.
>
> Signed-off-by: Maarten Lankhorst 

Looks good. Added to my -fixes queue.

Alex

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Stephen Warren]

On 01/07/2013 01:20 AM, Terje Bergstr?m wrote:
> On 04.01.2013 22:25, Stephen Warren wrote:
>> On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
>> ...
>>> I think we have now two ways to go forward with cons and pros:
>>>  1) Keep host1x and tegra-drm as separate driver
>>>+ Code almost done
>>>- we need dummy device and dummy driver
>>>- extra code and API when host1x creates dummy device and its passed
>>> to tegra-drm
...
>>>  2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
>>> and whatever other personalities we wish would also be subcomponents of
>>> host1x. host1x calls tegra-drm directly to handle preparation for drm
>>> initialization. As they're in the same module, circular dependency is ok.
>>>+ Simpler conceptually (no dummy device/driver)
>>>+ Less code
>>>- Proposal doesn't yet exist
>>
>> But that said, I agree this approach would be very reasonable; it seems
>> to me that host1x really is the main HW behind a DRM driver or a V4L2
>> driver or ... As such, it seems quite reasonable for a single struct
>> device to exist that represents host1x, and for the driver for that
>> device to register both a DRM and a V4L2 driver etc. The code could
>> physically be organized into separate modules, and under different
>> Kconfig options for configurability etc.
>>
>> But either way, I'll let you (Thierry and Terje) work out which way to go.
> 
> If we want separate modules, we'd need the dummy device & dummy driver
> binding between them.

I haven't really thought it through, but I don't think so; I was
thinking separate modules more just to allow linking smaller chunks of
code at once rather than allowing optional functionality via loading (or
not) various modules. Hence, simple function calls between the
files/modules. Still, there may well be no need at all to split it into
separate modules.

[Bug 58840] rendering error with MSAA on HD6850

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=58840

--- Comment #7 from almos  ---
(In reply to comment #6)
> (In reply to comment #5)
> > Couldn't set 1280x960 OpenGL video mode: Couldn't find matching GLX visual
> > on the next startup.
> 
> If you want MSAA GLX visuals, you must *install* the gallium driver and
> restart the X server for it to pick up the visuals.

I know, but the last time I tried to install it, the whole screen became noise,
like I said in the initial report.

-- 
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/20130107/331778f6/attachment.html>

[PATCHv16 5/7] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Hi Afzal,

On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
> Hi Steffen,
> 
> On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
> > Add helper to get fb_videomode from devicetree.
> 
> >  drivers/video/fbmon.c |   42 ++
> >  include/linux/fb.h|4 
> 
> This breaks DaVinci (da8xx_omapl_defconfig), following change was
> required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
> is not defined. There may be better solutions, following was the
> one that was used by me to test this series.
> 
> ---8<--
> 
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 58b9860..0ce30d1 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -716,9 +716,19 @@ extern void fb_destroy_modedb(struct fb_videomode 
> *modedb);
>  extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
>  extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
> 
> +#if defined(CONFIG_OF_VIDEOMODE) && defined(CONFIG_FB_MODE_HELPERS)
>  extern int of_get_fb_videomode(struct device_node *np,
>struct fb_videomode *fb,
>int index);
> +#else
> +static inline int of_get_fb_videomode(struct device_node *np,
> + struct fb_videomode *fb,
> + int index)
> +{
> +   return -EINVAL;
> +}
> +#endif
> +
>  extern int fb_videomode_from_videomode(const struct videomode *vm,
>struct fb_videomode *fbmode);
> 
> ---8<--
> 

I just did a quick "make da8xx_omapl_defconfig && make" and it builds just fine.
On what version did you apply the series?
At the moment I have the series sitting on 3.7. Didn't try any 3.8-rcx yet.
But fixing this shouldn't be a problem.

> 
> > +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
> 
> As _OF_VIDEOMODE is a bool type CONFIG, isn't,
> 
> #ifdef CONFIG_OF_VIDEOMODE
> 
> sufficient ?
> 

Yes, that is right. But I think IS_ENABLED is the preferred way to do it, isn't 
it?

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCHv16 0/7] of: add display helper

[Steffen Trumtrar]

On Mon, Jan 07, 2013 at 06:23:54AM +, Mohammed, Afzal wrote:
> Hi Steffen,
> 
> On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:
> 
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
> 
> After another big bang, your series in the previous world was tried ;)
> 
> This series has been tested on DA850 EVM, AM335x EVM, EVM-SK along
> with the fix mentioned in 5/7, there was a build breakage on default
> config on DaVinci boards with this series, fix as well as more
> details are mentioned as reply to 5/7.
> 
> With those changes or equivalent to achieve the same,
> 
> Tested-by: Afzal Mohammed 
>

Thanks.

Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCHv16 5/7] fbmon: add of_videomode helpers

[Mohammed, Afzal]

Hi Steffen,

On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
> On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:

> > This breaks DaVinci (da8xx_omapl_defconfig), following change was
> > required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
> > is not defined. There may be better solutions, following was the
> > one that was used by me to test this series.

> I just did a quick "make da8xx_omapl_defconfig && make" and it builds just 
> fine.
> On what version did you apply the series?
> At the moment I have the series sitting on 3.7. Didn't try any 3.8-rcx yet.
> But fixing this shouldn't be a problem.

You are right, me idiot, error will happen only upon try to make use of
of_get_fb_videomode() (defined in this patch) in the da8xx-fb driver
(with da8xx_omapl_defconfig), to be exact upon adding,

"video: da8xx-fb: obtain fb_videomode info from dt" of my patch series.

The change as I mentioned or something similar would be required as
any driver that is going to make use of of_get_fb_videomode() would
break if CONFIG_OF_VIDEOMODE or CONFIG_FB_MODE_HELPERS is not defined.

And testing was done over v3.8-rc2.

> > > +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
> > 
> > As _OF_VIDEOMODE is a bool type CONFIG, isn't,
> > 
> > #ifdef CONFIG_OF_VIDEOMODE
> > 
> > sufficient ?
> > 
> 
> Yes, that is right. But I think IS_ENABLED is the preferred way to do it, 
> isn't it?

Now I realize it is.

Regards
Afzal

[PATCHv16 0/7] of: add display helper

[Mohammed, Afzal]

Hi Steffen,

On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:

> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.

After another big bang, your series in the previous world was tried ;)

This series has been tested on DA850 EVM, AM335x EVM, EVM-SK along
with the fix mentioned in 5/7, there was a build breakage on default
config on DaVinci boards with this series, fix as well as more
details are mentioned as reply to 5/7.

With those changes or equivalent to achieve the same,

Tested-by: Afzal Mohammed 

Regards
Afzal

[PATCHv16 5/7] fbmon: add of_videomode helpers

[Mohammed, Afzal]

Hi Steffen,

On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
> Add helper to get fb_videomode from devicetree.

>  drivers/video/fbmon.c |   42 ++
>  include/linux/fb.h|4 

This breaks DaVinci (da8xx_omapl_defconfig), following change was
required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
is not defined. There may be better solutions, following was the
one that was used by me to test this series.

---8<--

diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58b9860..0ce30d1 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -716,9 +716,19 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);

+#if defined(CONFIG_OF_VIDEOMODE) && defined(CONFIG_FB_MODE_HELPERS)
 extern int of_get_fb_videomode(struct device_node *np,
   struct fb_videomode *fb,
   int index);
+#else
+static inline int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index)
+{
+   return -EINVAL;
+}
+#endif
+
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);

---8<--


> +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)

As _OF_VIDEOMODE is a bool type CONFIG, isn't,

#ifdef CONFIG_OF_VIDEOMODE

sufficient ?

Regards
Afzal

[PATCH v3 4/4] drm/exynos: hdmi: support extra resolutions using drm_display_mode timings

[Rahul Sharma]

From: Sean Paul 

This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.

Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
Signed-off-by: Shirish S 
Signed-off-by: Akshay Saraswat 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1022 +-
 1 file changed, 374 insertions(+), 648 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d9d742a..f5eb986 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -88,6 +88,73 @@ struct hdmi_resources {
int regul_count;
 };

+struct hdmi_tg_regs {
+   u8 cmd[1];
+   u8 h_fsz[2];
+   u8 hact_st[2];
+   u8 hact_sz[2];
+   u8 v_fsz[2];
+   u8 vsync[2];
+   u8 vsync2[2];
+   u8 vact_st[2];
+   u8 vact_sz[2];
+   u8 field_chg[2];
+   u8 vact_st2[2];
+   u8 vact_st3[2];
+   u8 vact_st4[2];
+   u8 vsync_top_hdmi[2];
+   u8 vsync_bot_hdmi[2];
+   u8 field_top_hdmi[2];
+   u8 field_bot_hdmi[2];
+   u8 tg_3d[1];
+};
+
+struct hdmi_core_regs {
+   u8 h_blank[2];
+   u8 v2_blank[2];
+   u8 v1_blank[2];
+   u8 v_line[2];
+   u8 h_line[2];
+   u8 hsync_pol[1];
+   u8 vsync_pol[1];
+   u8 int_pro_mode[1];
+   u8 v_blank_f0[2];
+   u8 v_blank_f1[2];
+   u8 h_sync_start[2];
+   u8 h_sync_end[2];
+   u8 v_sync_line_bef_2[2];
+   u8 v_sync_line_bef_1[2];
+   u8 v_sync_line_aft_2[2];
+   u8 v_sync_line_aft_1[2];
+   u8 v_sync_line_aft_pxl_2[2];
+   u8 v_sync_line_aft_pxl_1[2];
+   u8 v_blank_f2[2]; /* for 3D mode */
+   u8 v_blank_f3[2]; /* for 3D mode */
+   u8 v_blank_f4[2]; /* for 3D mode */
+   u8 v_blank_f5[2]; /* for 3D mode */
+   u8 v_sync_line_aft_3[2];
+   u8 v_sync_line_aft_4[2];
+   u8 v_sync_line_aft_5[2];
+   u8 v_sync_line_aft_6[2];
+   u8 v_sync_line_aft_pxl_3[2];
+   u8 v_sync_line_aft_pxl_4[2];
+   u8 v_sync_line_aft_pxl_5[2];
+   u8 v_sync_line_aft_pxl_6[2];
+   u8 vact_space_1[2];
+   u8 vact_space_2[2];
+   u8 vact_space_3[2];
+   u8 vact_space_4[2];
+   u8 vact_space_5[2];
+   u8 vact_space_6[2];
+};
+
+struct hdmi_v14_conf {
+   int pixel_clock;
+   struct hdmi_core_regs core;
+   struct hdmi_tg_regs tg;
+   int cea_video_id;
+};
+
 struct hdmi_context {
struct device   *dev;
struct drm_device   *drm_dev;
@@ -106,6 +173,7 @@ struct hdmi_context {

/* current hdmiphy conf index */
int cur_conf;
+   struct hdmi_v14_confmode_conf;

struct hdmi_resources   res;

@@ -394,586 +462,132 @@ static const struct hdmi_v13_conf hdmi_v13_confs[] = {
 };

 /* HDMI Version 1.4 */
-static const u8 hdmiphy_conf27_027[32] = {
-   0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
-   0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xe3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf74_176[32] = {
-   0x01, 0xd1, 0x1f, 0x10, 0x40, 0x5b, 0xef, 0x08,
-   0x81, 0xa0, 0xb9, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x5a, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xa6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf74_25[32] = {
-   0x01, 0xd1, 0x1f, 0x10, 0x40, 0x40, 0xf8, 0x08,
-   0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xa5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf148_5[32] = {
-   0x01, 0xd1, 0x1f, 0x00, 0x40, 0x40, 0xf8, 0x08,
-   0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0x4b, 0x25, 0x03, 0x00, 0x00, 0x01, 0x00,
-};
-
-struct hdmi_tg_regs {
-   u8 cmd;
-   u8 h_fsz_l;
-   u8 h_fsz_h;
-   u8 hact_st_l;
-   u8 hact_st_h;
-   u8 hact_sz_l;
-   u8 hact_sz_h;
-   u8 v_fsz_l;
-   u8 v_fsz_h;
-   u8 vsync_l;
-   u8 vsync_h;
-   u8 vsync2_l;
-   u8 vsync2_h;
-   u8 vact_st_l;
-   u8 vact_st_h;
-   u8 vact_sz_l;
-   u8 vact_sz_h;
-   u8 field_chg_l;
-   u8 field_chg_h;
-   u8 vact_st2_l;
-   u8 vact_st2_h;
-   u8 vact_st3_l;
-   u8 vact_st3_h;
-   u8 vact_st4_l;
-   u8 vact_st4_h;
-   u8 vsync_top_hdmi_l;
-   u8 vsync_top_hdmi_h;
-   u8 vsync_bot_hdmi_l;
-   u8 vsync_bot_hdmi_h;
-   u8 field_top_hdmi_l;
-   u8 field_top_hdmi_h;
-   u8 field_bot_hdmi_l;
-   u8 field_bot_hdmi_h;
-   u8 tg_3d;
-};
-
-struct 

[PATCH v3 3/4] drm/exynos: mixer: set correct mode for range of resolutions

[Rahul Sharma]

With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index a67d933..d0db78b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -283,13 +283,13 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
MXR_CFG_SCAN_PROGRASSIVE);

/* choosing between porper HD and SD mode */
-   if (height == 480)
+   if (height <= 480)
val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height == 576)
+   else if (height <= 576)
val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height == 720)
+   else if (height <= 720)
val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height == 1080)
+   else if (height <= 1080)
val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
else
val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-- 
1.8.0

[PATCH v3 2/4] drm/exynos: implement display-mode-check callback in mixer driver

[Rahul Sharma]

This patch adds the implementation of check_timing callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21db895..a67d933 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -810,6 +810,29 @@ static void mixer_win_disable(void *ctx, int win)
mixer_ctx->win_data[win].enabled = false;
 }

+int mixer_check_timing(void *ctx, struct fb_videomode *timing)
+{
+   struct mixer_context *mixer_ctx = ctx;
+   u32 w, h;
+
+   w = timing->xres;
+   h = timing->yres;
+
+   DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
+   __func__, timing->xres, timing->yres,
+   timing->refresh, (timing->vmode &
+   FB_VMODE_INTERLACED) ? true : false);
+
+   if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16)
+   return 0;
+
+   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
+   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
+   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
+   return 0;
+
+   return -EINVAL;
+}
 static void mixer_wait_for_vblank(void *ctx)
 {
struct mixer_context *mixer_ctx = ctx;
@@ -947,6 +970,9 @@ static struct exynos_mixer_ops mixer_ops = {
.win_mode_set   = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
+
+   /* display */
+   .check_timing   = mixer_check_timing,
 };

 /* for pageflip event */
-- 
1.8.0

[PATCH v3 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

[Rahul Sharma]

This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.

Both, mixer check-mode and hdmi check-timing callbacks are called one after
another and ANDed result is returned back.

Signed-off-by: Rahul Sharma 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  5 -
 drivers/gpu/drm/exynos/exynos_hdmi.c | 13 ++---
 3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 55793c4..1c06a11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -125,9 +125,21 @@ static int drm_hdmi_get_edid(struct device *dev,
 static int drm_hdmi_check_timing(struct device *dev, void *timing)
 {
struct drm_hdmi_context *ctx = to_context(dev);
+   int ret = 0;

DRM_DEBUG_KMS("%s\n", __FILE__);

+   /*
+   * Both, mixer and hdmi should be able to handle the requested mode.
+   * If any of the two fails, return mode as BAD.
+   */
+
+   if (mixer_ops && mixer_ops->check_timing)
+   ret = mixer_ops->check_timing(ctx->mixer_ctx->ctx, timing);
+
+   if (ret)
+   return ret;
+
if (hdmi_ops && hdmi_ops->check_timing)
return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 784a7e9..f5202af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -32,7 +32,7 @@ struct exynos_hdmi_ops {
bool (*is_connected)(void *ctx);
int (*get_edid)(void *ctx, struct drm_connector *connector,
u8 *edid, int len);
-   int (*check_timing)(void *ctx, void *timing);
+   int (*check_timing)(void *ctx, struct fb_videomode *timing);
int (*power_on)(void *ctx, int mode);

/* manager */
@@ -58,6 +58,9 @@ struct exynos_mixer_ops {
void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
void (*win_commit)(void *ctx, int zpos);
void (*win_disable)(void *ctx, int zpos);
+
+   /* display */
+   int (*check_timing)(void *ctx, struct fb_videomode *timing);
 };

 void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..d9d742a 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1464,21 +1464,20 @@ static int hdmi_v14_check_timing(struct fb_videomode 
*check_timing)
return -EINVAL;
 }

-static int hdmi_check_timing(void *ctx, void *timing)
+static int hdmi_check_timing(void *ctx, struct fb_videomode *timing)
 {
struct hdmi_context *hdata = ctx;
-   struct fb_videomode *check_timing = timing;

DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);

-   DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", check_timing->xres,
-   check_timing->yres, check_timing->refresh,
-   check_timing->vmode);
+   DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", timing->xres,
+   timing->yres, timing->refresh,
+   timing->vmode);

if (hdata->type == HDMI_TYPE13)
-   return hdmi_v13_check_timing(check_timing);
+   return hdmi_v13_check_timing(timing);
else
-   return hdmi_v14_check_timing(check_timing);
+   return hdmi_v14_check_timing(timing);
 }

 static void hdmi_set_acr(u32 freq, u8 *acr)
-- 
1.8.0

[PATCH v3 0/4] drm/exynos: add support for extra resolutions to exynos5

[Rahul Sharma]

This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).

Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports the display mode.

V3:
- check_mode -> check_timing in patche description.
- Change type to u32 from unsigned int in mixer_check_timing.

V2:
- change mixer callback name to check_timing from check_mode
- callback parameter is changed to type "struct fb_videomode *" from "void *"
- organised the implementation of check_timing callback in mixer driver.

This patch series is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

Rahul Sharma (3):
  drm/exynos: add display-mode-check operation to exynos_mixer_ops
struct
  drm/exynos: implement display-mode-check callback in mixer driver
  drm/exynos: mixer: set correct mode for range of resolutions

Sean Paul (1):
  drm/exynos: hdmi: support extra resolutions using drm_display_mode
timings

 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |5 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1035 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c|   34 +-
 4 files changed, 426 insertions(+), 660 deletions(-)

-- 
1.8.0

[Bug 58840] rendering error with MSAA on HD6850

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=58840

--- Comment #6 from Marek Ol??k  ---
(In reply to comment #5)
> Couldn't set 1280x960 OpenGL video mode: Couldn't find matching GLX visual
> on the next startup.

If you want MSAA GLX visuals, you must *install* the gallium driver and restart
the X server for it to pick up the visuals.

-- 
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/20130107/466cf179/attachment-0001.html>

Re: [PATCHv16 5/7] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Hi Afzal,

On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:
 Hi Steffen,
 
 On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
  Add helper to get fb_videomode from devicetree.
 
   drivers/video/fbmon.c |   42 ++
   include/linux/fb.h|4 
 
 This breaks DaVinci (da8xx_omapl_defconfig), following change was
 required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
 is not defined. There may be better solutions, following was the
 one that was used by me to test this series.
 
 ---8--
 
 diff --git a/include/linux/fb.h b/include/linux/fb.h
 index 58b9860..0ce30d1 100644
 --- a/include/linux/fb.h
 +++ b/include/linux/fb.h
 @@ -716,9 +716,19 @@ extern void fb_destroy_modedb(struct fb_videomode 
 *modedb);
  extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
  extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
 
 +#if defined(CONFIG_OF_VIDEOMODE)  defined(CONFIG_FB_MODE_HELPERS)
  extern int of_get_fb_videomode(struct device_node *np,
struct fb_videomode *fb,
int index);
 +#else
 +static inline int of_get_fb_videomode(struct device_node *np,
 + struct fb_videomode *fb,
 + int index)
 +{
 +   return -EINVAL;
 +}
 +#endif
 +
  extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
 
 ---8--
 

I just did a quick make da8xx_omapl_defconfig  make and it builds just fine.
On what version did you apply the series?
At the moment I have the series sitting on 3.7. Didn't try any 3.8-rcx yet.
But fixing this shouldn't be a problem.

 
  +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
 
 As _OF_VIDEOMODE is a bool type CONFIG, isn't,
 
 #ifdef CONFIG_OF_VIDEOMODE
 
 sufficient ?
 

Yes, that is right. But I think IS_ENABLED is the preferred way to do it, isn't 
it?

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Terje Bergström]

On 04.01.2013 22:25, Stephen Warren wrote:
 On 01/04/2013 03:09 AM, Terje Bergström wrote:
 ...
 I think we have now two ways to go forward with cons and pros:
  1) Keep host1x and tegra-drm as separate driver
+ Code almost done
- we need dummy device and dummy driver
- extra code and API when host1x creates dummy device and its passed
 to tegra-drm
 
 Just to play devil's advocate:
 
 I suspect that's only a few lines of code.

Yes, that's true. There's some overhead, but there's not too many actual
code lines.

- tegra-drm device would need to be a child of host1x device. Having
 virtual and real devices as host1x children sounds weird.
 
 And I doubt that would cause problems.

True. It could become a problem if the driver just assumed that all
host1x children are actual hardware, but we could avoid that.

  2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
 and whatever other personalities we wish would also be subcomponents of
 host1x. host1x calls tegra-drm directly to handle preparation for drm
 initialization. As they're in the same module, circular dependency is ok.
+ Simpler conceptually (no dummy device/driver)
+ Less code
- Proposal doesn't yet exist
 
 But that said, I agree this approach would be very reasonable; it seems
 to me that host1x really is the main HW behind a DRM driver or a V4L2
 driver or ... As such, it seems quite reasonable for a single struct
 device to exist that represents host1x, and for the driver for that
 device to register both a DRM and a V4L2 driver etc. The code could
 physically be organized into separate modules, and under different
 Kconfig options for configurability etc.
 
 But either way, I'll let you (Thierry and Terje) work out which way to go.

If we want separate modules, we'd need the dummy device  dummy driver
binding between them. We could also just put them in the same module.
It'd make DRM a requirement to host1x driver, but given the current
structure, I think that'd be reasonable. We could later make it more
configurable if needed. Does this now make tegra-drm and host1x too
dependent on each other? I'm not sure.

I also like the fact that we don't have to export APIs to include, but
we can (if we so choose) keep all tegra-drm-host1x-APIs in local header
files. As we have noted, the two drivers are tightly interconnected,
changing the APIs is easier if we can just work on the same directory
hierarchy.

Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58840] rendering error with MSAA on HD6850

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=58840

--- Comment #7 from almos aaalmo...@gmail.com ---
(In reply to comment #6)
 (In reply to comment #5)
  Couldn't set 1280x960 OpenGL video mode: Couldn't find matching GLX visual
  on the next startup.
 
 If you want MSAA GLX visuals, you must *install* the gallium driver and
 restart the X server for it to pick up the visuals.

I know, but the last time I tried to install it, the whole screen became noise,
like I said in the initial report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks

[Maarten Lankhorst]

vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
configuration space is not restored correctly, resulting in MSI not working 
after switch.

Only useful item in dmesg is:

[   33.922807] radeon :01:00.0: Refused to change power state, currently in 
D3

I did some testing, dumping the difference in ms between first succesful switch
from D3 to D0, and it seems that there is slightly more than 20 ms difference 
when
the device is re-enabled through vga-switcheroo.

So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
working
on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 10 
ms.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

---
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 5515921..211a1d1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -897,6 +897,25 @@ static void radeon_check_arguments(struct radeon_device 
*rdev)
 }
 
 /**
+ * radeon_switcheroo_quirk_long_wakeup - return true if longer d3 delay is
+ * needed for waking up.
+ *
+ * @pdev: pci dev pointer
+ */
+static bool radeon_switcheroo_quirk_long_wakeup(struct pci_dev *pdev)
+{
+
+   /* 6600m in a macbook pro */
+   if (pdev-subsystem_vendor == PCI_VENDOR_ID_APPLE 
+   pdev-subsystem_device == 0x00e2) {
+   printk(KERN_INFO radeon: quirking longer d3 wakeup delay\n);
+   return true;
+   }
+
+   return false;
+}
+
+/**
  * radeon_switcheroo_set_state - set switcheroo state
  *
  * @pdev: pci dev pointer
@@ -910,10 +929,19 @@ static void radeon_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switchero
struct drm_device *dev = pci_get_drvdata(pdev);
pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
if (state == VGA_SWITCHEROO_ON) {
+   unsigned d3_delay = dev-pdev-d3_delay;
+
printk(KERN_INFO radeon: switched on\n);
/* don't suspend or resume card normally */
dev-switch_power_state = DRM_SWITCH_POWER_CHANGING;
+
+   if (d3_delay  20  radeon_switcheroo_quirk_long_wakeup(pdev))
+   dev-pdev-d3_delay = 20;
+
radeon_resume_kms(dev);
+
+   dev-pdev-d3_delay = d3_delay;
+
dev-switch_power_state = DRM_SWITCH_POWER_ON;
drm_kms_helper_poll_enable(dev);
} else {

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks

[Alex Deucher]

On Mon, Jan 7, 2013 at 9:18 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
 configuration space is not restored correctly, resulting in MSI not working 
 after switch.

 Only useful item in dmesg is:

 [   33.922807] radeon :01:00.0: Refused to change power state, currently 
 in D3

 I did some testing, dumping the difference in ms between first succesful 
 switch
 from D3 to D0, and it seems that there is slightly more than 20 ms difference 
 when
 the device is re-enabled through vga-switcheroo.

 So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not 
 working
 on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 
 10 ms.

 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

Looks good. Added to my -fixes queue.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression: drm/radeon: brightness control hard system lockup

[Alex Deucher]

On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack el...@fogrefinery.com wrote:

 Hi Alex,

 Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f drm/radeon: switch to a
 finer grained reset for evergreen introduced a hard system lockup to my
 setup. I found it after bisecting, and confirmed it by reverting it on
 the latest mainline ( 5f243b9 ).

 This:

echo 7  
 /sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0/brightness

 Causes a hard lock-up hard, i.e. immediate freeze, without any logs.

 See lspci output and kernel .config below.
 If there's any more info I can provide, please let me know.


Do you normally see GPU resets when changing the backlight?  Please
attach your dmesg output when changing the backlight with the patch
reverted.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57875

--- Comment #19 from Stefan Dösinger stefandoesin...@gmx.at ---
Are there any comments on the 2nd extension spec? If it looks good to you I'll
do some tests with the r200 and r500 GPUs I have to see how unclipped Z values
behave in fragment processing to make sure the extension doesn't guarantee
anything the HW cannot provide.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm: Fix comment about drm_exit which has been replaced by drm_platform_exit in 2.6.39

[Philippe De Swert]

Trivial comment fix. Since drm_exit() was removed in 2.6.39 (commit 8410ea3b ). 
As such the comment
is incorrect. drm_put_dev() is now called from drm_platform_exit() or when the 
pci device is unplugged.

Signed-off-by: Philippe De Swert philippe.desw...@jollamobile.com
---
 drivers/gpu/drm/drm_stub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 200e104..b39f591 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -445,7 +445,7 @@ static void drm_unplug_minor(struct drm_minor *minor)
 }
 
 /**
- * Called via drm_exit() at module unload time or when pci device is
+ * Called via drm_platform_exit() at module unload time or when pci device is
  * unplugged.
  *
  * Cleans up all DRM device, calling drm_lastclose().
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57875

--- Comment #20 from Marek Olšák mar...@gmail.com ---
FWIW, the extension specification looks good to me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Fan control in nouveau driver with geforce 9600gt

[Ozan Çağlayan]

 We will be waiting a until one kernel is released before activating fan
 management by default.

So these fan stuff will be merged into 3.9?



-- 
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

[Stephen Warren]

On 01/07/2013 01:20 AM, Terje Bergström wrote:
 On 04.01.2013 22:25, Stephen Warren wrote:
 On 01/04/2013 03:09 AM, Terje Bergström wrote:
 ...
 I think we have now two ways to go forward with cons and pros:
  1) Keep host1x and tegra-drm as separate driver
+ Code almost done
- we need dummy device and dummy driver
- extra code and API when host1x creates dummy device and its passed
 to tegra-drm
...
  2) Merge host1x and tegra-drm into one module. drm is a subcomponent,
 and whatever other personalities we wish would also be subcomponents of
 host1x. host1x calls tegra-drm directly to handle preparation for drm
 initialization. As they're in the same module, circular dependency is ok.
+ Simpler conceptually (no dummy device/driver)
+ Less code
- Proposal doesn't yet exist

 But that said, I agree this approach would be very reasonable; it seems
 to me that host1x really is the main HW behind a DRM driver or a V4L2
 driver or ... As such, it seems quite reasonable for a single struct
 device to exist that represents host1x, and for the driver for that
 device to register both a DRM and a V4L2 driver etc. The code could
 physically be organized into separate modules, and under different
 Kconfig options for configurability etc.

 But either way, I'll let you (Thierry and Terje) work out which way to go.
 
 If we want separate modules, we'd need the dummy device  dummy driver
 binding between them.

I haven't really thought it through, but I don't think so; I was
thinking separate modules more just to allow linking smaller chunks of
code at once rather than allowing optional functionality via loading (or
not) various modules. Hence, simple function calls between the
files/modules. Still, there may well be no need at all to split it into
separate modules.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.8

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Hi Dave,

   A few more fixes for DMA and a mac quick.

The following changes since commit eda85d6ad490923152544fba0473798b6cc0edf6:

  drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000)

are available in the git repository at:
  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8

Alex Deucher (2):
  drm/radeon: split r6xx and r7xx copy_dma functions
  drm/radeon: fix DMA CS parser for r6xx linear copy packet

Maarten Lankhorst (1):
  drm/radeon: add quirk for d3 delay during switcheroo poweron for apple 
macbooks

 drivers/gpu/drm/radeon/r600.c  |   10 ++--
 drivers/gpu/drm/radeon/r600_cs.c   |   31 +
 drivers/gpu/drm/radeon/radeon_asic.c   |4 +-
 drivers/gpu/drm/radeon/radeon_asic.h   |4 ++
 drivers/gpu/drm/radeon/radeon_device.c |   28 
 drivers/gpu/drm/radeon/rv770.c |   74 
 6 files changed, 135 insertions(+), 16 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #54 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #53)

Gerald, we can only support the open source drivers here. For fglrx issues
you'll have to turn to fglrx support resources.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv16 5/7] fbmon: add of_videomode helpers

[Rob Clark]

On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal af...@ti.com wrote:
 Hi Steffen,

 On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:
 On Mon, Jan 07, 2013 at 06:10:13AM +, Mohammed, Afzal wrote:

  This breaks DaVinci (da8xx_omapl_defconfig), following change was
  required to get it build if OF_VIDEOMODE or/and FB_MODE_HELPERS
  is not defined. There may be better solutions, following was the
  one that was used by me to test this series.

 I just did a quick make da8xx_omapl_defconfig  make and it builds just 
 fine.
 On what version did you apply the series?
 At the moment I have the series sitting on 3.7. Didn't try any 3.8-rcx yet.
 But fixing this shouldn't be a problem.

 You are right, me idiot, error will happen only upon try to make use of
 of_get_fb_videomode() (defined in this patch) in the da8xx-fb driver
 (with da8xx_omapl_defconfig), to be exact upon adding,

 video: da8xx-fb: obtain fb_videomode info from dt of my patch series.

 The change as I mentioned or something similar would be required as
 any driver that is going to make use of of_get_fb_videomode() would
 break if CONFIG_OF_VIDEOMODE or CONFIG_FB_MODE_HELPERS is not defined.

Shouldn't the driver that depends on CONFIG_OF_VIDEOMODE and
CONFIG_FB_MODE_HELPERS, explicitly select them?  I don't really see
the point of having the static-inline fallbacks.

fwiw, using 'select' is what I was doing for lcd panel support for
lcdc/da8xx drm driver (which was using the of videomode helpers,
albeit a slightly earlier version of the patches):

https://github.com/robclark/kernel-omap4/commit/e2aef5f281348afaaaeaa132699efc2831aa8384

BR,
-R


 And testing was done over v3.8-rc2.

   +#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
 
  As _OF_VIDEOMODE is a bool type CONFIG, isn't,
 
  #ifdef CONFIG_OF_VIDEOMODE
 
  sufficient ?
 

 Yes, that is right. But I think IS_ENABLED is the preferred way to do it, 
 isn't it?

 Now I realize it is.

 Regards
 Afzal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58667] Random crashes on CAYMAN

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=58667

--- Comment #30 from Alex Deucher ag...@yahoo.com ---
Should be fixed with this mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=59089

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Should be fixed with this mesa commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Get HDMI version from device tree

[Sean Paul]

Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.

Signed-off-by: Sean Paul seanp...@chromium.org
---
 .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   19 ++-
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
index 589edee..d1c7d91 100644
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
@@ -11,6 +11,8 @@ Required properties:
c) pin function mode.
d) optional flags and pull up/down.
e) drive strength.
+- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
+- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3
 
 Example:
 
@@ -19,4 +21,5 @@ Example:
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 0xf 1 3;
+   samsung,supports-hdmi-1.4;
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..9834ae5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2444,7 +2444,6 @@ static struct platform_device_id hdmi_driver_types[] = {
 static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos5-hdmi,
-   .data   = (void *)HDMI_TYPE14,
}, {
/* end node */
}
@@ -2498,16 +2497,18 @@ static int __devinit hdmi_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, drm_hdmi_ctx);
 
-   if (dev-of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(of_match_ptr(hdmi_match_types),
-   pdev-dev.of_node);
-   if (match == NULL)
-   return -ENODEV;
-   hdata-type = (enum hdmi_type)match-data;
-   } else {
+   if (!dev-of_node) {
hdata-type = (enum hdmi_type)platform_get_device_id
(pdev)-driver_data;
+   } else if (of_get_property(dev-of_node, samsung,supports-hdmi-1.4,
+   NULL)) {
+   hdata-type = HDMI_TYPE14;
+   } else if (of_get_property(dev-of_node, samsung,supports-hdmi-1.3,
+   NULL)) {
+   hdata-type = HDMI_TYPE13;
+   } else {
+   DRM_ERROR(Could not resolve HDMI version support\n);
+   return -ENODEV;
}
 
hdata-hpd_gpio = pdata-hpd_gpio;
-- 
1.7.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Only evict the blocks required to create the requested hole

[Daniel Vetter]

On Wed, Dec 19, 2012 at 04:51:06PM +, Chris Wilson wrote:
 Avoid clobbering adjacent blocks if they happen to expire earlier and
 amalgamate together to form the requested hole.
 
 In passing this fixes a regression from
 commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Feb 18 17:59:12 2011 +0100
 
 drm: mm: track free areas implicitly
 
 which swaps the end address for size (with a potential overflow) and
 effectively causes the eviction code to clobber almost all earlier
 buffers above the evictee.
 
 v2: Check the original hole not the adjusted as the coloring may confuse
 us when later searching for the overlapping nodes. Also make sure that
 we do apply the range restriction and color adjustment in the same
 order for both scanning, searching and insertion.
 
 v3: Send the version that was actually tested.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Daniel Vetter daniel.vet...@ffwll.ch

Picked up for -fixes with bugzilla link and Norberts tested-by added,
thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Get HDMI version from device tree

[Sean Paul]

On Mon, Jan 7, 2013 at 3:54 PM, Mitch Bradley w...@firmworks.com wrote:
 On 1/7/2013 10:43 AM, Sean Paul wrote:
 Add a property to the hdmi node so we can specify the HDMI version in
 the device tree instead of just defaulting to v1.4 with the existence of
 the dt node.

 Signed-off-by: Sean Paul seanp...@chromium.org
 ---
  .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
  drivers/gpu/drm/exynos/exynos_hdmi.c   |   19 
 ++-
  2 files changed, 13 insertions(+), 9 deletions(-)

 diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
 b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
 index 589edee..d1c7d91 100644
 --- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
 +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
 @@ -11,6 +11,8 @@ Required properties:
   c) pin function mode.
   d) optional flags and pull up/down.
   e) drive strength.
 +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
 +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

 a) This seems pretty generic, not at all samsung-specific, as the HDMI
 version numbering space is well-defined by the HDMI spec.

 b) It would be better to make it an integer property whose value
 encodes the version number, thus eliminating the need to add new
 properties as new HDMI versions appear.


Thanks for the quick review, Mitch.

How about:

- hdmi-version: 0=v1.3, 1=v1.4



  Example:

 @@ -19,4 +21,5 @@ Example:
   reg = 0x1453 0x10;
   interrupts = 0 95 0;
   hpd-gpio = gpx3 7 0xf 1 3;
 + samsung,supports-hdmi-1.4;
   };
 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 2c46b6c..9834ae5 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -2444,7 +2444,6 @@ static struct platform_device_id hdmi_driver_types[] = 
 {
  static struct of_device_id hdmi_match_types[] = {
   {
   .compatible = samsung,exynos5-hdmi,
 - .data   = (void *)HDMI_TYPE14,
   }, {
   /* end node */
   }
 @@ -2498,16 +2497,18 @@ static int __devinit hdmi_probe(struct 
 platform_device *pdev)

   platform_set_drvdata(pdev, drm_hdmi_ctx);

 - if (dev-of_node) {
 - const struct of_device_id *match;
 - match = of_match_node(of_match_ptr(hdmi_match_types),
 - pdev-dev.of_node);
 - if (match == NULL)
 - return -ENODEV;
 - hdata-type = (enum hdmi_type)match-data;
 - } else {
 + if (!dev-of_node) {
   hdata-type = (enum hdmi_type)platform_get_device_id
   (pdev)-driver_data;
 + } else if (of_get_property(dev-of_node, samsung,supports-hdmi-1.4,
 + NULL)) {
 + hdata-type = HDMI_TYPE14;
 + } else if (of_get_property(dev-of_node, samsung,supports-hdmi-1.3,
 + NULL)) {
 + hdata-type = HDMI_TYPE13;
 + } else {
 + DRM_ERROR(Could not resolve HDMI version support\n);
 + return -ENODEV;
   }

   hdata-hpd_gpio = pdata-hpd_gpio;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression: drm/radeon: brightness control hard system lockup

[Alex Deucher]

On Mon, Jan 7, 2013 at 4:33 PM, Eldad Zack el...@fogrefinery.com wrote:

 On Mon, 7 Jan 2013, Alex Deucher wrote:
 On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack el...@fogrefinery.com wrote:
 
  Hi Alex,
 
  Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f drm/radeon: switch to a
  finer grained reset for evergreen introduced a hard system lockup to my
  setup. I found it after bisecting, and confirmed it by reverting it on
  the latest mainline ( 5f243b9 ).
 
  This:
 
 echo 7  
  /sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0/brightness
 
  Causes a hard lock-up hard, i.e. immediate freeze, without any logs.
 
  See lspci output and kernel .config below.
  If there's any more info I can provide, please let me know.

 Do you normally see GPU resets when changing the backlight?  Please
 attach your dmesg output when changing the backlight with the patch
 reverted.

 I see nothing. Just to make sure, I cleared the buffer, cycled through
 0-7 a couple of hunderd times (until the flicker annoyed), but I see no
 messages at all.
 Is there any debug config I should turn on?

Can you try adding a printk() in evergreen_asic_reset() and see if it
is somehow getting called when you change the brightness?  When you
use the apci backlight control, the radeon driver is not involved at
all.  They only way the driver would get involved is if the acpi
backlight control somehow caused the GPU to hang and then the driver
detected the hang and attempted to reset the GPU.  I don't see any
evidence of a GPU reset in your kernel log however.  Note that the
driver also registers native backlight contol.  Does that work any
better than acpi?

Alex


 Turning ACPI debugging on gives me no messages neither when I use the
 cycle script.

 But I did find out something interesting enough, only because I
 happen to have sound debugging on, if I have a PCM stream open to a
 USB device, and then change the backlight level, it seems to drop to
 microframes, but it's not otherwise noticeable. Looks like setting the
 backlight still does something weird with my hardware/config.

 Below is a grep -i radeon from my boot dmesg.

 Cheers,
 Eldad

 [0.301558] [drm] radeon defaulting to kernel modesetting.
 [0.301626] [drm] radeon kernel modesetting enabled.
 [0.301694] bus: 'pci': add driver radeon
 [0.301716] bus: 'pci': driver_probe_device: matched device :01:00.0 
 with driver radeon
 [0.301718] bus: 'pci': really_probe: probing driver radeon with device 
 :01:00.0
 [0.302310] radeon :01:00.0: VRAM: 1024M 0x - 
 0x3FFF (1024M used)
 [0.302390] radeon :01:00.0: GTT: 512M 0x4000 - 
 0x5FFF
 [0.303021] [drm] radeon: 1024M of VRAM memory ready
 [0.303108] [drm] radeon: 512M of GTT memory ready.
 [0.303378] radeon :01:00.0: irq 41 for MSI/MSI-X
 [0.303390] radeon :01:00.0: radeon: using MSI.
 [0.303485] [drm] radeon: irq initialized.
 [0.304198] [drm] enabling PCIE gen 2 link speeds, disable with 
 radeon.pcie_gen2=0
 [0.304414] Registering platform device 'radeon_cp.0'. Parent at platform
 [0.304416] device: 'radeon_cp.0': device_add
 [0.304421] bus: 'platform': add device radeon_cp.0
 [0.304428] PM: Adding info for platform:radeon_cp.0
 [0.304497] platform radeon_cp.0: firmware: using built-in firmware 
 radeon/TURKS_pfp.bin
 [0.304501] platform radeon_cp.0: firmware: using built-in firmware 
 radeon/TURKS_me.bin
 [0.304503] platform radeon_cp.0: firmware: using built-in firmware 
 radeon/BTC_rlc.bin
 [0.304506] platform radeon_cp.0: firmware: using built-in firmware 
 radeon/TURKS_mc.bin
 [0.304517] bus: 'platform': remove device radeon_cp.0
 [0.304518] PM: Removing info for platform:radeon_cp.0
 [0.338906] radeon :01:00.0: WB enabled
 [0.338970] radeon :01:00.0: fence driver on ring 0 use gpu addr 
 0x4c00 and cpu addr 0x880244a0fc00
 [0.339064] radeon :01:00.0: fence driver on ring 3 use gpu addr 
 0x4c0c and cpu addr 0x880244a0fc0c
 [0.356604] device: 'radeon_bl0': device_add
 [0.356616] PM: Adding info for No Bus:radeon_bl0
 [0.407974] [drm] radeon atom DIG backlight initialized
 [0.408039] [drm] Radeon Display Connectors
 [0.410135] [drm] radeon: power management initialized
 [0.822297] fbcon: radeondrmfb (fb0) is primary device
 [1.585493] radeon :01:00.0: fb0: radeondrmfb frame buffer device
 [1.585546] radeon :01:00.0: registered panic notifier
 [1.585601] [drm] Initialized radeon 2.28.0 20080528 for :01:00.0 on 
 minor 0
 [1.585658] driver: ':01:00.0': driver_bound: bound to device 'radeon'
 [1.585661] bus: 'pci': really_probe: bound device :01:00.0 to driver 
 radeon


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Get HDMI version from device tree

[Stephen Warren]

On 01/07/2013 01:43 PM, Sean Paul wrote:
 Add a property to the hdmi node so we can specify the HDMI version in
 the device tree instead of just defaulting to v1.4 with the existence of
 the dt node.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
 b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

 @@ -11,6 +11,8 @@ Required properties:
   c) pin function mode.
   d) optional flags and pull up/down.
   e) drive strength.
 +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
 +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

Which device; the HDMI controller in the SoC, or the HDMI sink?

The HDMI sync reports what it supports in the EDID, so there shouldn't
be a need to duplicate this in the device tree (besides, how can you
know what the user plugged in without parsing the EDID?)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/8] drm/exynos: fimd: add complete_scanout function

[Mandeep Singh Baines]

On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K prathyus...@samsung.com wrote:
 The wait_for_vblank interface is modified to the complete_scanout
 function in fimd. This patch adds the fimd_complete_scanout function


With this series, you have a race if the rmfb happens before the flip
has completed.

Why not just use reference counts as is done in the i915 driver: see unpin_work.
The reference counts also allow you to avoid blocking in rmfb.

Regards,
Mandeep

 Inside fimd_complete_scanout, we read the shadow register for each
 window and compare it with the dma address of the framebuffer. If
 the dma_address is in the shadow register, then the function waits
 for the next vblank and returns.

 Signed-off-by: Prathyush K prathyus...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 32 
 +++-
  include/video/samsung_fimd.h |  1 +
  2 files changed, 32 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 3aeedf5..190ffde9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -46,6 +46,7 @@
  #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)

  #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
 +#define VIDWx_BUF_START_S(win, buf)(VIDW_BUF_START_S(buf) + (win) * 8)
  #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 
 8)
  #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)

 @@ -363,13 +364,42 @@ static void fimd_wait_for_vblank(struct device *dev)
 fimd_disable_vblank(dev);
  }

 +static void fimd_complete_scanout(struct device *dev, dma_addr_t dma_addr,
 +   unsigned long size)
 +{
 +   struct fimd_context *ctx = get_fimd_context(dev);
 +   int win;
 +   bool in_use = false;
 +
 +   if (ctx-suspended)
 +   return;
 +
 +   for (win = 0; win  WINDOWS_NR; win++) {
 +   dma_addr_t dma_addr_in_use;
 +
 +   if (!ctx-win_data[win].enabled)
 +   continue;
 +
 +   dma_addr_in_use = readl(ctx-regs + VIDWx_BUF_START_S(win, 
 0));
 +   if (dma_addr_in_use = dma_addr 
 +   dma_addr_in_use  (dma_addr + size)) {
 +   in_use = true;
 +   break;
 +   }
 +   }
 +
 +   if (in_use)
 +   fimd_wait_for_vblank(dev);
 +   return;
 +}
 +
  static struct exynos_drm_manager_ops fimd_manager_ops = {
 .dpms = fimd_dpms,
 .apply = fimd_apply,
 .commit = fimd_commit,
 .enable_vblank = fimd_enable_vblank,
 .disable_vblank = fimd_disable_vblank,
 -   .wait_for_vblank = fimd_wait_for_vblank,
 +   .complete_scanout = fimd_complete_scanout,
  };

  static void fimd_win_mode_set(struct device *dev,
 diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
 index 7ae6c07..382eaec 100644
 --- a/include/video/samsung_fimd.h
 +++ b/include/video/samsung_fimd.h
 @@ -274,6 +274,7 @@

  /* Video buffer addresses */
  #define VIDW_BUF_START(_buff)  (0xA0 + ((_buff) * 8))
 +#define VIDW_BUF_START_S(_buff)(0x40A0 + ((_buff) * 
 8))
  #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
  #define VIDW_BUF_END(_buff)(0xD0 + ((_buff) * 8))
  #define VIDW_BUF_END1(_buff)   (0xD4 + ((_buff) * 8))
 --
 1.8.0

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:drm-intel-fixes 4/4] drivers/gpu/drm/drm_mm.c:629:3: error: implicit declaration of function '__drm_mm_hole_node_end'

[kbuild test robot]

tree:   git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-fixes
head:   42f26597f4631137336315798461cd3d554e120c
commit: 42f26597f4631137336315798461cd3d554e120c [4/4] drm: Only evict the 
blocks required to create the requested hole
config: make ARCH=x86_64 allyesconfig

All error/warnings:

drivers/gpu/drm/drm_mm.c: In function 'drm_mm_scan_remove_block':
drivers/gpu/drm/drm_mm.c:629:3: error: implicit declaration of function 
'__drm_mm_hole_node_end' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

vim +/__drm_mm_hole_node_end +629 drivers/gpu/drm/drm_mm.c

ea7b1dd4 Daniel Vetter 2011-02-18  623  prev_node = 
list_entry(node-node_list.prev, struct drm_mm_node,
ea7b1dd4 Daniel Vetter 2011-02-18  624 
node_list);
709ea971 Daniel Vetter 2010-07-02  625  
ea7b1dd4 Daniel Vetter 2011-02-18  626  prev_node-hole_follows = 
node-scanned_preceeds_hole;
ea7b1dd4 Daniel Vetter 2011-02-18  627  list_add(node-node_list, 
prev_node-node_list);
709ea971 Daniel Vetter 2010-07-02  628  
42f26597 Chris Wilson  2012-12-19 @629   return 
(__drm_mm_hole_node_end(node)  mm-scan_hit_start 
42f26597 Chris Wilson  2012-12-19  630   node-start  
mm-scan_hit_end);
709ea971 Daniel Vetter 2010-07-02  631  }
709ea971 Daniel Vetter 2010-07-02  632  EXPORT_SYMBOL(drm_mm_scan_remove_block);

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon CS parser refactoring

[Ilija Hadzic]

On Fri, 4 Jan 2013, Alex Deucher wrote:


R6xx and r7xx are really all you need to worry about in this case.
R1xx-r5xx UMS uses a different kernel interface for command submission
and evergreen and later don't have UMS drm support.  UMS r6xx/r7xx
support used the same kernel interface for command submission but the
kernel side was much simpler.


OK, I have found an old machine with RV730 GPU and a known-working UMS: 
2.6.35 kernel, 6.13.2 DDX, 7.8.2 mesa (classic), 1.9 Xorg). I changed the 
kernel to the latest drm-next and ran tests with and without my 
CS-refactoring patches. Here are the results:


* It appears that drm-next in its current state is broken with regard
  to UMS (nothing to do with my patches, it was pre-broken to begin with).
  UMS provokes the kernel into a NULL-pointer dereference oops. Good news
  is that I have tracked down the crash and I will be sending the patches
  with the fix shortly.

* There are multiple patches that contributed to the breakage of UMS.
  I didn't bother pin-pointing them all, but one that I looked
  (6a7068b4) dates back to April 2012 so there are kernels out in
  distros that crash on UMS. That probably tells us how many UMS
  users are left out there :-). BTW, the reason UMS crashes is
  because parser-rdev is NULL in UMS mode so every patch that tries
  to dereference it (and shares the code path with UMS) will cause an
  oops (it will become clear when you see the patches).

* So, having fixed the above incidental finding, I got my machine
  with ancient UMS-userspace and a shiny latest drm-next kernel (plus
  my CS-refactoring patches plus my yet-to-be-sent UMS fixes) to
  work. My test consists of bringing up Gnome (it's Gnome 2 on that
  machine), running glxgears, sphereworld (an example code from
  OpenGL Superbible book), and OpenArena. Everything seems to work.

* Going back to KMS and retesting there, things still look good.

So this (with tests I did on Friday) should cover all the cases.


Additionally, UMS requires the old
non-gallium 3D drivers.  It sounds like some other change in the ddx
broke UMS support for r6xx/r7xx.


The DDX segfault I reported on Friday was provoked by trying to run 
Gallium 3D driver on the top of UMS. Once I switched back to classic, the 
crash went away. So I guess the userspace crash was provoked by some 
obscure path that was never intended to be exercised. I don't think

it's worth investigating further.

-- Ilija

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Get HDMI version from device tree

[Sean Paul]

On Jan 7, 2013 5:32 PM, Stephen Warren swar...@wwwdotorg.org wrote:

 On 01/07/2013 01:43 PM, Sean Paul wrote:
  Add a property to the hdmi node so we can specify the HDMI version in
  the device tree instead of just defaulting to v1.4 with the existence of
  the dt node.

  diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt

  @@ -11,6 +11,8 @@ Required properties:
c) pin function mode.
d) optional flags and pull up/down.
e) drive strength.
  +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
  +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

 Which device; the HDMI controller in the SoC, or the HDMI sink?


It's the controller.

 The HDMI sync reports what it supports in the EDID, so there shouldn't
 be a need to duplicate this in the device tree (besides, how can you
 know what the user plugged in without parsing the EDID?)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

fix for crashes provoked by UMS mode

[Ilija Hadzic]

At Dave's request I ran some regression tests on my CS-refactoring
patches [1] against old UMS userspace. The tests have revealed
that the current kernel can be provoked into crashing in UMS mode
(and the problem is unrelated to refactoring of CS code; it has
been here before).

The following patches will fix the problem that I discovered
while testing (and they should probably go to drm-fixes branch).
First two patches are the fix for the acute problem, while
the third patch is a fix for an incidental finding uncovered
while debugging the problem.


[1] http://lists.freedesktop.org/archives/dri-devel/2013-January/032814.html

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/radeon: fix NULL pointer dereference in UMS mode

[Ilija Hadzic]

In UMS mode parser-rdev is NULL, so dereferencing
will cause an oops.

Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
 drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 396baba0..45151c4 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -279,7 +279,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
  p-chunks[p-chunk_ib_idx].length_dw);
return -EINVAL;
}
-   if ((p-rdev-flags  RADEON_IS_AGP)) {
+   if (p-rdev  (p-rdev-flags  RADEON_IS_AGP)) {
p-chunks[p-chunk_ib_idx].kpage[0] = 
kmalloc(PAGE_SIZE, GFP_KERNEL);
p-chunks[p-chunk_ib_idx].kpage[1] = 
kmalloc(PAGE_SIZE, GFP_KERNEL);
if (p-chunks[p-chunk_ib_idx].kpage[0] == NULL ||
@@ -583,7 +583,8 @@ static int radeon_cs_update_pages(struct radeon_cs_parser 
*p, int pg_idx)
struct radeon_cs_chunk *ibc = p-chunks[p-chunk_ib_idx];
int i;
int size = PAGE_SIZE;
-   bool copy1 = (p-rdev-flags  RADEON_IS_AGP) ? false : true;
+   bool copy1 = (p-rdev  (p-rdev-flags  RADEON_IS_AGP)) ?
+   false : true;
 
for (i = ibc-last_copied_page + 1; i  pg_idx; i++) {
if (DRM_COPY_FROM_USER(p-ib.ptr + (i * (PAGE_SIZE/4)),
-- 
1.8.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/radeon: fix a bogus kfree

[Ilija Hadzic]

parser-chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.

This patch fixes a kernel oops that can be provoked
in UMS mode.

Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
 drivers/gpu/drm/radeon/r600_cs.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 9ea13d0..f8adb01 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2476,8 +2476,10 @@ static void r600_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
kfree(parser-relocs);
for (i = 0; i  parser-nchunks; i++) {
kfree(parser-chunks[i].kdata);
-   kfree(parser-chunks[i].kpage[0]);
-   kfree(parser-chunks[i].kpage[1]);
+   if (parser-rdev  (parser-rdev-flags  RADEON_IS_AGP)) {
+   kfree(parser-chunks[i].kpage[0]);
+   kfree(parser-chunks[i].kpage[1]);
+   }
}
kfree(parser-chunks);
kfree(parser-chunks_array);
-- 
1.8.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/radeon: fix error path in kpage allocation

[Ilija Hadzic]

Index into chunks[] array doesn't look right.

Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
 drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 45151c4..469661f 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -284,8 +284,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
p-chunks[p-chunk_ib_idx].kpage[1] = 
kmalloc(PAGE_SIZE, GFP_KERNEL);
if (p-chunks[p-chunk_ib_idx].kpage[0] == NULL ||
p-chunks[p-chunk_ib_idx].kpage[1] == NULL) {
-   kfree(p-chunks[i].kpage[0]);
-   kfree(p-chunks[i].kpage[1]);
+   kfree(p-chunks[p-chunk_ib_idx].kpage[0]);
+   kfree(p-chunks[p-chunk_ib_idx].kpage[1]);
return -ENOMEM;
}
}
-- 
1.8.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon CS parser refactoring

[Marek Olšák]

On Tue, Jan 8, 2013 at 12:09 AM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:


 On Fri, 4 Jan 2013, Alex Deucher wrote:

 R6xx and r7xx are really all you need to worry about in this case.
 R1xx-r5xx UMS uses a different kernel interface for command submission
 and evergreen and later don't have UMS drm support.  UMS r6xx/r7xx
 support used the same kernel interface for command submission but the
 kernel side was much simpler.


 OK, I have found an old machine with RV730 GPU and a known-working UMS:
 2.6.35 kernel, 6.13.2 DDX, 7.8.2 mesa (classic), 1.9 Xorg). I changed the
 kernel to the latest drm-next and ran tests with and without my
 CS-refactoring patches. Here are the results:

 * It appears that drm-next in its current state is broken with regard
   to UMS (nothing to do with my patches, it was pre-broken to begin with).
   UMS provokes the kernel into a NULL-pointer dereference oops. Good news
   is that I have tracked down the crash and I will be sending the patches
   with the fix shortly.

 * There are multiple patches that contributed to the breakage of UMS.
   I didn't bother pin-pointing them all, but one that I looked
   (6a7068b4) dates back to April 2012 so there are kernels out in
   distros that crash on UMS. That probably tells us how many UMS
   users are left out there :-). BTW, the reason UMS crashes is
   because parser-rdev is NULL in UMS mode so every patch that tries
   to dereference it (and shares the code path with UMS) will cause an
   oops (it will become clear when you see the patches).

 * So, having fixed the above incidental finding, I got my machine
   with ancient UMS-userspace and a shiny latest drm-next kernel (plus
   my CS-refactoring patches plus my yet-to-be-sent UMS fixes) to
   work. My test consists of bringing up Gnome (it's Gnome 2 on that
   machine), running glxgears, sphereworld (an example code from
   OpenGL Superbible book), and OpenArena. Everything seems to work.

 * Going back to KMS and retesting there, things still look good.

 So this (with tests I did on Friday) should cover all the cases.


 Additionally, UMS requires the old
 non-gallium 3D drivers.  It sounds like some other change in the ddx
 broke UMS support for r6xx/r7xx.


 The DDX segfault I reported on Friday was provoked by trying to run Gallium
 3D driver on the top of UMS. Once I switched back to classic, the crash went
 away. So I guess the userspace crash was provoked by some obscure path that
 was never intended to be exercised. I don't think
 it's worth investigating further.

IIRC, the radeon gallium drivers call abort() if they encounter an
unsupported DRM version (that is UMS).

Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon CS parser refactoring

[Ilija Hadzic]

On Mon, Jan 7, 2013 at 7:21 PM, Marek Olšák mar...@gmail.com wrote:

 IIRC, the radeon gallium drivers call abort() if they encounter an
 unsupported DRM version (that is UMS).


I am not familiar enough to comment, but my observation was that as
soon as I backed out to classic, the segfault went away. So I assumed
that the mismatch between the UMS and Gallium was the cause.

Anyway, it's a secondary issue for this thread.

-- Ilija
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=59089

--- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Seems good now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=59089

Alexandre Demers alexandre.f.dem...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

This patch set adds bug fixes and code cleanups and also
includes previous pull request you missed.
http://www.spinics.net/lists/dri-devel/msg32253.html

Summary:
- change exynos file license
  . Most of exynos files had been copied from some randome
file and not updated correctly(wrong company name used).
This was our mistakes so chagnes it correctly. For this,
I'm not sure that this patch should go to -fix or -next.
So please give me any comment if there is any problem.
- consider buffer allocation without iommu
  . Without iommu, dma_alloc_attrs function allocates some
memory region and returns cpu address so this patch makes
the cpu address to be set to buf-kvaddr correctly
- cleanups to ipp relevant codes.
- use common finish page flip function
  . to avoid the duplication of same code, use
exynos_drm_crtc_finish_pageflip function commonly instead
of each one.
- fix fimd resume issue.
  . when fimd was turned off by suspend, there was one issue that
the fimd wasn't turned on by resume so fix it chaing resume
condition.

If there is any problem, please kindly let me know.

Thanks,
Inki Dae

The following changes since commit eda85d6ad490923152544fba0473798b6cc0edf6:

  drm/nouveau: fix init with agpgart-uninorth (2013-01-04 16:04:33 +1000)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

Eunchul Kim (6):
  drm/exynos: change member variable name.
  drm/exynos: remove needless error handling to property.
  drm/exynos: consider both case of vflip and hflip.
  drm/exynos: fix build warning.
  drm/exynos: correct some comments to abbreviation.
  drm/exynos: remove needless parenthesis.

Inki Dae (4):
  drm/exynos: consider no iommu support to console framebuffer
  drm/exynos: change file license to GPL
  drm/exynos: consider buffer allocation without iommu
  drm/exynos: fix gem buffer allocation type checking

Jinyoung Jeon (1):
  drm/exynos: fix incorrect interrupt induced by m2m operation.

JoongMock Shin (1):
  drm/exynos: remove color bar pattern operation.

Prathyush K (1):
  drm/exynos: fimd: modify condition in fimd resume

Rahul Sharma (1):
  drm/exynos: move finish page flip to a common place

Sachin Kamat (10):
  drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c
  drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_fimc.c
  drm/exynos: Remove redundant NULL check
  drm/exynos: Use devm_clk_get in exynos_drm_fimc.c
  drm/exynos: Remove unnecessary devm_* freeing APIs in exynos_drm_rotator.c
  drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c
  drm/exynos: Use devm_clk_get in exynos_drm_rotator.c
  drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_gsc.c
  drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c
  drm/exynos: Use devm_clk_get in exynos_drm_gsc.c

Seung-Woo Kim (1):
  drm/exynos: fix flags in dma buf exporting

 drivers/gpu/drm/exynos/exynos_drm_buf.c   |   79 +++-
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   22 +
 drivers/gpu/drm/exynos/exynos_drm_connector.h |   22 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   22 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   52 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   23 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|   24 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h|   22 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.h   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   22 +
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   22 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   44 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |   22 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  124 -
 drivers/gpu/drm/exynos/exynos_drm_fimc.h  |   22 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   32 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   |   56 +++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.h   |   22 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |   22 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.c |   22 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.h |   22 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |   22 +---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   |   26 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   28 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.h   |   22 +
 

[PATCH 1/2] vga_switcheroo: add mux switched interface

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

this tells the drivers when the mux is switch to/from it, can be used
to report outputs as disconnected to userspace etc.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/vga/vga_switcheroo.c | 19 +++
 include/linux/vga_switcheroo.h   |  1 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index fa60add..2362175 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -93,6 +93,9 @@ static void vga_switcheroo_enable(void)
return;
 
client-id = ret;
+
+   if (client-ops-mux_switched)
+   client-ops-mux_switched(client-pdev, client-active 
? VGA_SWITCHEROO_ON : VGA_SWITCHEROO_OFF);
}
vga_switcheroo_debugfs_init(vgasr_priv);
vgasr_priv.active = true;
@@ -345,6 +348,13 @@ static int vga_switchto_stage2(struct 
vga_switcheroo_client *new_client)
if (ret)
return ret;
 
+   /* call mux switched callbacks */
+   if (active-ops-mux_switched)
+   active-ops-mux_switched(active-pdev, VGA_SWITCHEROO_OFF);
+
+   if (new_client-ops-mux_switched)
+   new_client-ops-mux_switched(new_client-pdev, 
VGA_SWITCHEROO_ON);
+
if (new_client-ops-reprobe)
new_client-ops-reprobe(new_client-pdev);
 
@@ -452,7 +462,16 @@ vga_switcheroo_debugfs_write(struct file *filp, const char 
__user *ubuf,
vgasr_priv.delayed_switch_active = false;
 
if (just_mux) {
+   struct vga_switcheroo_client *active;
+   active = find_active_client(vgasr_priv.clients);
+   if (!active)
+   return 0;
ret = vgasr_priv.handler-switchto(client_id);
+
+   if (active-ops-mux_switched)
+   active-ops-mux_switched(active-pdev, 
VGA_SWITCHEROO_OFF);
+   if (client-ops-mux_switched)
+   client-ops-mux_switched(client-pdev, 
VGA_SWITCHEROO_ON);
goto out;
}
 
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index ddb419c..6275719 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -40,6 +40,7 @@ struct vga_switcheroo_client_ops {
void (*set_gpu_state)(struct pci_dev *dev, enum vga_switcheroo_state);
void (*reprobe)(struct pci_dev *dev);
bool (*can_switch)(struct pci_dev *dev);
+   void (*mux_switched)(struct pci_dev *dev, enum vga_switcheroo_state);
 };
 
 #if defined(CONFIG_VGA_SWITCHEROO)
-- 
1.8.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] radeon: add support for forcing off lvds when mux switched away

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

otherwise userspace can get very confused
---
 drivers/gpu/drm/radeon/radeon_connectors.c |  4 
 drivers/gpu/drm/radeon/radeon_device.c | 14 ++
 drivers/gpu/drm/radeon/radeon_mode.h   |  2 ++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2399f25..e5a4a10 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -611,6 +611,10 @@ radeon_lvds_detect(struct drm_connector *connector, bool 
force)
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
struct drm_encoder *encoder = radeon_best_single_encoder(connector);
enum drm_connector_status ret = connector_status_disconnected;
+   struct radeon_device *rdev = connector-dev-dev_private;
+
+   if (rdev-mode_info.mux_force_disconnected)
+   return connector_status_disconnected;
 
if (encoder) {
struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(encoder);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index cd75626..bf66f09 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -945,10 +945,24 @@ static bool radeon_switcheroo_can_switch(struct pci_dev 
*pdev)
return can_switch;
 }
 
+static void radeon_switcheroo_mux_switched(struct pci_dev *pdev, enum 
vga_switcheroo_state state)
+{
+   struct drm_device *dev = pci_get_drvdata(pdev);
+   struct radeon_device *rdev = dev-dev_private;
+
+   if (state == VGA_SWITCHEROO_OFF)
+   rdev-mode_info.mux_force_disconnected = true;
+   else
+   rdev-mode_info.mux_force_disconnected = false;
+
+   drm_kms_helper_hotplug_event(dev);
+}
+
 static const struct vga_switcheroo_client_ops radeon_switcheroo_ops = {
.set_gpu_state = radeon_switcheroo_set_state,
.reprobe = NULL,
.can_switch = radeon_switcheroo_can_switch,
+   .mux_switched = radeon_switcheroo_mux_switched,
 };
 
 /**
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 4003f5a..172eed8 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -256,6 +256,8 @@ struct radeon_mode_info {
u16 firmware_flags;
/* pointer to backlight encoder */
struct radeon_encoder *bl_encoder;
+
+   bool mux_force_disconnected;
 };
 
 #define RADEON_MAX_BL_LEVEL 0xFF
-- 
1.8.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=59089

Thomas Rohloff v10la...@myway.de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #3 from Thomas Rohloff v10la...@myway.de ---
I don't want to play the bad guy but for me this is not fixed, just reduced.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58667] Random crashes on CAYMAN

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=58667

--- Comment #31 from Thomas Rohloff v10la...@myway.de ---
(In reply to comment #30)
 Should be fixed with this mesa commit:
 http://cgit.freedesktop.org/mesa/mesa/commit/
 ?id=4332f6fc185f968e7563e748b8c949021937c935

Sadly it isn't.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=59089

--- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #3)
 I don't want to play the bad guy but for me this is not fixed, just reduced.

Well, I closed it because I don't have the continuous GPU fault flood happening
anymore. However, I was unable to determine if there was still a GPU fault
happening. This bug is really about the flood.

So, I don't have any problem in reopening it if you do experience a flood of
GPU faults. I was getting GB of logs in no time.

Are you still seeing GPU faults only in some circumstances (games or specific
applications) or just opening a session (for me it's with Gnome Shell) is
enough? Also, keep in mind this bug is pinpointing a specific commit.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=58354

--- Comment #12 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Just to let you know, commit
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4332f6fc185f968e7563e748b8c949021937c935
didn't solve the issue for this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Get HDMI version from device tree

[Mitch Bradley]

On 1/7/2013 10:43 AM, Sean Paul wrote:
 Add a property to the hdmi node so we can specify the HDMI version in
 the device tree instead of just defaulting to v1.4 with the existence of
 the dt node.
 
 Signed-off-by: Sean Paul seanp...@chromium.org
 ---
  .../devicetree/bindings/drm/exynos/hdmi.txt|3 +++
  drivers/gpu/drm/exynos/exynos_hdmi.c   |   19 ++-
  2 files changed, 13 insertions(+), 9 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt 
 b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
 index 589edee..d1c7d91 100644
 --- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
 +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
 @@ -11,6 +11,8 @@ Required properties:
   c) pin function mode.
   d) optional flags and pull up/down.
   e) drive strength.
 +- samsung,supports-hdmi-1.4: Define if device supports HDMI v1.4
 +- samsung,supports-hdmi-1.3: Define if device supports HDMI v1.3

a) This seems pretty generic, not at all samsung-specific, as the HDMI
version numbering space is well-defined by the HDMI spec.

b) It would be better to make it an integer property whose value
encodes the version number, thus eliminating the need to add new
properties as new HDMI versions appear.

  
  Example:
  
 @@ -19,4 +21,5 @@ Example:
   reg = 0x1453 0x10;
   interrupts = 0 95 0;
   hpd-gpio = gpx3 7 0xf 1 3;
 + samsung,supports-hdmi-1.4;
   };
 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 2c46b6c..9834ae5 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -2444,7 +2444,6 @@ static struct platform_device_id hdmi_driver_types[] = {
  static struct of_device_id hdmi_match_types[] = {
   {
   .compatible = samsung,exynos5-hdmi,
 - .data   = (void *)HDMI_TYPE14,
   }, {
   /* end node */
   }
 @@ -2498,16 +2497,18 @@ static int __devinit hdmi_probe(struct 
 platform_device *pdev)
  
   platform_set_drvdata(pdev, drm_hdmi_ctx);
  
 - if (dev-of_node) {
 - const struct of_device_id *match;
 - match = of_match_node(of_match_ptr(hdmi_match_types),
 - pdev-dev.of_node);
 - if (match == NULL)
 - return -ENODEV;
 - hdata-type = (enum hdmi_type)match-data;
 - } else {
 + if (!dev-of_node) {
   hdata-type = (enum hdmi_type)platform_get_device_id
   (pdev)-driver_data;
 + } else if (of_get_property(dev-of_node, samsung,supports-hdmi-1.4,
 + NULL)) {
 + hdata-type = HDMI_TYPE14;
 + } else if (of_get_property(dev-of_node, samsung,supports-hdmi-1.3,
 + NULL)) {
 + hdata-type = HDMI_TYPE13;
 + } else {
 + DRM_ERROR(Could not resolve HDMI version support\n);
 + return -ENODEV;
   }
  
   hdata-hpd_gpio = pdata-hpd_gpio;
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression: drm/radeon: brightness control hard system lockup

[Eldad Zack]

On Mon, 7 Jan 2013, Alex Deucher wrote:
 On Sun, Jan 6, 2013 at 7:59 AM, Eldad Zack el...@fogrefinery.com wrote:
 
  Hi Alex,
 
  Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f drm/radeon: switch to a
  finer grained reset for evergreen introduced a hard system lockup to my
  setup. I found it after bisecting, and confirmed it by reverting it on
  the latest mainline ( 5f243b9 ).
 
  This:
 
 echo 7  
  /sys/devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0/brightness
 
  Causes a hard lock-up hard, i.e. immediate freeze, without any logs.
 
  See lspci output and kernel .config below.
  If there's any more info I can provide, please let me know.
 
 Do you normally see GPU resets when changing the backlight?  Please
 attach your dmesg output when changing the backlight with the patch
 reverted.

I see nothing. Just to make sure, I cleared the buffer, cycled through 
0-7 a couple of hunderd times (until the flicker annoyed), but I see no
messages at all.
Is there any debug config I should turn on?

Turning ACPI debugging on gives me no messages neither when I use the 
cycle script.

But I did find out something interesting enough, only because I 
happen to have sound debugging on, if I have a PCM stream open to a
USB device, and then change the backlight level, it seems to drop to
microframes, but it's not otherwise noticeable. Looks like setting the
backlight still does something weird with my hardware/config.

Below is a grep -i radeon from my boot dmesg.

Cheers,
Eldad

[0.301558] [drm] radeon defaulting to kernel modesetting.
[0.301626] [drm] radeon kernel modesetting enabled.
[0.301694] bus: 'pci': add driver radeon
[0.301716] bus: 'pci': driver_probe_device: matched device :01:00.0 
with driver radeon
[0.301718] bus: 'pci': really_probe: probing driver radeon with device 
:01:00.0
[0.302310] radeon :01:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)
[0.302390] radeon :01:00.0: GTT: 512M 0x4000 - 
0x5FFF
[0.303021] [drm] radeon: 1024M of VRAM memory ready
[0.303108] [drm] radeon: 512M of GTT memory ready.
[0.303378] radeon :01:00.0: irq 41 for MSI/MSI-X
[0.303390] radeon :01:00.0: radeon: using MSI.
[0.303485] [drm] radeon: irq initialized.
[0.304198] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[0.304414] Registering platform device 'radeon_cp.0'. Parent at platform
[0.304416] device: 'radeon_cp.0': device_add
[0.304421] bus: 'platform': add device radeon_cp.0
[0.304428] PM: Adding info for platform:radeon_cp.0
[0.304497] platform radeon_cp.0: firmware: using built-in firmware 
radeon/TURKS_pfp.bin
[0.304501] platform radeon_cp.0: firmware: using built-in firmware 
radeon/TURKS_me.bin
[0.304503] platform radeon_cp.0: firmware: using built-in firmware 
radeon/BTC_rlc.bin
[0.304506] platform radeon_cp.0: firmware: using built-in firmware 
radeon/TURKS_mc.bin
[0.304517] bus: 'platform': remove device radeon_cp.0
[0.304518] PM: Removing info for platform:radeon_cp.0
[0.338906] radeon :01:00.0: WB enabled
[0.338970] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0x880244a0fc00
[0.339064] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0x880244a0fc0c
[0.356604] device: 'radeon_bl0': device_add
[0.356616] PM: Adding info for No Bus:radeon_bl0
[0.407974] [drm] radeon atom DIG backlight initialized
[0.408039] [drm] Radeon Display Connectors
[0.410135] [drm] radeon: power management initialized
[0.822297] fbcon: radeondrmfb (fb0) is primary device
[1.585493] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[1.585546] radeon :01:00.0: registered panic notifier
[1.585601] [drm] Initialized radeon 2.28.0 20080528 for :01:00.0 on 
minor 0
[1.585658] driver: ':01:00.0': driver_bound: bound to device 'radeon'
[1.585661] bus: 'pci': really_probe: bound device :01:00.0 to driver 
radeon


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCHv16 5/7] fbmon: add of_videomode helpers

[Mohammed, Afzal]

Hi Rob,

On Tue, Jan 08, 2013 at 01:36:50, Rob Clark wrote:
 On Mon, Jan 7, 2013 at 2:46 AM, Mohammed, Afzal af...@ti.com wrote:
  On Mon, Jan 07, 2013 at 13:36:48, Steffen Trumtrar wrote:

  I just did a quick make da8xx_omapl_defconfig  make and it builds just 
  fine.
  On what version did you apply the series?
  At the moment I have the series sitting on 3.7. Didn't try any 3.8-rcx yet.
  But fixing this shouldn't be a problem.

  The change as I mentioned or something similar would be required as
  any driver that is going to make use of of_get_fb_videomode() would
  break if CONFIG_OF_VIDEOMODE or CONFIG_FB_MODE_HELPERS is not defined.

 Shouldn't the driver that depends on CONFIG_OF_VIDEOMODE and
 CONFIG_FB_MODE_HELPERS, explicitly select them?  I don't really see
 the point of having the static-inline fallbacks.

But here da8xx-fb driver does not depend on _OF_VIDEOMODE and
_FB_MODE_HELPERS, currently it works as a pure platform driver
for DaVinci SoC's without those CONFIG's. It is only upon
enhancing the driver to make use of of_get_fb_videomode() for
DT support those CONFIG's are being made use of.

As the driver can work w/o these CONFIG's and so as it is not a
dependency for driver on non-DT boot (as in the case of DaVinci),
I disagree in selecting those options always, but rather giving
user an option to select.

And selecting these options always will bring in some amount of code
onto Kernel image w/o any purpose in the case of DaVinci builds.

Another option would be to sprinkle driver with ifdef's to avoid
inline fallbacks, which is not a good thing to do.

Moreover having a static inline fallback is more in line with other
of_*'s.

 fwiw, using 'select' is what I was doing for lcd panel support for
 lcdc/da8xx drm driver (which was using the of videomode helpers,
 albeit a slightly earlier version of the patches):

In your case as it is a new driver  is meant only for DT, that
is fine, but here it is an existing driver that works w/o these.

Regards
Afzal

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel