i915_driver_irq_handler: irq 42: nobody cared

[Jiri Slaby]

On 04/11/2012 12:40 PM, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
>> On Tue, 10 Apr 2012 22:32:12 +0200
>> Daniel Vetter  wrote:
>>
>>> On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
 SERR- >>>
 I tried 3.2 and 3.3. Although the spurious interrupts were always
 there, they occurred with frequency lower by a magnitude (15 vs. 300
 after X starts). So I bisected that and it lead to a commit which
 fixes bad tiling for me:
 http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=for-jiri=79710e6ccabdac80c65cd13b944695ecc3e42a9d
>>>
>>> Pipelined fencing is pretty much just broken and we'll completely rip it
>>> out in 3.5. Does this also happen with 3.4-rc2?
>>
>> Does INTx- stay that way?  Or does it frequently read INTx+ if you
>> sample it a lot?  If it stays as INTx-, then something other than the
>> GPU is getting stuck (though it's possible this could be related to
>> pipelined fencing, if the fences are programmed to point at some funky
>> memory space).

Hi and sorry for the delay. It stays INTx-. And I tested that with patch
removing fencing.

> Shot in the dark, let's disable msi a bit. Can you try the below patch?

Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
busted, either in the card, the chipset or the kernel. Any idea how to
find out?

thanks,
-- 
js
suse labs

[PATCH] drm/radeon: improve sa allocator for multi ring load balancing

[j.gli...@gmail.com]

From: Jerome Glisse 

This add a per ring allocation management and load balance the
chunk of the temp buffer between each ring. A ring that often
fail to find a hole or worse have to wait for previous fence
will have more chance to grow over other ring. This ring is
properly CPU starve in a sense. Of course with no real user of
other ring this functionalities is hard to test but code seems
to work well (tested with 2 or 3 rings with main ring being either
first, in the middle or last).

Note it could be refine to decrease all ring before or after.
Right now it only change size of adjacent ring.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h|   30 ++-
 drivers/gpu/drm/radeon/radeon_gart.c   |2 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 +-
 drivers/gpu/drm/radeon/radeon_ring.c   |2 +-
 drivers/gpu/drm/radeon/radeon_sa.c |  409 ++--
 5 files changed, 306 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index dd006ab..28bc338 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -113,10 +113,10 @@ extern int radeon_lockup_timeout;

 /* internal ring indices */
 /* r1xx+ has gfx CP ring */
-#define RADEON_RING_TYPE_GFX_INDEX  0
+#define RADEON_RING_TYPE_GFX_INDEX  1

 /* cayman has 2 compute CP rings */
-#define CAYMAN_RING_TYPE_CP1_INDEX 1
+#define CAYMAN_RING_TYPE_CP1_INDEX 0
 #define CAYMAN_RING_TYPE_CP2_INDEX 2

 /* hardcode those limit for now */
@@ -409,15 +409,26 @@ struct radeon_bo_list {

 struct radeon_sa_bo;

-struct radeon_sa_manager {
-   spinlock_t  lock;
-   struct radeon_bo*bo;
+struct radeon_ra_manager {
struct list_headsa_bo;
-   unsignedsize;
+   unsignedsoffset;
+   unsignedeoffset;
+   unsignedfoffset;
+   unsignedloffset;
+   unsignedstarve;
struct radeon_sa_bo *last;
-   uint64_tgpu_addr;
-   void*cpu_ptr;
-   uint32_tdomain;
+};
+
+struct radeon_sa_manager {
+   spinlock_t  lock;
+   struct radeon_bo*bo;
+   unsignedsize;
+   unsignednrings;
+   uint64_tgpu_addr;
+   void*cpu_ptr;
+   uint32_tdomain;
+   unsigned long   update_timeout;
+   struct radeon_ra_managerrings[RADEON_NUM_RINGS];
 };

 /* sub-allocation buffer */
@@ -427,6 +438,7 @@ struct radeon_sa_bo {
unsignedsoffset;
unsignedeoffset;
unsignedsize;
+   unsignedring;
struct radeon_fence *fence;
boolfree;
 };
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index cab012f..973c31b 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -291,7 +291,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
/* mark first vm as always in use, it's the system one */
r = radeon_sa_bo_manager_init(rdev, >vm_manager.sa_manager,
  rdev->vm_manager.max_pfn * 8,
- RADEON_GEM_DOMAIN_VRAM);
+ RADEON_GEM_DOMAIN_VRAM, 1);
if (r) {
dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n",
(rdev->vm_manager.max_pfn * 8) >> 10);
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 35e54da..0e7c099 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -148,7 +148,7 @@ extern struct radeon_bo_va *radeon_bo_va(struct radeon_bo 
*rbo,
  */
 extern int radeon_sa_bo_manager_init(struct radeon_device *rdev,
 struct radeon_sa_manager *sa_manager,
-unsigned size, u32 domain);
+unsigned size, u32 domain, unsigned 
nrings);
 extern void radeon_sa_bo_manager_fini(struct radeon_device *rdev,
  struct radeon_sa_manager *sa_manager);
 extern int radeon_sa_bo_manager_start(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index b279a61..ec0aab38 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -151,7 +151,7 @@ int radeon_ib_pool_init(struct radeon_device *rdev)

r = radeon_sa_bo_manager_init(rdev, >ring_tmp_bo,
   

Include request for reset-rework branch v4

[Christian König]

On 03.05.2012 19:34, Jerome Glisse wrote:
> On Thu, May 3, 2012 at 1:28 PM, Christian K?nig  
> wrote:
>> On 03.05.2012 19:20, Alex Deucher wrote:
>>> 2012/5/3 Jerome Glisse:
 On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
 wrote:
> On 03.05.2012 18:32, Jerome Glisse wrote:
>> On Thu, May 3, 2012 at 4:19 AM, Christian
>> K?nig
>>   wrote:
>>> On 02.05.2012 18:01, Jerome Glisse wrote:
 On Wed, May 2, 2012 at 9:11 AM, Christian
 K?nig
   wrote:
> Hi Dave,
>
> there still seems to be the need for some further discussion about
> the
> SA
> code,
> so I again split that out of the patchset and tested the result a
> bit.
>
> Most of the stuff still works fine without those offending changes,
> so
> to
> avoid
> mailing around unrelated and already reviewed patches, I request the
> include
> the following 17 patches into drm-next.
>
> If you prefer to merge they are also available from
> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>
> Cheers,
> Christian.
>
 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.
>>> At least for now those three are NAK, cause I just realized we need to
>>> put
>>> those on top of a more sophisticated fence implementation.
>>>
>>> Your idea of not using a list, but 64 bit sequences instead actually
>>> sounds
>>> quite nifty to me. Going to hack something together in the next couple
>>> of
>>> hours.
>>>
>>> Christian.
>> Btw you said that you are having issue when using multiple ring, it
>> comes to my attention that you never sync with the GFX ring (unless
>> asked by userspace) that's wrong, before scheduling on another ring
>> than GFX index you need to emit semaphore to make the ring wait for
>> the last emited fence on the GFX ring because of ttm. What might
>> happen is that ttm scheduled bo move on the GFX ring and that the ring
>> you work on start using those bo at there soon to be GPU offset while
>> the bo data is not there yet.
> Yeah, already stumbled over that but IIRC Alex already solved that
> issue..
>
>
> We set the sync_obj to the fence of the move operation, so when there is
> a
> move operation in progress we sync to it correctly (at least I hope so).
>
> Christian.
>
 Looking at code doesn't seems ok, yes you use the fence from the move
 operation but you only emit wait if userspace ask for it, that's
 wrong.

 if (!(p->relocs[i].flags&RADEON_RELOC_DONT_SYNC)) {

>>> The default is to sync all the rings.  We only skip the sync if the
>>> _DONT_ sync flag is set.
>> Yeah, but the _DONT_ sync flag is just an optimization, and we only want to
>> not sync to things userspace has submitted.
>>
>>   E.g. userspace tells us that two jobs can happily run on the same bo even
>> if they are both writing to it
>>
>> So Jerome is completely right, userspace doesn't expect that TTM is jumping
>> in between and moving the bo around, that is indeed a bug and another thing
>> for the todo list.
>>
>> Christian.
> Well until userspace can tell kernel on which fence it wants to wait i
> believe this flags become obsolete and can be remove, i am pretty no
> release userspace code ever used that flags.

Agree, AFAIK it currently isn't used anyway.

Christian.

Include request for reset-rework branch v4

[Christian König]

On 03.05.2012 19:20, Alex Deucher wrote:
> 2012/5/3 Jerome Glisse:
>> On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
>>   wrote:
>>> On 03.05.2012 18:32, Jerome Glisse wrote:
 On Thu, May 3, 2012 at 4:19 AM, Christian K?nig
   wrote:
> On 02.05.2012 18:01, Jerome Glisse wrote:
>> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig> vodafone.de>
>>   wrote:
>>> Hi Dave,
>>>
>>> there still seems to be the need for some further discussion about the
>>> SA
>>> code,
>>> so I again split that out of the patchset and tested the result a bit.
>>>
>>> Most of the stuff still works fine without those offending changes, so
>>> to
>>> avoid
>>> mailing around unrelated and already reviewed patches, I request the
>>> include
>>> the following 17 patches into drm-next.
>>>
>>> If you prefer to merge they are also available from
>>> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>>>
>>> Cheers,
>>> Christian.
>>>
>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17
>> that
>> bring back some other of the previous cleanup.
> At least for now those three are NAK, cause I just realized we need to
> put
> those on top of a more sophisticated fence implementation.
>
> Your idea of not using a list, but 64 bit sequences instead actually
> sounds
> quite nifty to me. Going to hack something together in the next couple of
> hours.
>
> Christian.
 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.
>>> Yeah, already stumbled over that but IIRC Alex already solved that issue..
>>>
>>> We set the sync_obj to the fence of the move operation, so when there is a
>>> move operation in progress we sync to it correctly (at least I hope so).
>>>
>>> Christian.
>>>
>> Looking at code doesn't seems ok, yes you use the fence from the move
>> operation but you only emit wait if userspace ask for it, that's
>> wrong.
>>
>> if (!(p->relocs[i].flags&  RADEON_RELOC_DONT_SYNC)) {
>>
> The default is to sync all the rings.  We only skip the sync if the
> _DONT_ sync flag is set.
Yeah, but the _DONT_ sync flag is just an optimization, and we only want 
to not sync to things userspace has submitted.

  E.g. userspace tells us that two jobs can happily run on the same bo 
even if they are both writing to it

So Jerome is completely right, userspace doesn't expect that TTM is 
jumping in between and moving the bo around, that is indeed a bug and 
another thing for the todo list.

Christian.

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Christian König]

On 03.05.2012 18:34, Jerome Glisse wrote:
> On Thu, May 3, 2012 at 12:29 PM, Alex Deucher  
> wrote:
>> On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse  wrote:
>>> On Thu, May 3, 2012 at 7:39 AM, Christian K?nig 
>>>  wrote:
 On 03.05.2012 09:21, Michel D?nzer wrote:
> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:
>> From: Jerome Glisse
>>
>> This convert fence to use uint64_t sequence number intention is
>> to use the fact that uin64_t is big enough that we don't need to
>> care about wrap around.
>>
>> Tested with and without writeback using 0xF000 as initial
>> fence sequence and thus allowing to test the wrap around from
>> 32bits to 64bits.
>>
>> Signed-off-by: Jerome Glisse
> [...]
>
>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
>> b/drivers/gpu/drm/radeon/radeon_fence.c
>> index 7733429..6da1535 100644
>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
>> radeon_device *rdev, int ring)
>> rdev->fence_drv[ring].scratch_reg -
>> rdev->scratch.reg_base;
>> }
>> -   rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
>> +   rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
> Might want to ensure cpu_addr is 64 bit aligned, or there might be
> trouble on some architectures.
>
>
> With this change, Cayman cards will already use six scratch registers
> for the rings. It won't be possible to extend this scheme for even one
> additional ring, will it?

 That won't work anyway, since not all rings can deal with 64 bit fences, so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.
>>> This patch is fine with ring that can't emit directly 64bits, all you
>>> have to do is fix the emit_fence callback to properly handle it and
>>> then you have to fix the radeon_fence_read which can be move to a ring
>>> specific callback. Anyway point is that patchset works and is fine on
>>> current set of ring we have and it can work as easily for ring without
>>> easy 64bits value emitting. So please explain further why those patch
>>> can't work because as i just explained i don't see why.
>>>
>>> I have updated some v2 version of those patchset to handle the cayman
>>> and newer possibly running out of scratch reg and i also fix the
>>> alignment issue to be 64bits
>> FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
>> least), it's just memory writes so we could make the scratch pool
>> bigger.
>>
>> Alex
>>
> That's what my v2 does, just drop scratch reg for cayman and newer.
>
> Cheers,
> Jerome
>
I actually always wanted to change that in a way that scratch regs are 
only allocated if wb is really disabled, just never had time to do so 
(sigh).

Cheers,
Christian.

Include request for reset-rework branch v4

[Christian König]

On 03.05.2012 18:32, Jerome Glisse wrote:
> On Thu, May 3, 2012 at 4:19 AM, Christian K?nig  
> wrote:
>> On 02.05.2012 18:01, Jerome Glisse wrote:
>>> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig
>>>   wrote:
 Hi Dave,

 there still seems to be the need for some further discussion about the SA
 code,
 so I again split that out of the patchset and tested the result a bit.

 Most of the stuff still works fine without those offending changes, so to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

>>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
>>> bring back some other of the previous cleanup.
>> At least for now those three are NAK, cause I just realized we need to put
>> those on top of a more sophisticated fence implementation.
>>
>> Your idea of not using a list, but 64 bit sequences instead actually sounds
>> quite nifty to me. Going to hack something together in the next couple of
>> hours.
>>
>> Christian.
> Btw you said that you are having issue when using multiple ring, it
> comes to my attention that you never sync with the GFX ring (unless
> asked by userspace) that's wrong, before scheduling on another ring
> than GFX index you need to emit semaphore to make the ring wait for
> the last emited fence on the GFX ring because of ttm. What might
> happen is that ttm scheduled bo move on the GFX ring and that the ring
> you work on start using those bo at there soon to be GPU offset while
> the bo data is not there yet.
Yeah, already stumbled over that but IIRC Alex already solved that issue.

We set the sync_obj to the fence of the move operation, so when there is 
a move operation in progress we sync to it correctly (at least I hope so).

Christian.

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

One more regression fix and a 3 small patches:
- Paulo fixed the hdmi infoframe regression on gm45 introduced in 3.2 by
  Jesse.
- snb/ilk has a nice debug register where the hw can tell us when it
  dropped writes and we've added a WARN in 3.4 when this happens. This
  caught code which shouldn't run on gen6+, the two patches by Chris fix
  this. No known bad side-effects besides the WARN backtrace (and in a
  way, not really a regression fix, but still).
- Fix up 2 broken no-lvds quirks added in 3.4 - I've figured shipping with
  broken quirk entries is pointless, and these are easily revertable.

Yours, Daniel

The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a:

  Linux 3.4-rc5 (2012-04-29 15:19:10 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to c1230df7e19e0f27655c0eb9d966c7e03be7cc50:

  drm/i915: enable dip before writing data on gen4 (2012-05-03 15:55:38 +0200)


Chris Wilson (2):
  drm/i915: Do not read non-existent DPLL registers on PCH hardware
  drm/i915: Only enable IPS polling for gen5

Marc Gariepy (1):
  fixing dmi match for hp t5745 and hp st5747 thin client

Paulo Zanoni (1):
  drm/i915: enable dip before writing data on gen4

 drivers/gpu/drm/i915/i915_debugfs.c  |3 +++
 drivers/gpu/drm/i915/i915_dma.c  |   15 ++-
 drivers/gpu/drm/i915/intel_display.c |9 +
 drivers/gpu/drm/i915/intel_hdmi.c|2 +-
 drivers/gpu/drm/i915/intel_lvds.c|4 ++--
 5 files changed, 21 insertions(+), 12 deletions(-)

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 5:04 PM, Alex Deucher  wrote:
> On Thu, May 3, 2012 at 4:46 PM, Jerome Glisse  wrote:
>> On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse  wrote:
>>> On Thu, May 3, 2012 at 12:29 PM, Alex Deucher  
>>> wrote:
 On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse  
 wrote:
> On Thu, May 3, 2012 at 7:39 AM, Christian K?nig  vodafone.de> wrote:
>> On 03.05.2012 09:21, Michel D?nzer wrote:
>>>
>>> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:

 From: Jerome Glisse

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glisse
>>>
>>> [...]
>>>
 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
 ? ? ? ? ? ? ? ? ? ? ? ?rdev->fence_drv[ring].scratch_reg -
 ? ? ? ? ? ? ? ? ? ? ? ?rdev->scratch.reg_base;
 ? ? ? ?}
 - ? ? ? rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
 + ? ? ? rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
>>>
>>> Might want to ensure cpu_addr is 64 bit aligned, or there might be
>>> trouble on some architectures.
>>>
>>>
>>> With this change, Cayman cards will already use six scratch registers
>>> for the rings. It won't be possible to extend this scheme for even one
>>> additional ring, will it?
>>
>>
>> That won't work anyway, since not all rings can deal with 64 bit fences, 
>> so
>> we need to still use 32 bit signaling and extend them to 64 bit while
>> processing the fence value.
>>
>> Already working on that.
>>
>> Christian.
>
> This patch is fine with ring that can't emit directly 64bits, all you
> have to do is fix the emit_fence callback to properly handle it and
> then you have to fix the radeon_fence_read which can be move to a ring
> specific callback. Anyway point is that patchset works and is fine on
> current set of ring we have and it can work as easily for ring without
> easy 64bits value emitting. So please explain further why those patch
> can't work because as i just explained i don't see why.
>
> I have updated some v2 version of those patchset to handle the cayman
> and newer possibly running out of scratch reg and i also fix the
> alignment issue to be 64bits

 FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
 least), it's just memory writes so we could make the scratch pool
 bigger.

 Alex

>>>
>>> That's what my v2 does, just drop scratch reg for cayman and newer.
>>>
>>> Cheers,
>>> Jerome
>>
>> Btw uploaded a v3 with some more thing like warnononce for extra
>> safety, better comment and trying to mitigate race btw cpu reading and
>> gpu writing fence.
>> http://people.freedesktop.org/~glisse/reset3/
>
> In patch:
> http://people.freedesktop.org/~glisse/reset3/0003-drm-radeon-rework-fence-handling-drop-fence-list-v3.patch
>
> You can drop this hunk:
> + ? ? ? if (rdev->family >= CHIP_CAYMAN) {
> + ? ? ? ? ? ? ? /* because there is so many ring on newer GPU we can't use
> + ? ? ? ? ? ? ? ?* scratch reg thus we need to use event, on those GPU there
> + ? ? ? ? ? ? ? ?* is no AGP version and writting to system ram have always
> + ? ? ? ? ? ? ? ?* been reliable so far
> + ? ? ? ? ? ? ? ?*/
> + ? ? ? ? ? ? ? rdev->wb.enabled = true;
> + ? ? ? ? ? ? ? rdev->wb.use_event = true;
> + ? ? ? }
>
> As the code right below it does the exact same thing. ?It could
> probably be extended to APUs as well since they will never have AGP
> support. ?I'll send out a patch.
>
> Alex
>

Good catch updated patch
http://people.freedesktop.org/~glisse/reset3/

Cheers,
Jerome

[PATCH 4/4] drm/i915: make DBLCLK modes work

[Anssi Hannula]

13.04.2012 22:31, Paulo Zanoni kirjoitti:
> From: Paulo Zanoni 
> 
> They require an AVI InfoFrame with a proper Pixel Repetition field.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
> Signed-off-by: Paulo Zanoni 
> ---
> 
> I'm still waiting for confirmation on bugzilla, but I have access to a
> TV that reproduces the problem and the problem goes away with this patch
> series.

Shouldn't all this infoframe stuff be shared between the drivers (like
e.g. EDID stuff is)? I see i915, radeon, nouveau all have separate
implementations of it, and i915 seems to have it even twice (in
intel_hdmi.c and intel_sdvo.c).

The patch below only fixes the issue on one of those four places where
the avi/video infoframe is generated.


>  drivers/gpu/drm/i915/intel_drv.h  |2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c |8 ++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 175cca7..3afa7ab 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -215,6 +215,8 @@ struct intel_plane {
>  #define DIP_TYPE_AVI0x82
>  #define DIP_VERSION_AVI 0x2
>  #define DIP_LEN_AVI 13
> +#define DIP_AVI_PR_10
> +#define DIP_AVI_PR_21
>  
>  #define DIP_TYPE_SPD 0x83
>  #define DIP_VERSION_SPD  0x1
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 7de2d3b..8d25017 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -220,7 +220,8 @@ static void intel_set_infoframe(struct drm_encoder 
> *encoder,
>   intel_hdmi->write_infoframe(encoder, frame);
>  }
>  
> -static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
> +static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
> +  struct drm_display_mode *adjusted_mode)
>  {
>   struct dip_infoframe avi_if = {
>   .type = DIP_TYPE_AVI,
> @@ -228,6 +229,9 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder)
>   .len = DIP_LEN_AVI,
>   };
>  
> + if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> + avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
> +
>   intel_set_infoframe(encoder, _if);
>  }
>  
> @@ -290,7 +294,7 @@ static void intel_hdmi_mode_set(struct drm_encoder 
> *encoder,
>   I915_WRITE(intel_hdmi->sdvox_reg, sdvox);
>   POSTING_READ(intel_hdmi->sdvox_reg);
>  
> - intel_hdmi_set_avi_infoframe(encoder);
> + intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
>   intel_hdmi_set_spd_infoframe(encoder);
>  }
>  


-- 
Anssi Hannula

[PATCH] drm/radeon: clarify and extend wb setup on APUs and NI+ asics

[alexdeuc...@gmail.com]

From: Alex Deucher 

Use family rather than DCE check for clarity, also always use
wb on APUs, there will never be AGP variants.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_device.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 94f8561..8479617 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -241,8 +241,8 @@ int radeon_wb_init(struct radeon_device *rdev)
rdev->wb.use_event = true;
}
}
-   /* always use writeback/events on NI */
-   if (ASIC_IS_DCE5(rdev)) {
+   /* always use writeback/events on NI, APUs */
+   if (rdev->family >= CHIP_PALM) {
rdev->wb.enabled = true;
rdev->wb.use_event = true;
}
-- 
1.7.7.5

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Alex Deucher]

On Thu, May 3, 2012 at 4:46 PM, Jerome Glisse  wrote:
> On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse  wrote:
>> On Thu, May 3, 2012 at 12:29 PM, Alex Deucher  
>> wrote:
>>> On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse  
>>> wrote:
 On Thu, May 3, 2012 at 7:39 AM, Christian K?nig >>> vodafone.de> wrote:
> On 03.05.2012 09:21, Michel D?nzer wrote:
>>
>> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> This convert fence to use uint64_t sequence number intention is
>>> to use the fact that uin64_t is big enough that we don't need to
>>> care about wrap around.
>>>
>>> Tested with and without writeback using 0xF000 as initial
>>> fence sequence and thus allowing to test the wrap around from
>>> 32bits to 64bits.
>>>
>>> Signed-off-by: Jerome Glisse
>>
>> [...]
>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
>>> b/drivers/gpu/drm/radeon/radeon_fence.c
>>> index 7733429..6da1535 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>>> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
>>> radeon_device *rdev, int ring)
>>> ? ? ? ? ? ? ? ? ? ? ? ?rdev->fence_drv[ring].scratch_reg -
>>> ? ? ? ? ? ? ? ? ? ? ? ?rdev->scratch.reg_base;
>>> ? ? ? ?}
>>> - ? ? ? rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
>>> + ? ? ? rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
>>
>> Might want to ensure cpu_addr is 64 bit aligned, or there might be
>> trouble on some architectures.
>>
>>
>> With this change, Cayman cards will already use six scratch registers
>> for the rings. It won't be possible to extend this scheme for even one
>> additional ring, will it?
>
>
> That won't work anyway, since not all rings can deal with 64 bit fences, 
> so
> we need to still use 32 bit signaling and extend them to 64 bit while
> processing the fence value.
>
> Already working on that.
>
> Christian.

 This patch is fine with ring that can't emit directly 64bits, all you
 have to do is fix the emit_fence callback to properly handle it and
 then you have to fix the radeon_fence_read which can be move to a ring
 specific callback. Anyway point is that patchset works and is fine on
 current set of ring we have and it can work as easily for ring without
 easy 64bits value emitting. So please explain further why those patch
 can't work because as i just explained i don't see why.

 I have updated some v2 version of those patchset to handle the cayman
 and newer possibly running out of scratch reg and i also fix the
 alignment issue to be 64bits
>>>
>>> FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
>>> least), it's just memory writes so we could make the scratch pool
>>> bigger.
>>>
>>> Alex
>>>
>>
>> That's what my v2 does, just drop scratch reg for cayman and newer.
>>
>> Cheers,
>> Jerome
>
> Btw uploaded a v3 with some more thing like warnononce for extra
> safety, better comment and trying to mitigate race btw cpu reading and
> gpu writing fence.
> http://people.freedesktop.org/~glisse/reset3/

In patch:
http://people.freedesktop.org/~glisse/reset3/0003-drm-radeon-rework-fence-handling-drop-fence-list-v3.patch

You can drop this hunk:
+   if (rdev->family >= CHIP_CAYMAN) {
+   /* because there is so many ring on newer GPU we can't use
+* scratch reg thus we need to use event, on those GPU there
+* is no AGP version and writting to system ram have always
+* been reliable so far
+*/
+   rdev->wb.enabled = true;
+   rdev->wb.use_event = true;
+   }

As the code right below it does the exact same thing.  It could
probably be extended to APUs as well since they will never have AGP
support.  I'll send out a patch.

Alex

>
> Cheers,
> Jerome

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse  wrote:
> On Thu, May 3, 2012 at 12:29 PM, Alex Deucher  
> wrote:
>> On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse  wrote:
>>> On Thu, May 3, 2012 at 7:39 AM, Christian K?nig >> vodafone.de> wrote:
 On 03.05.2012 09:21, Michel D?nzer wrote:
>
> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> This convert fence to use uint64_t sequence number intention is
>> to use the fact that uin64_t is big enough that we don't need to
>> care about wrap around.
>>
>> Tested with and without writeback using 0xF000 as initial
>> fence sequence and thus allowing to test the wrap around from
>> 32bits to 64bits.
>>
>> Signed-off-by: Jerome Glisse
>
> [...]
>
>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
>> b/drivers/gpu/drm/radeon/radeon_fence.c
>> index 7733429..6da1535 100644
>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
>> radeon_device *rdev, int ring)
>> ? ? ? ? ? ? ? ? ? ? ? ?rdev->fence_drv[ring].scratch_reg -
>> ? ? ? ? ? ? ? ? ? ? ? ?rdev->scratch.reg_base;
>> ? ? ? ?}
>> - ? ? ? rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
>> + ? ? ? rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
>
> Might want to ensure cpu_addr is 64 bit aligned, or there might be
> trouble on some architectures.
>
>
> With this change, Cayman cards will already use six scratch registers
> for the rings. It won't be possible to extend this scheme for even one
> additional ring, will it?


 That won't work anyway, since not all rings can deal with 64 bit fences, so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.
>>>
>>> This patch is fine with ring that can't emit directly 64bits, all you
>>> have to do is fix the emit_fence callback to properly handle it and
>>> then you have to fix the radeon_fence_read which can be move to a ring
>>> specific callback. Anyway point is that patchset works and is fine on
>>> current set of ring we have and it can work as easily for ring without
>>> easy 64bits value emitting. So please explain further why those patch
>>> can't work because as i just explained i don't see why.
>>>
>>> I have updated some v2 version of those patchset to handle the cayman
>>> and newer possibly running out of scratch reg and i also fix the
>>> alignment issue to be 64bits
>>
>> FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
>> least), it's just memory writes so we could make the scratch pool
>> bigger.
>>
>> Alex
>>
>
> That's what my v2 does, just drop scratch reg for cayman and newer.
>
> Cheers,
> Jerome

Btw uploaded a v3 with some more thing like warnononce for extra
safety, better comment and trying to mitigate race btw cpu reading and
gpu writing fence.
http://people.freedesktop.org/~glisse/reset3/

Cheers,
Jerome

i915_driver_irq_handler: irq 42: nobody cared

[Ben Widawsky]

On Thu, 3 May 2012 14:54:22 -0700
Jesse Barnes  wrote:

> On Thu, 03 May 2012 23:16:02 +0200
> Jiri Slaby  wrote:
> 
> > On 05/03/2012 11:15 PM, Daniel Vetter wrote:
> > >>> Shot in the dark, let's disable msi a bit. Can you try the below patch?
> > >>
> > >> Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
> > >> busted, either in the card, the chipset or the kernel. Any idea how to
> > >> find out?
> > > 
> > > Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
> > 
> > Sure:
> > 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
> > Express Integrated Graphics Controller [8086:29c2] (rev 02)
> 
> Ok nevermind about the INTx-; now I'm not sure if it means anything or
> not in an MSI context (the spec doesn't require it, but I thought our
> devices would toggle it if they were sending interrupts).
> 
> But since line level works for you I guess it's ok to blacklist your
> chipset until we poke some hw folks internally about this.
> 
> Thanks,

I occassionally see missed IRQ on 16 (which is my USB) but it has only
started showing up in fairly recent dinq (haven't tried Linus') kernels
(I'd been using this laptop for over a year).


-- 
Ben Widawsky, Intel Open Source Technology Center

Enhancing EDID quirk functionality

[Adam Jackson]

On 5/3/12 2:01 PM, Ian Pilcher wrote:

> The patch does the following:

This looks good, thank you for taking it on.

> * Changes the vendor field of struct edid_quirk to an array, rather
>than a pointer.  (This has already been sent to the dri-devel list.)
> * Adds two new quirks EDID_QUIRK_DISABLE_INFOFRAMES and
>EDID_QUIRK_NO_AUDIO. This first quirk causes drm_detect_hdmi_monitor
>to return false; the second   causes drm_detect_monitor_audio to
>return false.
> * Logs the EDID vendor and model of connected monitors.
> * Adds an edid_quirks parameter to the drm module, for user-defined
>quirks.

I'd like to see documentation for the bit values of the quirks as well. 
And, ideally, this would also have some runtime API for manipulating the 
quirk list, so that way you can test new quirks without needing a reboot 
cycle.

To close the loop all the way on that I'd also want to be able to scrape 
the quirk list back out from that API, but that's not completely clean 
right now.  We're being a little cavalier with the quirk list as it 
stands because we don't differentiate among phy layers, and I can easily 
imagine a monitor that needs a quirk on DVI but where the same quirk on 
the same monitors' VGA would break it.  I don't think this has caused 
problems yet, but.

> With this patch, my display works when I add
> drm.edid_quirks=GSM:0x563f:0x180 to my kernel command line.  (0x80,
> EDID_QUIRK_DISABLE_INFOFRAMES, makes it work with the nouveau driver;
> 0x100, EDID_QUIRK_NO_AUDIO, makes it work with the i915 driver.  I.e.,
> the i915 driver is sending audio InfoFrames even when
> drm_detect_hdmi_monitor returns false; bug?)

InfoFrames are not valid for non-HDMI sinks, so yes, I'd call that a bug.

Your original bug report is a little strange, particularly:

https://bugzilla.redhat.com/attachment.cgi?id=572790

Where the EDID for DP-1 appears to be truncated: the "extension" field 
(second byte from the end) is 1 as you'd expect for an HDMI monitor, but 
there's no extension block.  How big of a file do you get from 
/sys/class/drm/*/edid for that port?

- ajax

[RFC v2 5/5] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/25/2012 03:45 AM, Thierry Reding wrote:
> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> currently has rudimentary GEM support and can run a console on the
> framebuffer as well as X using the xf86-video-modesetting driver. Only
> the RGB output is supported.
> 
> HDMI support was taken from NVIDIA's Linux kernel tree but it doesn't
> quite work. EDID data can be retrieved but the output doesn't properly
> activate the connected TV.
> 
> The DSI and TVO outputs and the HOST1X driver are just stubs that setup
> the corresponding resources but don't do anything useful yet.

I'm mainly going to comment on the device tree bindings here; hopefully
Jon and Terje can chime in on the code itself.

> diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt 
> b/Documentation/devicetree/bindings/gpu/drm/tegra.txt

> +Example:
> +
> +/memreserve/ 0x0e00 0x0200;
> +
> +...
> +
> +/ {
> + ...
> +
> + /* host1x */
> + host1x: host1x at 5000 {
> + compatible = "nvidia,tegra20-host1x";
> + reg = <0x5000 0x00024000>;
> + interrupts = <0 64 0x04   /* cop syncpt */
> +   0 65 0x04   /* mpcore syncpt */
> +   0 66 0x04   /* cop general */
> +   0 67 0x04>; /* mpcore general */
> + };

The host1x module is apparently a register bus, behind which all the
other modules sit. According to the address map in the TRM, "all the
other modules" appears to include all of MPE, VI, CSI, EPP, ISP, GR2D,
GR3D, DISPLAY A/B, HDMI, TVO, DSI, plus VG, VS, VCI, DSIB on Tegra30.

That said, I believe Terje wasn't convinced that all those modules are
really host1x children, just some. Can you check please, Terje?

Also, I wonder if host1x is really the parent of these modules,
register-bus-access-wise, or whether the bus covers the "graphic host
registers" at 0x5000-0x50023fff?

As such, I think the DT nodes for all those modules should be within the
host1x node (or perhaps graphics host node, pending above discussion):

host1x: host1x at 5000 {
mpe at 5404 { ... };
vi at 5408 { ... };
...
};

host1x can easily instantiate all the child nodes simply by calling
of_platform_populate() at the end of its probe; see
sound/soc/tegra/tegra30_ahub.c for an example.

> + /* video-encoding/decoding */
> + mpe at 5404 {
> + reg = <0x5404 0x0004>;
> + interrupts = <0 68 0x04>;
> + };

We'll probably end up needing a phandle from each of these nodes to
host1x, and a channel ID, so the drivers for these nodes can register
themselves with host1x. However, I it's probably OK to defer the DT
binding for this until we actually start working on command-channels.

> + /* graphics host */
> + graphics at 5400 {
> + compatible = "nvidia,tegra20-graphics";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;

I don't think those 3 properties are needed, unless there are child
nodes with registers.

> + display-controllers = < >;
> + carveout = <0x0e00 0x0200>;
> + host1x = <>;
> + gart = <>;
> +
> + connectors {

I'm not sure that it makes sense to put the connectors nodes underneath
the graphics host node; the connectors aren't objects with registers
that are accessed through a bus managed by the graphics node. Equally,
the connectors could be useful outside of the graphics driver - e.g. the
audio driver might need to refer to an HDMI connector.

Instead, I'd probably put the connector nodes at the top level of the
device tree, and have graphics contain a property that lists the
phandles of all available connectors.

> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + connector at 0 {
> + reg = <0>;
> + edid = /incbin/("machine.edid");
> + output = <>;
> + };

I think each of these needs some kind of compatible value to indicate
their type. Also, the ability to represent both HDMI video and audio
streams so that a sound card binding could use the HDMI connector too. I
see that drivers/extcon/ has appeared recently, and I wonder if the
connector nodes in DT shouldn't be handled by that subsystem?

> + connector at 1 {
> + reg = <1>;
> + output = <>;
> + ddc = <>;
> +
> + hpd-gpio = < 111 0>; /* PN7 */
> + };
> + };
> + };
> +};

> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c 
> b/arch/arm/mach-tegra/board-dt-tegra20.c

> + { "host1x", "pll_c",14400,  true },
> + { "disp1",  "pll_p",

PROBLEM: [drm:r600_do_init_cp] *ERROR* Failed to load firmware!

[Michel Dänzer]

On Don, 2012-05-03 at 09:32 +0200, Treeve Jelbert wrote: 
> On Monday 23 April 2012 11:18:52 you wrote:
> > Linux-3.3.3
> > 
> > $ dmesg|grep drm
> > [drm] Initialized drm 1.1.0 20060810
> > [drm] radeon defaulting to userspace modesetting.
> > [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> > [drm] No driver support for vblank timestamp query.
> > [drm] Initialized radeon 1.33.0 20080528 for :02:00.0 on minor 0
> > [drm] Setting GART location based on new memory map
> > [drm] Loading RV730 CP Microcode
> > [drm:r600_do_init_cp] *ERROR* Failed to load firmware!
> > 
> > 
> > 
> 
> I have now booted using radeon.modeset=0
> and then manually doing 'modprobe radeon  modeset=1'
> 
> 
> this gives the following messages on linux-3.3.4. The error message is now 
> different, but it still fails.

Odd. I suppose it really couldn't hurt talking to udev people for
tracking down why it's failing.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

i915_driver_irq_handler: irq 42: nobody cared

[Jesse Barnes]

On Thu, 03 May 2012 23:16:02 +0200
Jiri Slaby  wrote:

> On 05/03/2012 11:15 PM, Daniel Vetter wrote:
> >>> Shot in the dark, let's disable msi a bit. Can you try the below patch?
> >>
> >> Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
> >> busted, either in the card, the chipset or the kernel. Any idea how to
> >> find out?
> > 
> > Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
> 
> Sure:
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
> Express Integrated Graphics Controller [8086:29c2] (rev 02)

Ok nevermind about the INTx-; now I'm not sure if it means anything or
not in an MSI context (the spec doesn't require it, but I thought our
devices would toggle it if they were sending interrupts).

But since line level works for you I guess it's ok to blacklist your
chipset until we poke some hw folks internally about this.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH] drm/radeon: fix possible lack of synchronization btw ttm and other ring

[Alex Deucher]

On Thu, May 3, 2012 at 1:44 PM,   wrote:
> From: Jerome Glisse 
>
> We need to sync with the GFX ring as ttm might have schedule bo move
> on it and new command scheduled for other ring need to wait for bo
> data to be in place.
>
> Signed-off-by: Jerome Glisse 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/radeon_cs.c | ? 12 ++--
> ?include/drm/radeon_drm.h ? ? ? ? ? | ? ?1 -
> ?2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 82f2e7b0..e5f8e17 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -122,15 +122,15 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser 
> *p)
> ? ? ? ?int i, r;
>
> ? ? ? ?for (i = 0; i < p->nrelocs; i++) {
> + ? ? ? ? ? ? ? struct radeon_fence *fence;
> +
> ? ? ? ? ? ? ? ?if (!p->relocs[i].robj || !p->relocs[i].robj->tbo.sync_obj)
> ? ? ? ? ? ? ? ? ? ? ? ?continue;
>
> - ? ? ? ? ? ? ? if (!(p->relocs[i].flags & RADEON_RELOC_DONT_SYNC)) {
> - ? ? ? ? ? ? ? ? ? ? ? struct radeon_fence *fence = 
> p->relocs[i].robj->tbo.sync_obj;
> - ? ? ? ? ? ? ? ? ? ? ? if (fence->ring != p->ring && 
> !radeon_fence_signaled(fence)) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sync_to_ring[fence->ring] = true;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? need_sync = true;
> - ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? fence = p->relocs[i].robj->tbo.sync_obj;
> + ? ? ? ? ? ? ? if (fence->ring != p->ring && !radeon_fence_signaled(fence)) {
> + ? ? ? ? ? ? ? ? ? ? ? sync_to_ring[fence->ring] = true;
> + ? ? ? ? ? ? ? ? ? ? ? need_sync = true;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 7c491b4..5805686 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -926,7 +926,6 @@ struct drm_radeon_cs_chunk {
> ?};
>
> ?/* drm_radeon_cs_reloc.flags */
> -#define RADEON_RELOC_DONT_SYNC ? ? ? ? 0x01
>
> ?struct drm_radeon_cs_reloc {
> ? ? ? ?uint32_t ? ? ? ? ? ? ? ?handle;
> --
> 1.7.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix possible lack of synchronization btw ttm and other ring

[j.gli...@gmail.com]

From: Jerome Glisse 

We need to sync with the GFX ring as ttm might have schedule bo move
on it and new command scheduled for other ring need to wait for bo
data to be in place.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_cs.c |   12 ++--
 include/drm/radeon_drm.h   |1 -
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 82f2e7b0..e5f8e17 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -122,15 +122,15 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser 
*p)
int i, r;

for (i = 0; i < p->nrelocs; i++) {
+   struct radeon_fence *fence;
+
if (!p->relocs[i].robj || !p->relocs[i].robj->tbo.sync_obj)
continue;

-   if (!(p->relocs[i].flags & RADEON_RELOC_DONT_SYNC)) {
-   struct radeon_fence *fence = 
p->relocs[i].robj->tbo.sync_obj;
-   if (fence->ring != p->ring && 
!radeon_fence_signaled(fence)) {
-   sync_to_ring[fence->ring] = true;
-   need_sync = true;
-   }
+   fence = p->relocs[i].robj->tbo.sync_obj;
+   if (fence->ring != p->ring && !radeon_fence_signaled(fence)) {
+   sync_to_ring[fence->ring] = true;
+   need_sync = true;
}
}

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 7c491b4..5805686 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -926,7 +926,6 @@ struct drm_radeon_cs_chunk {
 };

 /* drm_radeon_cs_reloc.flags */
-#define RADEON_RELOC_DONT_SYNC 0x01

 struct drm_radeon_cs_reloc {
uint32_thandle;
-- 
1.7.7.6

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Christian König]

On 03.05.2012 09:21, Michel D?nzer wrote:
> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:
>> From: Jerome Glisse
>>
>> This convert fence to use uint64_t sequence number intention is
>> to use the fact that uin64_t is big enough that we don't need to
>> care about wrap around.
>>
>> Tested with and without writeback using 0xF000 as initial
>> fence sequence and thus allowing to test the wrap around from
>> 32bits to 64bits.
>>
>> Signed-off-by: Jerome Glisse
> [...]
>
>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
>> b/drivers/gpu/drm/radeon/radeon_fence.c
>> index 7733429..6da1535 100644
>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct radeon_device 
>> *rdev, int ring)
>>  rdev->fence_drv[ring].scratch_reg -
>>  rdev->scratch.reg_base;
>>  }
>> -rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
>> +rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
> Might want to ensure cpu_addr is 64 bit aligned, or there might be
> trouble on some architectures.
>
>
> With this change, Cayman cards will already use six scratch registers
> for the rings. It won't be possible to extend this scheme for even one
> additional ring, will it?

That won't work anyway, since not all rings can deal with 64 bit fences, 
so we need to still use 32 bit signaling and extend them to 64 bit while 
processing the fence value.

Already working on that.

Christian.

Include request for reset-rework branch v4

[Alex Deucher]

2012/5/3 Christian K?nig :
> On 03.05.2012 19:20, Alex Deucher wrote:
>>
>> 2012/5/3 Jerome Glisse:
>>>
>>> On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
>>>  ?wrote:

 On 03.05.2012 18:32, Jerome Glisse wrote:
>
> On Thu, May 3, 2012 at 4:19 AM, Christian
> K?nig
> ?wrote:
>>
>> On 02.05.2012 18:01, Jerome Glisse wrote:
>>>
>>> On Wed, May 2, 2012 at 9:11 AM, Christian
>>> K?nig
>>> ?wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about
 the
 SA
 code,
 so I again split that out of the patchset and tested the result a
 bit.

 Most of the stuff still works fine without those offending changes,
 so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

>>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17
>>> that
>>> bring back some other of the previous cleanup.
>>
>> At least for now those three are NAK, cause I just realized we need to
>> put
>> those on top of a more sophisticated fence implementation.
>>
>> Your idea of not using a list, but 64 bit sequences instead actually
>> sounds
>> quite nifty to me. Going to hack something together in the next couple
>> of
>> hours.
>>
>> Christian.
>
> Btw you said that you are having issue when using multiple ring, it
> comes to my attention that you never sync with the GFX ring (unless
> asked by userspace) that's wrong, before scheduling on another ring
> than GFX index you need to emit semaphore to make the ring wait for
> the last emited fence on the GFX ring because of ttm. What might
> happen is that ttm scheduled bo move on the GFX ring and that the ring
> you work on start using those bo at there soon to be GPU offset while
> the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that
 issue..


 We set the sync_obj to the fence of the move operation, so when there is
 a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.

>>> Looking at code doesn't seems ok, yes you use the fence from the move
>>> operation but you only emit wait if userspace ask for it, that's
>>> wrong.
>>>
>>> if (!(p->relocs[i].flags& ?RADEON_RELOC_DONT_SYNC)) {
>>>
>> The default is to sync all the rings. ?We only skip the sync if the
>> _DONT_ sync flag is set.
>
> Yeah, but the _DONT_ sync flag is just an optimization, and we only want to
> not sync to things userspace has submitted.
>
> ?E.g. userspace tells us that two jobs can happily run on the same bo even
> if they are both writing to it
>
> So Jerome is completely right, userspace doesn't expect that TTM is jumping
> in between and moving the bo around, that is indeed a bug and another thing
> for the todo list.

Ah, yes, that makes sense.  I misinterpreted the original comment.

Alex

Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 1:28 PM, Christian K?nig  
wrote:
> On 03.05.2012 19:20, Alex Deucher wrote:
>>
>> 2012/5/3 Jerome Glisse:
>>>
>>> On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
>>>  ?wrote:

 On 03.05.2012 18:32, Jerome Glisse wrote:
>
> On Thu, May 3, 2012 at 4:19 AM, Christian
> K?nig
> ?wrote:
>>
>> On 02.05.2012 18:01, Jerome Glisse wrote:
>>>
>>> On Wed, May 2, 2012 at 9:11 AM, Christian
>>> K?nig
>>> ?wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about
 the
 SA
 code,
 so I again split that out of the patchset and tested the result a
 bit.

 Most of the stuff still works fine without those offending changes,
 so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

>>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17
>>> that
>>> bring back some other of the previous cleanup.
>>
>> At least for now those three are NAK, cause I just realized we need to
>> put
>> those on top of a more sophisticated fence implementation.
>>
>> Your idea of not using a list, but 64 bit sequences instead actually
>> sounds
>> quite nifty to me. Going to hack something together in the next couple
>> of
>> hours.
>>
>> Christian.
>
> Btw you said that you are having issue when using multiple ring, it
> comes to my attention that you never sync with the GFX ring (unless
> asked by userspace) that's wrong, before scheduling on another ring
> than GFX index you need to emit semaphore to make the ring wait for
> the last emited fence on the GFX ring because of ttm. What might
> happen is that ttm scheduled bo move on the GFX ring and that the ring
> you work on start using those bo at there soon to be GPU offset while
> the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that
 issue..


 We set the sync_obj to the fence of the move operation, so when there is
 a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.

>>> Looking at code doesn't seems ok, yes you use the fence from the move
>>> operation but you only emit wait if userspace ask for it, that's
>>> wrong.
>>>
>>> if (!(p->relocs[i].flags& ?RADEON_RELOC_DONT_SYNC)) {
>>>
>> The default is to sync all the rings. ?We only skip the sync if the
>> _DONT_ sync flag is set.
>
> Yeah, but the _DONT_ sync flag is just an optimization, and we only want to
> not sync to things userspace has submitted.
>
> ?E.g. userspace tells us that two jobs can happily run on the same bo even
> if they are both writing to it
>
> So Jerome is completely right, userspace doesn't expect that TTM is jumping
> in between and moving the bo around, that is indeed a bug and another thing
> for the todo list.
>
> Christian.

Well until userspace can tell kernel on which fence it wants to wait i
believe this flags become obsolete and can be remove, i am pretty no
release userspace code ever used that flags.

Cheers,
Jerome

[PATCH libdrm 4/4] modetest: print more about our properties

[Daniel Vetter]

On Sat, Apr 21, 2012 at 05:51:53PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni 
> 
> In the future we'll have more than just connector properties, so create
> a dump_prop function that can handle any property (instead of the
> current dump_props function that only handles connector properties).
> 
> Also, make this function print a lot more information about the existing
> properties.
> 
> Also change the printed indentation of the modes to make the output more
> readable.
> 
> The previous function dump_props also segfaulted when we didn't have
> enought permissions. The new function does not segfault in this case (by
> checking for the return value of drmModeGetProperty).
> 
> Reviewed-by: Eugeni Dodonov 
> Signed-off-by: Paulo Zanoni 

Looks like this series here has been lost a bit. I've pushed all 4
patches, thanks.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 1:20 PM, Alex Deucher  wrote:
> 2012/5/3 Jerome Glisse :
>> On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
>>  wrote:
>>> On 03.05.2012 18:32, Jerome Glisse wrote:

 On Thu, May 3, 2012 at 4:19 AM, Christian K?nig
 ?wrote:
>
> On 02.05.2012 18:01, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig> vodafone.de>
>> ?wrote:
>>>
>>> Hi Dave,
>>>
>>> there still seems to be the need for some further discussion about the
>>> SA
>>> code,
>>> so I again split that out of the patchset and tested the result a bit.
>>>
>>> Most of the stuff still works fine without those offending changes, so
>>> to
>>> avoid
>>> mailing around unrelated and already reviewed patches, I request the
>>> include
>>> the following 17 patches into drm-next.
>>>
>>> If you prefer to merge they are also available from
>>> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>>>
>>> Cheers,
>>> Christian.
>>>
>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17
>> that
>> bring back some other of the previous cleanup.
>
> At least for now those three are NAK, cause I just realized we need to
> put
> those on top of a more sophisticated fence implementation.
>
> Your idea of not using a list, but 64 bit sequences instead actually
> sounds
> quite nifty to me. Going to hack something together in the next couple of
> hours.
>
> Christian.

 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.
>>>
>>> Yeah, already stumbled over that but IIRC Alex already solved that issue.
>>>
>>> We set the sync_obj to the fence of the move operation, so when there is a
>>> move operation in progress we sync to it correctly (at least I hope so).
>>>
>>> Christian.
>>>
>>
>> Looking at code doesn't seems ok, yes you use the fence from the move
>> operation but you only emit wait if userspace ask for it, that's
>> wrong.
>>
>> if (!(p->relocs[i].flags & RADEON_RELOC_DONT_SYNC)) {
>>
>
> The default is to sync all the rings. ?We only skip the sync if the
> _DONT_ sync flag is set.
>
> Alex
>

That's my point exactly, so if a bo move happen and userspace set dont
sync flag then the other ring might start doing work before bo data is
in place. This test should be removed or at least make the sync to the
bo move fence unconditional and use this flag only for sync with other
ring relative to current job you are scheduling.

Cheers,
Jerome

Include request for reset-rework branch v4

[Alex Deucher]

2012/5/3 Jerome Glisse :
> On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
>  wrote:
>> On 03.05.2012 18:32, Jerome Glisse wrote:
>>>
>>> On Thu, May 3, 2012 at 4:19 AM, Christian K?nig
>>> ?wrote:

 On 02.05.2012 18:01, Jerome Glisse wrote:
>
> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig vodafone.de>
> ?wrote:
>>
>> Hi Dave,
>>
>> there still seems to be the need for some further discussion about the
>> SA
>> code,
>> so I again split that out of the patchset and tested the result a bit.
>>
>> Most of the stuff still works fine without those offending changes, so
>> to
>> avoid
>> mailing around unrelated and already reviewed patches, I request the
>> include
>> the following 17 patches into drm-next.
>>
>> If you prefer to merge they are also available from
>> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>>
>> Cheers,
>> Christian.
>>
> I am ok with this 17 patchset, i just sent 3 patch on top of those 17
> that
> bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to
 put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually
 sounds
 quite nifty to me. Going to hack something together in the next couple of
 hours.

 Christian.
>>>
>>> Btw you said that you are having issue when using multiple ring, it
>>> comes to my attention that you never sync with the GFX ring (unless
>>> asked by userspace) that's wrong, before scheduling on another ring
>>> than GFX index you need to emit semaphore to make the ring wait for
>>> the last emited fence on the GFX ring because of ttm. What might
>>> happen is that ttm scheduled bo move on the GFX ring and that the ring
>>> you work on start using those bo at there soon to be GPU offset while
>>> the bo data is not there yet.
>>
>> Yeah, already stumbled over that but IIRC Alex already solved that issue.
>>
>> We set the sync_obj to the fence of the move operation, so when there is a
>> move operation in progress we sync to it correctly (at least I hope so).
>>
>> Christian.
>>
>
> Looking at code doesn't seems ok, yes you use the fence from the move
> operation but you only emit wait if userspace ask for it, that's
> wrong.
>
> if (!(p->relocs[i].flags & RADEON_RELOC_DONT_SYNC)) {
>

The default is to sync all the rings.  We only skip the sync if the
_DONT_ sync flag is set.

Alex

> in radeon_cs.c
>
> Cheers,
> Jerome

Enhancing EDID quirk functionality

[Ian Pilcher]

I just attached this patch to
https://bugzilla.redhat.com/show_bug.cgi?id=806091, along with the
following comments:

This is the "first draft" of an EDID quirk-based approach to solving
this problem.  I intend to perform a bit of cleanup and break it up
into a series of separate patches, but I'm posting it here for any
comments about the approach.

The patch does the following:

* Changes the vendor field of struct edid_quirk to an array, rather
  than a pointer.  (This has already been sent to the dri-devel list.)
* Adds two new quirks EDID_QUIRK_DISABLE_INFOFRAMES and
  EDID_QUIRK_NO_AUDIO. This first quirk causes drm_detect_hdmi_monitor
  to return false; the second   causes drm_detect_monitor_audio to
  return false.
* Logs the EDID vendor and model of connected monitors.
* Adds an edid_quirks parameter to the drm module, for user-defined
  quirks.

With this patch, my display works when I add
drm.edid_quirks=GSM:0x563f:0x180 to my kernel command line.  (0x80,
EDID_QUIRK_DISABLE_INFOFRAMES, makes it work with the nouveau driver;
0x100, EDID_QUIRK_NO_AUDIO, makes it work with the i915 driver.  I.e.,
the i915 driver is sending audio InfoFrames even when
drm_detect_hdmi_monitor returns false; bug?)

Thoughts?

-- 

Ian Pilcher arequipeno at gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."

-- next part --
A non-text attachment was scrubbed...
Name: edid_quirks_all.patch
Type: text/x-patch
Size: 9610 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120503/13c5436e/attachment-0001.bin>

Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 12:39 PM, Christian K?nig
 wrote:
> On 03.05.2012 18:32, Jerome Glisse wrote:
>>
>> On Thu, May 3, 2012 at 4:19 AM, Christian K?nig
>> ?wrote:
>>>
>>> On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian K?nig
 ?wrote:
>
> Hi Dave,
>
> there still seems to be the need for some further discussion about the
> SA
> code,
> so I again split that out of the patchset and tested the result a bit.
>
> Most of the stuff still works fine without those offending changes, so
> to
> avoid
> mailing around unrelated and already reviewed patches, I request the
> include
> the following 17 patches into drm-next.
>
> If you prefer to merge they are also available from
> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>
> Cheers,
> Christian.
>
 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.
>>>
>>> At least for now those three are NAK, cause I just realized we need to
>>> put
>>> those on top of a more sophisticated fence implementation.
>>>
>>> Your idea of not using a list, but 64 bit sequences instead actually
>>> sounds
>>> quite nifty to me. Going to hack something together in the next couple of
>>> hours.
>>>
>>> Christian.
>>
>> Btw you said that you are having issue when using multiple ring, it
>> comes to my attention that you never sync with the GFX ring (unless
>> asked by userspace) that's wrong, before scheduling on another ring
>> than GFX index you need to emit semaphore to make the ring wait for
>> the last emited fence on the GFX ring because of ttm. What might
>> happen is that ttm scheduled bo move on the GFX ring and that the ring
>> you work on start using those bo at there soon to be GPU offset while
>> the bo data is not there yet.
>
> Yeah, already stumbled over that but IIRC Alex already solved that issue.
>
> We set the sync_obj to the fence of the move operation, so when there is a
> move operation in progress we sync to it correctly (at least I hope so).
>
> Christian.
>

Looking at code doesn't seems ok, yes you use the fence from the move
operation but you only emit wait if userspace ask for it, that's
wrong.

if (!(p->relocs[i].flags & RADEON_RELOC_DONT_SYNC)) {

in radeon_cs.c

Cheers,
Jerome

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 12:29 PM, Alex Deucher  wrote:
> On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse  wrote:
>> On Thu, May 3, 2012 at 7:39 AM, Christian K?nig  
>> wrote:
>>> On 03.05.2012 09:21, Michel D?nzer wrote:

 On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:
>
> From: Jerome Glisse
>
> This convert fence to use uint64_t sequence number intention is
> to use the fact that uin64_t is big enough that we don't need to
> care about wrap around.
>
> Tested with and without writeback using 0xF000 as initial
> fence sequence and thus allowing to test the wrap around from
> 32bits to 64bits.
>
> Signed-off-by: Jerome Glisse

 [...]

> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 7733429..6da1535 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
> radeon_device *rdev, int ring)
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->fence_drv[ring].scratch_reg -
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->scratch.reg_base;
> ? ? ? ?}
> - ? ? ? rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
> + ? ? ? rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];

 Might want to ensure cpu_addr is 64 bit aligned, or there might be
 trouble on some architectures.


 With this change, Cayman cards will already use six scratch registers
 for the rings. It won't be possible to extend this scheme for even one
 additional ring, will it?
>>>
>>>
>>> That won't work anyway, since not all rings can deal with 64 bit fences, so
>>> we need to still use 32 bit signaling and extend them to 64 bit while
>>> processing the fence value.
>>>
>>> Already working on that.
>>>
>>> Christian.
>>
>> This patch is fine with ring that can't emit directly 64bits, all you
>> have to do is fix the emit_fence callback to properly handle it and
>> then you have to fix the radeon_fence_read which can be move to a ring
>> specific callback. Anyway point is that patchset works and is fine on
>> current set of ring we have and it can work as easily for ring without
>> easy 64bits value emitting. So please explain further why those patch
>> can't work because as i just explained i don't see why.
>>
>> I have updated some v2 version of those patchset to handle the cayman
>> and newer possibly running out of scratch reg and i also fix the
>> alignment issue to be 64bits
>
> FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
> least), it's just memory writes so we could make the scratch pool
> bigger.
>
> Alex
>

That's what my v2 does, just drop scratch reg for cayman and newer.

Cheers,
Jerome

Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 4:19 AM, Christian K?nig  
wrote:
> On 02.05.2012 18:01, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig
>> ?wrote:
>>>
>>> Hi Dave,
>>>
>>> there still seems to be the need for some further discussion about the SA
>>> code,
>>> so I again split that out of the patchset and tested the result a bit.
>>>
>>> Most of the stuff still works fine without those offending changes, so to
>>> avoid
>>> mailing around unrelated and already reviewed patches, I request the
>>> include
>>> the following 17 patches into drm-next.
>>>
>>> If you prefer to merge they are also available from
>>> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>>>
>>> Cheers,
>>> Christian.
>>>
>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
>> bring back some other of the previous cleanup.
>
> At least for now those three are NAK, cause I just realized we need to put
> those on top of a more sophisticated fence implementation.
>
> Your idea of not using a list, but 64 bit sequences instead actually sounds
> quite nifty to me. Going to hack something together in the next couple of
> hours.
>
> Christian.

Btw you said that you are having issue when using multiple ring, it
comes to my attention that you never sync with the GFX ring (unless
asked by userspace) that's wrong, before scheduling on another ring
than GFX index you need to emit semaphore to make the ring wait for
the last emited fence on the GFX ring because of ttm. What might
happen is that ttm scheduled bo move on the GFX ring and that the ring
you work on start using those bo at there soon to be GPU offset while
the bo data is not there yet.

Cheers,
Jerome

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Alex Deucher]

On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse  wrote:
> On Thu, May 3, 2012 at 7:39 AM, Christian K?nig  
> wrote:
>> On 03.05.2012 09:21, Michel D?nzer wrote:
>>>
>>> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:

 From: Jerome Glisse

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glisse
>>>
>>> [...]
>>>
 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
 ? ? ? ? ? ? ? ? ? ? ? ?rdev->fence_drv[ring].scratch_reg -
 ? ? ? ? ? ? ? ? ? ? ? ?rdev->scratch.reg_base;
 ? ? ? ?}
 - ? ? ? rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
 + ? ? ? rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
>>>
>>> Might want to ensure cpu_addr is 64 bit aligned, or there might be
>>> trouble on some architectures.
>>>
>>>
>>> With this change, Cayman cards will already use six scratch registers
>>> for the rings. It won't be possible to extend this scheme for even one
>>> additional ring, will it?
>>
>>
>> That won't work anyway, since not all rings can deal with 64 bit fences, so
>> we need to still use 32 bit signaling and extend them to 64 bit while
>> processing the fence value.
>>
>> Already working on that.
>>
>> Christian.
>
> This patch is fine with ring that can't emit directly 64bits, all you
> have to do is fix the emit_fence callback to properly handle it and
> then you have to fix the radeon_fence_read which can be move to a ring
> specific callback. Anyway point is that patchset works and is fine on
> current set of ring we have and it can work as easily for ring without
> easy 64bits value emitting. So please explain further why those patch
> can't work because as i just explained i don't see why.
>
> I have updated some v2 version of those patchset to handle the cayman
> and newer possibly running out of scratch reg and i also fix the
> alignment issue to be 64bits

FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
least), it's just memory writes so we could make the scratch pool
bigger.

Alex

> http://people.freedesktop.org/~glisse/reset3/
>
> Cheers,
> Jerome
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #60960|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #60959|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops

[Mark Brown]

The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.

Also remove the suspend function since all it does is log.

Signed-off-by: Mark Brown 
Acked-by: Francisco Jerez 
---
 drivers/gpu/drm/i2c/ch7006_drv.c |   16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..74ad254 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
 }

-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
 {
-   ch7006_dbg(client, "\n");
-
-   return 0;
-}
+   struct i2c_client *client = to_i2c_device(dev);

-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, "\n");

ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ch7006_ids);

+static const struct dev_pm_ops ch7006_pm_ops = {
+   .resume = ch7006_resume,
+};
+
 static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
-   .suspend = ch7006_suspend,
-   .resume = ch7006_resume,

.driver = {
.name = "ch7006",
+   .pm = _pm_ops,
},

.id_table = ch7006_ids,
-- 
1.7.10

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 7:39 AM, Christian K?nig  
wrote:
> On 03.05.2012 09:21, Michel D?nzer wrote:
>>
>> On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> This convert fence to use uint64_t sequence number intention is
>>> to use the fact that uin64_t is big enough that we don't need to
>>> care about wrap around.
>>>
>>> Tested with and without writeback using 0xF000 as initial
>>> fence sequence and thus allowing to test the wrap around from
>>> 32bits to 64bits.
>>>
>>> Signed-off-by: Jerome Glisse
>>
>> [...]
>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
>>> b/drivers/gpu/drm/radeon/radeon_fence.c
>>> index 7733429..6da1535 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_fence.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
>>> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
>>> radeon_device *rdev, int ring)
>>> ? ? ? ? ? ? ? ? ? ? ? ?rdev->fence_drv[ring].scratch_reg -
>>> ? ? ? ? ? ? ? ? ? ? ? ?rdev->scratch.reg_base;
>>> ? ? ? ?}
>>> - ? ? ? rdev->fence_drv[ring].cpu_addr =rdev->wb.wb[index/4];
>>> + ? ? ? rdev->fence_drv[ring].cpu_addr =u64*)>wb.wb[index/4];
>>
>> Might want to ensure cpu_addr is 64 bit aligned, or there might be
>> trouble on some architectures.
>>
>>
>> With this change, Cayman cards will already use six scratch registers
>> for the rings. It won't be possible to extend this scheme for even one
>> additional ring, will it?
>
>
> That won't work anyway, since not all rings can deal with 64 bit fences, so
> we need to still use 32 bit signaling and extend them to 64 bit while
> processing the fence value.
>
> Already working on that.
>
> Christian.

This patch is fine with ring that can't emit directly 64bits, all you
have to do is fix the emit_fence callback to properly handle it and
then you have to fix the radeon_fence_read which can be move to a ring
specific callback. Anyway point is that patchset works and is fine on
current set of ring we have and it can work as easily for ring without
easy 64bits value emitting. So please explain further why those patch
can't work because as i just explained i don't see why.

I have updated some v2 version of those patchset to handle the cayman
and newer possibly running out of scratch reg and i also fix the
alignment issue to be 64bits
http://people.freedesktop.org/~glisse/reset3/

Cheers,
Jerome

[PATCH 4/4] drm/i915: make DBLCLK modes work

[Daniel Vetter]

On Fri, Apr 13, 2012 at 04:31:41PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni 
>
> They require an AVI InfoFrame with a proper Pixel Repetition field.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
> Signed-off-by: Paulo Zanoni 

I've merged the 2 i915 patches for -next, thanks.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup

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

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


Yvon TANGUY  changed:

   What|Removed |Added

 CC||vono29 at gmail.com




--- Comment #14 from Yvon TANGUY   2012-05-03 11:17:41 ---
I'm affected with the same problem, I've log a bug report on launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986524). Don't know if it
will help.

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

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

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

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

--- Comment #3 from Bastien Dejean  2012-05-03 03:57:32 
PDT ---
Created attachment 60960
  --> https://bugs.freedesktop.org/attachment.cgi?id=60960
dmesg BIOS mode output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

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

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

--- Comment #2 from Bastien Dejean  2012-05-03 03:56:40 
PDT ---
Created attachment 60959
  --> https://bugs.freedesktop.org/attachment.cgi?id=60959
dmesg EFI mode output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Include request for reset-rework branch v4

[Christian König]

On 02.05.2012 18:01, Jerome Glisse wrote:
> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig  
> wrote:
>> Hi Dave,
>>
>> there still seems to be the need for some further discussion about the SA 
>> code,
>> so I again split that out of the patchset and tested the result a bit.
>>
>> Most of the stuff still works fine without those offending changes, so to 
>> avoid
>> mailing around unrelated and already reviewed patches, I request the include
>> the following 17 patches into drm-next.
>>
>> If you prefer to merge they are also available from
>> git://people.freedesktop.org/~deathsimple/linux branch reset-rework.
>>
>> Cheers,
>> Christian.
>>
> I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
> bring back some other of the previous cleanup.
At least for now those three are NAK, cause I just realized we need to 
put those on top of a more sophisticated fence implementation.

Your idea of not using a list, but 64 bit sequences instead actually 
sounds quite nifty to me. Going to hack something together in the next 
couple of hours.

Christian.

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

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

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

--- Comment #6 from Vadim Girlin  2012-05-03 03:16:19 PDT 
---
(In reply to comment #5)
> > vec3 p3 = vec3(p.x, p.y, p.z);
> > float t = dot(v, p3);
> > float t2 = gm1*t/v2 - g*p.w;
> > r = vec4( v*t2 + p3, g * (p.w - t));
> > 
> 
> Vadim, this is really great and much appreciated. I went through the steps and
> it all seems fine to me, also tested some examples and everything works great.
> This also makes the advanced path in the shader work again without my quirky
> workarounds in the while loop. I never really took much care with these kind 
> of
> optimisations, somehow blindly hoping that the compiler will automagically
> optimise everything. I'll try to be more careful in advance.
> 
> I'd like to put some comments in the code, like "optimised by Vadim" if that's
> ok with you or perhaps should I use your real name? Thanks.

Ah, yes, I forgot to set my full name in the account here. Updated now, so you
can use it if you want.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

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

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

Michel D?nzer  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  QAContact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #1 from Michel D?nzer  2012-05-03 03:03:24 
PDT ---
Please attach the dmesg output.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm nouveau fixes

[Dave Airlie]

Hi Linus,

just some regression fixes from Ben along with a variable that gcc failed 
to spot is uninitialised.

Dave.

The following changes since commit 655861e328cea83320190f4a57b3656ee952388c:

  Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm (2012-04-30 
15:34:41 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Ben Skeggs (3):
  drm/nouveau/bios: fix regression on some nv4x board
  drm/nouveau/hdmi: use correct hdmi regs for nvaa/nvac
  drm/nv10/gpio: fix thinko in mask for gpio lines 2-9

Christoph Bumiller (1):
  nvc0/fb: shut up PMFB interrupt after the first occurrence

Dave Airlie (2):
  Merge branch 'drm-nouveau-fixes' of 
git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  nouveau: initialise has_optimus variable.

 drivers/gpu/drm/nouveau/nouveau_acpi.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_bios.c |   10 +++---
 drivers/gpu/drm/nouveau/nouveau_hdmi.c |4 +++-
 drivers/gpu/drm/nouveau/nv10_gpio.c|2 +-
 drivers/gpu/drm/nouveau/nvc0_fb.c  |5 +
 5 files changed, 17 insertions(+), 6 deletions(-)

PROBLEM: [drm:r600_do_init_cp] *ERROR* Failed to load firmware!

[Treeve Jelbert]

On Monday 23 April 2012 11:18:52 you wrote:
> Linux-3.3.3
> 
> $ dmesg|grep drm
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon defaulting to userspace modesetting.
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] No driver support for vblank timestamp query.
> [drm] Initialized radeon 1.33.0 20080528 for :02:00.0 on minor 0
> [drm] Setting GART location based on new memory map
> [drm] Loading RV730 CP Microcode
> [drm:r600_do_init_cp] *ERROR* Failed to load firmware!
> 
> 
> 

I have now booted using radeon.modeset=0
and then manually doing 'modprobe radeon  modeset=1'


this gives the following messages on linux-3.3.4. The error message is now 
different, but it still fails.
The file /lib/firmware/radeon/RV730_pfp.bin exists
There are message about rv730/rv770



[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
[drm] initializing kernel modesetting (RV730 0x1002:0x9498 0x1787:0x2269).
[drm] register mmio base: 0xF300
[drm] register mmio size: 65536
ATOM BIOS: 88209JCA.EFK
radeon :02:00.0: VRAM: 512M 0x - 0x1FFF (512M 
used)
radeon :02:00.0: GTT: 512M 0x2000 - 0x3FFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 2028866 kiB.
[TTM] Initializing pool allocator.
[TTM] Initializing DMA pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :02:00.0: irq 42 for MSI/MSI-X
radeon :02:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: ib pool ready.
[drm] Loading RV730 Microcode
r600_cp: Failed to load firmware "radeon/RV730_pfp.bin"
[drm:rv770_startup] *ERROR* Failed to load firmware!
radeon :02:00.0: disabling GPU acceleration
radeon :02:00.0: 88011a561000 unpin not necessary
radeon :02:00.0: 88011a46c000 unpin not necessary
radeon :02:00.0: 88011a46c000 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   HDMI-A
[drm]   HPD2
[drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY1
[drm] Connector 1:
[drm]   VGA
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP1: INTERNAL_UNIPHY
[drm] Internal thermal controller without fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xE004
[drm] vram apper at 0xE000
[drm] size 5242880
[drm] fb depth is 24
[drm]pitch is 5120
bcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 160x64
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.13.0 20080528 for :02:00.0 on minor 0





> This may be related to udev:
> I have udev-182 + kmod-7
> 
> $ ls -l /lib/firmware/radeon/RV730*
> -rw-r--r-- 1 root root 5440 Apr 23 08:43 /lib/firmware/radeon/RV730_me.bin
> -rw-r--r-- 1 root root 3392 Apr 23 08:43 /lib/firmware/radeon/RV730_pfp.bin
> 
> 
> # lspci -nn -v -d 1002:
> 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee
> ATI RV730 PRO [Radeon HD 4650] [1002:9498] (prog-if 00 [VGA controller])
> Subsystem: Hightech Information System Ltd. Device [1787:2269] Flags: bus
> master, fast devsel, latency 0, IRQ 16
> Memory at e000 (64-bit, prefetchable) [size=256M]
> Memory at f300 (64-bit, non-prefetchable) [size=64K]
> I/O ports at a000 [size=256]
> [virtual] Expansion ROM at f200 [disabled] [size=128K]
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Legacy Endpoint, MSI 00
> Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1
> Len=010 
> 
> 02:00.1 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI RV710/730
> HDMI Audio [Radeon HD 4000 series] [1002:aa38]
> Subsystem: Hightech Information System Ltd. Device [1787:aa38]
> Flags: bus master, fast devsel, latency 0, IRQ 41
> Memory at f301 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Legacy Endpoint, MSI 00
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1
> Len=010 
> Kernel driver in use: snd_hda_intel
> 
> 
> Full config and dmesg files attached
> 
> 
> 
> 

[PATCH 2/4] drm/radeon: convert fence to uint64_t

[Michel Dänzer]

On Mit, 2012-05-02 at 16:20 -0400, j.glisse at gmail.com wrote: 
> From: Jerome Glisse 
> 
> This convert fence to use uint64_t sequence number intention is
> to use the fact that uin64_t is big enough that we don't need to
> care about wrap around.
> 
> Tested with and without writeback using 0xF000 as initial
> fence sequence and thus allowing to test the wrap around from
> 32bits to 64bits.
> 
> Signed-off-by: Jerome Glisse 

[...]

> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 7733429..6da1535 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct radeon_device 
> *rdev, int ring)
>   rdev->fence_drv[ring].scratch_reg -
>   rdev->scratch.reg_base;
>   }
> - rdev->fence_drv[ring].cpu_addr = >wb.wb[index/4];
> + rdev->fence_drv[ring].cpu_addr = (u64*)>wb.wb[index/4];

Might want to ensure cpu_addr is 64 bit aligned, or there might be
trouble on some architectures.


With this change, Cayman cards will already use six scratch registers
for the rings. It won't be possible to extend this scheme for even one
additional ring, will it?


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

Include request for reset-rework branch v4

[Dave Airlie]

> 
> there still seems to be the need for some further discussion about the SA 
> code,
> so I again split that out of the patchset and tested the result a bit.
> 
> Most of the stuff still works fine without those offending changes, so to 
> avoid
> mailing around unrelated and already reviewed patches, I request the include
> the following 17 patches into drm-next.

Okay I've merged these 17 patches into drm-next.

Thanks,
Dave,

[PATCH 4/4] gma500: opregion and ACPI

[Dave Airlie]

On Tue, May 1, 2012 at 2:33 PM, Alan Cox  wrote:
> From: Alan Cox 
>
> Add the opregion support and bring us in line with the opregion functionality 
> in the
> reference driver code. We can't share this with i915 currently because there 
> are
> hardcoded assumptions about dev_priv etc in both versions.

This isn't applying to my -next tree cleanly, do I need some previous patches?

I saw some acpi video ones going by but I wasn't sure what tree they
were to be merged via.

Dave.

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

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

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

--- Comment #5 from Marko  2012-05-02 22:42:10 PDT ---

> vec3 p3 = vec3(p.x, p.y, p.z);
> float t = dot(v, p3);
> float t2 = gm1*t/v2 - g*p.w;
> r = vec4( v*t2 + p3, g * (p.w - t));
> 

Vadim, this is really great and much appreciated. I went through the steps and
it all seems fine to me, also tested some examples and everything works great.
This also makes the advanced path in the shader work again without my quirky
workarounds in the while loop. I never really took much care with these kind of
optimisations, somehow blindly hoping that the compiler will automagically
optimise everything. I'll try to be more careful in advance. 

I'd like to put some comments in the code, like "optimised by Vadim" if that's
ok with you or perhaps should I use your real name? Thanks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Michel Dänzer]

On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote: 
 From: Jerome Glisse jgli...@redhat.com
 
 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.
 
 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.
 
 Signed-off-by: Jerome Glisse jgli...@redhat.com

[...]

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct radeon_device 
 *rdev, int ring)
   rdev-fence_drv[ring].scratch_reg -
   rdev-scratch.reg_base;
   }
 - rdev-fence_drv[ring].cpu_addr = rdev-wb.wb[index/4];
 + rdev-fence_drv[ring].cpu_addr = (u64*)rdev-wb.wb[index/4];

Might want to ensure cpu_addr is 64 bit aligned, or there might be
trouble on some architectures.


With this change, Cayman cards will already use six scratch registers
for the rings. It won't be possible to extend this scheme for even one
additional ring, will it?


-- 
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: [PATCH 4/4] gma500: opregion and ACPI

[Dave Airlie]

On Tue, May 1, 2012 at 2:33 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
 From: Alan Cox a...@linux.intel.com

 Add the opregion support and bring us in line with the opregion functionality 
 in the
 reference driver code. We can't share this with i915 currently because there 
 are
 hardcoded assumptions about dev_priv etc in both versions.

This isn't applying to my -next tree cleanly, do I need some previous patches?

I saw some acpi video ones going by but I wasn't sure what tree they
were to be merged via.

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

Re: Include request for reset-rework branch v4

[Christian König]

On 02.05.2012 18:01, Jerome Glisse wrote:

On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de  wrote:

Hi Dave,

there still seems to be the need for some further discussion about the SA code,
so I again split that out of the patchset and tested the result a bit.

Most of the stuff still works fine without those offending changes, so to avoid
mailing around unrelated and already reviewed patches, I request the include
the following 17 patches into drm-next.

If you prefer to merge they are also available from
git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

Cheers,
Christian.


I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
bring back some other of the previous cleanup.
At least for now those three are NAK, cause I just realized we need to 
put those on top of a more sophisticated fence implementation.


Your idea of not using a list, but 64 bit sequences instead actually 
sounds quite nifty to me. Going to hack something together in the next 
couple of hours.


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

Re: Include request for reset-rework branch v4

[Dave Airlie]

 
 there still seems to be the need for some further discussion about the SA 
 code,
 so I again split that out of the patchset and tested the result a bit.
 
 Most of the stuff still works fine without those offending changes, so to 
 avoid
 mailing around unrelated and already reviewed patches, I request the include
 the following 17 patches into drm-next.

Okay I've merged these 17 patches into drm-next.

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

Re: [PATCH 4/4] gma500: opregion and ACPI

[Alan Cox]

On Thu, 3 May 2012 09:15:23 +0100
Dave Airlie airl...@gmail.com wrote:

 On Tue, May 1, 2012 at 2:33 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
  From: Alan Cox a...@linux.intel.com
 
  Add the opregion support and bring us in line with the opregion 
  functionality in the
  reference driver code. We can't share this with i915 currently because 
  there are
  hardcoded assumptions about dev_priv etc in both versions.
 
 This isn't applying to my -next tree cleanly, do I need some previous patches?
 
 I saw some acpi video ones going by but I wasn't sure what tree they
 were to be merged via.

I'd assumed the ACPI tree. I'll pull your current tree and see what needs
to be sorted out where.

Alan

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

Re: [PATCH 4/4] drm/i915: make DBLCLK modes work

[Daniel Vetter]

On Fri, Apr 13, 2012 at 04:31:41PM -0300, Paulo Zanoni wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 They require an AVI InfoFrame with a proper Pixel Repetition field.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com

I've merged the 2 i915 patches for -next, thanks.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
  QAContact|xorg-t...@lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-05-03 03:03:24 PDT 
---
Please attach the dmesg output.

-- 
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 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-daemon]

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

--- Comment #6 from Vadim Girlin pt...@yandex.ru 2012-05-03 03:16:19 PDT ---
(In reply to comment #5)
  vec3 p3 = vec3(p.x, p.y, p.z);
  float t = dot(v, p3);
  float t2 = gm1*t/v2 - g*p.w;
  r = vec4( v*t2 + p3, g * (p.w - t));
  
 
 Vadim, this is really great and much appreciated. I went through the steps and
 it all seems fine to me, also tested some examples and everything works great.
 This also makes the advanced path in the shader work again without my quirky
 workarounds in the while loop. I never really took much care with these kind 
 of
 optimisations, somehow blindly hoping that the compiler will automagically
 optimise everything. I'll try to be more careful in advance.
 
 I'd like to put some comments in the code, like optimised by Vadim if that's
 ok with you or perhaps should I use your real name? Thanks.

Ah, yes, I forgot to set my full name in the account here. Updated now, so you
can use it if you want.

-- 
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 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-daemon]

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

--- Comment #2 from Bastien Dejean nihilh...@gmail.com 2012-05-03 03:56:40 
PDT ---
Created attachment 60959
  -- https://bugs.freedesktop.org/attachment.cgi?id=60959
dmesg EFI mode output

-- 
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 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-daemon]

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

--- Comment #3 from Bastien Dejean nihilh...@gmail.com 2012-05-03 03:57:32 
PDT ---
Created attachment 60960
  -- https://bugs.freedesktop.org/attachment.cgi?id=60960
dmesg BIOS mode output

-- 
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 42678] [3.3-rc1] radeon stuck in kernel after lockup

[bugzilla-daemon]

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


Yvon TANGUY von...@gmail.com changed:

   What|Removed |Added

 CC||von...@gmail.com




--- Comment #14 from Yvon TANGUY von...@gmail.com  2012-05-03 11:17:41 ---
I'm affected with the same problem, I've log a bug report on launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986524). Don't know if it
will help.

-- 
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: Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Christian König]

On 03.05.2012 09:21, Michel Dänzer wrote:

On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

From: Jerome Glissejgli...@redhat.com

This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.

Tested with and without writeback using 0xF000 as initial
fence sequence and thus allowing to test the wrap around from
32bits to 64bits.

Signed-off-by: Jerome Glissejgli...@redhat.com

[...]


diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7733429..6da1535 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)
rdev-fence_drv[ring].scratch_reg -
rdev-scratch.reg_base;
}
-   rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
+   rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

Might want to ensure cpu_addr is 64 bit aligned, or there might be
trouble on some architectures.


With this change, Cayman cards will already use six scratch registers
for the rings. It won't be possible to extend this scheme for even one
additional ring, will it?


That won't work anyway, since not all rings can deal with 64 bit fences, 
so we need to still use 32 bit signaling and extend them to 64 bit while 
processing the fence value.


Already working on that.

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

Re: PROBLEM: [drm:r600_do_init_cp] *ERROR* Failed to load firmware!

[Treeve Jelbert]

On Monday 23 April 2012 11:18:52 you wrote:
 Linux-3.3.3
 
 $ dmesg|grep drm
 [drm] Initialized drm 1.1.0 20060810
 [drm] radeon defaulting to userspace modesetting.
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] No driver support for vblank timestamp query.
 [drm] Initialized radeon 1.33.0 20080528 for :02:00.0 on minor 0
 [drm] Setting GART location based on new memory map
 [drm] Loading RV730 CP Microcode
 [drm:r600_do_init_cp] *ERROR* Failed to load firmware!
 
 
 

I have now booted using radeon.modeset=0
and then manually doing 'modprobe radeon  modeset=1'


this gives the following messages on linux-3.3.4. The error message is now 
different, but it still fails.
The file /lib/firmware/radeon/RV730_pfp.bin exists
There are message about rv730/rv770



[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
[drm] initializing kernel modesetting (RV730 0x1002:0x9498 0x1787:0x2269).
[drm] register mmio base: 0xF300
[drm] register mmio size: 65536
ATOM BIOS: 88209JCA.EFK
radeon :02:00.0: VRAM: 512M 0x - 0x1FFF (512M 
used)
radeon :02:00.0: GTT: 512M 0x2000 - 0x3FFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 2028866 kiB.
[TTM] Initializing pool allocator.
[TTM] Initializing DMA pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :02:00.0: irq 42 for MSI/MSI-X
radeon :02:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: ib pool ready.
[drm] Loading RV730 Microcode
r600_cp: Failed to load firmware radeon/RV730_pfp.bin
[drm:rv770_startup] *ERROR* Failed to load firmware!
radeon :02:00.0: disabling GPU acceleration
radeon :02:00.0: 88011a561000 unpin not necessary
radeon :02:00.0: 88011a46c000 unpin not necessary
radeon :02:00.0: 88011a46c000 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   HDMI-A
[drm]   HPD2
[drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY1
[drm] Connector 1:
[drm]   VGA
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP1: INTERNAL_UNIPHY
[drm] Internal thermal controller without fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xE004
[drm] vram apper at 0xE000
[drm] size 5242880
[drm] fb depth is 24
[drm]pitch is 5120
bcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 160x64
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.13.0 20080528 for :02:00.0 on minor 0





 This may be related to udev:
 I have udev-182 + kmod-7
 
 $ ls -l /lib/firmware/radeon/RV730*
 -rw-r--r-- 1 root root 5440 Apr 23 08:43 /lib/firmware/radeon/RV730_me.bin
 -rw-r--r-- 1 root root 3392 Apr 23 08:43 /lib/firmware/radeon/RV730_pfp.bin
 
 
 # lspci -nn -v -d 1002:
 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee
 ATI RV730 PRO [Radeon HD 4650] [1002:9498] (prog-if 00 [VGA controller])
 Subsystem: Hightech Information System Ltd. Device [1787:2269] Flags: bus
 master, fast devsel, latency 0, IRQ 16
 Memory at e000 (64-bit, prefetchable) [size=256M]
 Memory at f300 (64-bit, non-prefetchable) [size=64K]
 I/O ports at a000 [size=256]
 [virtual] Expansion ROM at f200 [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1
 Len=010 ?
 
 02:00.1 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI RV710/730
 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
 Subsystem: Hightech Information System Ltd. Device [1787:aa38]
 Flags: bus master, fast devsel, latency 0, IRQ 41
 Memory at f301 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1
 Len=010 ?
 Kernel driver in use: snd_hda_intel
 
 
 Full config and dmesg files attached
 
 
 
 
 
 
 
 
 
 
 $ sh scripts/ver_linux
 If some fields are 

[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops

[Mark Brown]

The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.

Also remove the suspend function since all it does is log.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Acked-by: Francisco Jerez curroje...@riseup.net
---
 drivers/gpu/drm/i2c/ch7006_drv.c |   16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..74ad254 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
 }
 
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
 {
-   ch7006_dbg(client, \n);
-
-   return 0;
-}
+   struct i2c_client *client = to_i2c_device(dev);
 
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, \n);
 
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, ch7006_ids);
 
+static const struct dev_pm_ops ch7006_pm_ops = {
+   .resume = ch7006_resume,
+};
+
 static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
-   .suspend = ch7006_suspend,
-   .resume = ch7006_resume,
 
.driver = {
.name = ch7006,
+   .pm = ch7006_pm_ops,
},
 
.id_table = ch7006_ids,
-- 
1.7.10

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

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #60959|application/octet-stream|text/plain
  mime type||

-- 
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 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #60960|application/octet-stream|text/plain
  mime type||

-- 
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: PROBLEM: [drm:r600_do_init_cp] *ERROR* Failed to load firmware!

[Michel Dänzer]

On Don, 2012-05-03 at 09:32 +0200, Treeve Jelbert wrote: 
 On Monday 23 April 2012 11:18:52 you wrote:
  Linux-3.3.3
  
  $ dmesg|grep drm
  [drm] Initialized drm 1.1.0 20060810
  [drm] radeon defaulting to userspace modesetting.
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] No driver support for vblank timestamp query.
  [drm] Initialized radeon 1.33.0 20080528 for :02:00.0 on minor 0
  [drm] Setting GART location based on new memory map
  [drm] Loading RV730 CP Microcode
  [drm:r600_do_init_cp] *ERROR* Failed to load firmware!
  
  
  
 
 I have now booted using radeon.modeset=0
 and then manually doing 'modprobe radeon  modeset=1'
 
 
 this gives the following messages on linux-3.3.4. The error message is now 
 different, but it still fails.

Odd. I suppose it really couldn't hurt talking to udev people for
tracking down why it's failing.


-- 
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: [PATCH 4/4] drm/i915: make DBLCLK modes work

[Anssi Hannula]

13.04.2012 22:31, Paulo Zanoni kirjoitti:
 From: Paulo Zanoni paulo.r.zan...@intel.com
 
 They require an AVI InfoFrame with a proper Pixel Repetition field.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
 
 I'm still waiting for confirmation on bugzilla, but I have access to a
 TV that reproduces the problem and the problem goes away with this patch
 series.

Shouldn't all this infoframe stuff be shared between the drivers (like
e.g. EDID stuff is)? I see i915, radeon, nouveau all have separate
implementations of it, and i915 seems to have it even twice (in
intel_hdmi.c and intel_sdvo.c).

The patch below only fixes the issue on one of those four places where
the avi/video infoframe is generated.


  drivers/gpu/drm/i915/intel_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |8 ++--
  2 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 175cca7..3afa7ab 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -215,6 +215,8 @@ struct intel_plane {
  #define DIP_TYPE_AVI0x82
  #define DIP_VERSION_AVI 0x2
  #define DIP_LEN_AVI 13
 +#define DIP_AVI_PR_10
 +#define DIP_AVI_PR_21
  
  #define DIP_TYPE_SPD 0x83
  #define DIP_VERSION_SPD  0x1
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index 7de2d3b..8d25017 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -220,7 +220,8 @@ static void intel_set_infoframe(struct drm_encoder 
 *encoder,
   intel_hdmi-write_infoframe(encoder, frame);
  }
  
 -static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
 +static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
 +  struct drm_display_mode *adjusted_mode)
  {
   struct dip_infoframe avi_if = {
   .type = DIP_TYPE_AVI,
 @@ -228,6 +229,9 @@ static void intel_hdmi_set_avi_infoframe(struct 
 drm_encoder *encoder)
   .len = DIP_LEN_AVI,
   };
  
 + if (adjusted_mode-flags  DRM_MODE_FLAG_DBLCLK)
 + avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
 +
   intel_set_infoframe(encoder, avi_if);
  }
  
 @@ -290,7 +294,7 @@ static void intel_hdmi_mode_set(struct drm_encoder 
 *encoder,
   I915_WRITE(intel_hdmi-sdvox_reg, sdvox);
   POSTING_READ(intel_hdmi-sdvox_reg);
  
 - intel_hdmi_set_avi_infoframe(encoder);
 + intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
   intel_hdmi_set_spd_infoframe(encoder);
  }
  


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

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

One more regression fix and a 3 small patches:
- Paulo fixed the hdmi infoframe regression on gm45 introduced in 3.2 by
  Jesse.
- snb/ilk has a nice debug register where the hw can tell us when it
  dropped writes and we've added a WARN in 3.4 when this happens. This
  caught code which shouldn't run on gen6+, the two patches by Chris fix
  this. No known bad side-effects besides the WARN backtrace (and in a
  way, not really a regression fix, but still).
- Fix up 2 broken no-lvds quirks added in 3.4 - I've figured shipping with
  broken quirk entries is pointless, and these are easily revertable.

Yours, Daniel

The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a:

  Linux 3.4-rc5 (2012-04-29 15:19:10 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to c1230df7e19e0f27655c0eb9d966c7e03be7cc50:

  drm/i915: enable dip before writing data on gen4 (2012-05-03 15:55:38 +0200)


Chris Wilson (2):
  drm/i915: Do not read non-existent DPLL registers on PCH hardware
  drm/i915: Only enable IPS polling for gen5

Marc Gariepy (1):
  fixing dmi match for hp t5745 and hp st5747 thin client

Paulo Zanoni (1):
  drm/i915: enable dip before writing data on gen4

 drivers/gpu/drm/i915/i915_debugfs.c  |3 +++
 drivers/gpu/drm/i915/i915_dma.c  |   15 ++-
 drivers/gpu/drm/i915/intel_display.c |9 +
 drivers/gpu/drm/i915/intel_hdmi.c|2 +-
 drivers/gpu/drm/i915/intel_lvds.c|4 ++--
 5 files changed, 21 insertions(+), 12 deletions(-)

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 7:39 AM, Christian König deathsim...@vodafone.de wrote:
 On 03.05.2012 09:21, Michel Dänzer wrote:

 On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

 From: Jerome Glissejgli...@redhat.com

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glissejgli...@redhat.com

 [...]

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
                        rdev-fence_drv[ring].scratch_reg -
                        rdev-scratch.reg_base;
        }
 -       rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
 +       rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

 Might want to ensure cpu_addr is 64 bit aligned, or there might be
 trouble on some architectures.


 With this change, Cayman cards will already use six scratch registers
 for the rings. It won't be possible to extend this scheme for even one
 additional ring, will it?


 That won't work anyway, since not all rings can deal with 64 bit fences, so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.

This patch is fine with ring that can't emit directly 64bits, all you
have to do is fix the emit_fence callback to properly handle it and
then you have to fix the radeon_fence_read which can be move to a ring
specific callback. Anyway point is that patchset works and is fine on
current set of ring we have and it can work as easily for ring without
easy 64bits value emitting. So please explain further why those patch
can't work because as i just explained i don't see why.

I have updated some v2 version of those patchset to handle the cayman
and newer possibly running out of scratch reg and i also fix the
alignment issue to be 64bits
http://people.freedesktop.org/~glisse/reset3/

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

Re: Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Alex Deucher]

On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 7:39 AM, Christian König deathsim...@vodafone.de 
 wrote:
 On 03.05.2012 09:21, Michel Dänzer wrote:

 On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

 From: Jerome Glissejgli...@redhat.com

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glissejgli...@redhat.com

 [...]

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
                        rdev-fence_drv[ring].scratch_reg -
                        rdev-scratch.reg_base;
        }
 -       rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
 +       rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

 Might want to ensure cpu_addr is 64 bit aligned, or there might be
 trouble on some architectures.


 With this change, Cayman cards will already use six scratch registers
 for the rings. It won't be possible to extend this scheme for even one
 additional ring, will it?


 That won't work anyway, since not all rings can deal with 64 bit fences, so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.

 This patch is fine with ring that can't emit directly 64bits, all you
 have to do is fix the emit_fence callback to properly handle it and
 then you have to fix the radeon_fence_read which can be move to a ring
 specific callback. Anyway point is that patchset works and is fine on
 current set of ring we have and it can work as easily for ring without
 easy 64bits value emitting. So please explain further why those patch
 can't work because as i just explained i don't see why.

 I have updated some v2 version of those patchset to handle the cayman
 and newer possibly running out of scratch reg and i also fix the
 alignment issue to be 64bits

FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
least), it's just memory writes so we could make the scratch pool
bigger.

Alex

 http://people.freedesktop.org/~glisse/reset3/

 Cheers,
 Jerome
 ___
 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: Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 4:19 AM, Christian König deathsim...@vodafone.de wrote:
 On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about the SA
 code,
 so I again split that out of the patchset and tested the result a bit.

 Most of the stuff still works fine without those offending changes, so to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

 I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
 bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually sounds
 quite nifty to me. Going to hack something together in the next couple of
 hours.

 Christian.

Btw you said that you are having issue when using multiple ring, it
comes to my attention that you never sync with the GFX ring (unless
asked by userspace) that's wrong, before scheduling on another ring
than GFX index you need to emit semaphore to make the ring wait for
the last emited fence on the GFX ring because of ttm. What might
happen is that ttm scheduled bo move on the GFX ring and that the ring
you work on start using those bo at there soon to be GPU offset while
the bo data is not there yet.

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

Re: Include request for reset-rework branch v4

[Christian König]

On 03.05.2012 18:32, Jerome Glisse wrote:

On Thu, May 3, 2012 at 4:19 AM, Christian Königdeathsim...@vodafone.de  wrote:

On 02.05.2012 18:01, Jerome Glisse wrote:

On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de
  wrote:

Hi Dave,

there still seems to be the need for some further discussion about the SA
code,
so I again split that out of the patchset and tested the result a bit.

Most of the stuff still works fine without those offending changes, so to
avoid
mailing around unrelated and already reviewed patches, I request the
include
the following 17 patches into drm-next.

If you prefer to merge they are also available from
git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

Cheers,
Christian.


I am ok with this 17 patchset, i just sent 3 patch on top of those 17 that
bring back some other of the previous cleanup.

At least for now those three are NAK, cause I just realized we need to put
those on top of a more sophisticated fence implementation.

Your idea of not using a list, but 64 bit sequences instead actually sounds
quite nifty to me. Going to hack something together in the next couple of
hours.

Christian.

Btw you said that you are having issue when using multiple ring, it
comes to my attention that you never sync with the GFX ring (unless
asked by userspace) that's wrong, before scheduling on another ring
than GFX index you need to emit semaphore to make the ring wait for
the last emited fence on the GFX ring because of ttm. What might
happen is that ttm scheduled bo move on the GFX ring and that the ring
you work on start using those bo at there soon to be GPU offset while
the bo data is not there yet.

Yeah, already stumbled over that but IIRC Alex already solved that issue.

We set the sync_obj to the fence of the move operation, so when there is 
a move operation in progress we sync to it correctly (at least I hope so).


Christian.

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

Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Christian König]

On 03.05.2012 18:34, Jerome Glisse wrote:

On Thu, May 3, 2012 at 12:29 PM, Alex Deucheralexdeuc...@gmail.com  wrote:

On Thu, May 3, 2012 at 11:56 AM, Jerome Glissej.gli...@gmail.com  wrote:

On Thu, May 3, 2012 at 7:39 AM, Christian Königdeathsim...@vodafone.de  wrote:

On 03.05.2012 09:21, Michel Dänzer wrote:

On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

From: Jerome Glissejgli...@redhat.com

This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.

Tested with and without writeback using 0xF000 as initial
fence sequence and thus allowing to test the wrap around from
32bits to 64bits.

Signed-off-by: Jerome Glissejgli...@redhat.com

[...]


diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7733429..6da1535 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
radeon_device *rdev, int ring)
rdev-fence_drv[ring].scratch_reg -
rdev-scratch.reg_base;
}
-   rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
+   rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

Might want to ensure cpu_addr is 64 bit aligned, or there might be
trouble on some architectures.


With this change, Cayman cards will already use six scratch registers
for the rings. It won't be possible to extend this scheme for even one
additional ring, will it?


That won't work anyway, since not all rings can deal with 64 bit fences, so
we need to still use 32 bit signaling and extend them to 64 bit while
processing the fence value.

Already working on that.

Christian.

This patch is fine with ring that can't emit directly 64bits, all you
have to do is fix the emit_fence callback to properly handle it and
then you have to fix the radeon_fence_read which can be move to a ring
specific callback. Anyway point is that patchset works and is fine on
current set of ring we have and it can work as easily for ring without
easy 64bits value emitting. So please explain further why those patch
can't work because as i just explained i don't see why.

I have updated some v2 version of those patchset to handle the cayman
and newer possibly running out of scratch reg and i also fix the
alignment issue to be 64bits

FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
least), it's just memory writes so we could make the scratch pool
bigger.

Alex


That's what my v2 does, just drop scratch reg for cayman and newer.

Cheers,
Jerome

I actually always wanted to change that in a way that scratch regs are 
only allocated if wb is really disabled, just never had time to do so 
(sigh).


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

Re: Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 12:39 PM, Christian König
deathsim...@vodafone.de wrote:
 On 03.05.2012 18:32, Jerome Glisse wrote:

 On Thu, May 3, 2012 at 4:19 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about the
 SA
 code,
 so I again split that out of the patchset and tested the result a bit.

 Most of the stuff still works fine without those offending changes, so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to
 put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually
 sounds
 quite nifty to me. Going to hack something together in the next couple of
 hours.

 Christian.

 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that issue.

 We set the sync_obj to the fence of the move operation, so when there is a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.


Looking at code doesn't seems ok, yes you use the fence from the move
operation but you only emit wait if userspace ask for it, that's
wrong.

if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {

in radeon_cs.c

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

Re: Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 1:20 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 2012/5/3 Jerome Glisse j.gli...@gmail.com:
 On Thu, May 3, 2012 at 12:39 PM, Christian König
 deathsim...@vodafone.de wrote:
 On 03.05.2012 18:32, Jerome Glisse wrote:

 On Thu, May 3, 2012 at 4:19 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about the
 SA
 code,
 so I again split that out of the patchset and tested the result a bit.

 Most of the stuff still works fine without those offending changes, so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to
 put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually
 sounds
 quite nifty to me. Going to hack something together in the next couple of
 hours.

 Christian.

 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that issue.

 We set the sync_obj to the fence of the move operation, so when there is a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.


 Looking at code doesn't seems ok, yes you use the fence from the move
 operation but you only emit wait if userspace ask for it, that's
 wrong.

 if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {


 The default is to sync all the rings.  We only skip the sync if the
 _DONT_ sync flag is set.

 Alex


That's my point exactly, so if a bo move happen and userspace set dont
sync flag then the other ring might start doing work before bo data is
in place. This test should be removed or at least make the sync to the
bo move fence unconditional and use this flag only for sync with other
ring relative to current job you are scheduling.

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

Re: Include request for reset-rework branch v4

[Alex Deucher]

2012/5/3 Jerome Glisse j.gli...@gmail.com:
 On Thu, May 3, 2012 at 12:39 PM, Christian König
 deathsim...@vodafone.de wrote:
 On 03.05.2012 18:32, Jerome Glisse wrote:

 On Thu, May 3, 2012 at 4:19 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de
  wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about the
 SA
 code,
 so I again split that out of the patchset and tested the result a bit.

 Most of the stuff still works fine without those offending changes, so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to
 put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually
 sounds
 quite nifty to me. Going to hack something together in the next couple of
 hours.

 Christian.

 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that issue.

 We set the sync_obj to the fence of the move operation, so when there is a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.


 Looking at code doesn't seems ok, yes you use the fence from the move
 operation but you only emit wait if userspace ask for it, that's
 wrong.

 if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {


The default is to sync all the rings.  We only skip the sync if the
_DONT_ sync flag is set.

Alex

 in radeon_cs.c

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

Re: Include request for reset-rework branch v4

[Christian König]

On 03.05.2012 19:20, Alex Deucher wrote:

2012/5/3 Jerome Glissej.gli...@gmail.com:

On Thu, May 3, 2012 at 12:39 PM, Christian König
deathsim...@vodafone.de  wrote:

On 03.05.2012 18:32, Jerome Glisse wrote:

On Thu, May 3, 2012 at 4:19 AM, Christian Königdeathsim...@vodafone.de
  wrote:

On 02.05.2012 18:01, Jerome Glisse wrote:

On Wed, May 2, 2012 at 9:11 AM, Christian Königdeathsim...@vodafone.de
  wrote:

Hi Dave,

there still seems to be the need for some further discussion about the
SA
code,
so I again split that out of the patchset and tested the result a bit.

Most of the stuff still works fine without those offending changes, so
to
avoid
mailing around unrelated and already reviewed patches, I request the
include
the following 17 patches into drm-next.

If you prefer to merge they are also available from
git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

Cheers,
Christian.


I am ok with this 17 patchset, i just sent 3 patch on top of those 17
that
bring back some other of the previous cleanup.

At least for now those three are NAK, cause I just realized we need to
put
those on top of a more sophisticated fence implementation.

Your idea of not using a list, but 64 bit sequences instead actually
sounds
quite nifty to me. Going to hack something together in the next couple of
hours.

Christian.

Btw you said that you are having issue when using multiple ring, it
comes to my attention that you never sync with the GFX ring (unless
asked by userspace) that's wrong, before scheduling on another ring
than GFX index you need to emit semaphore to make the ring wait for
the last emited fence on the GFX ring because of ttm. What might
happen is that ttm scheduled bo move on the GFX ring and that the ring
you work on start using those bo at there soon to be GPU offset while
the bo data is not there yet.

Yeah, already stumbled over that but IIRC Alex already solved that issue..

We set the sync_obj to the fence of the move operation, so when there is a
move operation in progress we sync to it correctly (at least I hope so).

Christian.


Looking at code doesn't seems ok, yes you use the fence from the move
operation but you only emit wait if userspace ask for it, that's
wrong.

if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {


The default is to sync all the rings.  We only skip the sync if the
_DONT_ sync flag is set.
Yeah, but the _DONT_ sync flag is just an optimization, and we only want 
to not sync to things userspace has submitted.


 E.g. userspace tells us that two jobs can happily run on the same bo 
even if they are both writing to it


So Jerome is completely right, userspace doesn't expect that TTM is 
jumping in between and moving the bo around, that is indeed a bug and 
another thing for the todo list.


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

Re: Include request for reset-rework branch v4

[Jerome Glisse]

On Thu, May 3, 2012 at 1:28 PM, Christian König deathsim...@vodafone.de wrote:
 On 03.05.2012 19:20, Alex Deucher wrote:

 2012/5/3 Jerome Glissej.gli...@gmail.com:

 On Thu, May 3, 2012 at 12:39 PM, Christian König
 deathsim...@vodafone.de  wrote:

 On 03.05.2012 18:32, Jerome Glisse wrote:

 On Thu, May 3, 2012 at 4:19 AM, Christian
 Königdeathsim...@vodafone.de
  wrote:

 On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian
 Königdeathsim...@vodafone.de
  wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about
 the
 SA
 code,
 so I again split that out of the patchset and tested the result a
 bit.

 Most of the stuff still works fine without those offending changes,
 so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to
 put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually
 sounds
 quite nifty to me. Going to hack something together in the next couple
 of
 hours.

 Christian.

 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that
 issue..


 We set the sync_obj to the fence of the move operation, so when there is
 a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.

 Looking at code doesn't seems ok, yes you use the fence from the move
 operation but you only emit wait if userspace ask for it, that's
 wrong.

 if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {

 The default is to sync all the rings.  We only skip the sync if the
 _DONT_ sync flag is set.

 Yeah, but the _DONT_ sync flag is just an optimization, and we only want to
 not sync to things userspace has submitted.

  E.g. userspace tells us that two jobs can happily run on the same bo even
 if they are both writing to it

 So Jerome is completely right, userspace doesn't expect that TTM is jumping
 in between and moving the bo around, that is indeed a bug and another thing
 for the todo list.

 Christian.

Well until userspace can tell kernel on which fence it wants to wait i
believe this flags become obsolete and can be remove, i am pretty no
release userspace code ever used that flags.

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

Re: Include request for reset-rework branch v4

[Alex Deucher]

2012/5/3 Christian König deathsim...@vodafone.de:
 On 03.05.2012 19:20, Alex Deucher wrote:

 2012/5/3 Jerome Glissej.gli...@gmail.com:

 On Thu, May 3, 2012 at 12:39 PM, Christian König
 deathsim...@vodafone.de  wrote:

 On 03.05.2012 18:32, Jerome Glisse wrote:

 On Thu, May 3, 2012 at 4:19 AM, Christian
 Königdeathsim...@vodafone.de
  wrote:

 On 02.05.2012 18:01, Jerome Glisse wrote:

 On Wed, May 2, 2012 at 9:11 AM, Christian
 Königdeathsim...@vodafone.de
  wrote:

 Hi Dave,

 there still seems to be the need for some further discussion about
 the
 SA
 code,
 so I again split that out of the patchset and tested the result a
 bit.

 Most of the stuff still works fine without those offending changes,
 so
 to
 avoid
 mailing around unrelated and already reviewed patches, I request the
 include
 the following 17 patches into drm-next.

 If you prefer to merge they are also available from
 git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

 Cheers,
 Christian.

 I am ok with this 17 patchset, i just sent 3 patch on top of those 17
 that
 bring back some other of the previous cleanup.

 At least for now those three are NAK, cause I just realized we need to
 put
 those on top of a more sophisticated fence implementation.

 Your idea of not using a list, but 64 bit sequences instead actually
 sounds
 quite nifty to me. Going to hack something together in the next couple
 of
 hours.

 Christian.

 Btw you said that you are having issue when using multiple ring, it
 comes to my attention that you never sync with the GFX ring (unless
 asked by userspace) that's wrong, before scheduling on another ring
 than GFX index you need to emit semaphore to make the ring wait for
 the last emited fence on the GFX ring because of ttm. What might
 happen is that ttm scheduled bo move on the GFX ring and that the ring
 you work on start using those bo at there soon to be GPU offset while
 the bo data is not there yet.

 Yeah, already stumbled over that but IIRC Alex already solved that
 issue..


 We set the sync_obj to the fence of the move operation, so when there is
 a
 move operation in progress we sync to it correctly (at least I hope so).

 Christian.

 Looking at code doesn't seems ok, yes you use the fence from the move
 operation but you only emit wait if userspace ask for it, that's
 wrong.

 if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {

 The default is to sync all the rings.  We only skip the sync if the
 _DONT_ sync flag is set.

 Yeah, but the _DONT_ sync flag is just an optimization, and we only want to
 not sync to things userspace has submitted.

  E.g. userspace tells us that two jobs can happily run on the same bo even
 if they are both writing to it

 So Jerome is completely right, userspace doesn't expect that TTM is jumping
 in between and moving the bo around, that is indeed a bug and another thing
 for the todo list.

Ah, yes, that makes sense.  I misinterpreted the original comment.

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

[PATCH] drm/radeon: fix possible lack of synchronization btw ttm and other ring

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

We need to sync with the GFX ring as ttm might have schedule bo move
on it and new command scheduled for other ring need to wait for bo
data to be in place.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_cs.c |   12 ++--
 include/drm/radeon_drm.h   |1 -
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 82f2e7b0..e5f8e17 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -122,15 +122,15 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser 
*p)
int i, r;
 
for (i = 0; i  p-nrelocs; i++) {
+   struct radeon_fence *fence;
+
if (!p-relocs[i].robj || !p-relocs[i].robj-tbo.sync_obj)
continue;
 
-   if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {
-   struct radeon_fence *fence = 
p-relocs[i].robj-tbo.sync_obj;
-   if (fence-ring != p-ring  
!radeon_fence_signaled(fence)) {
-   sync_to_ring[fence-ring] = true;
-   need_sync = true;
-   }
+   fence = p-relocs[i].robj-tbo.sync_obj;
+   if (fence-ring != p-ring  !radeon_fence_signaled(fence)) {
+   sync_to_ring[fence-ring] = true;
+   need_sync = true;
}
}
 
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 7c491b4..5805686 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -926,7 +926,6 @@ struct drm_radeon_cs_chunk {
 };
 
 /* drm_radeon_cs_reloc.flags */
-#define RADEON_RELOC_DONT_SYNC 0x01
 
 struct drm_radeon_cs_reloc {
uint32_thandle;
-- 
1.7.7.6

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

Re: Include request for reset-rework branch v4

[Christian König]

On 03.05.2012 19:34, Jerome Glisse wrote:

On Thu, May 3, 2012 at 1:28 PM, Christian Königdeathsim...@vodafone.de  wrote:

On 03.05.2012 19:20, Alex Deucher wrote:

2012/5/3 Jerome Glissej.gli...@gmail.com:

On Thu, May 3, 2012 at 12:39 PM, Christian König
deathsim...@vodafone.dewrote:

On 03.05.2012 18:32, Jerome Glisse wrote:

On Thu, May 3, 2012 at 4:19 AM, Christian
Königdeathsim...@vodafone.de
  wrote:

On 02.05.2012 18:01, Jerome Glisse wrote:

On Wed, May 2, 2012 at 9:11 AM, Christian
Königdeathsim...@vodafone.de
  wrote:

Hi Dave,

there still seems to be the need for some further discussion about
the
SA
code,
so I again split that out of the patchset and tested the result a
bit.

Most of the stuff still works fine without those offending changes,
so
to
avoid
mailing around unrelated and already reviewed patches, I request the
include
the following 17 patches into drm-next.

If you prefer to merge they are also available from
git://people.freedesktop.org/~deathsimple/linux branch reset-rework.

Cheers,
Christian.


I am ok with this 17 patchset, i just sent 3 patch on top of those 17
that
bring back some other of the previous cleanup.

At least for now those three are NAK, cause I just realized we need to
put
those on top of a more sophisticated fence implementation.

Your idea of not using a list, but 64 bit sequences instead actually
sounds
quite nifty to me. Going to hack something together in the next couple
of
hours.

Christian.

Btw you said that you are having issue when using multiple ring, it
comes to my attention that you never sync with the GFX ring (unless
asked by userspace) that's wrong, before scheduling on another ring
than GFX index you need to emit semaphore to make the ring wait for
the last emited fence on the GFX ring because of ttm. What might
happen is that ttm scheduled bo move on the GFX ring and that the ring
you work on start using those bo at there soon to be GPU offset while
the bo data is not there yet.

Yeah, already stumbled over that but IIRC Alex already solved that
issue..


We set the sync_obj to the fence of the move operation, so when there is
a
move operation in progress we sync to it correctly (at least I hope so).

Christian.


Looking at code doesn't seems ok, yes you use the fence from the move
operation but you only emit wait if userspace ask for it, that's
wrong.

if (!(p-relocs[i].flagsRADEON_RELOC_DONT_SYNC)) {


The default is to sync all the rings.  We only skip the sync if the
_DONT_ sync flag is set.

Yeah, but the _DONT_ sync flag is just an optimization, and we only want to
not sync to things userspace has submitted.

  E.g. userspace tells us that two jobs can happily run on the same bo even
if they are both writing to it

So Jerome is completely right, userspace doesn't expect that TTM is jumping
in between and moving the bo around, that is indeed a bug and another thing
for the todo list.

Christian.

Well until userspace can tell kernel on which fence it wants to wait i
believe this flags become obsolete and can be remove, i am pretty no
release userspace code ever used that flags.


Agree, AFAIK it currently isn't used anyway.

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

Re: Enhancing EDID quirk functionality

[Ian Pilcher]

I just attached this patch to
https://bugzilla.redhat.com/show_bug.cgi?id=806091, along with the
following comments:

This is the first draft of an EDID quirk-based approach to solving
this problem.  I intend to perform a bit of cleanup and break it up
into a series of separate patches, but I'm posting it here for any
comments about the approach.

The patch does the following:

* Changes the vendor field of struct edid_quirk to an array, rather
  than a pointer.  (This has already been sent to the dri-devel list.)
* Adds two new quirks EDID_QUIRK_DISABLE_INFOFRAMES and
  EDID_QUIRK_NO_AUDIO. This first quirk causes drm_detect_hdmi_monitor
  to return false; the second   causes drm_detect_monitor_audio to
  return false.
* Logs the EDID vendor and model of connected monitors.
* Adds an edid_quirks parameter to the drm module, for user-defined
  quirks.

With this patch, my display works when I add
drm.edid_quirks=GSM:0x563f:0x180 to my kernel command line.  (0x80,
EDID_QUIRK_DISABLE_INFOFRAMES, makes it work with the nouveau driver;
0x100, EDID_QUIRK_NO_AUDIO, makes it work with the i915 driver.  I.e.,
the i915 driver is sending audio InfoFrames even when
drm_detect_hdmi_monitor returns false; bug?)

Thoughts?

-- 

Ian Pilcher arequip...@gmail.com
If you're going to shift my paradigm ... at least buy me dinner first.

diff -ur linux-3.3/drivers/gpu/drm/drm_drv.c linux-3.3-working/drivers/gpu/drm/drm_drv.c
--- linux-3.3/drivers/gpu/drm/drm_drv.c	2012-03-18 18:15:34.0 -0500
+++ linux-3.3-working/drivers/gpu/drm/drm_drv.c	2012-04-27 21:30:07.535452184 -0500
@@ -280,6 +280,8 @@
 		ret = -1;
 		goto err_p3;
 	}
+	
+	drm_edid_xtra_quirks_parse();
 
 	DRM_INFO(Initialized %s %d.%d.%d %s\n,
 		 CORE_NAME, CORE_MAJOR, CORE_MINOR, CORE_PATCHLEVEL, CORE_DATE);
@@ -304,6 +306,8 @@
 
 	idr_remove_all(drm_minors_idr);
 	idr_destroy(drm_minors_idr);
+	
+	drm_edid_xtra_quirks_free();
 }
 
 module_init(drm_core_init);
diff -ur linux-3.3/drivers/gpu/drm/drm_edid.c linux-3.3-working/drivers/gpu/drm/drm_edid.c
--- linux-3.3/drivers/gpu/drm/drm_edid.c	2012-03-18 18:15:34.0 -0500
+++ linux-3.3-working/drivers/gpu/drm/drm_edid.c	2012-04-28 01:11:51.316839743 -0500
@@ -66,6 +66,10 @@
 #define EDID_QUIRK_FIRST_DETAILED_PREFERRED	(1  5)
 /* use +hsync +vsync for detailed mode */
 #define EDID_QUIRK_DETAILED_SYNC_PP		(1  6)
+/* Display is confused by InfoFrames; don't send any. */
+#define EDID_QUIRK_DISABLE_INFOFRAMES		(1  7)
+/* Display doesn't have any audio output */
+#define EDID_QUIRK_NO_AUDIO			(1  8)
 
 struct detailed_mode_closure {
 	struct drm_connector *connector;
@@ -81,7 +85,7 @@
 #define LEVEL_CVT	3
 
 static struct edid_quirk {
-	char *vendor;
+	char vendor[4];
 	int product_id;
 	u32 quirks;
 } edid_quirk_list[] = {
@@ -122,13 +126,100 @@
 	{ SAM, 638, EDID_QUIRK_PREFER_LARGE_60 },
 };
 
+/* Parsed extra quirks from the edid_quirks module parameter */
+static struct edid_quirk *edid_xtra_quirk_list;
+static int edid_num_xtra_quirks;
+
+/*
+ * Free the extra EDID quirks list.
+ */
+void drm_edid_xtra_quirks_free(void)
+{
+	kfree(edid_xtra_quirk_list);
+	edid_xtra_quirk_list = NULL;
+	edid_num_xtra_quirks = 0;
+}
+
+/*
+ * Parse the EDID quirk at s and store it a q. Returns 1 on success, 0 on error.
+ */
+static int drm_edid_parse_quirk(char *s, struct edid_quirk *q)
+{
+	char *c;
+
+	if (sscanf(s, %3s:%i:%i,
+		   q-vendor, q-product_id, q-quirks) == 3) {
+		DRM_DEBUG(Parsed EDID quirk: 
+			  mfr: %s, product: %d, quirks: %u\n,
+			  q-vendor, q-product_id, q-quirks);
+		return 1;
+	} else {
+		if ((c = strchr(s, ',')) != NULL) {
+			*c = 0;
+		}
+		printk(KERN_WARNING Invalid EDID quirk: '%s'\n, s);
+		if (c != NULL) {
+			*c = ',';
+		}
+		return 0;
+	}
+}
+
+/*
+ * Parse drm_edid_xtra_quirks and create the extra EDID quirks list.
+ */
+void drm_edid_xtra_quirks_parse(void)
+{
+	int num_quirks;
+	char *c;
+	if (drm_edid_xtra_quirks == NULL) {
+		edid_xtra_quirk_list = NULL;
+		edid_num_xtra_quirks = 0;
+		return;
+	}
+	
+	/* Number of (potential) quirks = number of commas in param + 1 */
+	num_quirks = 1;
+	c = drm_edid_xtra_quirks;
+	while ((c = strchr(c, ',')) != NULL) {
+		++num_quirks;
+		++c;
+	}
+
+	if (num_quirks  DRM_EDID_XTRA_QUIRKS_MAX) {
+		printk(KERN_WARNING Number of additional EDID quirks limited 
+		   to  __stringify(DRM_EDID_XTRA_QUIRKS_MAX) \n);
+		num_quirks = DRM_EDID_XTRA_QUIRKS_MAX;
+	}
+	
+	edid_xtra_quirk_list = kmalloc(sizeof(struct edid_quirk) * num_quirks,
+   GFP_KERNEL);
+	if (edid_xtra_quirk_list == NULL) {
+		printk(KERN_WARNING Failed to allocate memory for additional 
+		   EDID quirks\n);
+		return;
+	}
+	
+	edid_num_xtra_quirks = 0;
+	c = drm_edid_xtra_quirks;
+	while (1) {
+		edid_num_xtra_quirks += drm_edid_parse_quirk(c,
+

Re: [PATCH] drm/radeon: fix possible lack of synchronization btw ttm and other ring

[Alex Deucher]

On Thu, May 3, 2012 at 1:44 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 We need to sync with the GFX ring as ttm might have schedule bo move
 on it and new command scheduled for other ring need to wait for bo
 data to be in place.

 Signed-off-by: Jerome Glisse jgli...@redhat.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/radeon_cs.c |   12 ++--
  include/drm/radeon_drm.h           |    1 -
  2 files changed, 6 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 82f2e7b0..e5f8e17 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -122,15 +122,15 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser 
 *p)
        int i, r;

        for (i = 0; i  p-nrelocs; i++) {
 +               struct radeon_fence *fence;
 +
                if (!p-relocs[i].robj || !p-relocs[i].robj-tbo.sync_obj)
                        continue;

 -               if (!(p-relocs[i].flags  RADEON_RELOC_DONT_SYNC)) {
 -                       struct radeon_fence *fence = 
 p-relocs[i].robj-tbo.sync_obj;
 -                       if (fence-ring != p-ring  
 !radeon_fence_signaled(fence)) {
 -                               sync_to_ring[fence-ring] = true;
 -                               need_sync = true;
 -                       }
 +               fence = p-relocs[i].robj-tbo.sync_obj;
 +               if (fence-ring != p-ring  !radeon_fence_signaled(fence)) {
 +                       sync_to_ring[fence-ring] = true;
 +                       need_sync = true;
                }
        }

 diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
 index 7c491b4..5805686 100644
 --- a/include/drm/radeon_drm.h
 +++ b/include/drm/radeon_drm.h
 @@ -926,7 +926,6 @@ struct drm_radeon_cs_chunk {
  };

  /* drm_radeon_cs_reloc.flags */
 -#define RADEON_RELOC_DONT_SYNC         0x01

  struct drm_radeon_cs_reloc {
        uint32_t                handle;
 --
 1.7.7.6

 ___
 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: Enhancing EDID quirk functionality

[Adam Jackson]

On 5/3/12 2:01 PM, Ian Pilcher wrote:


The patch does the following:


This looks good, thank you for taking it on.


* Changes the vendor field of struct edid_quirk to an array, rather
   than a pointer.  (This has already been sent to the dri-devel list.)
* Adds two new quirks EDID_QUIRK_DISABLE_INFOFRAMES and
   EDID_QUIRK_NO_AUDIO. This first quirk causes drm_detect_hdmi_monitor
   to return false; the second   causes drm_detect_monitor_audio to
   return false.
* Logs the EDID vendor and model of connected monitors.
* Adds an edid_quirks parameter to the drm module, for user-defined
   quirks.


I'd like to see documentation for the bit values of the quirks as well. 
And, ideally, this would also have some runtime API for manipulating the 
quirk list, so that way you can test new quirks without needing a reboot 
cycle.


To close the loop all the way on that I'd also want to be able to scrape 
the quirk list back out from that API, but that's not completely clean 
right now.  We're being a little cavalier with the quirk list as it 
stands because we don't differentiate among phy layers, and I can easily 
imagine a monitor that needs a quirk on DVI but where the same quirk on 
the same monitors' VGA would break it.  I don't think this has caused 
problems yet, but.



With this patch, my display works when I add
drm.edid_quirks=GSM:0x563f:0x180 to my kernel command line.  (0x80,
EDID_QUIRK_DISABLE_INFOFRAMES, makes it work with the nouveau driver;
0x100, EDID_QUIRK_NO_AUDIO, makes it work with the i915 driver.  I.e.,
the i915 driver is sending audio InfoFrames even when
drm_detect_hdmi_monitor returns false; bug?)


InfoFrames are not valid for non-HDMI sinks, so yes, I'd call that a bug.

Your original bug report is a little strange, particularly:

https://bugzilla.redhat.com/attachment.cgi?id=572790

Where the EDID for DP-1 appears to be truncated: the extension field 
(second byte from the end) is 1 as you'd expect for an HDMI monitor, but 
there's no extension block.  How big of a file do you get from 
/sys/class/drm/*/edid for that port?


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

Re: i915_driver_irq_handler: irq 42: nobody cared

[Jiri Slaby]

On 04/11/2012 12:40 PM, Daniel Vetter wrote:
 On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
 On Tue, 10 Apr 2012 22:32:12 +0200
 Daniel Vetter dan...@ffwll.ch wrote:

 On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-

 I tried 3.2 and 3.3. Although the spurious interrupts were always
 there, they occurred with frequency lower by a magnitude (15 vs. 300
 after X starts). So I bisected that and it lead to a commit which
 fixes bad tiling for me:
 http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=for-jiriid=79710e6ccabdac80c65cd13b944695ecc3e42a9d

 Pipelined fencing is pretty much just broken and we'll completely rip it
 out in 3.5. Does this also happen with 3.4-rc2?

 Does INTx- stay that way?  Or does it frequently read INTx+ if you
 sample it a lot?  If it stays as INTx-, then something other than the
 GPU is getting stuck (though it's possible this could be related to
 pipelined fencing, if the fences are programmed to point at some funky
 memory space).

Hi and sorry for the delay. It stays INTx-. And I tested that with patch
removing fencing.

 Shot in the dark, let's disable msi a bit. Can you try the below patch?

Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
busted, either in the card, the chipset or the kernel. Any idea how to
find out?

thanks,
-- 
js
suse labs


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

Re: Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 12:29 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 7:39 AM, Christian König deathsim...@vodafone.de 
 wrote:
 On 03.05.2012 09:21, Michel Dänzer wrote:

 On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

 From: Jerome Glissejgli...@redhat.com

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glissejgli...@redhat.com

 [...]

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
                        rdev-fence_drv[ring].scratch_reg -
                        rdev-scratch.reg_base;
        }
 -       rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
 +       rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

 Might want to ensure cpu_addr is 64 bit aligned, or there might be
 trouble on some architectures.


 With this change, Cayman cards will already use six scratch registers
 for the rings. It won't be possible to extend this scheme for even one
 additional ring, will it?


 That won't work anyway, since not all rings can deal with 64 bit fences, so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.

 This patch is fine with ring that can't emit directly 64bits, all you
 have to do is fix the emit_fence callback to properly handle it and
 then you have to fix the radeon_fence_read which can be move to a ring
 specific callback. Anyway point is that patchset works and is fine on
 current set of ring we have and it can work as easily for ring without
 easy 64bits value emitting. So please explain further why those patch
 can't work because as i just explained i don't see why.

 I have updated some v2 version of those patchset to handle the cayman
 and newer possibly running out of scratch reg and i also fix the
 alignment issue to be 64bits

 FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
 least), it's just memory writes so we could make the scratch pool
 bigger.

 Alex


 That's what my v2 does, just drop scratch reg for cayman and newer.

 Cheers,
 Jerome

Btw uploaded a v3 with some more thing like warnononce for extra
safety, better comment and trying to mitigate race btw cpu reading and
gpu writing fence.
http://people.freedesktop.org/~glisse/reset3/

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

Re: Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Alex Deucher]

On Thu, May 3, 2012 at 4:46 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 12:29 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 7:39 AM, Christian König deathsim...@vodafone.de 
 wrote:
 On 03.05.2012 09:21, Michel Dänzer wrote:

 On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

 From: Jerome Glissejgli...@redhat.com

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glissejgli...@redhat.com

 [...]

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
                        rdev-fence_drv[ring].scratch_reg -
                        rdev-scratch.reg_base;
        }
 -       rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
 +       rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

 Might want to ensure cpu_addr is 64 bit aligned, or there might be
 trouble on some architectures.


 With this change, Cayman cards will already use six scratch registers
 for the rings. It won't be possible to extend this scheme for even one
 additional ring, will it?


 That won't work anyway, since not all rings can deal with 64 bit fences, 
 so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.

 This patch is fine with ring that can't emit directly 64bits, all you
 have to do is fix the emit_fence callback to properly handle it and
 then you have to fix the radeon_fence_read which can be move to a ring
 specific callback. Anyway point is that patchset works and is fine on
 current set of ring we have and it can work as easily for ring without
 easy 64bits value emitting. So please explain further why those patch
 can't work because as i just explained i don't see why.

 I have updated some v2 version of those patchset to handle the cayman
 and newer possibly running out of scratch reg and i also fix the
 alignment issue to be 64bits

 FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
 least), it's just memory writes so we could make the scratch pool
 bigger.

 Alex


 That's what my v2 does, just drop scratch reg for cayman and newer.

 Cheers,
 Jerome

 Btw uploaded a v3 with some more thing like warnononce for extra
 safety, better comment and trying to mitigate race btw cpu reading and
 gpu writing fence.
 http://people.freedesktop.org/~glisse/reset3/

In patch:
http://people.freedesktop.org/~glisse/reset3/0003-drm-radeon-rework-fence-handling-drop-fence-list-v3.patch

You can drop this hunk:
+   if (rdev-family = CHIP_CAYMAN) {
+   /* because there is so many ring on newer GPU we can't use
+* scratch reg thus we need to use event, on those GPU there
+* is no AGP version and writting to system ram have always
+* been reliable so far
+*/
+   rdev-wb.enabled = true;
+   rdev-wb.use_event = true;
+   }

As the code right below it does the exact same thing.  It could
probably be extended to APUs as well since they will never have AGP
support.  I'll send out a patch.

Alex


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

[PATCH] drm/radeon: clarify and extend wb setup on APUs and NI+ asics

[alexdeucher]

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

Use family rather than DCE check for clarity, also always use
wb on APUs, there will never be AGP variants.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon_device.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 94f8561..8479617 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -241,8 +241,8 @@ int radeon_wb_init(struct radeon_device *rdev)
rdev-wb.use_event = true;
}
}
-   /* always use writeback/events on NI */
-   if (ASIC_IS_DCE5(rdev)) {
+   /* always use writeback/events on NI, APUs */
+   if (rdev-family = CHIP_PALM) {
rdev-wb.enabled = true;
rdev-wb.use_event = true;
}
-- 
1.7.7.5

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

Re: i915_driver_irq_handler: irq 42: nobody cared

[Daniel Vetter]

On Thu, May 03, 2012 at 09:56:08PM +0200, Jiri Slaby wrote:
 On 04/11/2012 12:40 PM, Daniel Vetter wrote:
  On Tue, Apr 10, 2012 at 01:34:11PM -0700, Jesse Barnes wrote:
  On Tue, 10 Apr 2012 22:32:12 +0200
  Daniel Vetter dan...@ffwll.ch wrote:
 
  On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
  Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
  TAbort- MAbort- SERR- PERR- INTx-
 
  I tried 3.2 and 3.3. Although the spurious interrupts were always
  there, they occurred with frequency lower by a magnitude (15 vs. 300
  after X starts). So I bisected that and it lead to a commit which
  fixes bad tiling for me:
  http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=for-jiriid=79710e6ccabdac80c65cd13b944695ecc3e42a9d
 
  Pipelined fencing is pretty much just broken and we'll completely rip it
  out in 3.5. Does this also happen with 3.4-rc2?
 
  Does INTx- stay that way?  Or does it frequently read INTx+ if you
  sample it a lot?  If it stays as INTx-, then something other than the
  GPU is getting stuck (though it's possible this could be related to
  pipelined fencing, if the fences are programmed to point at some funky
  memory space).
 
 Hi and sorry for the delay. It stays INTx-. And I tested that with patch
 removing fencing.
 
  Shot in the dark, let's disable msi a bit. Can you try the below patch?
 
 Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
 busted, either in the card, the chipset or the kernel. Any idea how to
 find out?

Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915_driver_irq_handler: irq 42: nobody cared

[Jiri Slaby]

On 05/03/2012 11:15 PM, Daniel Vetter wrote:
 Shot in the dark, let's disable msi a bit. Can you try the below patch?

 Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
 busted, either in the card, the chipset or the kernel. Any idea how to
 find out?
 
 Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?

Sure:
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
Express Integrated Graphics Controller [8086:29c2] (rev 02)

thanks,
-- 
js
suse labs


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

Re: Re: [PATCH 2/4] drm/radeon: convert fence to uint64_t

[Jerome Glisse]

On Thu, May 3, 2012 at 5:04 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, May 3, 2012 at 4:46 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 12:34 PM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 12:29 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Thu, May 3, 2012 at 11:56 AM, Jerome Glisse j.gli...@gmail.com wrote:
 On Thu, May 3, 2012 at 7:39 AM, Christian König deathsim...@vodafone.de 
 wrote:
 On 03.05.2012 09:21, Michel Dänzer wrote:

 On Mit, 2012-05-02 at 16:20 -0400, j.gli...@gmail.com wrote:

 From: Jerome Glissejgli...@redhat.com

 This convert fence to use uint64_t sequence number intention is
 to use the fact that uin64_t is big enough that we don't need to
 care about wrap around.

 Tested with and without writeback using 0xF000 as initial
 fence sequence and thus allowing to test the wrap around from
 32bits to 64bits.

 Signed-off-by: Jerome Glissejgli...@redhat.com

 [...]

 diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
 b/drivers/gpu/drm/radeon/radeon_fence.c
 index 7733429..6da1535 100644
 --- a/drivers/gpu/drm/radeon/radeon_fence.c
 +++ b/drivers/gpu/drm/radeon/radeon_fence.c
 @@ -386,9 +388,9 @@ int radeon_fence_driver_start_ring(struct
 radeon_device *rdev, int ring)
                        rdev-fence_drv[ring].scratch_reg -
                        rdev-scratch.reg_base;
        }
 -       rdev-fence_drv[ring].cpu_addr =rdev-wb.wb[index/4];
 +       rdev-fence_drv[ring].cpu_addr =u64*)rdev-wb.wb[index/4];

 Might want to ensure cpu_addr is 64 bit aligned, or there might be
 trouble on some architectures.


 With this change, Cayman cards will already use six scratch registers
 for the rings. It won't be possible to extend this scheme for even one
 additional ring, will it?


 That won't work anyway, since not all rings can deal with 64 bit fences, 
 so
 we need to still use 32 bit signaling and extend them to 64 bit while
 processing the fence value.

 Already working on that.

 Christian.

 This patch is fine with ring that can't emit directly 64bits, all you
 have to do is fix the emit_fence callback to properly handle it and
 then you have to fix the radeon_fence_read which can be move to a ring
 specific callback. Anyway point is that patchset works and is fine on
 current set of ring we have and it can work as easily for ring without
 easy 64bits value emitting. So please explain further why those patch
 can't work because as i just explained i don't see why.

 I have updated some v2 version of those patchset to handle the cayman
 and newer possibly running out of scratch reg and i also fix the
 alignment issue to be 64bits

 FWIW, we don't actually use scratch regs any more on r6xx+ (non-AGP at
 least), it's just memory writes so we could make the scratch pool
 bigger.

 Alex


 That's what my v2 does, just drop scratch reg for cayman and newer.

 Cheers,
 Jerome

 Btw uploaded a v3 with some more thing like warnononce for extra
 safety, better comment and trying to mitigate race btw cpu reading and
 gpu writing fence.
 http://people.freedesktop.org/~glisse/reset3/

 In patch:
 http://people.freedesktop.org/~glisse/reset3/0003-drm-radeon-rework-fence-handling-drop-fence-list-v3.patch

 You can drop this hunk:
 +       if (rdev-family = CHIP_CAYMAN) {
 +               /* because there is so many ring on newer GPU we can't use
 +                * scratch reg thus we need to use event, on those GPU there
 +                * is no AGP version and writting to system ram have always
 +                * been reliable so far
 +                */
 +               rdev-wb.enabled = true;
 +               rdev-wb.use_event = true;
 +       }

 As the code right below it does the exact same thing.  It could
 probably be extended to APUs as well since they will never have AGP
 support.  I'll send out a patch.

 Alex


Good catch updated patch
http://people.freedesktop.org/~glisse/reset3/

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

Re: i915_driver_irq_handler: irq 42: nobody cared

[Jesse Barnes]

On Thu, 03 May 2012 23:16:02 +0200
Jiri Slaby jsl...@suse.cz wrote:

 On 05/03/2012 11:15 PM, Daniel Vetter wrote:
  Shot in the dark, let's disable msi a bit. Can you try the below patch?
 
  Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
  busted, either in the card, the chipset or the kernel. Any idea how to
  find out?
  
  Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
 
 Sure:
 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
 Express Integrated Graphics Controller [8086:29c2] (rev 02)

Ok nevermind about the INTx-; now I'm not sure if it means anything or
not in an MSI context (the spec doesn't require it, but I thought our
devices would toggle it if they were sending interrupts).

But since line level works for you I guess it's ok to blacklist your
chipset until we poke some hw folks internally about this.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915_driver_irq_handler: irq 42: nobody cared

[Ben Widawsky]

On Thu, 3 May 2012 14:54:22 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:

 On Thu, 03 May 2012 23:16:02 +0200
 Jiri Slaby jsl...@suse.cz wrote:
 
  On 05/03/2012 11:15 PM, Daniel Vetter wrote:
   Shot in the dark, let's disable msi a bit. Can you try the below patch?
  
   Yeah, no IRQ_NONE at the end of i915_driver_irq_handler now. So MSI is
   busted, either in the card, the chipset or the kernel. Any idea how to
   find out?
   
   Ok, so MSI is busted. Can you please paste lspci -nn for you intel gpu?
  
  Sure:
  00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31
  Express Integrated Graphics Controller [8086:29c2] (rev 02)
 
 Ok nevermind about the INTx-; now I'm not sure if it means anything or
 not in an MSI context (the spec doesn't require it, but I thought our
 devices would toggle it if they were sending interrupts).
 
 But since line level works for you I guess it's ok to blacklist your
 chipset until we poke some hw folks internally about this.
 
 Thanks,

I occassionally see missed IRQ on 16 (which is my USB) but it has only
started showing up in fairly recent dinq (haven't tried Linus') kernels
(I'd been using this laptop for over a year).


-- 
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: improve sa allocator for multi ring load balancing

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

This add a per ring allocation management and load balance the
chunk of the temp buffer between each ring. A ring that often
fail to find a hole or worse have to wait for previous fence
will have more chance to grow over other ring. This ring is
properly CPU starve in a sense. Of course with no real user of
other ring this functionalities is hard to test but code seems
to work well (tested with 2 or 3 rings with main ring being either
first, in the middle or last).

Note it could be refine to decrease all ring before or after.
Right now it only change size of adjacent ring.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon.h|   30 ++-
 drivers/gpu/drm/radeon/radeon_gart.c   |2 +-
 drivers/gpu/drm/radeon/radeon_object.h |2 +-
 drivers/gpu/drm/radeon/radeon_ring.c   |2 +-
 drivers/gpu/drm/radeon/radeon_sa.c |  409 ++--
 5 files changed, 306 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index dd006ab..28bc338 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -113,10 +113,10 @@ extern int radeon_lockup_timeout;
 
 /* internal ring indices */
 /* r1xx+ has gfx CP ring */
-#define RADEON_RING_TYPE_GFX_INDEX  0
+#define RADEON_RING_TYPE_GFX_INDEX  1
 
 /* cayman has 2 compute CP rings */
-#define CAYMAN_RING_TYPE_CP1_INDEX 1
+#define CAYMAN_RING_TYPE_CP1_INDEX 0
 #define CAYMAN_RING_TYPE_CP2_INDEX 2
 
 /* hardcode those limit for now */
@@ -409,15 +409,26 @@ struct radeon_bo_list {
 
 struct radeon_sa_bo;
 
-struct radeon_sa_manager {
-   spinlock_t  lock;
-   struct radeon_bo*bo;
+struct radeon_ra_manager {
struct list_headsa_bo;
-   unsignedsize;
+   unsignedsoffset;
+   unsignedeoffset;
+   unsignedfoffset;
+   unsignedloffset;
+   unsignedstarve;
struct radeon_sa_bo *last;
-   uint64_tgpu_addr;
-   void*cpu_ptr;
-   uint32_tdomain;
+};
+
+struct radeon_sa_manager {
+   spinlock_t  lock;
+   struct radeon_bo*bo;
+   unsignedsize;
+   unsignednrings;
+   uint64_tgpu_addr;
+   void*cpu_ptr;
+   uint32_tdomain;
+   unsigned long   update_timeout;
+   struct radeon_ra_managerrings[RADEON_NUM_RINGS];
 };
 
 /* sub-allocation buffer */
@@ -427,6 +438,7 @@ struct radeon_sa_bo {
unsignedsoffset;
unsignedeoffset;
unsignedsize;
+   unsignedring;
struct radeon_fence *fence;
boolfree;
 };
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index cab012f..973c31b 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -291,7 +291,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
/* mark first vm as always in use, it's the system one */
r = radeon_sa_bo_manager_init(rdev, rdev-vm_manager.sa_manager,
  rdev-vm_manager.max_pfn * 8,
- RADEON_GEM_DOMAIN_VRAM);
+ RADEON_GEM_DOMAIN_VRAM, 1);
if (r) {
dev_err(rdev-dev, failed to allocate vm bo (%dKB)\n,
(rdev-vm_manager.max_pfn * 8)  10);
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 35e54da..0e7c099 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -148,7 +148,7 @@ extern struct radeon_bo_va *radeon_bo_va(struct radeon_bo 
*rbo,
  */
 extern int radeon_sa_bo_manager_init(struct radeon_device *rdev,
 struct radeon_sa_manager *sa_manager,
-unsigned size, u32 domain);
+unsigned size, u32 domain, unsigned 
nrings);
 extern void radeon_sa_bo_manager_fini(struct radeon_device *rdev,
  struct radeon_sa_manager *sa_manager);
 extern int radeon_sa_bo_manager_start(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index b279a61..ec0aab38 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -151,7 +151,7 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
 
r = radeon_sa_bo_manager_init(rdev, rdev-ring_tmp_bo,
   

[Bug 43477] rendering errors in unigine tropics and sanctuary (regression)

[bugzilla-daemon]

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

--- Comment #4 from imamdxl8...@gmail.com 2012-05-03 18:58:13 PDT ---
same result with Intel GMA 4500 with Mesa 8-series and Mesa 8.1-devel from git

-- 
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: Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
 On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
  Hi Luca, Maarten,
  
  On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
   On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis madman2...@gmail.com 
   wrote:
On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
   
dmitry.torok...@gmail.com wrote:
On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
On 2012-04-28 02:19 -0400, Alex Deucher wrote:
 On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler 
 nbow...@elliptictech.com wrote:
  Unfortunately, that's not the end of my VGA-related
  regressions. :(
 
  While tracking down the black screen issue, I've been having
  the monitor directly connected to the video card the whole
  time, but now when I'm connected through my KVM switch (an
  IOGear GCS1804), it appears that something's going wrong with
  reading the EDID, because the available modes are all screwed
  up (both console and X decide they want to drive the display
  at 1024x768).  Here's the output of xrandr on 3.2.15:
 
   % xrandr
   Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
  4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
  inverted right x axis y axis) 352mm x 264mm
  1600x1200  75.0*+   70.0 65.0 60.0
  1280x1024  85.0 +   75.0 60.0
  1920x1440  60.0
  1856x1392  60.0
  1792x1344  60.0
  1920x1200  74.9 59.9
  1680x1050  84.9 74.9 60.0
  1400x1050  85.0 74.9 60.0
  1440x900   84.8 75.0 59.9
  1280x960   85.0 60.0
  1360x768   60.0
  1280x800   84.9 74.9 59.8
  1152x864   75.0
  1280x768   84.8 74.9 59.9
  1024x768   85.0 75.1 75.0 70.1 60.0 
  43.5 43.5
  832x62474.6
  800x60085.1 72.2 75.0 60.3 56.2
  848x48060.0
  640x48085.0 75.0 72.8 72.8 66.7 
  60.0 59.9
  720x40085.0 87.8 70.1
  640x40085.1
  640x35085.1
  320x200   165.1
 
  And on 3.4-rc4+ (with your patch cherry-picked):
 
   % xrandr
   Screen 1: minimum 320 x 200, current 1024 x 768, maximum
  4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
  inverted right x axis y axis) 0mm x 0mm
  1024x768   60.0*
  800x60060.3 56.2
  848x48060.0
  640x48059.9
  320x200   165.1
 
  Running xrandr on 3.4-rc4+ also causes the screen to go black
  for a second when it does not on 3.2.15.  It also causes
  several messages of the form
 
   [drm] nouveau :01:00.0: Load detected on output B
 
  to be logged.  Also, looking at
  /sys/class/drm/card0-VGA-1/edid I see that it is empty on
  3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
  when the KVM is not involved.

 Were you ever able to fetch a EDID with the KVM involved?  KVMs
 are notorious for not connecting the ddc pins.
   
Yes, it works on 3.2.15 as described above.
   
I have the same (or similar) KVM (not in the office at the moment)
and I can confirm that with newer kernels EDID fecthing in flaky.
It's 50/50 if EDED retrieval succeeds or if it fails with:
   
Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208
   
Earlier kernels were able to retrieve EDEDs reliably.
   
This is with:
   
[1.678392] [drm] nouveau :01:00.0: Detected an NV50
generation card (0x086b00a2)

Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support

[Stephen Warren]

On 04/25/2012 03:45 AM, Thierry Reding wrote:
 This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
 currently has rudimentary GEM support and can run a console on the
 framebuffer as well as X using the xf86-video-modesetting driver. Only
 the RGB output is supported.
 
 HDMI support was taken from NVIDIA's Linux kernel tree but it doesn't
 quite work. EDID data can be retrieved but the output doesn't properly
 activate the connected TV.
 
 The DSI and TVO outputs and the HOST1X driver are just stubs that setup
 the corresponding resources but don't do anything useful yet.

I'm mainly going to comment on the device tree bindings here; hopefully
Jon and Terje can chime in on the code itself.

 diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt 
 b/Documentation/devicetree/bindings/gpu/drm/tegra.txt

 +Example:
 +
 +/memreserve/ 0x0e00 0x0200;
 +
 +...
 +
 +/ {
 + ...
 +
 + /* host1x */
 + host1x: host1x@5000 {
 + compatible = nvidia,tegra20-host1x;
 + reg = 0x5000 0x00024000;
 + interrupts = 0 64 0x04   /* cop syncpt */
 +   0 65 0x04   /* mpcore syncpt */
 +   0 66 0x04   /* cop general */
 +   0 67 0x04; /* mpcore general */
 + };

The host1x module is apparently a register bus, behind which all the
other modules sit. According to the address map in the TRM, all the
other modules appears to include all of MPE, VI, CSI, EPP, ISP, GR2D,
GR3D, DISPLAY A/B, HDMI, TVO, DSI, plus VG, VS, VCI, DSIB on Tegra30.

That said, I believe Terje wasn't convinced that all those modules are
really host1x children, just some. Can you check please, Terje?

Also, I wonder if host1x is really the parent of these modules,
register-bus-access-wise, or whether the bus covers the graphic host
registers at 0x5000-0x50023fff?

As such, I think the DT nodes for all those modules should be within the
host1x node (or perhaps graphics host node, pending above discussion):

host1x: host1x@5000 {
mpe@5404 { ... };
vi@5408 { ... };
...
};

host1x can easily instantiate all the child nodes simply by calling
of_platform_populate() at the end of its probe; see
sound/soc/tegra/tegra30_ahub.c for an example.

 + /* video-encoding/decoding */
 + mpe@5404 {
 + reg = 0x5404 0x0004;
 + interrupts = 0 68 0x04;
 + };

We'll probably end up needing a phandle from each of these nodes to
host1x, and a channel ID, so the drivers for these nodes can register
themselves with host1x. However, I it's probably OK to defer the DT
binding for this until we actually start working on command-channels.

 + /* graphics host */
 + graphics@5400 {
 + compatible = nvidia,tegra20-graphics;
 +
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;

I don't think those 3 properties are needed, unless there are child
nodes with registers.

 + display-controllers = disp1 disp2;
 + carveout = 0x0e00 0x0200;
 + host1x = host1x;
 + gart = gart;
 +
 + connectors {

I'm not sure that it makes sense to put the connectors nodes underneath
the graphics host node; the connectors aren't objects with registers
that are accessed through a bus managed by the graphics node. Equally,
the connectors could be useful outside of the graphics driver - e.g. the
audio driver might need to refer to an HDMI connector.

Instead, I'd probably put the connector nodes at the top level of the
device tree, and have graphics contain a property that lists the
phandles of all available connectors.

 + #address-cells = 1;
 + #size-cells = 0;
 +
 + connector@0 {
 + reg = 0;
 + edid = /incbin/(machine.edid);
 + output = lvds;
 + };

I think each of these needs some kind of compatible value to indicate
their type. Also, the ability to represent both HDMI video and audio
streams so that a sound card binding could use the HDMI connector too. I
see that drivers/extcon/ has appeared recently, and I wonder if the
connector nodes in DT shouldn't be handled by that subsystem?

 + connector@1 {
 + reg = 1;
 + output = hdmi;
 + ddc = i2c2;
 +
 + hpd-gpio = gpio 111 0; /* PN7 */
 + };
 + };
 + };
 +};

 diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c 
 b/arch/arm/mach-tegra/board-dt-tegra20.c

 + { host1x, pll_c,14400,  true },
 + { disp1,  pll_p,6,  true },
 + { disp2,  pll_p,6,  true },

Can we use these tables /just/ to 

Re: [PATCH] drm/radeon: clarify and extend wb setup on APUs and NI+ asics

[Michel Dänzer]

On Don, 2012-05-03 at 17:06 -0400, alexdeuc...@gmail.com wrote: 
 From: Alex Deucher alexander.deuc...@amd.com
 
 Use family rather than DCE check for clarity, also always use
 wb on APUs, there will never be AGP variants.
 
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com

Reviewed-by: Michel Dänzer michel.daen...@amd.com


-- 
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