Re: [PATCH] drm: Remove two unused fields from struct drm_display_mode

2012-08-20 Thread Jani Nikula
On Fri, 17 Aug 2012, Damien Lespiau  wrote:
> From: Damien Lespiau 
>
> Signed-off-by: Damien Lespiau 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/drm_modes.c |3 ---
>  include/drm/drm_crtc.h  |2 --
>  2 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index b7adb4a..28637c1 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -706,9 +706,6 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, 
> int adjust_flags)
>   p->crtc_vblank_end = max(p->crtc_vsync_end, p->crtc_vtotal);
>   p->crtc_hblank_start = min(p->crtc_hsync_start, p->crtc_hdisplay);
>   p->crtc_hblank_end = max(p->crtc_hsync_end, p->crtc_htotal);
> -
> - p->crtc_hadjusted = false;
> - p->crtc_vadjusted = false;
>  }
>  EXPORT_SYMBOL(drm_mode_set_crtcinfo);
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a1a0386..ced3625 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -166,8 +166,6 @@ struct drm_display_mode {
>   int crtc_vsync_start;
>   int crtc_vsync_end;
>   int crtc_vtotal;
> - int crtc_hadjusted;
> - int crtc_vadjusted;
>  
>   /* Driver private mode info */
>   int private_size;
> -- 
> 1.7.7.5
>
> ___
> 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


Re: [PATCH 11/13] drm/exynos: changed context name of hdmi and mixer

2012-08-20 Thread InKi Dae
2012/8/20 InKi Dae :
> 2012/8/20 Joonyoung Shim :
>> On 08/20/2012 03:17 PM, InKi Dae wrote:
>>>
>>> 2012/8/20 Joonyoung Shim :

 On 08/20/2012 11:29 AM, InKi Dae wrote:
>
> 2012/8/20 Joonyoung Shim :
>>
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>>
>>> this patch changes ctx variable name in exynos_drm_hdmi_context
>>> structure to client because the use of ctx variable makes it confused.
>>
>>
>> I don't prefer "client" name. This is not client and server
>> relationship.
>>
> Okay, give me your opinion. which one do you prefer?


 Just "data".

>>> It's not clear. "data" is so comprehensive just use "child_ctx". we
>>> already use "parent_ctx" as the context of exynos_drm_hdmi module.
>>
>>
>> Actually, i prefer "data" term than "ctx" term. Anyway i want to focus
>> why this problem is occurred because i think that codes are some ugly. I
>> think we first need to consider to solve this situation using code
>> redesign, structure change and etc.
>>
>
> calm down and focus on the use of term. this is so minor and this is
> not related to design issue.
>

and it's not important whether you prefer this term or not. if the use
of "data" term is logical enough then we will use it otherwise
"child_ctx" so give me your comment why you don't prefer "child_ctx"
term. actually, now hdmi codes use "hdata" term as context's instance
but other use "ctx" term. as I mentioned before, I gave you my opinion
that "data" term is so comprehensive so I DON'T PREFER "data" term.

>> Thanks.
>>
>>
>>>
 Thanks.


>>> Signed-off-by: Inki Dae 
>>> Signed-off-by: Kyungmin Park 
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   38
>>> +++---
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
>>> drivers/gpu/drm/exynos/exynos_hdmi.c |   12 
>>> drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
>>> 4 files changed, 31 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> index 3fdf0b6..bced38e 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>>> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device
>>> *dev)
>>>   DRM_DEBUG_KMS("%s\n", __FILE__);
>>>   if (hdmi_ops && hdmi_ops->is_connected)
>>> -   return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
>>> +   return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
>>>   return false;
>>> }
>>> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
>>>   DRM_DEBUG_KMS("%s\n", __FILE__);
>>>   if (hdmi_ops && hdmi_ops->get_edid)
>>> -   return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx,
>>> connector,
>>> edid,
>>> - len);
>>> +   return hdmi_ops->get_edid(ctx->hdmi_ctx->client,
>>> connector,
>>> +   edid, len);
>>>   return 0;
>>> }
>>> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
>>> void *timing)
>>>   DRM_DEBUG_KMS("%s\n", __FILE__);
>>>   if (hdmi_ops && hdmi_ops->check_timing)
>>> -   return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx,
>>> timing);
>>> +   return hdmi_ops->check_timing(ctx->hdmi_ctx->client,
>>> timing);
>>>   return 0;
>>> }
>>> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev,
>>> int
>>> mode)
>>>   DRM_DEBUG_KMS("%s\n", __FILE__);
>>>   if (hdmi_ops && hdmi_ops->power_on)
>>> -   return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
>>> +   return hdmi_ops->power_on(ctx->hdmi_ctx->client,
>>> mode);
>>>   return 0;
>>> }
>>> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
>>> *subdrv_dev)
>>>   DRM_DEBUG_KMS("%s\n", __FILE__);
>>>   if (mixer_ops && mixer_ops->enable_vblank)
>>> -   return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
>>> +   return
>>> mixer_ops->enable_vblank(ctx->mixer_ctx->client,
>>>   manager->pipe);
>>>   return 0;
>>> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct
>>> device
>>> *subdrv_dev)
>>>   DRM_DEBUG_KMS("%s\n", __FILE__);
>>>   if (mixer_ops && mixer_ops->disable_vblank)
>>> -   return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
>>> +   return
>>> mixer_ops->disable_vblank(ctx->mixer_ctx->client);
>>> }
>>>   

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

2012-08-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #51 from gy...@gmx.de 2012-08-20 07:32:20 UTC ---
With this xorg.conf i can use two external monitor connected to the
dockingstation.
Additionally the internal screen of the notebook is in textmode.
--
$cat /etc/X11/xorg.conf
Section "Device"
  Identifier "radeon"
  Driver "radeon"
  BusID "PCI:22:00:0"
EndSection

Section "Device"
  Identifier "intel"
  Driver "intel"
  BusID "PCI:00:02:0"
EndSection

Section "Screen"
  Identifier "Screen0"
  Device "radeon"
EndSection

Section "Screen"
  Identifier "Screen1"
  Device "intel"
EndSection

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 46241] New: Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241

   Summary: Resume to black screen on AMD A8-3500m/Radeon 6620G
   Product: Drivers
   Version: 2.5
Kernel Version: Linux version 3.6.0-030600rc1-generic (apw@gomeisa)
(gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
#201208022056 SMP Fri Aug 3 00:57:36 UTC 2012
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: geoffrey.te...@canonical.com
Regression: No


Created an attachment (id=77931)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77931)
/proc/cpu_info

I can suspend and resume however when I resume the screen stays black. It looks
like the backlight isn't coming on, but it's notable that I don't see anything
on my external screen either. I can see consoles on my external monitor (over
HDMI) if I switch using Ctrl-Alt-FnKey combos.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241





--- Comment #1 from Geoffrey Teale   2012-08-20 
07:42:47 ---
Created an attachment (id=77941)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77941)
lspci

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241





--- Comment #2 from Geoffrey Teale   2012-08-20 
07:43:23 ---
Created an attachment (id=77951)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77951)
modules

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241





--- Comment #3 from Geoffrey Teale   2012-08-20 
07:44:08 ---
Created an attachment (id=77961)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77961)
ver_linux

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241





--- Comment #4 from Geoffrey Teale   2012-08-20 
07:44:55 ---
Created an attachment (id=77971)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=77971)
io

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241





--- Comment #5 from Geoffrey Teale   2012-08-20 
07:55:10 ---
Sorry, should look like this:
[1.] Lenovo E525 screen black on resume
[2.] My setup is a Lenovo Thinkpad E525, AMD A8-3500m/Radeon 6620G Llano
series APU.  I am running Ubuntu 12.04, but with a mainline 3.6 kernel
(although this bug occurs in previous kernel version including the
stock Ubuntu 12.04 kernel). I can suspend and resume however when I
resume the screen stays black. It looks like the backlight isn't coming
on, but it's notable that I don't see anything on my external screen
either. I can see consoles on my external monitor (over HDMI) if I
switch using Ctrl-Alt-FnKey combos.
[3.] modules,kernel,dri
[4.] Linux version 3.6.0-030600rc1-generic (apw@gomeisa) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201208022056 SMP Fri Aug 3 00:57:36 UTC 2012
[5.]
[6.]
[7.]
Description:Ubuntu 12.04 LTS
Release:12.04
[7.1.]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux stop-squark 3.6.0-030600rc1-generic #201208022056 SMP Fri Aug 3 00:57:36
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Gnu C  4.6
Gnu make   3.81
binutils   2.22
util-linux 2.20.1
mount  support
module-init-tools  3.16
e2fsprogs  1.42
pcmciautils018
PPP2.4.5
Linux C Library2.15
Dynamic linker (ldd)   2.15
Procps 3.2.8
Net-tools  1.60
Kbd1.15.2
Sh-utils   8.13
wireless-tools 30
Modules Loaded input_polldev iptable_filter dm_crypt joydev
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
ip_tables x_tables bridge stp llc arc4 kvm_amd kvm thinkpad_acpi hid_generic
bnep microcode rtl8192ce rtl8192c_common rtlwifi rfcomm snd_hda_codec_conexant
bluetooth mac80211 psmouse serio_raw snd_seq_midi parport_pc ppdev
snd_hda_codec_hdmi k10temp snd_rawmidi cfg80211 snd_seq_midi_event
snd_hda_intel snd_hda_codec snd_seq snd_hwdep snd_pcm i2c_piix4 snd_seq_device
snd_timer snd nvram soundcore snd_page_alloc mac_hid binfmt_misc lp parport
usbhid hid video radeon ttm drm_kms_helper drm i2c_algo_bit sdhci_pci sdhci
r8169
[7.2.] 
processor: 0
vendor_id: AuthenticAMD
cpu family: 18
model: 1
model name: AMD A8-3500M APU with Radeon(tm) HD Graphics
stepping: 0
microcode: 0x314
cpu MHz: 800.000
cache size: 1024 KB
physical id: 0
siblings: 4
core id: 0
cpu cores: 4
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 6
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid
aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat cpb hw_pstate npt
lbrv svm_lock nrip_save pausefilter
bogomips: 2994.58
TLB size: 1536 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor: 1
vendor_id: AuthenticAMD
cpu family: 18
model: 1
model name: AMD A8-3500M APU with Radeon(tm) HD Graphics
stepping: 0
microcode: 0x314
cpu MHz: 800.000
cache size: 1024 KB
physical id: 0
siblings: 4
core id: 1
cpu cores: 4
apicid: 1
initial apicid: 1
fpu: yes
fpu_exception: yes
cpuid level: 6
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid
aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat cpb hw_pstate npt
lbrv svm_lock nrip_save pausefilter
bogomips: 2994.58
TLB size: 1536 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 40 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor: 2
vendor_id: AuthenticAMD
cpu family: 18
model: 1
model name: AMD A8-3500M APU with Radeon(tm) HD Graphics
stepping: 0
microcode: 0x314
cpu MHz: 800.000
cache size: 1024 KB
physical id: 0
siblings: 4
core id: 2
cpu cores: 4
apicid: 2
initial apicid: 2
fpu: yes
fpu_exception: yes
cpuid level: 6
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fx

[PATCH 01/11] drm/radeon: fence virtual address and free it once idle v4

2012-08-20 Thread Christian König
From: Jerome Glisse 

Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.

Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.

v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.
v4: Fix compilation warnings.

Signed-off-by: Jerome Glisse 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h|1 +
 drivers/gpu/drm/radeon/radeon_cs.c |   32 +---
 drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
 drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
 drivers/gpu/drm/radeon/radeon_object.c |6 +-
 5 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+   struct radeon_fence *fence;
boolvalid;
 };
 
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..b4a0db24 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
 }
 
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+   struct radeon_vm *vm = &fpriv->vm;
+   struct radeon_bo_list *lobj;
+
+   if (parser->chunk_ib_idx == -1) {
+   return;
+   }
+   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0) {
+   return;
+   }
+
+   list_for_each_entry(lobj, &parser->validated, tv.head) {
+   struct radeon_bo_va *bo_va;
+   struct radeon_bo *rbo = lobj->bo;
+
+   bo_va = radeon_bo_va(rbo, vm);
+   radeon_fence_unref(&bo_va->fence);
+   bo_va->fence = radeon_fence_ref(fence);
+   }
+}
+
 /**
  * cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
 {
unsigned i;
 
-   if (!error)
+   if (!error) {
+   /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
still reserved */
+   radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
-   else
+   } else {
ttm_eu_backoff_reservation(&parser->validated);
+   }
 
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
 
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
 
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
 
-   if (bo_va->valid)
+   if (bo_va->valid && mem)
return 0;
 
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
 struct radeon_bo *bo)
 {
struct radeon_bo_va *bo_va;
+   int r;
 
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
 
+   /* wait for va use to end */
+   while (bo_va->fence) {
+   r = radeon_fence_wait(bo_va->fence, false);
+   if (r) {
+   DRM_ERROR("error while waiting for fence: %d\n", r);
+   }
+   if (r == -EDEADLK) {
+   r = radeon_gpu_reset(rdev);
+   if (!r)
+   continue;
+   }
+   break;
+   }
+   radeon_fence_unref(&bo_va->fence);
+
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(&rdev->vm_manager.lock);
 
-   /* remove all bo */
+   /* remove al

make VM handling async v2

2012-08-20 Thread Christian König
Second and hopefully last round for this patchset.

v2: Fix suspend/resume, and incorporate Jeromes comments.

Cheers,
Christian.

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


[PATCH 02/11] drm/radeon: cleanup VM id handling a bit

2012-08-20 Thread Christian König
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/ni.c  |5 +++--
 drivers/gpu/drm/radeon/r100.c|2 +-
 drivers/gpu/drm/radeon/r600.c|2 +-
 drivers/gpu/drm/radeon/radeon.h  |5 +++--
 drivers/gpu/drm/radeon/radeon_cs.c   |   18 +++---
 drivers/gpu/drm/radeon/radeon_ring.c |   14 +++---
 drivers/gpu/drm/radeon/si.c  |5 +++--
 7 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9945d86..efa3ab9 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -871,12 +871,13 @@ void cayman_ring_ib_execute(struct radeon_device *rdev, 
struct radeon_ib *ib)
 #endif
  (ib->gpu_addr & 0xFFFC));
radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0xFF);
-   radeon_ring_write(ring, ib->length_dw | (ib->vm_id << 24));
+   radeon_ring_write(ring, ib->length_dw | 
+ (ib->vm ? (ib->vm->id << 24) : 0));
 
/* flush read cache over gart for this vmid */
radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
radeon_ring_write(ring, (CP_COHER_CNTL2 - PACKET3_SET_CONFIG_REG_START) 
>> 2);
-   radeon_ring_write(ring, ib->vm_id);
+   radeon_ring_write(ring, ib->vm ? ib->vm->id : 0);
radeon_ring_write(ring, PACKET3(PACKET3_SURFACE_SYNC, 3));
radeon_ring_write(ring, PACKET3_TC_ACTION_ENA | PACKET3_SH_ACTION_ENA);
radeon_ring_write(ring, 0x);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 8acb34f..5f5f524 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3816,7 +3816,7 @@ int r100_ib_test(struct radeon_device *rdev, struct 
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
-   r = radeon_ib_get(rdev, RADEON_RING_TYPE_GFX_INDEX, &ib, 256);
+   r = radeon_ib_get(rdev, RADEON_RING_TYPE_GFX_INDEX, &ib, NULL, 256);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 637280f..75d448d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2635,7 +2635,7 @@ int r600_ib_test(struct radeon_device *rdev, struct 
radeon_ring *ring)
return r;
}
WREG32(scratch, 0xCAFEDEAD);
-   r = radeon_ib_get(rdev, ring->idx, &ib, 256);
+   r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
if (r) {
DRM_ERROR("radeon: failed to get ib (%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8d75c65..ef1fdf2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -611,7 +611,7 @@ struct radeon_ib {
uint32_t*ptr;
int ring;
struct radeon_fence *fence;
-   unsignedvm_id;
+   struct radeon_vm*vm;
boolis_const_ib;
struct radeon_fence *sync_to[RADEON_NUM_RINGS];
struct radeon_semaphore *semaphore;
@@ -753,7 +753,8 @@ struct si_rlc {
 };
 
 int radeon_ib_get(struct radeon_device *rdev, int ring,
- struct radeon_ib *ib, unsigned size);
+ struct radeon_ib *ib, struct radeon_vm *vm,
+ unsigned size);
 void radeon_ib_free(struct radeon_device *rdev, struct radeon_ib *ib);
 int radeon_ib_schedule(struct radeon_device *rdev, struct radeon_ib *ib,
   struct radeon_ib *const_ib);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index b4a0db24..0a9d1eb 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -363,7 +363,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
 * uncached).
 */
r =  radeon_ib_get(rdev, parser->ring, &parser->ib,
-  ib_chunk->length_dw * 4);
+  NULL, ib_chunk->length_dw * 4);
if (r) {
DRM_ERROR("Failed to get ib !\n");
return r;
@@ -380,7 +380,6 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
return r;
}
radeon_cs_sync_rings(parser);
-   parser->ib.vm_id = 0;
r = radeon_ib_schedule(rdev, &parser->ib, NULL);
if (r) {
DRM_ERROR("Failed to schedule IB !\n");
@@ -426,7 +425,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
return -EINVAL;
}
r =  radeon_ib_get(rdev, parser->ring, &parser->const_ib,
-   

[PATCH 03/11] drm/radeon: move VM funcs into asic structure

2012-08-20 Thread Christian König
So it looks more like the rest of the driver.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h  |   35 +---
 drivers/gpu/drm/radeon/radeon_asic.c |   50 ++
 drivers/gpu/drm/radeon/radeon_gart.c |   16 +--
 3 files changed, 54 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ef1fdf2..5163346 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -660,28 +660,12 @@ struct radeon_vm {
struct radeon_fence *fence;
 };
 
-struct radeon_vm_funcs {
-   int (*init)(struct radeon_device *rdev);
-   void (*fini)(struct radeon_device *rdev);
-   /* cs mutex must be lock for schedule_ib */
-   int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, int id);
-   void (*unbind)(struct radeon_device *rdev, struct radeon_vm *vm);
-   void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm *vm);
-   uint32_t (*page_flags)(struct radeon_device *rdev,
-  struct radeon_vm *vm,
-  uint32_t flags);
-   void (*set_page)(struct radeon_device *rdev, struct radeon_vm *vm,
-   unsigned pfn, uint64_t addr, uint32_t flags);
-};
-
 struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
uint32_tuse_bitmap;
struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
-   /* fields constant after init */
-   const struct radeon_vm_funcs*funcs;
/* number of VMIDs */
unsignednvm;
/* vram base address for page table entry  */
@@ -1147,6 +1131,18 @@ struct radeon_asic {
void (*tlb_flush)(struct radeon_device *rdev);
int (*set_page)(struct radeon_device *rdev, int i, uint64_t 
addr);
} gart;
+   struct {
+   int (*init)(struct radeon_device *rdev);
+   void (*fini)(struct radeon_device *rdev);
+   int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, 
int id);
+   void (*unbind)(struct radeon_device *rdev, struct radeon_vm 
*vm);
+   void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm 
*vm);
+   uint32_t (*page_flags)(struct radeon_device *rdev,
+  struct radeon_vm *vm,
+  uint32_t flags);
+   void (*set_page)(struct radeon_device *rdev, struct radeon_vm 
*vm,
+unsigned pfn, uint64_t addr, uint32_t flags);
+   } vm;
/* ring specific callbacks */
struct {
void (*ib_execute)(struct radeon_device *rdev, struct radeon_ib 
*ib);
@@ -1698,6 +1694,13 @@ void radeon_ring_write(struct radeon_ring *ring, 
uint32_t v);
 #define radeon_asic_reset(rdev) (rdev)->asic->asic_reset((rdev))
 #define radeon_gart_tlb_flush(rdev) (rdev)->asic->gart.tlb_flush((rdev))
 #define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev), 
(i), (p))
+#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
+#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
+#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v), 
(id))
+#define radeon_asic_vm_unbind(rdev, v) (rdev)->asic->vm.unbind((rdev), (v))
+#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev), 
(v))
+#define radeon_asic_vm_page_flags(rdev, v, flags) 
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
+#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags) 
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
 #define radeon_ring_start(rdev, r, cp) 
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
 #define radeon_ring_test(rdev, r, cp) 
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
 #define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev), 
(cp))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 973417c..7d29d53 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1342,16 +1342,6 @@ static struct radeon_asic btc_asic = {
},
 };
 
-static const struct radeon_vm_funcs cayman_vm_funcs = {
-   .init = &cayman_vm_init,
-   .fini = &cayman_vm_fini,
-   .bind = &cayman_vm_bind,
-   .unbind = &cayman_vm_unbind,
-   .tlb_flush = &cayman_vm_tlb_flush,
-   .page_flags = &cayman_vm_page_flags,
-   .set_page = &cayman_vm_set_page,
-};
-
 static struct radeon_asic cayman_asic = {
.init = &cayman_init,
.fini = &cayman_fini,
@@ -1366,6 +1356,15 @@ static struct radeon_asic cayman_asic = {
.tlb_flush = &cayman_pcie_gart_tlb_flush,
.set_

[PATCH 04/11] drm/radeon: remove vm_unbind

2012-08-20 Thread Christian König
It actually isn't very useful.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/ni.c  |   11 ---
 drivers/gpu/drm/radeon/radeon.h  |2 --
 drivers/gpu/drm/radeon/radeon_asic.c |3 ---
 drivers/gpu/drm/radeon/radeon_gart.c |1 -
 drivers/gpu/drm/radeon/si.c  |   12 
 5 files changed, 29 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index efa3ab9..3b1aab3 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1501,17 +1501,6 @@ int cayman_vm_bind(struct radeon_device *rdev, struct 
radeon_vm *vm, int id)
return 0;
 }
 
-void cayman_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
-{
-   WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (vm->id << 2), 0);
-   WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm->id << 2), 0);
-   WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0);
-   /* flush hdp cache */
-   WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
-   /* bits 0-7 are the VM contexts0-7 */
-   WREG32(VM_INVALIDATE_REQUEST, 1 << vm->id);
-}
-
 void cayman_vm_tlb_flush(struct radeon_device *rdev, struct radeon_vm *vm)
 {
if (vm->id == -1)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5163346..aeb2d1f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1135,7 +1135,6 @@ struct radeon_asic {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, 
int id);
-   void (*unbind)(struct radeon_device *rdev, struct radeon_vm 
*vm);
void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm 
*vm);
uint32_t (*page_flags)(struct radeon_device *rdev,
   struct radeon_vm *vm,
@@ -1697,7 +1696,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
 #define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
 #define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v), 
(id))
-#define radeon_asic_vm_unbind(rdev, v) (rdev)->asic->vm.unbind((rdev), (v))
 #define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev), 
(v))
 #define radeon_asic_vm_page_flags(rdev, v, flags) 
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
 #define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags) 
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 7d29d53..9d5f4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1360,7 +1360,6 @@ static struct radeon_asic cayman_asic = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
.bind = &cayman_vm_bind,
-   .unbind = &cayman_vm_unbind,
.tlb_flush = &cayman_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
@@ -1463,7 +1462,6 @@ static struct radeon_asic trinity_asic = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
.bind = &cayman_vm_bind,
-   .unbind = &cayman_vm_unbind,
.tlb_flush = &cayman_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
@@ -1566,7 +1564,6 @@ static struct radeon_asic si_asic = {
.init = &si_vm_init,
.fini = &si_vm_fini,
.bind = &si_vm_bind,
-   .unbind = &si_vm_unbind,
.tlb_flush = &si_vm_tlb_flush,
.page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2902e5f..18a03ab 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -522,7 +522,6 @@ static void radeon_vm_unbind_locked(struct radeon_device 
*rdev,
radeon_fence_unref(&vm->fence);
 
/* hw unbind */
-   radeon_asic_vm_unbind(rdev, vm);
rdev->vm_manager.use_bitmap &= ~(1 << vm->id);
list_del_init(&vm->list);
vm->id = -1;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4ebcb33..40a9a85 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2795,18 +2795,6 @@ int si_vm_bind(struct radeon_device *rdev, struct 
radeon_vm *vm, int id)
return 0;
 }
 
-void si_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm)
-{
-   if (vm->id < 8)
-   WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0);
-   else
-

[PATCH 05/11] drm/radeon: add sync helper function

2012-08-20 Thread Christian König
Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_cs.c |   20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0a9d1eb..85a80e4 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -115,19 +115,27 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p, 
u32 ring, s32 priority
return 0;
 }
 
+static void radeon_cs_sync_to(struct radeon_cs_parser *p,
+ struct radeon_fence *fence)
+{
+   struct radeon_fence *other;
+
+   if (!fence)
+   return;
+
+   other = p->ib.sync_to[fence->ring];
+   p->ib.sync_to[fence->ring] = radeon_fence_later(fence, other);
+}
+
 static void radeon_cs_sync_rings(struct radeon_cs_parser *p)
 {
int i;
 
for (i = 0; i < p->nrelocs; i++) {
-   struct radeon_fence *a, *b;
-
-   if (!p->relocs[i].robj || !p->relocs[i].robj->tbo.sync_obj)
+   if (!p->relocs[i].robj)
continue;
 
-   a = p->relocs[i].robj->tbo.sync_obj;
-   b = p->ib.sync_to[a->ring];
-   p->ib.sync_to[a->ring] = radeon_fence_later(a, b);
+   radeon_cs_sync_to(p, p->relocs[i].robj->tbo.sync_obj);
}
 }
 
-- 
1.7.9.5

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


[PATCH 06/11] drm/radeon: make VM flushs a ring operation

2012-08-20 Thread Christian König
Move flushing the VMs as function into the rings.
First step to make VM operations async.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/ni.c  |   31 ---
 drivers/gpu/drm/radeon/radeon.h  |6 --
 drivers/gpu/drm/radeon/radeon_asic.c |   12 +---
 drivers/gpu/drm/radeon/radeon_asic.h |3 +--
 drivers/gpu/drm/radeon/radeon_cs.c   |1 +
 drivers/gpu/drm/radeon/radeon_gart.c |4 +++-
 drivers/gpu/drm/radeon/radeon_ring.c |8 
 drivers/gpu/drm/radeon/si.c  |   15 ---
 8 files changed, 42 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 3b1aab3..ad337e8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1494,24 +1494,9 @@ int cayman_vm_bind(struct radeon_device *rdev, struct 
radeon_vm *vm, int id)
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (id << 2), 0);
WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (id << 2), vm->last_pfn);
WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (id << 2), vm->pt_gpu_addr >> 
12);
-   /* flush hdp cache */
-   WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
-   /* bits 0-7 are the VM contexts0-7 */
-   WREG32(VM_INVALIDATE_REQUEST, 1 << id);
return 0;
 }
 
-void cayman_vm_tlb_flush(struct radeon_device *rdev, struct radeon_vm *vm)
-{
-   if (vm->id == -1)
-   return;
-
-   /* flush hdp cache */
-   WREG32(HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
-   /* bits 0-7 are the VM contexts0-7 */
-   WREG32(VM_INVALIDATE_REQUEST, 1 << vm->id);
-}
-
 #define R600_PTE_VALID (1 << 0)
 #define R600_PTE_SYSTEM(1 << 1)
 #define R600_PTE_SNOOPED   (1 << 2)
@@ -1543,3 +1528,19 @@ void cayman_vm_set_page(struct radeon_device *rdev, 
struct radeon_vm *vm,
addr |= flags;
writeq(addr, ptr + (pfn * 8));
 }
+
+void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
+{
+   struct radeon_ring *ring = &rdev->ring[ib->ring];
+
+   if (!ib->vm || ib->vm->id == -1)
+   return;
+
+   /* flush hdp cache */
+   radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
+   radeon_ring_write(ring, 0x1);
+
+   /* bits 0-7 are the VM contexts0-7 */
+   radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
+   radeon_ring_write(ring, 1 << ib->vm->id);
+}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index aeb2d1f..1228778 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -658,6 +658,8 @@ struct radeon_vm {
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
+   /* last flush or NULL if we still need to flush */
+   struct radeon_fence *last_flush;
 };
 
 struct radeon_vm_manager {
@@ -1135,7 +1137,6 @@ struct radeon_asic {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, 
int id);
-   void (*tlb_flush)(struct radeon_device *rdev, struct radeon_vm 
*vm);
uint32_t (*page_flags)(struct radeon_device *rdev,
   struct radeon_vm *vm,
   uint32_t flags);
@@ -1154,6 +1155,7 @@ struct radeon_asic {
int (*ring_test)(struct radeon_device *rdev, struct radeon_ring 
*cp);
int (*ib_test)(struct radeon_device *rdev, struct radeon_ring 
*cp);
bool (*is_lockup)(struct radeon_device *rdev, struct 
radeon_ring *cp);
+   void (*vm_flush)(struct radeon_device *rdev, struct radeon_ib 
*ib);
} ring[RADEON_NUM_RINGS];
/* irqs */
struct {
@@ -1696,7 +1698,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
 #define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
 #define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v), 
(id))
-#define radeon_asic_vm_tlb_flush(rdev, v) (rdev)->asic->vm.tlb_flush((rdev), 
(v))
 #define radeon_asic_vm_page_flags(rdev, v, flags) 
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
 #define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags) 
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
 #define radeon_ring_start(rdev, r, cp) 
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
@@ -1705,6 +1706,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_ring_ib_execute(rdev, r, ib) 
(rdev)->asic->ring[(r)].ib_execute((rdev), (ib))
 #define radeon_ring_ib_parse(rdev, r, ib) 
(rdev)->asic->ring[(r)].ib_parse((rdev), (ib))
 #define radeon_ring_is_lockup(rdev, r, cp) 
(rdev)->asic->ring[(r)].is_lockup((rdev), (

[PATCH 08/11] drm/radeon: rework VM page table handling

2012-08-20 Thread Christian König
Removing the need to wait for anything.

Still not ideal, since we need to free pt on va remove.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h  |4 +-
 drivers/gpu/drm/radeon/radeon_cs.c   |   28 +
 drivers/gpu/drm/radeon/radeon_gart.c |  107 +++---
 drivers/gpu/drm/radeon/radeon_sa.c   |   20 +++
 4 files changed, 43 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e0c6673..ed0ef17 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -316,7 +316,6 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
-   struct radeon_fence *fence;
boolvalid;
 };
 
@@ -1794,8 +1793,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev);
 void radeon_vm_manager_fini(struct radeon_device *rdev);
 int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
 void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
-int radeon_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm);
-void radeon_vm_unbind(struct radeon_device *rdev, struct radeon_vm *vm);
+int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
 struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
   struct radeon_vm *vm, int ring);
 void radeon_vm_fence(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index dc4554e..300fc25 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -286,30 +286,6 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
 }
 
-static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
- struct radeon_fence *fence)
-{
-   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
-   struct radeon_vm *vm = &fpriv->vm;
-   struct radeon_bo_list *lobj;
-
-   if (parser->chunk_ib_idx == -1) {
-   return;
-   }
-   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0) {
-   return;
-   }
-
-   list_for_each_entry(lobj, &parser->validated, tv.head) {
-   struct radeon_bo_va *bo_va;
-   struct radeon_bo *rbo = lobj->bo;
-
-   bo_va = radeon_bo_va(rbo, vm);
-   radeon_fence_unref(&bo_va->fence);
-   bo_va->fence = radeon_fence_ref(fence);
-   }
-}
-
 /**
  * cs_parser_fini() - clean parser states
  * @parser:parser structure holding parsing context.
@@ -323,8 +299,6 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
unsigned i;
 
if (!error) {
-   /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
still reserved */
-   radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
} else {
@@ -475,7 +449,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
 
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
-   r = radeon_vm_bind(rdev, vm);
+   r = radeon_vm_alloc_pt(rdev, vm);
if (r) {
goto out;
}
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index d668733..4bce026 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -478,43 +478,26 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
return 0;
 }
 
-/* global mutex must be lock */
 /**
- * radeon_vm_unbind_locked - unbind a specific vm
+ * radeon_vm_free_pt - free the page table for a specific vm
  *
  * @rdev: radeon_device pointer
  * @vm: vm to unbind
  *
- * Unbind the requested vm (cayman+).
- * Wait for use of the VM to finish, then unbind the page table,
- * and free the page table memory.
+ * Free the page table of a specific vm (cayman+).
+ *
+ * Global and local mutex must be lock!
  */
-static void radeon_vm_unbind_locked(struct radeon_device *rdev,
+static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
 {
struct radeon_bo_va *bo_va;
 
-   /* wait for vm use to end */
-   while (vm->fence) {
-   int r;
-   r = radeon_fence_wait(vm->fence, false);
-   if (r)
-   DRM_ERROR("error while waiting for fence: %d\n", r);
-   if (r == -EDEADLK) {
-   mutex_unlock(&rdev->vm_manager.lock);
-   r = radeon_gpu_reset(rdev);
-   mutex_lock(&rdev->vm_manager.lock);
- 

[PATCH 07/11] drm/radeon: rework VMID handling

2012-08-20 Thread Christian König
Move binding onto the ring, simplifying handling a bit.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/ni.c|   20 ++---
 drivers/gpu/drm/radeon/radeon.h|   30 +++-
 drivers/gpu/drm/radeon/radeon_asic.c   |9 +--
 drivers/gpu/drm/radeon/radeon_asic.h   |4 +-
 drivers/gpu/drm/radeon/radeon_cs.c |9 +--
 drivers/gpu/drm/radeon/radeon_device.c |1 -
 drivers/gpu/drm/radeon/radeon_gart.c   |  126 +---
 drivers/gpu/drm/radeon/si.c|   30 ++--
 8 files changed, 153 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index ad337e8..88d5713 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1489,14 +1489,6 @@ void cayman_vm_fini(struct radeon_device *rdev)
 {
 }
 
-int cayman_vm_bind(struct radeon_device *rdev, struct radeon_vm *vm, int id)
-{
-   WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (id << 2), 0);
-   WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (id << 2), vm->last_pfn);
-   WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (id << 2), vm->pt_gpu_addr >> 
12);
-   return 0;
-}
-
 #define R600_PTE_VALID (1 << 0)
 #define R600_PTE_SYSTEM(1 << 1)
 #define R600_PTE_SNOOPED   (1 << 2)
@@ -1532,10 +1524,20 @@ void cayman_vm_set_page(struct radeon_device *rdev, 
struct radeon_vm *vm,
 void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
 {
struct radeon_ring *ring = &rdev->ring[ib->ring];
+   struct radeon_vm *vm = ib->vm;
 
-   if (!ib->vm || ib->vm->id == -1)
+   if (vm == NULL)
return;
 
+   radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR + 
(vm->id << 2), 0));
+   radeon_ring_write(ring, 0);
+
+   radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + 
(vm->id << 2), 0));
+   radeon_ring_write(ring, vm->last_pfn);
+
+   radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm->id << 2), 0));
+   radeon_ring_write(ring, vm->pt_gpu_addr >> 12);
+
/* flush hdp cache */
radeon_ring_write(ring, PACKET0(HDP_MEM_COHERENCY_FLUSH_CNTL, 0));
radeon_ring_write(ring, 0x1);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1228778..e0c6673 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -268,6 +268,22 @@ static inline struct radeon_fence 
*radeon_fence_later(struct radeon_fence *a,
}
 }
 
+static inline bool radeon_fence_is_earlier(struct radeon_fence *a,
+  struct radeon_fence *b)
+{
+   if (!a) {
+   return false;
+   }
+
+   if (!b) {
+   return true;
+   }
+
+   BUG_ON(a->ring != b->ring);
+
+   return a->seq < b->seq;
+}
+
 /*
  * Tiling registers
  */
@@ -647,10 +663,13 @@ struct radeon_ring {
 /*
  * VM
  */
+
+#define RADEON_NUM_VM  16
+
 struct radeon_vm {
struct list_headlist;
struct list_headva;
-   int id;
+   unsignedid;
unsignedlast_pfn;
u64 pt_gpu_addr;
u64 *pt;
@@ -665,7 +684,7 @@ struct radeon_vm {
 struct radeon_vm_manager {
struct mutexlock;
struct list_headlru_vm;
-   uint32_tuse_bitmap;
+   struct radeon_fence *active[RADEON_NUM_VM];
struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
/* number of VMIDs */
@@ -1136,7 +1155,6 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
-   int (*bind)(struct radeon_device *rdev, struct radeon_vm *vm, 
int id);
uint32_t (*page_flags)(struct radeon_device *rdev,
   struct radeon_vm *vm,
   uint32_t flags);
@@ -1697,7 +1715,6 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev), 
(i), (p))
 #define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
 #define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_bind(rdev, v, id) (rdev)->asic->vm.bind((rdev), (v), 
(id))
 #define radeon_asic_vm_page_flags(rdev, v, flags) 
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
 #define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags) 
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
 #define radeon_ring_start(rdev, r, cp) 
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
@@ -1779,6 +1796,11 @@ int radeon_vm_init(struct radeon_device *rdev, struct 
radeon_vm *vm

[PATCH 09/11] drm/radeon: Move looping over the PTEs into chip code

2012-08-20 Thread Christian König
Makes it easier to move it into the rings.

Signed-off-by: Christian König 
Reviewed-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/ni.c  |   22 +++---
 drivers/gpu/drm/radeon/radeon.h  |   12 ++--
 drivers/gpu/drm/radeon/radeon_asic.c |3 ---
 drivers/gpu/drm/radeon/radeon_asic.h |7 +++
 drivers/gpu/drm/radeon/radeon_gart.c |   24 ++--
 5 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 88d5713..1fd2e41 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1495,9 +1495,7 @@ void cayman_vm_fini(struct radeon_device *rdev)
 #define R600_PTE_READABLE  (1 << 5)
 #define R600_PTE_WRITEABLE (1 << 6)
 
-uint32_t cayman_vm_page_flags(struct radeon_device *rdev,
- struct radeon_vm *vm,
- uint32_t flags)
+uint32_t cayman_vm_page_flags(struct radeon_device *rdev, uint32_t flags)
 {
uint32_t r600_flags = 0;
 
@@ -1512,13 +1510,23 @@ uint32_t cayman_vm_page_flags(struct radeon_device 
*rdev,
 }
 
 void cayman_vm_set_page(struct radeon_device *rdev, struct radeon_vm *vm,
-   unsigned pfn, uint64_t addr, uint32_t flags)
+   unsigned pfn, struct ttm_mem_reg *mem,
+   unsigned npages, uint32_t flags)
 {
void __iomem *ptr = (void *)vm->pt;
+   uint64_t addr;
+   int i;
+
+   addr = flags = cayman_vm_page_flags(rdev, flags);
 
-   addr = addr & 0xF000ULL;
-   addr |= flags;
-   writeq(addr, ptr + (pfn * 8));
+for (i = 0; i < npages; ++i, ++pfn) {
+if (mem) {
+addr = radeon_vm_get_addr(rdev, mem, i);
+   addr = addr & 0xF000ULL;
+   addr |= flags;
+}
+   writeq(addr, ptr + (pfn * 8));
+}
 }
 
 void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ed0ef17..7d37cb2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1154,11 +1154,9 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
-   uint32_t (*page_flags)(struct radeon_device *rdev,
-  struct radeon_vm *vm,
-  uint32_t flags);
void (*set_page)(struct radeon_device *rdev, struct radeon_vm 
*vm,
-unsigned pfn, uint64_t addr, uint32_t flags);
+unsigned pfn, struct ttm_mem_reg *mem,
+unsigned npages, uint32_t flags);
} vm;
/* ring specific callbacks */
struct {
@@ -1714,8 +1712,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev), 
(i), (p))
 #define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
 #define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_page_flags(rdev, v, flags) 
(rdev)->asic->vm.page_flags((rdev), (v), (flags))
-#define radeon_asic_vm_set_page(rdev, v, pfn, addr, flags) 
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (addr), (flags))
+#define radeon_asic_vm_set_page(rdev, v, pfn, mem, npages, flags) 
(rdev)->asic->vm.set_page((rdev), (v), (pfn), (mem), (npages), (flags))
 #define radeon_ring_start(rdev, r, cp) 
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
 #define radeon_ring_test(rdev, r, cp) 
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
 #define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev), 
(cp))
@@ -1799,6 +1796,9 @@ struct radeon_fence *radeon_vm_grab_id(struct 
radeon_device *rdev,
 void radeon_vm_fence(struct radeon_device *rdev,
 struct radeon_vm *vm,
 struct radeon_fence *fence);
+u64 radeon_vm_get_addr(struct radeon_device *rdev,
+   struct ttm_mem_reg *mem,
+   unsigned pfn);
 int radeon_vm_bo_update_pte(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_bo *bo,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 5486674..4b99a24 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1359,7 +1359,6 @@ static struct radeon_asic cayman_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
-   .page_flags = &cayman_vm_page_flags,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1462,7 +1461,6 @@ static struct radeon_asic trinity_asic = {
.vm 

[PATCH 10/11] drm/radeon: make sure ib bo is properly bound and up to date in vm space

2012-08-20 Thread Christian König
From: Jerome Glisse 

Make sure that the ib bo is bound and is page table is up to date
in the virtual address space.

Signed-off-by: Jerome Glisse 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_cs.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 300fc25..3ae7c27 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -372,10 +372,15 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
 static int radeon_bo_vm_update_pte(struct radeon_cs_parser *parser,
   struct radeon_vm *vm)
 {
+   struct radeon_device *rdev = parser->rdev;
struct radeon_bo_list *lobj;
struct radeon_bo *bo;
int r;
 
+   r = radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo, 
&rdev->ring_tmp_bo.bo->tbo.mem);
+   if (r) {
+   return r;
+   }
list_for_each_entry(lobj, &parser->validated, tv.head) {
bo = lobj->bo;
r = radeon_vm_bo_update_pte(parser->rdev, vm, bo, &bo->tbo.mem);
-- 
1.7.9.5

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


[PATCH 11/11] drm/radeon: make page table updates async v2

2012-08-20 Thread Christian König
Currently doing the update with the CP.

v2: Rebased on Jeromes bugfix. Make validity comparison
more human readable.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/ni.c  |   20 ++
 drivers/gpu/drm/radeon/nid.h |1 +
 drivers/gpu/drm/radeon/radeon.h  |2 +
 drivers/gpu/drm/radeon/radeon_asic.c |3 ++
 drivers/gpu/drm/radeon/radeon_gart.c |   70 +-
 5 files changed, 71 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 1fd2e41..78d9cfb 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1513,20 +1513,24 @@ void cayman_vm_set_page(struct radeon_device *rdev, 
struct radeon_vm *vm,
unsigned pfn, struct ttm_mem_reg *mem,
unsigned npages, uint32_t flags)
 {
-   void __iomem *ptr = (void *)vm->pt;
-   uint64_t addr;
+   struct radeon_ring *ring = &rdev->ring[rdev->asic->vm.pt_ring_index];
+   uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
int i;
 
addr = flags = cayman_vm_page_flags(rdev, flags);
 
-for (i = 0; i < npages; ++i, ++pfn) {
-if (mem) {
-addr = radeon_vm_get_addr(rdev, mem, i);
+   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
+   radeon_ring_write(ring, pt & 0x);
+   radeon_ring_write(ring, (pt >> 32) & 0xff);
+   for (i = 0; i < npages; ++i) {
+   if (mem) {
+   addr = radeon_vm_get_addr(rdev, mem, i);
addr = addr & 0xF000ULL;
addr |= flags;
-}
-   writeq(addr, ptr + (pfn * 8));
-}
+   }
+   radeon_ring_write(ring, addr & 0x);
+   radeon_ring_write(ring, (addr >> 32) & 0x);
+   }
 }
 
 void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ib *ib)
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 870db34..2423d1b 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -585,6 +585,7 @@
 #definePACKET3_SET_CONTEXT_REG_INDIRECT0x73
 #definePACKET3_SET_RESOURCE_INDIRECT   0x74
 #definePACKET3_SET_APPEND_CNT  0x75
+#definePACKET3_ME_WRITE0x7A
 
 #endif
 
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7d37cb2..3de0f08 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1154,6 +1154,8 @@ struct radeon_asic {
struct {
int (*init)(struct radeon_device *rdev);
void (*fini)(struct radeon_device *rdev);
+
+   u32 pt_ring_index;
void (*set_page)(struct radeon_device *rdev, struct radeon_vm 
*vm,
 unsigned pfn, struct ttm_mem_reg *mem,
 unsigned npages, uint32_t flags);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 4b99a24..d0b4e50 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1359,6 +1359,7 @@ static struct radeon_asic cayman_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
+   .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1461,6 +1462,7 @@ static struct radeon_asic trinity_asic = {
.vm = {
.init = &cayman_vm_init,
.fini = &cayman_vm_fini,
+   .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
@@ -1563,6 +1565,7 @@ static struct radeon_asic si_asic = {
.vm = {
.init = &si_vm_init,
.fini = &si_vm_fini,
+   .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.set_page = &cayman_vm_set_page,
},
.ring = {
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index bf5378b..3ef6698 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -464,15 +464,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
continue;
 
list_for_each_entry(bo_va, &vm->va, vm_list) {
-   struct ttm_mem_reg *mem = NULL;
-   if (bo_va->valid)
-   mem = &bo_va->bo->tbo.mem;
-
bo_va->valid = false;
-   r = radeon_vm_bo_update_pte(rdev, vm, bo_va->bo, mem);
-   if (r) {
-   DRM_ERROR("Failed to update pte for vm %d!\n", 
vm->

Re: [RFC 0/5] Generic panel framework

2012-08-20 Thread Tomi Valkeinen
On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> Hi Tomi,

> mipi-dbi-bus might not belong to include/video/panel/ though, as it can be 
> used for non-panel devices (at least in theory). The future mipi-dsi-bus 
> certainly will.

They are both display busses. So while they could be used for anything,
I find it quite unlikely as there are much better alternatives for
generic bus needs.

> Would you be able to send incremental patches on top of v2 to implement the 
> solution you have in mind ? It would be neat if you could also implement mipi-
> dsi-bus for the OMAP DSS and test the code with a real device :-)

Yes, I'd like to try this out on OMAP, both DBI and DSI. However, I fear
it'll be quite complex due to the dependencies all around we have in the
current driver. We're working on simplifying things so that it'll be
easier to try thing like the panel framework, though, so we're going in
the right direction.

> > Generally about locks, if we define that panel ops may only be called
> > exclusively, does it simplify things? I think we can make such
> > requirements, as there should be only one display framework that handles
> > the panel. Then we don't need locking for things like enable/disable.
> 
> Pushing locking to callers would indeed simplify panel drivers, but we need 
> to 
> make sure we won't need to expose a panel to several callers in the future.

I have a feeling that would be a bad idea.

Display related stuff are quite sensitive to any delays, so any extra
transactions over, say, DSI bus could cause a noticeable glitch on the
screen. I'm not sure what are all the possible ops that a panel can
offer, but I think all that affect the display or could cause delays
should be handled by one controlling entity (drm or such). The
controlling entity needs to handle locking anyway, so in that sense I
don't think it's an extra burden for it.

The things that come to my mind that could possibly cause calls to the
panel outside drm: debugfs, sysfs, audio, backlight. Of those, I think
backlight should go through drm. Audio, no idea. debugfs and sysfs
locking needs to be handled by the panel driver, and they are a bit
problematic as I guess having them requires full locking.

 Tomi



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/radeon: fix checking of MSAA renderbuffers on r600-r700

2012-08-20 Thread Marek Olšák
On Mon, Aug 20, 2012 at 7:35 AM, Paul Menzel
 wrote:
> Dear Marek,
>
>
> thank you for all your work on MSAA.
>
>
> Am Sonntag, den 19.08.2012, 21:23 +0200 schrieb Marek Olšák:
>
> Unfortunately you do not provide any commit message. What is the problem
> and what are the symptoms? When was it introduced? How is it solved in
> your patch?

The MSAA checking was mostly unimplemented on r600-r700. The userspace
submits GPU commands and the kernel driver computes how much memory
the GPU will access and checks if it's all within buffer bounds the
userspace allocated. This patch fixes the computations of the size of
MSAA surfaces in memory.

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


[PATCH 01/10] drm/exynos: added device object to subdrv's remove callback as argument

2012-08-20 Thread Inki Dae
when remove callback of exynos_drm_subdrv is called, it could need
device object for sub driver to control things specific to hw such as
runtime pm.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e22704b..24c45d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -266,7 +266,7 @@ struct exynos_drm_subdrv {
struct exynos_drm_manager *manager;
 
int (*probe)(struct drm_device *drm_dev, struct device *dev);
-   void (*remove)(struct drm_device *dev);
+   void (*remove)(struct drm_device *drm_dev, struct device *dev);
int (*open)(struct drm_device *drm_dev, struct device *dev,
struct drm_file *file);
void (*close)(struct drm_device *drm_dev, struct device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b19cd93..47396e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -678,7 +678,7 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }
 
-static void fimd_subdrv_remove(struct drm_device *drm_dev)
+static void fimd_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 537027a..f900da0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -466,7 +466,7 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }
 
-static void vidi_subdrv_remove(struct drm_device *drm_dev)
+static void vidi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-- 
1.7.4.1

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


[PATCH 00/10 v2] updated exynos-drm-fixes

2012-08-20 Thread Inki Dae
Hello all,

Changelog v2:
. fixed duplicated mode setting.
  - this patch includes below three patches of v1 and fixes
the issue that drm_helper_connector_dpms() isn't called.
http://www.spinics.net/lists/dri-devel/msg26427.html
http://www.spinics.net/lists/dri-devel/msg26428.html
http://www.spinics.net/lists/dri-devel/msg26430.html
. removed below two patches of v1 and the patch for changing
  context name of hdmi and mixer will be updated for code
  consistency later because now hdmi module still use "hdata"
  term as context name in other functions.
  http://www.spinics.net/lists/dri-devel/msg26434.html
  http://www.spinics.net/lists/dri-devel/msg26435.html
. fixed below patch of v1 so that drm_format_num_planes() is called
http://www.spinics.net/lists/dri-devel/msg26432.html
. separated below patch of v1 into exynos drm framework and device
  specific parts.
  http://www.spinics.net/lists/dri-devel/msg26431.html

Changelog v1:
This patch set fixes the following:
. fixed page align
  - page align is done by exynos_drm_gem_create() so do not align
in page unit at exynos_drm_gem_dumb_create().
. removed unnecessary dpms call
  - encoder's mode_set callback isn't specific to hardware so
it doesn't need to call exynos_drm_encoder_dpms()
. control display power at connector module
  - it doesn't need that display power is controlled by encoder's dpms
so moves it into connector module so that the display power can be
controlled by connector's dpms properly.
. make sure that hardware overlay for fimd and hdmi is disabled
  - the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
. check NV12M format specific to Exynos properly
  - this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
. updated crtc to plane safely
  - if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)

And code clean like below:
. separated fimd_power_on into some parts
  - separated fimd_power_on into fimd_activate and fimd_clock functions
and fimd_activate function will call fimd_clock to control fimd power
and vsync interrupt.
. separated subdrv->probe call and encoder/connector creation
  - with this patch, exynos drm core module can take exception when some
operation was failed properly.
. changed context name of hdmi and mixer
  - changed ctx variable name in exynos_drm_hdmi_context structure to client
because the use of ctx variable name makes it confused.
. fixed build warning

Thanks.

Inki Dae (10):
  drm/exynos: added device object to subdrv's remove callback as
argument
  drm/exynos: separated subdrv_probe function into two parts.
  drm/exynos: fixed page align bug.
  drm/exynos: separeated fimd_power_on into some parts.
  drm/exynos: fixed duplicated mode setting.
  drm/exynos: add wait_for_vblank callback interface.
  drm/exynos: make sure that hardware overlay for fimd is disabled
  drm/exynos: make sure that hardware overlay for hdmi is disabled
  drm/exynos: check NV12M format specific to Exynos properly
  drm/exynos: update crtc to plane safely

 drivers/gpu/drm/exynos/exynos_drm_connector.c |   41 ++-
 drivers/gpu/drm/exynos/exynos_drm_connector.h |2 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   93 ---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |3 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   19 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   99 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 ++---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   74 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |   13 +++
 16 files changed, 364 insertions(+), 86 deletions(-)

-- 
1.7.4.1


[PATCH 02/10] drm/exynos: separated subdrv_probe function into two parts.

2012-08-20 Thread Inki Dae
this patch separates exynos_drm_subdrv_probe function into sub driver's probe 
call
and encoder/connector creation so that exynos drm core module can take exception
when some operation was failed properly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |   93 +-
 1 files changed, 65 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
 
 static LIST_HEAD(exynos_drm_subdrv_list);
 
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
 {
struct drm_encoder *encoder;
struct drm_connector *connector;
+   int ret;
 
DRM_DEBUG_DRIVER("%s\n", __FILE__);
 
-   if (subdrv->probe) {
-   int ret;
-
-   /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
-   ret = subdrv->probe(dev, subdrv->dev);
-   if (ret)
-   return ret;
-   }
-
if (!subdrv->manager)
return 0;
 
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
-   encoder->funcs->destroy(encoder);
-   return -EFAULT;
+   ret = -EFAULT;
+   goto err_destroy_encoder;
}
 
subdrv->encoder = encoder;
subdrv->connector = connector;
 
return 0;
+
+err_destroy_encoder:
+   encoder->funcs->destroy(encoder);
+   return ret;
 }
 
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
 {
-   DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
-   if (subdrv->remove)
-   subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
 }
 
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+   struct exynos_drm_subdrv *subdrv)
+{
+   if (subdrv->probe) {
+   int ret;
+
+   subdrv->drm_dev = dev;
+
+   /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+   ret = subdrv->probe(dev, subdrv->dev);
+   if (ret)
+   return ret;
+   }
+
+   if (!subdrv->manager)
+   return -EINVAL;
+
+   subdrv->manager->dev = subdrv->dev;
+
+   return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+   DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+   if (subdrv->remove)
+   subdrv->remove(dev, subdrv->dev);
+}
+
 int exynos_drm_device_register(struct drm_device *dev)
 {
struct exynos_drm_subdrv *subdrv, *n;
+   unsigned int fine_cnt = 0;
int err;
 
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
 
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
-   subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(&subdrv->list);
+   continue;
}
+
+   err = exynos_drm_create_enc_conn(dev, subdrv);
+   if (err) {
+   DRM_DEBUG("failed to create encoder and connector.\n");
+   exynos_drm_subdrv_remove(dev, subdrv);
+   list_del(&subdrv->list);
+   continue;
+   }
+
+  

[PATCH 03/10] drm/exynos: fixed page align bug.

2012-08-20 Thread Inki Dae
do not align in page unit at dumb creation. the align is done
by exynos_drm_gem_create() to be called commonly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index da4e3ca..a38051c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -662,7 +662,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
 */
 
args->pitch = args->width * ((args->bpp + 7) / 8);
-   args->size = PAGE_ALIGN(args->pitch * args->height);
+   args->size = args->pitch * args->height;
 
exynos_gem_obj = exynos_drm_gem_create(dev, args->flags, args->size);
if (IS_ERR(exynos_gem_obj))
-- 
1.7.4.1

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


[PATCH 04/10] drm/exynos: separeated fimd_power_on into some parts.

2012-08-20 Thread Inki Dae
this patch separetes fimd_power_on into fimd_activate and fimd_clock and
fimd_activate function will call fimd_clock to control fimd power and
vsync interrupt.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   60 --
 1 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 47396e1..0ec9d86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -747,16 +747,10 @@ static void fimd_clear_win(struct fimd_context *ctx, int 
win)
writel(val, ctx->regs + SHADOWCON);
 }
 
-static int fimd_power_on(struct fimd_context *ctx, bool enable)
+static int fimd_clock(struct fimd_context *ctx, bool enable)
 {
-   struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
-   struct device *dev = subdrv->dev;
-
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   if (enable != false && enable != true)
-   return -EINVAL;
-
if (enable) {
int ret;
 
@@ -769,18 +763,31 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
clk_disable(ctx->bus_clk);
return ret;
}
+   } else {
+   clk_disable(ctx->lcd_clk);
+   clk_disable(ctx->bus_clk);
+   }
 
-   ctx->suspended = false;
+   return 0;
+}
+
+static int fimd_activate(struct fimd_context *ctx, bool enable)
+{
+   if (enable) {
+   int ret;
+   struct device *dev = ctx->subdrv.dev;
+
+   ret = fimd_clock(ctx, true);
+   if (ret < 0)
+   return ret;
 
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, &ctx->irq_flags))
fimd_enable_vblank(dev);
 
-   fimd_apply(dev);
+   ctx->suspended = false;
} else {
-   clk_disable(ctx->lcd_clk);
-   clk_disable(ctx->bus_clk);
-
+   fimd_clock(ctx, false);
ctx->suspended = true;
}
 
@@ -930,15 +937,15 @@ static int fimd_suspend(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
 
-   if (pm_runtime_suspended(dev))
-   return 0;
-
/*
 * do not use pm_runtime_suspend(). if pm_runtime_suspend() is
 * called here, an error would be returned by that interface
 * because the usage_count of pm runtime is more than 1.
 */
-   return fimd_power_on(ctx, false);
+   if (!pm_runtime_suspended(dev))
+   return fimd_activate(ctx, false);
+
+   return 0;
 }
 
 static int fimd_resume(struct device *dev)
@@ -950,8 +957,21 @@ 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))
-   return fimd_power_on(ctx, true);
+   if (pm_runtime_suspended(dev)) {
+   int ret;
+
+   ret = fimd_activate(ctx, false);
+   if (ret < 0)
+   return ret;
+
+   /*
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
+*/
+   fimd_apply(dev);
+   }
 
return 0;
 }
@@ -964,7 +984,7 @@ static int fimd_runtime_suspend(struct device *dev)
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   return fimd_power_on(ctx, false);
+   return fimd_activate(ctx, false);
 }
 
 static int fimd_runtime_resume(struct device *dev)
@@ -973,7 +993,7 @@ static int fimd_runtime_resume(struct device *dev)
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   return fimd_power_on(ctx, true);
+   return fimd_activate(ctx, true);
 }
 #endif
 
-- 
1.7.4.1

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


[PATCH 05/10] drm/exynos: fixed duplicated mode setting.

2012-08-20 Thread Inki Dae
this patch fixes that when drm_crtc_helper_set_mode() is called,
mode data for hardware overlay and conntroller are updated two times.
for example, in case that drm_crtc_helper_set_mode() is called,
overlay_ops->commit() and manager_ops->commit() callbacks can be called
two times, first at drm_crtc_helper_set_mode() and second
at drm_helper_connector_dpms().

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   41 -
 drivers/gpu/drm/exynos/exynos_drm_connector.h |2 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |3 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   30 +++---
 4 files changed, 62 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d956819..1fadc22 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -40,6 +40,7 @@ struct exynos_drm_connector {
struct drm_connectordrm_connector;
uint32_tencoder_id;
struct exynos_drm_manager *manager;
+   uint32_tdpms;
 };
 
 /* convert exynos_video_timings to drm_display_mode */
@@ -226,6 +227,43 @@ static struct drm_connector_helper_funcs 
exynos_connector_helper_funcs = {
.best_encoder   = exynos_drm_best_encoder,
 };
 
+void exynos_drm_display_power(struct drm_connector *connector, int mode)
+{
+   struct drm_encoder *encoder = connector->encoder;
+   struct exynos_drm_connector *exynos_connector;
+   struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
+   struct exynos_drm_display_ops *display_ops = manager->display_ops;
+
+   exynos_connector = to_exynos_connector(connector);
+
+   if (exynos_connector->dpms == mode) {
+   DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
+   return;
+   }
+
+   if (display_ops && display_ops->power_on)
+   display_ops->power_on(manager->dev, mode);
+
+   exynos_connector->dpms = mode;
+}
+
+static void exynos_drm_connector_dpms(struct drm_connector *connector,
+   int mode)
+{
+   DRM_DEBUG_KMS("%s\n", __FILE__);
+
+   /*
+* in case that drm_crtc_helper_set_mode() is called,
+* encoder/crtc->funcs->dpms() will be just returned
+* because they already were DRM_MODE_DPMS_ON so only
+* exynos_drm_display_power() will be called.
+*/
+   drm_helper_connector_dpms(connector, mode);
+
+   exynos_drm_display_power(connector, mode);
+
+}
+
 static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
unsigned int max_width, unsigned int max_height)
 {
@@ -285,7 +323,7 @@ static void exynos_drm_connector_destroy(struct 
drm_connector *connector)
 }
 
 static struct drm_connector_funcs exynos_connector_funcs = {
-   .dpms   = drm_helper_connector_dpms,
+   .dpms   = exynos_drm_connector_dpms,
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
@@ -334,6 +372,7 @@ struct drm_connector *exynos_drm_connector_create(struct 
drm_device *dev,
 
exynos_connector->encoder_id = encoder->base.id;
exynos_connector->manager = manager;
+   exynos_connector->dpms = DRM_MODE_DPMS_OFF;
connector->encoder = encoder;
 
err = drm_mode_connector_attach_encoder(connector, encoder);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.h 
b/drivers/gpu/drm/exynos/exynos_drm_connector.h
index 1c7b2b5..40a55c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.h
@@ -31,4 +31,6 @@
 struct drm_connector *exynos_drm_connector_create(struct drm_device *dev,
   struct drm_encoder *encoder);
 
+void exynos_drm_display_power(struct drm_connector *connector, int mode);
+
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index abb1e2f..b612bf5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -97,6 +97,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
+   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
exynos_plane_commit(exynos_crtc->plane);
exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
 }
@@ -126,8 +127,6 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-
/*
 * copy the mode data adjusted by mode_fixup() into crtc->mode
 * so that hardware can be seet to proper mode.
d

[PATCH 09/10] drm/exynos: check NV12M format specific to Exynos properly

2012-08-20 Thread Inki Dae
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 +++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
 4 files changed, 73 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..98f8b83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
  * exynos specific framebuffer structure.
  *
  * @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
+   unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
 };
 
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty  = exynos_drm_fb_dirty,
 };
 
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+   unsigned int cnt)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+   exynos_fb = to_exynos_fb(fb);
+
+   exynos_fb->buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+   exynos_fb = to_exynos_fb(fb);
+
+   return exynos_fb->buf_cnt;
+}
+
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return &exynos_fb->fb;
 }
 
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   unsigned int cnt = 0;
+
+   if (mode_cmd->pixel_format != DRM_FORMAT_NV12)
+   return drm_format_num_planes(mode_cmd->pixel_format);
+
+   while (cnt != MAX_FB_BUFFER) {
+   if (!mode_cmd->handles[cnt])
+   break;
+   cnt++;
+   }
+
+   /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+   if (cnt == 2) {
+   /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+   if (mode_cmd->offsets[1] &&
+   mode_cmd->handles[0] == mode_cmd->handles[1])
+   cnt = 1;
+   }
+
+   return cnt;
+}
+
 static struct drm_framebuffer *
 exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
  struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
-   int nr;
int i;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
}
 
exynos_fb = to_exynos_fb(fb);
-   nr = exynos_drm_format_num_buffers(fb->pixel_format);
+   exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+   DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
 
-   for (i = 1; i < nr; i++) {
+   for (i = 1; i < exynos_fb->buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 5082375..96262e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -28,19 +28,6 @@
 #ifndef _EXYNOS_DRM_FB_H_
 #define _EXYNOS_DRM_FB_H
 
-static inline int exynos_drm_format_num_buffers(uint32_t format)
-{
-   switch (format) {
-   case DRM_FORMAT_NV12:
-   case DRM_FORMAT_NV12MT:
-   return 2;
-   case DRM_FORMAT_YUV420:
-   return 3;
-   default:
-   return 1;
-   }
-}
-
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct d

[PATCH 06/10] drm/exynos: add wait_for_vblank callback interface.

2012-08-20 Thread Inki Dae
this interface can be used to make sure that hardware overlay is disabled
to avoid that memory region is accessed by dma after gem buffer was released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   17 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   10 ++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..00e4bdc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
 #define MAX_FB_BUFFER  4
 #define DEFAULT_ZPOS   -1
 
+#define _wait_for(COND, MS) ({ \
+   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
+   int ret__ = 0;  \
+   while (!(COND)) {   \
+   if (time_after(jiffies, timeout__)) {   \
+   ret__ = -ETIMEDOUT; \
+   break;  \
+   }   \
+   }   \
+   ret__;  \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
 struct drm_device;
 struct exynos_drm_overlay;
 struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
  * @commit: apply hardware specific overlay data to registers.
  * @enable: enable hardware specific overlay.
  * @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * dma transfer is completed.
  */
 struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+   void (*wait_for_vblank)(struct device *subdrv_dev);
 };
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 08ba62f..98d5576 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -430,4 +430,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder 
*encoder, void *data)
 
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+   /*
+* wait for vblank interrupt
+* - with iommu, the dma operation could induce page fault
+* when accessed to memory after gem buffer was released so
+* make sure that the dma operation is completed before releasing
+* the gem bufer.
+*/
+   if (overlay_ops->wait_for_vblank)
+   overlay_ops->wait_for_vblank(manager->dev);
 }
-- 
1.7.4.1

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


[PATCH 07/10] drm/exynos: make sure that hardware overlay for fimd is disabled

2012-08-20 Thread Inki Dae
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..2378d80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data->enabled = false;
 }
 
+static void fimd_wait_for_vblank(struct device *dev)
+{
+   struct fimd_context *ctx = get_fimd_context(dev);
+   int ret;
+
+   ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
+   VIDCON1_VSTATUS_BACKPORCH), 50);
+   if (ret < 0)
+   DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
 static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+   .wait_for_vblank = fimd_wait_for_vblank,
 };
 
 static struct exynos_drm_manager fimd_manager = {
-- 
1.7.4.1

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


[PATCH 10/10] drm/exynos: update crtc to plane safely

2012-08-20 Thread Inki Dae
if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   59 +-
 1 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 98d5576..80a649b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -45,6 +45,7 @@
  * @dpms: store the encoder dpms value.
  */
 struct exynos_drm_encoder {
+   struct drm_crtc *old_crtc;
struct drm_encoder  drm_encoder;
struct exynos_drm_manager   *manager;
int dpms;
@@ -124,22 +125,74 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
 }
 
+static void disable_plane_to_crtc(struct drm_device *dev,
+   struct drm_crtc *old_crtc,
+   struct drm_crtc *new_crtc)
+{
+   struct drm_plane *plane;
+
+   /*
+* if old_crtc isn't same as encoder->crtc then it means that
+* user changed crtc id to another one so the plane to old_crtc
+* should be disabled and plane->crtc should be set to new_crtc
+* (encoder->crtc)
+*/
+   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+   if (plane->crtc == old_crtc) {
+   /*
+* do not change below call order.
+*
+* plane->funcs->disable_plane call checks
+* if encoder->crtc is same as plane->crtc and if same
+* then overlay_ops->disable callback will be called
+* to diasble current hw overlay so plane->crtc should
+* have new_crtc because new_crtc was set to
+* encoder->crtc in advance.
+*/
+   plane->crtc = new_crtc;
+   plane->funcs->disable_plane(plane);
+   }
+   }
+}
+
 static void exynos_drm_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
 struct drm_display_mode *adjusted_mode)
 {
struct drm_device *dev = encoder->dev;
struct drm_connector *connector;
-   struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
-   struct exynos_drm_manager_ops *manager_ops = manager->ops;
+   struct exynos_drm_manager *manager;
+   struct exynos_drm_manager_ops *manager_ops;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-   if (connector->encoder == encoder)
+   if (connector->encoder == encoder) {
+   struct exynos_drm_encoder *exynos_encoder;
+
+   exynos_encoder = to_exynos_encoder(encoder);
+
+   if (exynos_encoder->old_crtc != encoder->crtc &&
+   exynos_encoder->old_crtc) {
+
+   /*
+* disable a plane to old crtc and change
+* crtc of the plane to new one.
+*/
+   disable_plane_to_crtc(dev,
+   exynos_encoder->old_crtc,
+   encoder->crtc);
+   }
+
+   manager = exynos_drm_get_manager(encoder);
+   manager_ops = manager->ops;
+
if (manager_ops && manager_ops->mode_set)
manager_ops->mode_set(manager->dev,
adjusted_mode);
+
+   exynos_encoder->old_crtc = encoder->crtc;
+   }
}
 }
 
-- 
1.7.4.1

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


[PATCH 08/10] drm/exynos: make sure that hardware overlay for hdmi is disabled

2012-08-20 Thread Inki Dae
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c|   13 +
 3 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..0584132 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -274,10 +274,21 @@ static void drm_mixer_disable(struct device *subdrv_dev, 
int zpos)
ctx->enabled[win] = false;
 }
 
+static void drm_mixer_wait_for_vblank(struct device *subdrv_dev)
+{
+   struct drm_hdmi_context *ctx = to_context(subdrv_dev);
+
+   DRM_DEBUG_KMS("%s\n", __FILE__);
+
+   if (mixer_ops && mixer_ops->wait_for_vblank)
+   mixer_ops->wait_for_vblank(ctx->mixer_ctx->ctx);
+}
+
 static struct exynos_drm_overlay_ops drm_hdmi_overlay_ops = {
.mode_set = drm_mixer_mode_set,
.commit = drm_mixer_commit,
.disable = drm_mixer_disable,
+   .wait_for_vblank = drm_mixer_wait_for_vblank,
 };
 
 static struct exynos_drm_manager hdmi_manager = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index a91c420..d9f9e9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -67,6 +67,7 @@ struct exynos_mixer_ops {
void (*dpms)(void *ctx, int mode);
 
/* overlay */
+   void (*wait_for_vblank)(void *ctx);
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);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 30fcc12..ba3be9b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -726,6 +726,18 @@ static void mixer_dpms(void *ctx, int mode)
}
 }
 
+static void mixer_wait_for_vblank(void *ctx)
+{
+   struct mixer_context *mixer_ctx = ctx;
+   struct mixer_resources *res = &mixer_ctx->mixer_res;
+   int ret;
+
+   ret = wait_for((mixer_reg_read(res, MXR_INT_STATUS) &
+   MXR_INT_STATUS_VSYNC), 50);
+   if (ret < 0)
+   DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
 static void mixer_win_mode_set(void *ctx,
  struct exynos_drm_overlay *overlay)
 {
@@ -818,6 +830,7 @@ static struct exynos_mixer_ops mixer_ops = {
.dpms   = mixer_dpms,
 
/* overlay */
+   .wait_for_vblank= mixer_wait_for_vblank,
.win_mode_set   = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
-- 
1.7.4.1

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


drm/ttm: Remove cpu_writers related code

2012-08-20 Thread Maarten Lankhorst
Nobody uses it, so might as well simplify the code some.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 36f4b28..ddfe393 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -141,7 +141,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
 
BUG_ON(atomic_read(&bo->list_kref.refcount));
BUG_ON(atomic_read(&bo->kref.refcount));
-   BUG_ON(atomic_read(&bo->cpu_writers));
BUG_ON(bo->sync_obj != NULL);
BUG_ON(bo->mem.mm_node != NULL);
BUG_ON(!list_empty(&bo->lru));
@@ -1050,16 +1049,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_mem_space);
 
-int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
-{
-   if ((atomic_read(&bo->cpu_writers) > 0) && no_wait)
-   return -EBUSY;
-
-   return wait_event_interruptible(bo->event_queue,
-   atomic_read(&bo->cpu_writers) == 0);
-}
-EXPORT_SYMBOL(ttm_bo_wait_cpu);
-
 int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
struct ttm_placement *placement,
bool interruptible, bool no_wait_reserve,
@@ -1211,7 +1200,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
 
kref_init(&bo->kref);
kref_init(&bo->list_kref);
-   atomic_set(&bo->cpu_writers, 0);
atomic_set(&bo->reserved, 1);
init_waitqueue_head(&bo->event_queue);
INIT_LIST_HEAD(&bo->lru);
@@ -1769,35 +1757,6 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_wait);
 
-int ttm_bo_synccpu_write_grab(struct ttm_buffer_object *bo, bool no_wait)
-{
-   struct ttm_bo_device *bdev = bo->bdev;
-   int ret = 0;
-
-   /*
-* Using ttm_bo_reserve makes sure the lru lists are updated.
-*/
-
-   ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
-   if (unlikely(ret != 0))
-   return ret;
-   spin_lock(&bdev->fence_lock);
-   ret = ttm_bo_wait(bo, false, true, no_wait);
-   spin_unlock(&bdev->fence_lock);
-   if (likely(ret == 0))
-   atomic_inc(&bo->cpu_writers);
-   ttm_bo_unreserve(bo);
-   return ret;
-}
-EXPORT_SYMBOL(ttm_bo_synccpu_write_grab);
-
-void ttm_bo_synccpu_write_release(struct ttm_buffer_object *bo)
-{
-   if (atomic_dec_and_test(&bo->cpu_writers))
-   wake_up_all(&bo->event_queue);
-}
-EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
-
 /**
  * A buffer object shrink method that tries to swap out the first
  * buffer object on the bo_global::swap_lru list.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..626a3f6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -439,7 +439,6 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
INIT_LIST_HEAD(&fbo->swap);
INIT_LIST_HEAD(&fbo->io_reserve_lru);
fbo->vm_node = NULL;
-   atomic_set(&fbo->cpu_writers, 0);
 
fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj);
kref_init(&fbo->list_kref);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3832fe1..3f48a46 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -181,15 +181,6 @@ retry_this_bo:
}
 
entry->reserved = true;
-   if (unlikely(atomic_read(&bo->cpu_writers) > 0)) {
-   ttm_eu_backoff_reservation_locked(list);
-   spin_unlock(&glob->lru_lock);
-   ttm_eu_list_ref_sub(list);
-   ret = ttm_bo_wait_cpu(bo, false);
-   if (ret)
-   return ret;
-   goto retry;
-   }
}
 
ttm_eu_del_from_lru_locked(list);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index e15f2a8..0853162 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -225,12 +225,6 @@ struct ttm_buffer_object {
bool evicted;
 
/**
-* Members protected by the bo::reserved lock only when written to.
-*/
-
-   atomic_t cpu_writers;
-
-   /**
 * Members protected by the bdev::lru_lock.
 */
 
@@ -423,31 +417,6 @@ extern void ttm_bo_unlock_delayed_workqueue(struct 
ttm_bo_device *bdev,
int resched);
 
 /**
- * ttm_bo_synccpu_write_grab
- *
- * @bo: The buffer object:
- * @no_wait: Return immediately if buffer is busy.
- *
- * Synchronizes a buffer object for CPU RW access. This means
- * blocking command submission that affects the buffer and
- * waiting for buffer idle. This lock is recursive.
- * Returns
- * -EBUSY if the buffer is busy and no_wait is true.
- * -ERESTARTSYS if interrupted by a signal.
- */
-extern 

[PATCH] drm/radeon: init lockup timeout on ring init

2012-08-20 Thread Christian König
Reset the lockup timeout on ring (re-)initialisation.

Otherwise we get error messages like this on gpu resets:
[ 1559.949177] radeon :01:00.0: GPU lockup CP stall for more than 
1482270msec

Signed-off-by: Christian König 
cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/radeon_ring.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index ec79b37..43c431a 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -706,6 +706,7 @@ int radeon_ring_init(struct radeon_device *rdev, struct 
radeon_ring *ring, unsig
if (radeon_debugfs_ring_init(rdev, ring)) {
DRM_ERROR("Failed to register debugfs file for rings !\n");
}
+   radeon_ring_lockup_update(ring);
return 0;
 }
 
-- 
1.7.9.5

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


[PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util

2012-08-20 Thread Maarten Lankhorst
How is this different from just calling with no_wait == false?
As far as I can tell, both paths end up with the same result..

Signed-off-by: Maarten Lankhorst 

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3f48a46..4e7b596 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -82,22 +82,6 @@ static void ttm_eu_list_ref_sub(struct list_head *list)
}
 }
 
-static int ttm_eu_wait_unreserved_locked(struct list_head *list,
-struct ttm_buffer_object *bo)
-{
-   struct ttm_bo_global *glob = bo->glob;
-   int ret;
-
-   ttm_eu_del_from_lru_locked(list);
-   spin_unlock(&glob->lru_lock);
-   ret = ttm_bo_wait_unreserved(bo, true);
-   spin_lock(&glob->lru_lock);
-   if (unlikely(ret != 0))
-   ttm_eu_backoff_reservation_locked(list);
-   return ret;
-}
-
-
 void ttm_eu_backoff_reservation(struct list_head *list)
 {
struct ttm_validate_buffer *entry;
@@ -152,19 +136,10 @@ retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
 
-retry_this_bo:
-   ret = ttm_bo_reserve_locked(bo, true, true, true, val_seq);
+   ret = ttm_bo_reserve_locked(bo, true, false, true, val_seq);
switch (ret) {
case 0:
break;
-   case -EBUSY:
-   ret = ttm_eu_wait_unreserved_locked(list, bo);
-   if (unlikely(ret != 0)) {
-   spin_unlock(&glob->lru_lock);
-   ttm_eu_list_ref_sub(list);
-   return ret;
-   }
-   goto retry_this_bo;
case -EAGAIN:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(&glob->lru_lock);

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


[Bug 53512] kernel rejects cs in quake wars

2012-08-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=53512

almos  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from almos  2012-08-20 13:56:19 UTC ---
With kernel 3.5.1, libdrm 2.4.38 and mesa git-c51f8e2 I couldn't reproduce
this. Closing.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

2012-08-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #32 from Alex Deucher  2012-08-20 14:03:44 UTC ---
A similar patch is already upstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=81ee8fb6b52ec69eeed37fe7943446af1dccecc5

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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/radeon: init lockup timeout on ring init

2012-08-20 Thread Michel Dänzer
On Mon, 2012-08-20 at 15:38 +0200, Christian König wrote: 
> Reset the lockup timeout on ring (re-)initialisation.
> 
> Otherwise we get error messages like this on gpu resets:
> [ 1559.949177] radeon :01:00.0: GPU lockup CP stall for more than 
> 1482270msec
> 
> Signed-off-by: Christian König 
> cc: sta...@kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_ring.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index ec79b37..43c431a 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -706,6 +706,7 @@ int radeon_ring_init(struct radeon_device *rdev, struct 
> radeon_ring *ring, unsig
>   if (radeon_debugfs_ring_init(rdev, ring)) {
>   DRM_ERROR("Failed to register debugfs file for rings !\n");
>   }
> + radeon_ring_lockup_update(ring);
>   return 0;
>  }

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: radeon testing

2012-08-20 Thread Alex Deucher
On Mon, Aug 20, 2012 at 8:30 AM, Luca Tettamanti  wrote:
> On Thu, Aug 16, 2012 at 11:51:10AM -0400, Alex Deucher wrote:
>> I've gathered up the various outstanding radeon patches and put them
>> up in a tree for testing:
>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip
>> Some of these may end up in -fixes, but most of them are -next
>> material.  I haven't had a chance to go through Christian's last set
>> of VM patches yet.
>>
>> Highlights:
>> - rom fetch fixes (UEFI, thunderbolt docks)
>> - major ACPI rework
>> - backlight control for newer asics
>
> Hi Alex,
> I just tested the rebased acpi_patches branch: ACPI part works fine, but
> I see a big slow down during radeon driver initialization when the
> screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> screen just flickers during boot). With initcall_debug I see:
>
> [2.355300] calling  radeon_init+0x0/0x1000 [radeon] @ 552
> ...
> [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 
> 3102147 usecs
>
> For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not 
> very
> informative, I'll try and get more info...

Can you bisect?

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


[PATCH] drm: stop vmgfx driver explosion

2012-08-20 Thread Alan Cox
From: Alan Cox 

If you do a page flip with no flags set then event is NULL. If event is
NULL then the vmw_gfx driver likes to go digging into NULL and extracts
NULL->base.file_priv.

On a modern kernel with NULL mapping protection it's just another oops,
without it there are some "intriguing" possibilities.

What it should do is an open question but that for the driver owners to
sort out.

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 6b0078f..c50724b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1688,15 +1688,19 @@ int vmw_du_page_flip(struct drm_crtc *crtc,
struct vmw_private *dev_priv = vmw_priv(crtc->dev);
struct drm_framebuffer *old_fb = crtc->fb;
struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(fb);
-   struct drm_file *file_priv = event->base.file_priv;
+   struct drm_file *file_priv ;
struct vmw_fence_obj *fence = NULL;
struct drm_clip_rect clips;
int ret;
 
+   if (event == NULL)
+   return -EINVAL;
+
/* require ScreenObject support for page flipping */
if (!dev_priv->sou_priv)
return -ENOSYS;
 
+   file_priv = event->base.file_priv;
if (!vmw_kms_screen_object_flippable(dev_priv, crtc))
return -EINVAL;
 

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


[PATCH 2/3] drm/cirrus: Remove unused validate_sequence

2012-08-20 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/cirrus/cirrus_drv.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 64ea597..5d04564 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -143,7 +143,6 @@ struct cirrus_device {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
struct ttm_bo_device bdev;
-   atomic_t validate_sequence;
} ttm;
bool mm_inited;
 };

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


[PATCH] drm/ttm: cleanup ttm_execbuf_util.c slightly more

2012-08-20 Thread Maarten Lankhorst
The removed member is unneeded, an extra pass is done after all
buffers have been reserved. The behavior stays the same even without
the removed member, but this makes the code slightly more readable.

Depends on previous 2 execbuf-util patches.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |   69 +++-
 1 file changed, 24 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 4e7b596..a545bc9 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -32,7 +32,7 @@
 #include 
 #include 
 
-static void ttm_eu_backoff_reservation_locked(struct list_head *list)
+static void ttm_eu_backoff_reservation_locked(struct list_head *list, bool 
removed)
 {
struct ttm_validate_buffer *entry;
 
@@ -41,43 +41,13 @@ static void ttm_eu_backoff_reservation_locked(struct 
list_head *list)
if (!entry->reserved)
continue;
 
-   if (entry->removed) {
-   ttm_bo_add_to_lru(bo);
-   entry->removed = false;
-
-   }
entry->reserved = false;
-   atomic_set(&bo->reserved, 0);
-   wake_up_all(&bo->event_queue);
-   }
-}
-
-static void ttm_eu_del_from_lru_locked(struct list_head *list)
-{
-   struct ttm_validate_buffer *entry;
-
-   list_for_each_entry(entry, list, head) {
-   struct ttm_buffer_object *bo = entry->bo;
-   if (!entry->reserved)
-   continue;
 
-   if (!entry->removed) {
-   entry->put_count = ttm_bo_del_from_lru(bo);
-   entry->removed = true;
-   }
-   }
-}
-
-static void ttm_eu_list_ref_sub(struct list_head *list)
-{
-   struct ttm_validate_buffer *entry;
-
-   list_for_each_entry(entry, list, head) {
-   struct ttm_buffer_object *bo = entry->bo;
-
-   if (entry->put_count) {
-   ttm_bo_list_ref_sub(bo, entry->put_count, true);
-   entry->put_count = 0;
+   if (removed) {
+   ttm_bo_unreserve_locked(bo);
+   } else {
+   atomic_set(&bo->reserved, 0);
+   wake_up_all(&bo->event_queue);
}
}
 }
@@ -93,7 +63,7 @@ void ttm_eu_backoff_reservation(struct list_head *list)
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;
spin_lock(&glob->lru_lock);
-   ttm_eu_backoff_reservation_locked(list);
+   ttm_eu_backoff_reservation_locked(list, true);
spin_unlock(&glob->lru_lock);
 }
 EXPORT_SYMBOL(ttm_eu_backoff_reservation);
@@ -122,8 +92,6 @@ int ttm_eu_reserve_buffers(struct list_head *list)
 
list_for_each_entry(entry, list, head) {
entry->reserved = false;
-   entry->put_count = 0;
-   entry->removed = false;
}
 
entry = list_first_entry(list, struct ttm_validate_buffer, head);
@@ -141,26 +109,37 @@ retry:
case 0:
break;
case -EAGAIN:
-   ttm_eu_backoff_reservation_locked(list);
+   ttm_eu_backoff_reservation_locked(list, false);
spin_unlock(&glob->lru_lock);
-   ttm_eu_list_ref_sub(list);
ret = ttm_bo_wait_unreserved(bo, true);
if (unlikely(ret != 0))
return ret;
goto retry;
default:
-   ttm_eu_backoff_reservation_locked(list);
+   ttm_eu_backoff_reservation_locked(list, false);
spin_unlock(&glob->lru_lock);
-   ttm_eu_list_ref_sub(list);
return ret;
}
 
entry->reserved = true;
}
 
-   ttm_eu_del_from_lru_locked(list);
+   list_for_each_entry(entry, list, head) {
+   struct ttm_buffer_object *bo = entry->bo;
+
+   entry->put_count = ttm_bo_del_from_lru(bo);
+   }
+
spin_unlock(&glob->lru_lock);
-   ttm_eu_list_ref_sub(list);
+
+   list_for_each_entry(entry, list, head) {
+   struct ttm_buffer_object *bo = entry->bo;
+
+   if (entry->put_count) {
+   ttm_bo_list_ref_sub(bo, entry->put_count, true);
+   entry->put_count = 0;
+   }
+   }
 
return 0;
 }
diff --git a/include/drm/ttm/ttm_execbuf_util.h 
b/include/drm/ttm/ttm_execbuf_util.h
index 26cc7f9..0ef7c95 100644
--- a/include/drm/ttm/ttm_execbuf_util.h
+++ b/include/drm/ttm/ttm_execbuf_util.h
@@ -42,7 +42,6 @@
  * @new_sync_obj_arg: New sync_obj_arg for @bo, to be used once

[PATCH 1/3] drm/ast: remove unused validate_sequence

2012-08-20 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ast/ast_drv.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index d4af9ed..20a437f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -94,7 +94,6 @@ struct ast_private {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
struct ttm_bo_device bdev;
-   atomic_t validate_sequence;
} ttm;
 
struct drm_gem_object *cursor_cache;

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


[PATCH 3/3] drm/mgag200: remove unused validate_sequence

2012-08-20 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/mgag200/mgag200_drv.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 6f13b35..d22cbbf 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -195,7 +195,6 @@ struct mga_device {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
struct ttm_bo_device bdev;
-   atomic_t validate_sequence;
} ttm;
 
u32 reg_1e24; /* SE model number */

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


Re: [PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700

2012-08-20 Thread Alex Deucher
On Sun, Aug 19, 2012 at 5:58 PM, Dave Airlie  wrote:
> On Mon, Aug 20, 2012 at 7:51 AM, Marek Olšák  wrote:
>> Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
>>
>> If it is merged in Linus's tree in the coming days, I'll try to
>> complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.
>
> I'll try and get it merged to 3.6 sometime this week.

I've got a drm-fixes tree for radeon in progress now.  I'll add this
as well as the other odds and ends for fixes.

>
> Dave.
> ___
> 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


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241


Alan  changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
 Kernel Version|Linux version   |3.6
   |3.6.0-030600rc1-generic |
   |(apw@gomeisa) (gcc version  |
   |4.6.3 (Ubuntu/Linaro|
   |4.6.3-1ubuntu5) )   |
   |#201208022056 SMP Fri Aug 3 |
   |00:57:36 UTC 2012   |




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping

2012-08-20 Thread Tvrtko Ursulin

There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.

Signed-off-by: Tvrtko Ursulin 
---

 radeon_atombios.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index f9c21f9..d67d4f3 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -452,7 +452,7 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
}
 
/* Fujitsu D3003-S2 board lists DVI-I as DVI-D and VGA */
-   if ((dev->pdev->device == 0x9802) &&
+   if (((dev->pdev->device == 0x9802) || (dev->pdev->device == 0x9806)) &&
(dev->pdev->subsystem_vendor == 0x1734) &&
(dev->pdev->subsystem_device == 0x11bd)) {
if (*connector_type == DRM_MODE_CONNECTOR_VGA) {

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


[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=46241


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #6 from Alex Deucher   2012-08-20 14:46:28 
---
Looks like a duplicate of:
https://bugs.freedesktop.org/show_bug.cgi?id=43829

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 30812] radeon module fails to initialize with modeset=1 on PPC32 with RV280

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=30812


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=30922


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11

2012-08-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=53111

--- Comment #15 from Michel Dänzer  2012-08-20 14:59:34 UTC 
---
(In reply to comment #10)
> Well, it seems running it through qapitrace doesn't lock.

The apitrace looks incomplete: it doesn't contain any actual rendering
operations.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: stop vmgfx driver explosion

2012-08-20 Thread Jakob Bornecrantz
- Original Message -
> From: Alan Cox 
> 
> If you do a page flip with no flags set then event is NULL. If event
> is NULL then the vmw_gfx driver likes to go digging into NULL and
> extracts NULL->base.file_priv.
> 
> On a modern kernel with NULL mapping protection it's just another
> oops, without it there are some "intriguing" possibilities.
> 
> What it should do is an open question but that for the driver owners
> to sort out.
> 
> Signed-off-by: Alan Cox 

Thanks Alan!

Reviewed-by: Jakob Bornecrantz 

I think CC stable is in order.

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


[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11

2012-08-20 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=53111

--- Comment #16 from Alexandre Demers  2012-08-20 
15:05:03 UTC ---
(In reply to comment #15)
> (In reply to comment #10)
> > Well, it seems running it through qapitrace doesn't lock.
> 
> The apitrace looks incomplete: it doesn't contain any actual rendering
> operations.

I'll rerun it at home tonight.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 31502] Not possible to use KMS with Radeon 9200 anymore

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31502


Alan  changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
  Component|Other   |Video(DRI - non Intel)
 AssignedTo|other_ot...@kernel-bugs.osd |drivers_video-dri@kernel-bu
   |l.org   |gs.osdl.org
Product|Other   |Drivers




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 31502] Not possible to use KMS with Radeon 9200 anymore

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31502


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #2 from Alex Deucher   2012-08-20 15:12:02 
---
Is this still an issue with newer kernels?  If so, can you bisect?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 31682] Radeon console output very slow with kms

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31682


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #5 from Alan   2012-08-20 15:13:08 ---
(or use the GART like GMA50 ...)

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 31712] GPU lockup CP stall after resume from hibernation

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31712


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util

2012-08-20 Thread Jerome Glisse
On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst
 wrote:
> How is this different from just calling with no_wait == false?
> As far as I can tell, both paths end up with the same result..
>
> Signed-off-by: Maarten Lankhorst 

NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked
part is important. It must happen with lru lock held and without any
dropping of this lock prior to wait for bo unreserve.

Cheers,
Jerome

>
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 3f48a46..4e7b596 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -82,22 +82,6 @@ static void ttm_eu_list_ref_sub(struct list_head *list)
> }
>  }
>
> -static int ttm_eu_wait_unreserved_locked(struct list_head *list,
> -struct ttm_buffer_object *bo)
> -{
> -   struct ttm_bo_global *glob = bo->glob;
> -   int ret;
> -
> -   ttm_eu_del_from_lru_locked(list);
> -   spin_unlock(&glob->lru_lock);
> -   ret = ttm_bo_wait_unreserved(bo, true);
> -   spin_lock(&glob->lru_lock);
> -   if (unlikely(ret != 0))
> -   ttm_eu_backoff_reservation_locked(list);
> -   return ret;
> -}
> -
> -
>  void ttm_eu_backoff_reservation(struct list_head *list)
>  {
> struct ttm_validate_buffer *entry;
> @@ -152,19 +136,10 @@ retry:
> list_for_each_entry(entry, list, head) {
> struct ttm_buffer_object *bo = entry->bo;
>
> -retry_this_bo:
> -   ret = ttm_bo_reserve_locked(bo, true, true, true, val_seq);
> +   ret = ttm_bo_reserve_locked(bo, true, false, true, val_seq);
> switch (ret) {
> case 0:
> break;
> -   case -EBUSY:
> -   ret = ttm_eu_wait_unreserved_locked(list, bo);
> -   if (unlikely(ret != 0)) {
> -   spin_unlock(&glob->lru_lock);
> -   ttm_eu_list_ref_sub(list);
> -   return ret;
> -   }
> -   goto retry_this_bo;
> case -EAGAIN:
> ttm_eu_backoff_reservation_locked(list);
> spin_unlock(&glob->lru_lock);
>
> ___
> 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


Re: drm/ttm: Remove cpu_writers related code

2012-08-20 Thread Jerome Glisse
On Mon, Aug 20, 2012 at 9:32 AM, Maarten Lankhorst
 wrote:
> Nobody uses it, so might as well simplify the code some.
>
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Jerome Glisse 

> ---
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 36f4b28..ddfe393 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -141,7 +141,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
>
> BUG_ON(atomic_read(&bo->list_kref.refcount));
> BUG_ON(atomic_read(&bo->kref.refcount));
> -   BUG_ON(atomic_read(&bo->cpu_writers));
> BUG_ON(bo->sync_obj != NULL);
> BUG_ON(bo->mem.mm_node != NULL);
> BUG_ON(!list_empty(&bo->lru));
> @@ -1050,16 +1049,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
>  }
>  EXPORT_SYMBOL(ttm_bo_mem_space);
>
> -int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
> -{
> -   if ((atomic_read(&bo->cpu_writers) > 0) && no_wait)
> -   return -EBUSY;
> -
> -   return wait_event_interruptible(bo->event_queue,
> -   atomic_read(&bo->cpu_writers) == 0);
> -}
> -EXPORT_SYMBOL(ttm_bo_wait_cpu);
> -
>  int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
> struct ttm_placement *placement,
> bool interruptible, bool no_wait_reserve,
> @@ -1211,7 +1200,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
>
> kref_init(&bo->kref);
> kref_init(&bo->list_kref);
> -   atomic_set(&bo->cpu_writers, 0);
> atomic_set(&bo->reserved, 1);
> init_waitqueue_head(&bo->event_queue);
> INIT_LIST_HEAD(&bo->lru);
> @@ -1769,35 +1757,6 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
>  }
>  EXPORT_SYMBOL(ttm_bo_wait);
>
> -int ttm_bo_synccpu_write_grab(struct ttm_buffer_object *bo, bool no_wait)
> -{
> -   struct ttm_bo_device *bdev = bo->bdev;
> -   int ret = 0;
> -
> -   /*
> -* Using ttm_bo_reserve makes sure the lru lists are updated.
> -*/
> -
> -   ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
> -   if (unlikely(ret != 0))
> -   return ret;
> -   spin_lock(&bdev->fence_lock);
> -   ret = ttm_bo_wait(bo, false, true, no_wait);
> -   spin_unlock(&bdev->fence_lock);
> -   if (likely(ret == 0))
> -   atomic_inc(&bo->cpu_writers);
> -   ttm_bo_unreserve(bo);
> -   return ret;
> -}
> -EXPORT_SYMBOL(ttm_bo_synccpu_write_grab);
> -
> -void ttm_bo_synccpu_write_release(struct ttm_buffer_object *bo)
> -{
> -   if (atomic_dec_and_test(&bo->cpu_writers))
> -   wake_up_all(&bo->event_queue);
> -}
> -EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
> -
>  /**
>   * A buffer object shrink method that tries to swap out the first
>   * buffer object on the bo_global::swap_lru list.
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index f8187ea..626a3f6 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -439,7 +439,6 @@ static int ttm_buffer_object_transfer(struct 
> ttm_buffer_object *bo,
> INIT_LIST_HEAD(&fbo->swap);
> INIT_LIST_HEAD(&fbo->io_reserve_lru);
> fbo->vm_node = NULL;
> -   atomic_set(&fbo->cpu_writers, 0);
>
> fbo->sync_obj = driver->sync_obj_ref(bo->sync_obj);
> kref_init(&fbo->list_kref);
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 3832fe1..3f48a46 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -181,15 +181,6 @@ retry_this_bo:
> }
>
> entry->reserved = true;
> -   if (unlikely(atomic_read(&bo->cpu_writers) > 0)) {
> -   ttm_eu_backoff_reservation_locked(list);
> -   spin_unlock(&glob->lru_lock);
> -   ttm_eu_list_ref_sub(list);
> -   ret = ttm_bo_wait_cpu(bo, false);
> -   if (ret)
> -   return ret;
> -   goto retry;
> -   }
> }
>
> ttm_eu_del_from_lru_locked(list);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index e15f2a8..0853162 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -225,12 +225,6 @@ struct ttm_buffer_object {
> bool evicted;
>
> /**
> -* Members protected by the bo::reserved lock only when written to.
> -*/
> -
> -   atomic_t cpu_writers;
> -
> -   /**
>  * Members protected by the bdev::lru_lock.
>  */
>
> @@ -423,31 +417,6 @@ extern void ttm_bo_unlock_delayed_workqueue(struct 
> ttm_bo_device *bdev,
> int resched);
>
>  /**
> - * ttm_bo_synccpu_write_grab
> - *
> - * @bo: The buffer object:
> - * @no_wait

[Bug 31892] Problems with nouveau on my HP laptop

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31892


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 31972] 2.6.38.1: radeon hd 6870: kms, hdmi, signal is correct only for 1-2 seconds

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31972


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #4 from Alan   2012-08-20 15:18:17 ---
If this is still seen with modern kernels please reopen/update thanks

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/ttm: cleanup ttm_execbuf_util.c slightly more

2012-08-20 Thread Jerome Glisse
On Mon, Aug 20, 2012 at 10:36 AM, Maarten Lankhorst
 wrote:
> The removed member is unneeded, an extra pass is done after all
> buffers have been reserved. The behavior stays the same even without
> the removed member, but this makes the code slightly more readable.
>
> Depends on previous 2 execbuf-util patches.
>
> Signed-off-by: Maarten Lankhorst 

NAK this one modify lru list handling in wrong way, we need to track
lru per object no way around it.

Cheers,
Jerome

> ---
>  drivers/gpu/drm/ttm/ttm_execbuf_util.c |   69 
> +++-
>  1 file changed, 24 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 4e7b596..a545bc9 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -32,7 +32,7 @@
>  #include 
>  #include 
>
> -static void ttm_eu_backoff_reservation_locked(struct list_head *list)
> +static void ttm_eu_backoff_reservation_locked(struct list_head *list, bool 
> removed)
>  {
> struct ttm_validate_buffer *entry;
>
> @@ -41,43 +41,13 @@ static void ttm_eu_backoff_reservation_locked(struct 
> list_head *list)
> if (!entry->reserved)
> continue;
>
> -   if (entry->removed) {
> -   ttm_bo_add_to_lru(bo);
> -   entry->removed = false;
> -
> -   }
> entry->reserved = false;
> -   atomic_set(&bo->reserved, 0);
> -   wake_up_all(&bo->event_queue);
> -   }
> -}
> -
> -static void ttm_eu_del_from_lru_locked(struct list_head *list)
> -{
> -   struct ttm_validate_buffer *entry;
> -
> -   list_for_each_entry(entry, list, head) {
> -   struct ttm_buffer_object *bo = entry->bo;
> -   if (!entry->reserved)
> -   continue;
>
> -   if (!entry->removed) {
> -   entry->put_count = ttm_bo_del_from_lru(bo);
> -   entry->removed = true;
> -   }
> -   }
> -}
> -
> -static void ttm_eu_list_ref_sub(struct list_head *list)
> -{
> -   struct ttm_validate_buffer *entry;
> -
> -   list_for_each_entry(entry, list, head) {
> -   struct ttm_buffer_object *bo = entry->bo;
> -
> -   if (entry->put_count) {
> -   ttm_bo_list_ref_sub(bo, entry->put_count, true);
> -   entry->put_count = 0;
> +   if (removed) {
> +   ttm_bo_unreserve_locked(bo);
> +   } else {
> +   atomic_set(&bo->reserved, 0);
> +   wake_up_all(&bo->event_queue);
> }
> }
>  }
> @@ -93,7 +63,7 @@ void ttm_eu_backoff_reservation(struct list_head *list)
> entry = list_first_entry(list, struct ttm_validate_buffer, head);
> glob = entry->bo->glob;
> spin_lock(&glob->lru_lock);
> -   ttm_eu_backoff_reservation_locked(list);
> +   ttm_eu_backoff_reservation_locked(list, true);
> spin_unlock(&glob->lru_lock);
>  }
>  EXPORT_SYMBOL(ttm_eu_backoff_reservation);
> @@ -122,8 +92,6 @@ int ttm_eu_reserve_buffers(struct list_head *list)
>
> list_for_each_entry(entry, list, head) {
> entry->reserved = false;
> -   entry->put_count = 0;
> -   entry->removed = false;
> }
>
> entry = list_first_entry(list, struct ttm_validate_buffer, head);
> @@ -141,26 +109,37 @@ retry:
> case 0:
> break;
> case -EAGAIN:
> -   ttm_eu_backoff_reservation_locked(list);
> +   ttm_eu_backoff_reservation_locked(list, false);
> spin_unlock(&glob->lru_lock);
> -   ttm_eu_list_ref_sub(list);
> ret = ttm_bo_wait_unreserved(bo, true);
> if (unlikely(ret != 0))
> return ret;
> goto retry;
> default:
> -   ttm_eu_backoff_reservation_locked(list);
> +   ttm_eu_backoff_reservation_locked(list, false);
> spin_unlock(&glob->lru_lock);
> -   ttm_eu_list_ref_sub(list);
> return ret;
> }
>
> entry->reserved = true;
> }
>
> -   ttm_eu_del_from_lru_locked(list);
> +   list_for_each_entry(entry, list, head) {
> +   struct ttm_buffer_object *bo = entry->bo;
> +
> +   entry->put_count = ttm_bo_del_from_lru(bo);
> +   }
> +
> spin_unlock(&glob->lru_lock);
> -   ttm_eu_list_ref_sub(list);
> +
> +   list_for_each_entry(entry, list, head) {
> +   struct ttm_buffer_object *bo = entry->bo;
> +
> +   if (entry->put_count) {
> +  

[PATCH 1/4] drm/radeon: implement ACPI VFCT vbios fetch (v3)

2012-08-20 Thread alexdeucher
From: David Lamparter 

This is required for pure UEFI systems.  The vbios is stored
in ACPI rather than at the legacy vga location.

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

V2: fix #ifdefs as per Greg's comments
V3: fix it harder

Signed-off-by: Alex Deucher 
Reviewed-by: Jerome Glisse 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_bios.c |   60 ++
 1 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 501f488..a32232f 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 /*
  * BIOS.
  */
@@ -476,6 +477,63 @@ static bool radeon_read_disabled_bios(struct radeon_device 
*rdev)
return legacy_read_disabled_bios(rdev);
 }
 
+#ifdef CONFIG_ACPI
+static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   bool ret = false;
+   struct acpi_table_header *hdr;
+   /* acpi_get_table_with_size is not exported :( */
+   acpi_size tbl_size = 0x7fff;
+   UEFI_ACPI_VFCT *vfct;
+   GOP_VBIOS_CONTENT *vbios;
+   VFCT_IMAGE_HEADER *vhdr;
+
+   if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
+   return false;
+   if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#1)\n");
+   goto out_unmap;
+   }
+
+   vfct = (UEFI_ACPI_VFCT *)hdr;
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
+   DRM_ERROR("ACPI VFCT table present but broken (too short 
#2)\n");
+   goto out_unmap;
+   }
+
+   vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
+   vhdr = &vbios->VbiosHeader;
+   DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
%d\n",
+   vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
+   vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
+
+   if (vhdr->PCIBus != rdev->pdev->bus->number ||
+   vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+   vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
+   vhdr->VendorID != rdev->pdev->vendor ||
+   vhdr->DeviceID != rdev->pdev->device) {
+   DRM_INFO("ACPI VFCT table is not for this card\n");
+   goto out_unmap;
+   };
+
+   if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
vhdr->ImageLength > tbl_size) {
+   DRM_ERROR("ACPI VFCT image truncated\n");
+   goto out_unmap;
+   }
+
+   rdev->bios = kmemdup(&vbios->VbiosContent, vhdr->ImageLength, 
GFP_KERNEL);
+   ret = !!rdev->bios;
+
+out_unmap:
+   /* uh, no idea what to do here... */
+   return ret;
+}
+#else
+static inline bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+   return false;
+}
+#endif
 
 bool radeon_get_bios(struct radeon_device *rdev)
 {
@@ -484,6 +542,8 @@ bool radeon_get_bios(struct radeon_device *rdev)
 
r = radeon_atrm_get_bios(rdev);
if (r == false)
+   r = radeon_acpi_vfct_bios(rdev);
+   if (r == false)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
-- 
1.7.7.5

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


[PATCH 2/4] ACPI: export symbol acpi_get_table_with_size

2012-08-20 Thread alexdeucher
From: Alex Deucher 

We need it in the radeon drm module to fetch
and verify the vbios image on UEFI systems.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/acpi/acpica/tbxface.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index ea4c6d5..29e51bc 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -387,6 +387,7 @@ acpi_get_table_with_size(char *signature,
 
return (AE_NOT_FOUND);
 }
+ACPI_EXPORT_SYMBOL(acpi_get_table_with_size)
 
 acpi_status
 acpi_get_table(char *signature,
-- 
1.7.7.5

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


[PATCH 3/4] drm/radeon: convert radeon vfct code to use acpi_get_table_with_size

2012-08-20 Thread alexdeucher
From: Alex Deucher 

Allows us to verify the table size.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_bios.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index a32232f..ab0b2f7 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -482,13 +482,12 @@ static bool radeon_acpi_vfct_bios(struct radeon_device 
*rdev)
 {
bool ret = false;
struct acpi_table_header *hdr;
-   /* acpi_get_table_with_size is not exported :( */
-   acpi_size tbl_size = 0x7fff;
+   acpi_size tbl_size;
UEFI_ACPI_VFCT *vfct;
GOP_VBIOS_CONTENT *vbios;
VFCT_IMAGE_HEADER *vhdr;
 
-   if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
+   if (!ACPI_SUCCESS(acpi_get_table_with_size("VFCT", 1, &hdr, &tbl_size)))
return false;
if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
DRM_ERROR("ACPI VFCT table present but broken (too short 
#1)\n");
@@ -525,7 +524,6 @@ static bool radeon_acpi_vfct_bios(struct radeon_device 
*rdev)
ret = !!rdev->bios;
 
 out_unmap:
-   /* uh, no idea what to do here... */
return ret;
 }
 #else
-- 
1.7.7.5

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


[PATCH 4/4] drm/radeon: split ATRM support out from the ATPX handler (v3)

2012-08-20 Thread alexdeucher
From: Alex Deucher 

There are systems that use ATRM, but not ATPX.

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

V2: fix #ifdefs as per Greg's comments
V3: fix it harder

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon.h  |   15 -
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |   56 +--
 drivers/gpu/drm/radeon/radeon_bios.c |   80 -
 3 files changed, 77 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9930419..59a1531 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -142,21 +142,6 @@ struct radeon_device;
 /*
  * BIOS.
  */
-#define ATRM_BIOS_PAGE 4096
-
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_atrm_supported(struct pci_dev *pdev);
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len);
-#else
-static inline bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   return false;
-}
-
-static inline int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int 
len){
-   return -EINVAL;
-}
-#endif
 bool radeon_get_bios(struct radeon_device *rdev);
 
 /*
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 98724fc..2a2cf0b 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -30,57 +30,8 @@ static struct radeon_atpx_priv {
/* handle for device - and atpx */
acpi_handle dhandle;
acpi_handle atpx_handle;
-   acpi_handle atrm_handle;
 } radeon_atpx_priv;
 
-/* retrieve the ROM in 4k blocks */
-static int radeon_atrm_call(acpi_handle atrm_handle, uint8_t *bios,
-   int offset, int len)
-{
-   acpi_status status;
-   union acpi_object atrm_arg_elements[2], *obj;
-   struct acpi_object_list atrm_arg;
-   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
-
-   atrm_arg.count = 2;
-   atrm_arg.pointer = &atrm_arg_elements[0];
-
-   atrm_arg_elements[0].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[0].integer.value = offset;
-
-   atrm_arg_elements[1].type = ACPI_TYPE_INTEGER;
-   atrm_arg_elements[1].integer.value = len;
-
-   status = acpi_evaluate_object(atrm_handle, NULL, &atrm_arg, &buffer);
-   if (ACPI_FAILURE(status)) {
-   printk("failed to evaluate ATRM got %s\n", 
acpi_format_exception(status));
-   return -ENODEV;
-   }
-
-   obj = (union acpi_object *)buffer.pointer;
-   memcpy(bios+offset, obj->buffer.pointer, obj->buffer.length);
-   len = obj->buffer.length;
-   kfree(buffer.pointer);
-   return len;
-}
-
-bool radeon_atrm_supported(struct pci_dev *pdev)
-{
-   /* get the discrete ROM only via ATRM */
-   if (!radeon_atpx_priv.atpx_detected)
-   return false;
-
-   if (radeon_atpx_priv.dhandle == DEVICE_ACPI_HANDLE(&pdev->dev))
-   return false;
-   return true;
-}
-
-
-int radeon_atrm_get_bios_chunk(uint8_t *bios, int offset, int len)
-{
-   return radeon_atrm_call(radeon_atpx_priv.atrm_handle, bios, offset, 
len);
-}
-
 static int radeon_atpx_get_version(acpi_handle handle)
 {
acpi_status status;
@@ -198,7 +149,7 @@ static int radeon_atpx_power_state(enum 
vga_switcheroo_client_id id,
 
 static bool radeon_atpx_pci_probe_handle(struct pci_dev *pdev)
 {
-   acpi_handle dhandle, atpx_handle, atrm_handle;
+   acpi_handle dhandle, atpx_handle;
acpi_status status;
 
dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);
@@ -209,13 +160,8 @@ static bool radeon_atpx_pci_probe_handle(struct pci_dev 
*pdev)
if (ACPI_FAILURE(status))
return false;
 
-   status = acpi_get_handle(dhandle, "ATRM", &atrm_handle);
-   if (ACPI_FAILURE(status))
-   return false;
-
radeon_atpx_priv.dhandle = dhandle;
radeon_atpx_priv.atpx_handle = atpx_handle;
-   radeon_atpx_priv.atrm_handle = atrm_handle;
return true;
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index ab0b2f7..d306cc8 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -99,16 +99,81 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return true;
 }
 
+#ifdef CONFIG_ACPI
 /* ATRM is used to get the BIOS on the discrete cards in
  * dual-gpu systems.
  */
+/* retrieve the ROM in 4k blocks */
+#define ATRM_BIOS_PAGE 4096
+/**
+ * radeon_atrm_call - fetch a chunk of the vbios
+ *
+ * @atrm_handle: acpi ATRM handle
+ * @bios: vbios image pointer
+ * @offset: offset of vbios image data to fetch
+ * @len: length of vbios image data to fetch
+ *
+ * Executes ATRM to fetch a chunk of the discrete
+ * vbios image on PX systems (all asics).
+ * Returns the length of the buffer fetched.
+ */
+static int radeon_atr

[Bug 32072] 2.6.38 Regression: Nvidia GeForce8400 + i915 = Crash on Boot

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=32072


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||INSUFFICIENT_DATA




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 32162] GPU lockup with RV350, KMS, Compiz, Pageflipping

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=32162


Alan  changed:

   What|Removed |Added

  Component|Video(AGP)  |Video(DRI - non Intel)
 AssignedTo|airl...@linux.ie|drivers_video-dri@kernel-bu
   ||gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] radeon: align r600 msaa buffers to a multiple of macrotile size * num samples

2012-08-20 Thread Marek Olšák
I am not sure whether this is needed, but better be safe than sorry.
---
 radeon/radeon_surface.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 98f4aaf..4118a37 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -356,7 +356,7 @@ static int r6_surface_init_2d(struct radeon_surface_manager 
*surf_man,
 surf->bo_alignment =
 MAX2(surf_man->hw_info.num_pipes *
  surf_man->hw_info.num_banks *
- surf->bpe * 64,
+ surf->nsamples * surf->bpe * 64,
  xalign * yalign * surf->nsamples * surf->bpe);
 }
 
-- 
1.7.9.5

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


[Bug 32162] GPU lockup with RV350, KMS, Compiz, Pageflipping

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=32162


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #6 from Alex Deucher   2012-08-20 15:29:25 
---
Is this still an issue with a newer kernel?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

2012-08-20 Thread Matthew Garrett
On Mon, Aug 20, 2012 at 10:31:04AM -0500, Seth Forshee wrote:
> + /*
> +  * For secondary graphics devices shouldn't be initialized
> +  * until the handler and primary graphics device have been
> +  * registered with vga_switcheroo.
> +  *
> +  * FIXME: Is vga_default_device() reliable enough for this
> +  * purpose?
> +  *
> +  * FIXME: If vga_switcheroo is disabled secondary devices
> +  * never gets initialized. Is this okay? Maybe it is, since
> +  * we can't switch to the secondary GPU anyway.
> +  */

Won't this break the multiple cards with independent outputs case?

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 33512] radeon: lots of time spent in atombios_crtc_disable

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=33512


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 33912] [RV515] Kernel .35 onwards, Random X freezes while scrolling

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=33912


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

2012-08-20 Thread Matthew Garrett
On Mon, Aug 20, 2012 at 10:56:33AM -0500, Seth Forshee wrote:
> On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote:
> > Won't this break the multiple cards with independent outputs case?
> 
> Yes, if they don't have a switcheroo handler. I only have experience
> with one such machine, which had optimus graphics. My recollection is
> that it did have a switcheroo handler, which was only capable of
> controlling power to the discrete card.

So if I have a desktop machine and install two graphics cards?

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready

2012-08-20 Thread Matthew Garrett
On Mon, Aug 20, 2012 at 11:24:44AM -0500, Seth Forshee wrote:

> I'm not sure how we support both of these cases without doing something
> more like what I originally proposed, i.e. registering the LVDS
> connector even if it doesn't look like a panel is attached. I still
> honestly favor that approach, although it does come with its own set of
> challenges.
> 
> The only other option I can come up with is to reprobe LVDS after
> switcheroo and add the connector at that time. I haven't investigated
> this option in detail, but at first glance it looks like there are at
> least some places where DRM isn't prepared to cope with adding
> connectors after initialization.

Well, one option is to identify whether the hardware is switcheroo 
capable without the use of the switcheroo driver. It looks like we can 
do that in the majority of cases - Apple is the only special case I can 
see, and that one's a fairly easy workaround.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util

2012-08-20 Thread Maarten Lankhorst
Hey,

Op 20-08-12 17:15, Jerome Glisse schreef:
> On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst
>  wrote:
>> How is this different from just calling with no_wait == false?
>> As far as I can tell, both paths end up with the same result..
>>
>> Signed-off-by: Maarten Lankhorst 
> NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked
> part is important. It must happen with lru lock held and without any
> dropping of this lock prior to wait for bo unreserve.
>

You're right, I missed the part where it removed those, causing the later
patch to be wrong too. However I  still think the code can be made more
readable. Wouldn't it be better if it used the unlocked variants instead?
It would save a lot of extra list traversals, and you could drop
removed, reserved and put_count from ttm_validate_buffer.

~Maarten

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


Re: [PATCH] drm/ttm: remove EBUSY handling in ttm_execbuf_util

2012-08-20 Thread Jerome Glisse
On Mon, Aug 20, 2012 at 1:55 PM, Maarten Lankhorst
 wrote:
> Hey,
>
> Op 20-08-12 17:15, Jerome Glisse schreef:
>> On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst
>>  wrote:
>>> How is this different from just calling with no_wait == false?
>>> As far as I can tell, both paths end up with the same result..
>>>
>>> Signed-off-by: Maarten Lankhorst 
>> NAK this seriously modify the behavior. The ttm_eu_del_from_lru_locked
>> part is important. It must happen with lru lock held and without any
>> dropping of this lock prior to wait for bo unreserve.
>>
>
> You're right, I missed the part where it removed those, causing the later
> patch to be wrong too. However I  still think the code can be made more
> readable. Wouldn't it be better if it used the unlocked variants instead?
> It would save a lot of extra list traversals, and you could drop
> removed, reserved and put_count from ttm_validate_buffer.
>
> ~Maarten
>

No, as i said the lock can not be drop, i don't see much
simplification of this code. Also the path you trying to modify is
taken only is some bo is reserved by some other process, which is
supposed to be rare event.

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


Re: make VM handling async v2

2012-08-20 Thread Alex Deucher
On Mon, Aug 20, 2012 at 4:08 AM, Christian König
 wrote:
> Second and hopefully last round for this patchset.
>
> v2: Fix suspend/resume, and incorporate Jeromes comments.

Looks good to me.  Can you put up a git branch somewhere?

Reviewed-by: Alex Deucher 


>
> Cheers,
> Christian.
>
> ___
> 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


Re: radeon testing

2012-08-20 Thread Luca Tettamanti
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
> > I see a big slow down during radeon driver initialization when the
> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> > screen just flickers during boot). With initcall_debug I see:
> >
> > [2.355300] calling  radeon_init+0x0/0x1000 [radeon] @ 552
> > ...
> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 
> > 3102147 usecs
> >
> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not 
> > very
> > informative, I'll try and get more info...
> 
> Can you bisect?

I've put in some printk, this is the result:

[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done

This is the patch:

--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
 
+   printk(KERN_INFO "%s\n", __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i < 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
 
+   printk(KERN_INFO "evergreen_mc_stop\n");
evergreen_mc_stop(rdev, &save);
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_resume\n");
evergreen_mc_resume(rdev, &save);
+   printk(KERN_INFO "evergreen_mc_resume done\n");
/* we need to own VRAM, so turn off the VGA renderer here
 * to stop it overwriting our objects */
rv515_vga_render_disable(rdev);


Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:

commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher 
Date:   Wed Aug 15 17:18:42 2012 -0400

drm/radeon: properly handle mc_stop/mc_resume on evergreen+

- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access

This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.



I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...




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


[Bug 31862] 2.6.39.3 (and earlier): White text blocks shown during boot-up

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31862


Alan  changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO
  Component|Other   |Video(DRI - non Intel)
 AssignedTo|other_ot...@kernel-bugs.osd |drivers_video-dri@kernel-bu
   |l.org   |gs.osdl.org
Product|Other   |Drivers




--- Comment #3 from Alan   2012-08-20 21:14:47 ---
Because nothing had happened since 2011 and because it appeared to be to do
with the userspace. Just having a general prune of old bugs - not particularly
picking on yours

Now it's re-opened and known current hopefully it'll shake a branch or two.

Do you only see the white rectangles during dracut or do they appear in X or
console too ?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up

2012-08-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=31862


Alan  changed:

   What|Removed |Added

Summary|2.6.39.3 (and earlier): |3.4(and earlier): White
   |White text blocks shown |text blocks shown during
   |during boot-up  |boot-up




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

2012-08-20 Thread Randy Dunlap
On 08/19/2012 10:22 PM, Dave Airlie wrote:

> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap  wrote:
>> On 08/17/12 15:55, Dave Airlie wrote:
>>
>>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
 On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  wrote:
> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>
>> for , we have verified cases on inteldrmfb, radeondrmfb, and
>> cirrusdrmfb.
>>
>> This is the last message displayed before the system hangs.  This seems
>> to be hitting a large number of users in Fedora, though certainly not
>> everyone.  This started happening with the 3.5 updates, and is still an
>> issue.  It appears to be a race condition, because various things have
>> allowed boot to continue for some users, though there is no clear work
>> around. Has anyone else run across this?  Any ideas.  For more
>> background we have the following bugs:
>>
>> inteldrmfb:
>> https://bugzilla.redhat.com/show_bug.cgi?id=843826
>>
>> radeondrmfb:
>> https://bugzilla.redhat.com/show_bug.cgi?id=845745
>>
>> cirrusdrmfb :
>> https://bugzilla.redhat.com/show_bug.cgi?id=843860
>>
>> It should be noted that the conflicting fb hw usage message is not new,
>> it has been around for a while, but this is the last message seen before
>> the hang.
>
>
> Hi,  (adding dri-devel mailing list)
>
>
> I started seeing this problem on 3.5-rc6.
>
> AFAICT, the system is not actually hung, it's just that no output
> is showing up on the real (physical) output device (display) -- it's
> going somewhere else (or to the bit bucket).
>

 Can we bisect this at all?
>>
>> I guess I'll have to try again.  My first attempt did not
>> prove anything, I think because the conflict does not happen
>> 100% of the time (i.e., it feels like a timing problem).
>>
 I worry the intel one will bisect to where we moved the conflict
 resolution earlier, but I'd like to see if applying that patch earlier
 causes the issue, since radeon has it.
>>
>> Do you know of a specific commit that I could revert and test?
> 
> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
> 
> might work, but it just changes the timing mostly.
> 
> also testing 3.4 with that on top would be good.


That commit doesn't apply cleanly to 3.4, but reverting
it on 3.5-rc6 (where I first saw the problem) allows me to boot
3.5-rc6 multiple times without a problem.

Maybe Justin can get more stable testing done also..

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


Re: [RFC 0/5] Generic panel framework

2012-08-20 Thread Laurent Pinchart
Hi Tomi,

On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > Hi Tomi,
> > 
> > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be
> > used for non-panel devices (at least in theory). The future mipi-dsi-bus
> > certainly will.
> 
> They are both display busses. So while they could be used for anything,
> I find it quite unlikely as there are much better alternatives for
> generic bus needs.

My point is that they could be used for display devices other than panels. 
This is especially true for DSI, as there are DSI to HDMI converters. 
Technically speaking that's also true for DBI, as DBI chips convert from DBI 
to DPI, but we can group both the DBI-to-DPI chip and the panel in a single 
panel object.

> > Would you be able to send incremental patches on top of v2 to implement
> > the solution you have in mind ? It would be neat if you could also
> > implement mipi- dsi-bus for the OMAP DSS and test the code with a real
> > device :-)
> 
> Yes, I'd like to try this out on OMAP, both DBI and DSI. However, I fear
> it'll be quite complex due to the dependencies all around we have in the
> current driver. We're working on simplifying things so that it'll be
> easier to try thing like the panel framework, though, so we're going in
> the right direction.

If you want the panel framework to support your use cases I'm afraid you will 
need to work on that ;-)
 
> > > Generally about locks, if we define that panel ops may only be called
> > > exclusively, does it simplify things? I think we can make such
> > > requirements, as there should be only one display framework that handles
> > > the panel. Then we don't need locking for things like enable/disable.
> > 
> > Pushing locking to callers would indeed simplify panel drivers, but we
> > need to make sure we won't need to expose a panel to several callers in
> > the future.
>
> I have a feeling that would be a bad idea.
> 
> Display related stuff are quite sensitive to any delays, so any extra
> transactions over, say, DSI bus could cause a noticeable glitch on the
> screen. I'm not sure what are all the possible ops that a panel can
> offer, but I think all that affect the display or could cause delays
> should be handled by one controlling entity (drm or such). The
> controlling entity needs to handle locking anyway, so in that sense I
> don't think it's an extra burden for it.
> 
> The things that come to my mind that could possibly cause calls to the
> panel outside drm: debugfs, sysfs, audio, backlight. Of those, I think
> backlight should go through drm. Audio, no idea. debugfs and sysfs
> locking needs to be handled by the panel driver, and they are a bit
> problematic as I guess having them requires full locking.

-- 
Regards,

Laurent Pinchart

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


Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

2012-08-20 Thread Dave Airlie
On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap  wrote:
> On 08/19/2012 10:22 PM, Dave Airlie wrote:
>
>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap  wrote:
>>> On 08/17/12 15:55, Dave Airlie wrote:
>>>
 On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  
> wrote:
>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>
>>> for , we have verified cases on inteldrmfb, radeondrmfb, and
>>> cirrusdrmfb.
>>>
>>> This is the last message displayed before the system hangs.  This seems
>>> to be hitting a large number of users in Fedora, though certainly not
>>> everyone.  This started happening with the 3.5 updates, and is still an
>>> issue.  It appears to be a race condition, because various things have
>>> allowed boot to continue for some users, though there is no clear work
>>> around. Has anyone else run across this?  Any ideas.  For more
>>> background we have the following bugs:
>>>
>>> inteldrmfb:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=843826
>>>
>>> radeondrmfb:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=845745
>>>
>>> cirrusdrmfb :
>>> https://bugzilla.redhat.com/show_bug.cgi?id=843860
>>>
>>> It should be noted that the conflicting fb hw usage message is not new,
>>> it has been around for a while, but this is the last message seen before
>>> the hang.
>>
>>
>> Hi,  (adding dri-devel mailing list)
>>
>>
>> I started seeing this problem on 3.5-rc6.
>>
>> AFAICT, the system is not actually hung, it's just that no output
>> is showing up on the real (physical) output device (display) -- it's
>> going somewhere else (or to the bit bucket).
>>
>
> Can we bisect this at all?
>>>
>>> I guess I'll have to try again.  My first attempt did not
>>> prove anything, I think because the conflict does not happen
>>> 100% of the time (i.e., it feels like a timing problem).
>>>
> I worry the intel one will bisect to where we moved the conflict
> resolution earlier, but I'd like to see if applying that patch earlier
> causes the issue, since radeon has it.
>>>
>>> Do you know of a specific commit that I could revert and test?
>>
>> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
>>
>> might work, but it just changes the timing mostly.
>>
>> also testing 3.4 with that on top would be good.
>
>
> That commit doesn't apply cleanly to 3.4, but reverting
> it on 3.5-rc6 (where I first saw the problem) allows me to boot
> 3.5-rc6 multiple times without a problem.
>
> Maybe Justin can get more stable testing done also..

Randy do you have a vga= on your kernel command line?

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


Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

2012-08-20 Thread Randy Dunlap
On 08/20/2012 05:23 PM, Dave Airlie wrote:

> On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap  wrote:
>> On 08/19/2012 10:22 PM, Dave Airlie wrote:
>>
>>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap  wrote:
 On 08/17/12 15:55, Dave Airlie wrote:

> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  
>> wrote:
>>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>>
 for , we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.

 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:

 inteldrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=843826

 radeondrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=845745

 cirrusdrmfb :
 https://bugzilla.redhat.com/show_bug.cgi?id=843860

 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen 
 before
 the hang.
>>>
>>>
>>> Hi,  (adding dri-devel mailing list)
>>>
>>>
>>> I started seeing this problem on 3.5-rc6.
>>>
>>> AFAICT, the system is not actually hung, it's just that no output
>>> is showing up on the real (physical) output device (display) -- it's
>>> going somewhere else (or to the bit bucket).
>>>
>>
>> Can we bisect this at all?

 I guess I'll have to try again.  My first attempt did not
 prove anything, I think because the conflict does not happen
 100% of the time (i.e., it feels like a timing problem).

>> I worry the intel one will bisect to where we moved the conflict
>> resolution earlier, but I'd like to see if applying that patch earlier
>> causes the issue, since radeon has it.

 Do you know of a specific commit that I could revert and test?
>>>
>>> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
>>>
>>> might work, but it just changes the timing mostly.
>>>
>>> also testing 3.4 with that on top would be good.
>>
>>
>> That commit doesn't apply cleanly to 3.4, but reverting
>> it on 3.5-rc6 (where I first saw the problem) allows me to boot
>> 3.5-rc6 multiple times without a problem.
>>
>> Maybe Justin can get more stable testing done also..
> 
> Randy do you have a vga= on your kernel command line?


Ah, yes:  "vga=ask"

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


[PATCH v2] drm/exynos: add wait_for_vblank callback interface.

2012-08-20 Thread Inki Dae
Changelog v2:
fixed comments.

Changelog v1:
this interface can be used to make sure that hardware overlay is disabled
to avoid that memory region is accessed by dma after gem buffer was released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   17 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   10 ++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..eec77aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
 #define MAX_FB_BUFFER  4
 #define DEFAULT_ZPOS   -1
 
+#define _wait_for(COND, MS) ({ \
+   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
+   int ret__ = 0;  \
+   while (!(COND)) {   \
+   if (time_after(jiffies, timeout__)) {   \
+   ret__ = -ETIMEDOUT; \
+   break;  \
+   }   \
+   }   \
+   ret__;  \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
 struct drm_device;
 struct exynos_drm_overlay;
 struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
  * @commit: apply hardware specific overlay data to registers.
  * @enable: enable hardware specific overlay.
  * @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * hardware overlay is disabled.
  */
 struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+   void (*wait_for_vblank)(struct device *subdrv_dev);
 };
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 08ba62f..f453116 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -430,4 +430,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder 
*encoder, void *data)
 
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+   /*
+* wait for vblank interrupt
+* - this makes sure that hardware overlay is disabled to avoid
+* for the dma accesses to memory after gem buffer was released
+* because the setting for disabling the overlay will be updated
+* at vsync.
+*/
+   if (overlay_ops->wait_for_vblank)
+   overlay_ops->wait_for_vblank(manager->dev);
 }
-- 
1.7.4.1

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


[PATCH v2] drm/exynos: separated subdrv_probe function into two parts.

2012-08-20 Thread Inki Dae
Changelog v2:
fixed the issue that when sub driver is probed, no kms drivers such as
fimd or hdmi are failed. no kms drivers have no manager so if manager is
null then encoder and connector creation should be ignored.

Changelog v1:
this patch separates exynos_drm_subdrv_probe function into sub driver's probe 
call
and encoder/connector creation so that exynos drm core module can take exception
when some operation was failed properly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |  100 -
 1 files changed, 69 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..7b0432b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,33 +34,15 @@
 
 static LIST_HEAD(exynos_drm_subdrv_list);
 
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
 {
struct drm_encoder *encoder;
struct drm_connector *connector;
+   int ret;
 
DRM_DEBUG_DRIVER("%s\n", __FILE__);
 
-   if (subdrv->probe) {
-   int ret;
-
-   /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
-   ret = subdrv->probe(dev, subdrv->dev);
-   if (ret)
-   return ret;
-   }
-
-   if (!subdrv->manager)
-   return 0;
-
subdrv->manager->dev = subdrv->dev;
 
/* create and initialize a encoder for this sub driver. */
@@ -78,24 +60,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
-   encoder->funcs->destroy(encoder);
-   return -EFAULT;
+   ret = -EFAULT;
+   goto err_destroy_encoder;
}
 
subdrv->encoder = encoder;
subdrv->connector = connector;
 
return 0;
+
+err_destroy_encoder:
+   encoder->funcs->destroy(encoder);
+   return ret;
 }
 
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
 {
-   DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
-   if (subdrv->remove)
-   subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +89,43 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
 }
 
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+   struct exynos_drm_subdrv *subdrv)
+{
+   if (subdrv->probe) {
+   int ret;
+
+   subdrv->drm_dev = dev;
+
+   /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+   ret = subdrv->probe(dev, subdrv->dev);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+   DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+   if (subdrv->remove)
+   subdrv->remove(dev, subdrv->dev);
+}
+
 int exynos_drm_device_register(struct drm_device *dev)
 {
struct exynos_drm_subdrv *subdrv, *n;
+   unsigned int fine_cnt = 0;
int err;
 
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +134,36 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
 
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
-   subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(&subdrv->list);
+   continue;
+   }
+
+   /*
+* if manager is null then it means that this sub driver
+   

[PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700

2012-08-20 Thread Dave Airlie
On Mon, Aug 20, 2012 at 7:51 AM, Marek Ol??k  wrote:
> Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
>
> If it is merged in Linus's tree in the coming days, I'll try to
> complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.

I'll try and get it merged to 3.6 sometime this week.

Dave.


[Bug 46231] New: Radeon NI: evergreen_resume fails after GPU lockup

2012-08-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=46231

   Summary: Radeon NI: evergreen_resume fails after GPU lockup
   Product: Drivers
   Version: 2.5
Kernel Version: 3.6-rc2
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: ben at b1c1l1.com
Regression: No


I've always had GPU lockups on my Radeon HD 6750M (MacBookPro8,2) but have not
been able to get good kernel messages until upgrading to 3.6-rc2:

[88296.175333] radeon :01:00.0: GPU lockup CP stall for more than 1msec 
[88296.175348] radeon :01:00.0: GPU lockup (waiting for 0x004f368c
last fence id 0x004f3681)
[88296.176433] radeon :01:00.0: Saved 439 dwords of commands on ring 0. 
[88296.176439] radeon :01:00.0: GPU softreset 
[88296.176445] radeon :01:00.0:   GRBM_STATUS=0xA00038A0
[88296.176450] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[88296.176455] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[88296.176460] radeon :01:00.0:   SRBM_STATUS=0x20C0
[88296.176466] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x0100
[88296.176471] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00011002
[88296.176476] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x00028506
[88296.176482] radeon :01:00.0:   R_008680_CP_STAT  = 0x80838647
[88296.176493] radeon :01:00.0:   GRBM_SOFT_RESET=0x7F6B
[88296.176600] radeon :01:00.0:   GRBM_STATUS=0x800038A0
[88296.176605] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[88296.176610] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[88296.176615] radeon :01:00.0:   SRBM_STATUS=0x20C0
[88296.176620] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[88296.176625] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[88296.176630] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[88296.176636] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[88296.177642] radeon :01:00.0: GPU reset succeeded, trying to resume
[88296.177647] radeon :01:00.0: GPU softreset 
[88296.177652] radeon :01:00.0:   GRBM_STATUS=0x800038A0
[88296.177657] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[88296.177662] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[88296.177667] radeon :01:00.0:   SRBM_STATUS=0x20C0
[88296.177672] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[88296.177677] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[88296.177682] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[88296.177687] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[88296.177698] radeon :01:00.0:   GRBM_SOFT_RESET=0x7F6B
[88296.177805] radeon :01:00.0:   GRBM_STATUS=0x800038A0
[88296.177810] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[88296.177814] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[88296.177819] radeon :01:00.0:   SRBM_STATUS=0x20C0
[88296.177824] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[88296.177829] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[88296.177835] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[88296.177840] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[88296.183915] [drm] probing gen 2 caps for device 8086:101 = 2/0
[88296.183918] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[88296.187771] [drm] PCIE GART of 512M enabled (table at 0x0004).
[88296.187948] radeon :01:00.0: WB enabled
[88296.187957] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x880265260c00
[88296.417147] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)
[88296.417150] [drm:evergreen_resume] *ERROR* evergreen startup failed on
resume

blee at supra ~ $ lspci -nn | grep VGA
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Whistler [AMD Radeon HD 6600M Series] [1002:6741]

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


[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:50 PM, Inki Dae wrote:
> this patch separates sub driver's probe call and encoder/connector creation
> so that exynos drm core module can take exception when some operation was
> failed properly.

Which exceptions? I don't know this patch gives any benefit to us.

>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_core.c |   93 
> +-
>   1 files changed, 65 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
> b/drivers/gpu/drm/exynos/exynos_drm_core.c
> index 84dd099..1c8d5fe 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
> @@ -34,30 +34,15 @@
>   
>   static LIST_HEAD(exynos_drm_subdrv_list);
>   
> -static int exynos_drm_subdrv_probe(struct drm_device *dev,
> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
>   struct exynos_drm_subdrv *subdrv)
>   {
>   struct drm_encoder *encoder;
>   struct drm_connector *connector;
> + int ret;
>   
>   DRM_DEBUG_DRIVER("%s\n", __FILE__);
>   
> - if (subdrv->probe) {
> - int ret;
> -
> - /*
> -  * this probe callback would be called by sub driver
> -  * after setting of all resources to this sub driver,
> -  * such as clock, irq and register map are done or by load()
> -  * of exynos drm driver.
> -  *
> -  * P.S. note that this driver is considered for modularization.
> -  */
> - ret = subdrv->probe(dev, subdrv->dev);
> - if (ret)
> - return ret;
> - }
> -
>   if (!subdrv->manager)
>   return 0;
>   
> @@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
>   connector = exynos_drm_connector_create(dev, encoder);
>   if (!connector) {
>   DRM_ERROR("failed to create connector\n");
> - encoder->funcs->destroy(encoder);
> - return -EFAULT;
> + ret = -EFAULT;
> + goto err_destroy_encoder;
>   }
>   
>   subdrv->encoder = encoder;
>   subdrv->connector = connector;
>   
>   return 0;
> +
> +err_destroy_encoder:
> + encoder->funcs->destroy(encoder);
> + return ret;
>   }
>   
> -static void exynos_drm_subdrv_remove(struct drm_device *dev,
> -   struct exynos_drm_subdrv *subdrv)
> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
>   {
> - DRM_DEBUG_DRIVER("%s\n", __FILE__);
> -
> - if (subdrv->remove)
> - subdrv->remove(dev);
> -
>   if (subdrv->encoder) {
>   struct drm_encoder *encoder = subdrv->encoder;
>   encoder->funcs->destroy(encoder);
> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device 
> *dev,
>   }
>   }
>   
> +static int exynos_drm_subdrv_probe(struct drm_device *dev,
> + struct exynos_drm_subdrv *subdrv)
> +{
> + if (subdrv->probe) {
> + int ret;
> +
> + subdrv->drm_dev = dev;
> +
> + /*
> +  * this probe callback would be called by sub driver
> +  * after setting of all resources to this sub driver,
> +  * such as clock, irq and register map are done or by load()
> +  * of exynos drm driver.
> +  *
> +  * P.S. note that this driver is considered for modularization.
> +  */
> + ret = subdrv->probe(dev, subdrv->dev);
> + if (ret)
> + return ret;
> + }
> +
> + if (!subdrv->manager)
> + return -EINVAL;
> +
> + subdrv->manager->dev = subdrv->dev;
> +
> + return 0;
> +}
> +
> +static void exynos_drm_subdrv_remove(struct drm_device *dev,
> +   struct exynos_drm_subdrv *subdrv)
> +{
> + DRM_DEBUG_DRIVER("%s\n", __FILE__);
> +
> + if (subdrv->remove)
> + subdrv->remove(dev, subdrv->dev);
> +}
> +
>   int exynos_drm_device_register(struct drm_device *dev)
>   {
>   struct exynos_drm_subdrv *subdrv, *n;
> + unsigned int fine_cnt = 0;
>   int err;
>   
>   DRM_DEBUG_DRIVER("%s\n", __FILE__);
> @@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device *dev)
>   return -EINVAL;
>   
>   list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
> - subdrv->drm_dev = dev;
>   err = exynos_drm_subdrv_probe(dev, subdrv);
>   if (err) {
>   DRM_DEBUG("exynos drm subdrv probe failed.\n");
>   list_del(&subdrv->list);
> + continue;
>   }
> +
> + err = exynos_drm_create_enc_conn(dev, subdrv);
> + if (err) {
> + DRM_DEB

[PATCH 04/13] drm/exynos: use empty function instead of drm_helper_connector_dpms

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:50 PM, Inki Dae wrote:
> crtc and encoder's dpms callback will be called before connector's dpms
> is called so drm_helper_connector_dpms doesn't need to be called.

I can't understand this description. I know crtc and encoder dpms are called
by drm_helper_connector_dpms.

> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
>   1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index d956819..65acf0d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -226,6 +226,13 @@ static struct drm_connector_helper_funcs 
> exynos_connector_helper_funcs = {
>   .best_encoder   = exynos_drm_best_encoder,
>   };
>   
> +static void exynos_drm_connector_dpms(struct drm_connector *connector, int 
> mode)
> +{
> + DRM_DEBUG_KMS("%s\n", __FILE__);
> +
> + /* drm framework doesn't check NULL. */
> +}
> +
>   static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
>   unsigned int max_width, unsigned int max_height)
>   {
> @@ -285,7 +292,7 @@ static void exynos_drm_connector_destroy(struct 
> drm_connector *connector)
>   }
>   
>   static struct drm_connector_funcs exynos_connector_funcs = {
> - .dpms   = drm_helper_connector_dpms,
> + .dpms   = exynos_drm_connector_dpms,
>   .fill_modes = exynos_drm_connector_fill_modes,
>   .detect = exynos_drm_connector_detect,
>   .destroy= exynos_drm_connector_destroy,



[PATCH 05/13] drm/exynos: removed exynos_drm_encoder_dpms call

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:50 PM, Inki Dae wrote:
> encoder's mode_set callback isn't specific to hardware so it doesn't
> need to call exynos_drm_encoder_dpms().

Then, where is exynos_drm_encoder_dpms() called?

>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 --
>   1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index 2c037cd..3dae250 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -138,8 +138,6 @@ static void exynos_drm_encoder_mode_set(struct 
> drm_encoder *encoder,
>   
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
> - exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
> -
>   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
>   if (connector->encoder == encoder)
>   if (manager_ops && manager_ops->mode_set)



[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:50 PM, Inki Dae wrote:
> this patch adds buf_cnt variable in exynos_drm_fb structure and
> that means a buffer count to drm framebuffer and also adds two
> functions to get/set the buffer count from/to exynos_drm_fb structure.
> if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
> to drm framebuffer refering to mode_cmd->handles and offsets.
> but when booted, the buffer count will always be 1 because pixel
> format of console framebuffer is RGB format.
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 
> +++-
>   drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 +++--
>   drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
>   drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>   4 files changed, 73 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 4ccfe43..2d1bc3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -41,10 +41,12 @@
>* exynos specific framebuffer structure.
>*
>* @fb: drm framebuffer obejct.
> + * @buf_cnt: a buffer count to drm framebuffer.
>* @exynos_gem_obj: array of exynos specific gem object containing a gem 
> object.
>*/
>   struct exynos_drm_fb {
>   struct drm_framebuffer  fb;
> + unsigned intbuf_cnt;
>   struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
>   };
>   
> @@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs 
> = {
>   .dirty  = exynos_drm_fb_dirty,
>   };
>   
> +void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
> + unsigned int cnt)
> +{
> + struct exynos_drm_fb *exynos_fb;
> +
> + exynos_fb = to_exynos_fb(fb);
> +
> + exynos_fb->buf_cnt = cnt;
> +}
> +
> +unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
> +{
> + struct exynos_drm_fb *exynos_fb;
> +
> + exynos_fb = to_exynos_fb(fb);
> +
> + return exynos_fb->buf_cnt;
> +}
> +
>   struct drm_framebuffer *
>   exynos_drm_framebuffer_init(struct drm_device *dev,
>   struct drm_mode_fb_cmd2 *mode_cmd,
> @@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
>   return &exynos_fb->fb;
>   }
>   
> +static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + unsigned int cnt = 0;
> +
> + if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
> + return 2;
> +
> + while (cnt != MAX_FB_BUFFER) {
> + if (!mode_cmd->handles[cnt])
> + break;
> + cnt++;
> + }
> +
> + /*
> +  * check if NV12 or NV12M.
> +  *
> +  * NV12
> +  * handles[0] = base1, offsets[0] = 0
> +  * handles[1] = base1, offsets[1] = Y_size
> +  *
> +  * NV12M
> +  * handles[0] = base1, offsets[0] = 0
> +  * handles[1] = base2, offsets[1] = 0
> +  */
> + if (cnt == 2) {
> + /*
> +  * in case of NV12 format, offsets[1] is not 0 and
> +  * handles[0] is same as handles[1].
> +  */
> + if (mode_cmd->offsets[1] &&
> + mode_cmd->handles[0] == mode_cmd->handles[1])
> + cnt = 1;
> + }
> +
> + return cnt;
> +}

No, please don't add specific function. There is already 
drm_format_num_planes() function

> +
>   static struct drm_framebuffer *
>   exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> struct drm_mode_fb_cmd2 *mode_cmd)
> @@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct 
> drm_file *file_priv,
>   struct drm_gem_object *obj;
>   struct drm_framebuffer *fb;
>   struct exynos_drm_fb *exynos_fb;
> - int nr;
>   int i;
>   
>   DRM_DEBUG_KMS("%s\n", __FILE__);
> @@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct 
> drm_file *file_priv,
>   }
>   
>   exynos_fb = to_exynos_fb(fb);
> - nr = exynos_drm_format_num_buffers(fb->pixel_format);
> + exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
> +
> + DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
>   
> - for (i = 1; i < nr; i++) {
> + for (i = 1; i < exynos_fb->buf_cnt; i++) {
>   obj = drm_gem_object_lookup(dev, file_priv,
>   mode_cmd->handles[i]);
>   if (!obj) {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> index 5082375..96262e5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
> @@ -28,19 +28,6 @@
>   #ifndef _EXYNOS_DRM_FB_H_
>   #define _EXYNOS_DRM_FB_H
>   
> -static inline int exynos_drm_format_num_buffers(uint32_t format)
> -{
> -

[PATCH 10/13] drm/exynos: update crtc to plane safely

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:50 PM, Inki Dae wrote:
> if old_crtc isn't same as encoder->crtc then it means that
> user changed crtc id to another one so a plane to old_crtc
> should be disabled so that current plane can be updated safely
> and plane->crtc should be set to new crtc(encoder->crtc)
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_encoder.c |   59 
> +-
>   1 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index a562a94..7bcace8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -44,6 +44,7 @@
>* @dpms: store the encoder dpms value.
>*/
>   struct exynos_drm_encoder {
> + struct drm_crtc *old_crtc;
>   struct drm_encoder  drm_encoder;
>   struct exynos_drm_manager   *manager;
>   int dpms;
> @@ -106,22 +107,74 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder 
> *encoder,
>   return true;
>   }
>   
> +static void disable_plane_to_crtc(struct drm_device *dev,
> + struct drm_crtc *old_crtc,
> + struct drm_crtc *new_crtc)
> +{
> + struct drm_plane *plane;
> +
> + /*
> +  * if old_crtc isn't same as encoder->crtc then it means that
> +  * user changed crtc id to another one so the plane to old_crtc
> +  * should be disabled and plane->crtc should be set to new_crtc
> +  * (encoder->crtc)
> +  */
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->crtc == old_crtc) {
> + /*
> +  * do not change below call order.
> +  *
> +  * plane->funcs->disable_plane call checks
> +  * if encoder->crtc is same as plane->crtc and if same
> +  * then overlay_ops->disable callback will be called
> +  * to diasble current hw overlay so plane->crtc should
> +  * have new_crtc because new_crtc was set to
> +  * encoder->crtc in advance.
> +  */
> + plane->crtc = new_crtc;
> + plane->funcs->disable_plane(plane);
> + }
> + }
> +}
> +
>   static void exynos_drm_encoder_mode_set(struct drm_encoder *encoder,
>struct drm_display_mode *mode,
>struct drm_display_mode *adjusted_mode)
>   {
>   struct drm_device *dev = encoder->dev;
>   struct drm_connector *connector;
> - struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
> - struct exynos_drm_manager_ops *manager_ops = manager->ops;
> + struct exynos_drm_manager *manager;
> + struct exynos_drm_manager_ops *manager_ops;
>   
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> - if (connector->encoder == encoder)
> + if (connector->encoder == encoder) {
> + struct exynos_drm_encoder *exynos_encoder;
> +
> + exynos_encoder = to_exynos_encoder(encoder);

Does needs to do this in for statement?

> +
> + if (exynos_encoder->old_crtc != encoder->crtc &&
> + exynos_encoder->old_crtc) {
> +
> + /*
> +  * disable a plane to old crtc and change
> +  * crtc of the plane to new one.
> +  */
> + disable_plane_to_crtc(dev,
> + exynos_encoder->old_crtc,
> + encoder->crtc);
> + }
> +
> + manager = exynos_drm_get_manager(encoder);
> + manager_ops = manager->ops;

Does needs to do this in for statement?


> +
>   if (manager_ops && manager_ops->mode_set)
>   manager_ops->mode_set(manager->dev,
>   adjusted_mode);
> +
> + exynos_encoder->old_crtc = encoder->crtc;
> + }
>   }
>   }
>   



[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:50 PM, Inki Dae wrote:
> this patch changes ctx variable name in exynos_drm_hdmi_context
> structure to client because the use of ctx variable makes it confused.

I don't prefer "client" name. This is not client and server relationship.

>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   38 
> +++---
>   drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
>   drivers/gpu/drm/exynos/exynos_hdmi.c |   12 
>   drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
>   4 files changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> index 3fdf0b6..bced38e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> @@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->is_connected)
> - return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
> + return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
>   
>   return false;
>   }
> @@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->get_edid)
> - return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector, edid,
> -   len);
> + return hdmi_ops->get_edid(ctx->hdmi_ctx->client, connector,
> + edid, len);
>   
>   return 0;
>   }
> @@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev, void 
> *timing)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->check_timing)
> - return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
> + return hdmi_ops->check_timing(ctx->hdmi_ctx->client, timing);
>   
>   return 0;
>   }
> @@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int mode)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->power_on)
> - return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
> + return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);
>   
>   return 0;
>   }
> @@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device 
> *subdrv_dev)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (mixer_ops && mixer_ops->enable_vblank)
> - return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
> + return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
>   manager->pipe);
>   
>   return 0;
> @@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device 
> *subdrv_dev)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (mixer_ops && mixer_ops->disable_vblank)
> - return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
> + return mixer_ops->disable_vblank(ctx->mixer_ctx->client);
>   }
>   
>   static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>   struct drm_connector *connector,
> - const struct drm_display_mode *mode,
> + struct drm_display_mode *mode,
>   struct drm_display_mode *adjusted_mode)
>   {
>   struct drm_hdmi_context *ctx = to_context(subdrv_dev);
> @@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->mode_fixup)
> - hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector, mode,
> + hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector, mode,
>adjusted_mode);
>   }
>   
> @@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device *subdrv_dev, 
> void *mode)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->mode_set)
> - hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
> + hdmi_ops->mode_set(ctx->hdmi_ctx->client, mode);
>   }
>   
>   static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
> @@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device 
> *subdrv_dev,
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->get_max_resol)
> - hdmi_ops->get_max_resol(ctx->hdmi_ctx->ctx, width, height);
> + hdmi_ops->get_max_resol(ctx->hdmi_ctx->client, width, height);
>   }
>   
>   static void drm_hdmi_commit(struct device *subdrv_dev)
> @@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
>   DRM_DEBUG_KMS("%s\n", __FILE__);
>   
>   if (hdmi_ops && hdmi_ops->commit)
> - hdmi_ops->commit(ctx->hdmi_ctx->ctx);
> + hdmi_ops->commit(ctx->hdmi_ctx->client);
>   }
>   
>   s

[PATCH V3 2/2] video: drm: exynos: Add device tree support

2012-08-20 Thread Joonyoung Shim
On 08/17/2012 06:37 PM, Leela Krishna Amudala wrote:
> Hello,
>
> On Fri, Aug 17, 2012 at 6:55 AM, Joonyoung Shim  wrote:
>> Hi,
>>
>> 2012/8/16 Leela Krishna Amudala :
>>> Add device tree based discovery support for DRM-FIMD driver.
>>>
>>> Signed-off-by: Leela Krishna Amudala 
>>> ---
>>>   Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
>>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
>>> -
>>>   2 files changed, 173 insertions(+), 2 deletions(-)
>>>   create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
>>> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>>> new file mode 100644
>>> index 000..8ad8814
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>>> @@ -0,0 +1,80 @@
>>> +* Samsung Display Controller using DRM frame work
>>> +
>>> +The display controller is used to transfer image data from memory to an
>>> +external LCD driver interface. It supports various color formats such as
>>> +rgb and yuv.
>>> +
>>> +Required properties:
>>> + - compatible: Should be "samsung,exynos5-drm" for fimd using DRM frame 
>>> work.
>> Just use "samsung,exynos5-fb" and add to support exynos4-fb
>>
> In the first version of this patch set I used "samsung,exynos5-fb",
> but as per Kyungmin Park's suggestion changed it to exynos5-drm.

OK, but this doesn't mean drm device so it is right to use exynos5-fimd.
Add "exynos5-fimd" compatible and also use exynos5-fb, it is used in 
s3c-fb driver.

>>> + - reg: physical base address of the controller and length of memory
>>> +   mapped region.
>>> + - interrupts: Three interrupts should be specified. The interrupts should 
>>> be
>>> +   specified in the following order.
>>> +   - VSYNC interrupt
>>> +   - FIFO level interrupt
>>> +   - FIMD System Interrupt
>>> +
>>> + - samsung,fimd-display: This property should specify the phandle of the
>>> +   display device node which holds the video interface timing with the
>>> +   below mentioned properties.
>>> +
>>> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
>>> + horizontal timing includes four parameters in the following order.
>>> +
>>> + - horizontal back porch (in number of lcd clocks)
>>> + - horizontal front porch (in number of lcd clocks)
>>> + - hsync pulse width (in number of lcd clocks)
>>> + - Display panels X resolution.
>>> +
>>> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
>>> + vertical timing includes four parameters in the following order.
>>> +
>>> + - vertical back porch (in number of lcd lines)
>>> + - vertical front porch (in number of lcd lines)
>>> + - vsync pulse width (in number of lcd clocks)
>>> + - Display panels Y resolution.
>>> +
>>> +
>>> + - samsung,default-window: Specifies the default window number of the fimd 
>>> controller.
>>> +
>>> + - samsung,fimd-win-bpp: Specifies the bits per pixel.
>>> +
>>> +Optional properties:
>>> + - supports-mipi-panel: Specifies the lcd is mipi panel type
>> How is this property used?
>>
> As this driver can be interfaced through MIPI or eDP, Arch side code
> will check whether this property is available or not, if it is
> available then it assumes mipi panel is connected and certain clock
> rate will be set to fimd clock, otherwise assumes other panel is
> connected and other clock rate will be set at arch side.

But it is not used currently in the driver.

>
>>> + - samsung,fimd-vidout-rgb: Video output format is RGB.
>>> + - samsung,fimd-inv-vclk: invert video clock polarity.
>>> + - samsung,fimd-frame-rate: Number of video frames per second.
>>> +
>>> +Example:
>>> +
>>> +   The following is an example for the fimd controller is split into
>>> +   two portions. The SoC specific portion can be specified in the SoC
>>> +   specific dts file. The board specific portion can be specified in 
>>> the
>>> +   board specific dts file.
>>> +
>>> +   - SoC Specific portion
>>> +
>>> +   fimd {
>>> +   compatible = "samsung,exynos5-drm";
>>> +   interrupt-parent = <&combiner>;
>>> +   reg = <0x1440 0x4>;
>>> +   interrupts = <18 5>, <18 4>, <18 6>;
>>> +   };
>>> +
>>> +   - Board Specific portion
>>> +
>>> +   lcd_fimd0: lcd_panel0 {
>>> +   lcd-htiming = <4 4 4 480>;
>>> +   lcd-vtiming = <4 4 4 320>;
>>> +   supports-mipi-panel;
>>> +   };
>>> +
>>> +   fimd {
>>> +   samsung,fimd-display = <&lcd_fimd0>;
>>> +   samsung,fimd-vidout-rgb;
>>> +   samsung,fimd-inv-vclk;
>>> +   samsung,fimd-frame-rate = <60>;
>>> +   samsung,default-window = <0>;
>>> +   samsung,fimd-win-bpp = <32>;
>>> +   };
>>> +
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/dr

[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.

2012-08-20 Thread InKi Dae
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch separates sub driver's probe call and encoder/connector
>> creation
>> so that exynos drm core module can take exception when some operation was
>> failed properly.
>
>
> Which exceptions? I don't know this patch gives any benefit to us.
>

previous code didn't take exception when exynos_drm_encoder_create()
is falied. and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.

>
>>
>> Signed-off-by: Inki Dae 
>> Signed-off-by: Kyungmin Park 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_core.c |   93
>> +-
>>   1 files changed, 65 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> index 84dd099..1c8d5fe 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> @@ -34,30 +34,15 @@
>> static LIST_HEAD(exynos_drm_subdrv_list);
>>   -static int exynos_drm_subdrv_probe(struct drm_device *dev,
>> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
>> struct exynos_drm_subdrv *subdrv)
>>   {
>> struct drm_encoder *encoder;
>> struct drm_connector *connector;
>> +   int ret;
>> DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>   - if (subdrv->probe) {
>> -   int ret;
>> -
>> -   /*
>> -* this probe callback would be called by sub driver
>> -* after setting of all resources to this sub driver,
>> -* such as clock, irq and register map are done or by
>> load()
>> -* of exynos drm driver.
>> -*
>> -* P.S. note that this driver is considered for
>> modularization.
>> -*/
>> -   ret = subdrv->probe(dev, subdrv->dev);
>> -   if (ret)
>> -   return ret;
>> -   }
>> -
>> if (!subdrv->manager)
>> return 0;
>>   @@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device
>> *dev,
>> connector = exynos_drm_connector_create(dev, encoder);
>> if (!connector) {
>> DRM_ERROR("failed to create connector\n");
>> -   encoder->funcs->destroy(encoder);
>> -   return -EFAULT;
>> +   ret = -EFAULT;
>> +   goto err_destroy_encoder;
>> }
>> subdrv->encoder = encoder;
>> subdrv->connector = connector;
>> return 0;
>> +
>> +err_destroy_encoder:
>> +   encoder->funcs->destroy(encoder);
>> +   return ret;
>>   }
>>   -static void exynos_drm_subdrv_remove(struct drm_device *dev,
>> - struct exynos_drm_subdrv *subdrv)
>> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
>>   {
>> -   DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> -
>> -   if (subdrv->remove)
>> -   subdrv->remove(dev);
>> -
>> if (subdrv->encoder) {
>> struct drm_encoder *encoder = subdrv->encoder;
>> encoder->funcs->destroy(encoder);
>> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device
>> *dev,
>> }
>>   }
>>   +static int exynos_drm_subdrv_probe(struct drm_device *dev,
>> +   struct exynos_drm_subdrv *subdrv)
>> +{
>> +   if (subdrv->probe) {
>> +   int ret;
>> +
>> +   subdrv->drm_dev = dev;
>> +
>> +   /*
>> +* this probe callback would be called by sub driver
>> +* after setting of all resources to this sub driver,
>> +* such as clock, irq and register map are done or by
>> load()
>> +* of exynos drm driver.
>> +*
>> +* P.S. note that this driver is considered for
>> modularization.
>> +*/
>> +   ret = subdrv->probe(dev, subdrv->dev);
>> +   if (ret)
>> +   return ret;
>> +   }
>> +
>> +   if (!subdrv->manager)
>> +   return -EINVAL;
>> +
>> +   subdrv->manager->dev = subdrv->dev;
>> +
>> +   return 0;
>> +}
>> +
>> +static void exynos_drm_subdrv_remove(struct drm_device *dev,
>> + struct exynos_drm_subdrv *subdrv)
>> +{
>> +   DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> +
>> +   if (subdrv->remove)
>> +   subdrv->remove(dev, subdrv->dev);
>> +}
>> +
>>   int exynos_drm_device_register(struct drm_device *dev)
>>   {
>> struct exynos_drm_subdrv *subdrv, *n;
>> +   unsigned int fine_cnt = 0;
>> int err;
>> DRM_DEBUG_DRIVER("%s\n", __FILE__);
>> @@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device
>> *

[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.

2012-08-20 Thread Joonyoung Shim
On 08/20/2012 10:52 AM, InKi Dae wrote:
> 2012/8/20 Joonyoung Shim :
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>> this patch separates sub driver's probe call and encoder/connector
>>> creation
>>> so that exynos drm core module can take exception when some operation was
>>> failed properly.
>>
>> Which exceptions? I don't know this patch gives any benefit to us.
>>
> previous code didn't take exception when exynos_drm_encoder_create()
> is falied.

No, it is considered.

> and for now, exynos_drm_encoder/connector_create functions
> was called at exynos_drm_subdrv_probe() so know that this patch is for
> code clean by separating them into two parts also.

It's ok, but it just splitting.

>
>>> Signed-off-by: Inki Dae 
>>> Signed-off-by: Kyungmin Park 
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_core.c |   93
>>> +-
>>>1 files changed, 65 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> index 84dd099..1c8d5fe 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>>> @@ -34,30 +34,15 @@
>>>  static LIST_HEAD(exynos_drm_subdrv_list);
>>>-static int exynos_drm_subdrv_probe(struct drm_device *dev,
>>> +static int exynos_drm_create_enc_conn(struct drm_device *dev,
>>>  struct exynos_drm_subdrv *subdrv)
>>>{
>>>  struct drm_encoder *encoder;
>>>  struct drm_connector *connector;
>>> +   int ret;
>>>  DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>>- if (subdrv->probe) {
>>> -   int ret;
>>> -
>>> -   /*
>>> -* this probe callback would be called by sub driver
>>> -* after setting of all resources to this sub driver,
>>> -* such as clock, irq and register map are done or by
>>> load()
>>> -* of exynos drm driver.
>>> -*
>>> -* P.S. note that this driver is considered for
>>> modularization.
>>> -*/
>>> -   ret = subdrv->probe(dev, subdrv->dev);
>>> -   if (ret)
>>> -   return ret;
>>> -   }
>>> -
>>>  if (!subdrv->manager)
>>>  return 0;
>>>@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device
>>> *dev,
>>>  connector = exynos_drm_connector_create(dev, encoder);
>>>  if (!connector) {
>>>  DRM_ERROR("failed to create connector\n");
>>> -   encoder->funcs->destroy(encoder);
>>> -   return -EFAULT;
>>> +   ret = -EFAULT;
>>> +   goto err_destroy_encoder;
>>>  }
>>>  subdrv->encoder = encoder;
>>>  subdrv->connector = connector;
>>>  return 0;
>>> +
>>> +err_destroy_encoder:
>>> +   encoder->funcs->destroy(encoder);
>>> +   return ret;
>>>}
>>>-static void exynos_drm_subdrv_remove(struct drm_device *dev,
>>> - struct exynos_drm_subdrv *subdrv)
>>> +static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
>>>{
>>> -   DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>> -
>>> -   if (subdrv->remove)
>>> -   subdrv->remove(dev);
>>> -
>>>  if (subdrv->encoder) {
>>>  struct drm_encoder *encoder = subdrv->encoder;
>>>  encoder->funcs->destroy(encoder);
>>> @@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device
>>> *dev,
>>>  }
>>>}
>>>+static int exynos_drm_subdrv_probe(struct drm_device *dev,
>>> +   struct exynos_drm_subdrv *subdrv)
>>> +{
>>> +   if (subdrv->probe) {
>>> +   int ret;
>>> +
>>> +   subdrv->drm_dev = dev;
>>> +
>>> +   /*
>>> +* this probe callback would be called by sub driver
>>> +* after setting of all resources to this sub driver,
>>> +* such as clock, irq and register map are done or by
>>> load()
>>> +* of exynos drm driver.
>>> +*
>>> +* P.S. note that this driver is considered for
>>> modularization.
>>> +*/
>>> +   ret = subdrv->probe(dev, subdrv->dev);
>>> +   if (ret)
>>> +   return ret;
>>> +   }
>>> +
>>> +   if (!subdrv->manager)
>>> +   return -EINVAL;
>>> +
>>> +   subdrv->manager->dev = subdrv->dev;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static void exynos_drm_subdrv_remove(struct drm_device *dev,
>>> + struct exynos_drm_subdrv *subdrv)
>>> +{
>>> +   DRM_DEBUG_DRIVER("%s\n", __FILE__);
>>> +
>>> +   if (subdrv->remove)
>>> +   subdrv->remove(dev, subdrv->dev);
>>> +}
>>> +
>>>int exynos_drm_device_register(struct d

  1   2   3   >