Reply: Question on S3 on evergreen

[Huang, FrankR]

Dave, actually Alex helps me a lot in AMD internal. I appreciated him very 
much. He supports me for this project for nearly a year. But sometimes, he is a 
little busy with community's stuff. So I'll ask some quesitons here directly. 
Hope you guys can give me some suggestion(i.e. this S3 issue.) :)

Thanks,
Frank

-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: 2011-10-13 (???) 20:08
To: Xavier Bestel
Cc: Huang, FrankR; dri-devel at lists.freedesktop.org
Subject: Re: Question on S3 on evergreen

On Thu, Oct 13, 2011 at 1:07 PM, Xavier Bestel  wrote:
> On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
>> On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel  
>> wrote:
>> > Hi,
>> >
>> > On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
>> >> [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
>> >> functions from linux to CE.
>> >
>> > I imagine you already have checked with your company's lawyers, but if I
>> > understand correctly that means your drivers will be distributed under
>> > the GPL ?
>>
>> All the GPU driver code is licensed under MIT.
>
> Oh, I thought "linux" meant "kernel", not "X11".

The kernel drm driver code is all MIT licensed. The license is there
at the top of the files.

Dave.


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111013/5cf45794/attachment.htm>

Reply: Question on S3 on evergreen

[Huang, FrankR]

Xav, thanks for your reminder. Actually our law leam has already checked the 
license. As Dave said, the DRM kernel driver is all MIT-licensed and we will be 
free to use them. When the drm uses linux kernel function calls, we will use 
freebsd(none-GPL) equivalent to replace.
Dave, by the way, I want to ask you about some exceptions in DRM. you know in 
some files(i.e. drm_fb_helper.c), it includes MODULE_LICENSE("GPL and 
additional rights"). Does it mean it is GPL licensed? Is it free to use this 
file?

Thanks,
Frank


-Original Message-
From: Xavier Bestel [mailto:xavier.bes...@free.fr]
Sent: 2011-10-13 (???) 20:07
To: Dave Airlie
Cc: Huang, FrankR; dri-devel at lists.freedesktop.org
Subject: Re: Question on S3 on evergreen

On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
> On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel  
> wrote:
> > Hi,
> >
> > On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
> >> [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
> >> functions from linux to CE.
> >
> > I imagine you already have checked with your company's lawyers, but if I
> > understand correctly that means your drivers will be distributed under
> > the GPL ?
> 
> All the GPU driver code is licensed under MIT.

Oh, I thought "linux" meant "kernel", not "X11".

Xav



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111013/0ac0fe46/attachment-0001.html>

[PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Takashi Iwai]

At Thu, 13 Oct 2011 12:28:07 -0700,
Keith Packard wrote:
> 
> On Thu, 13 Oct 2011 20:05:49 +0200, Takashi Iwai  wrote:
> 
> > Yes, this looks more understandable, indeed.
> > Would you patch it by yourself or should I refresh the patch?
> > In either way, I'll test tomorrow, as I'm already at home without a
> > test machine.
> 
> I don't have time before Monday to look at this further.

OK, I'll refresh and test the patch tomorrow.


Takashi

drm/radeon/kms: improve performance of blit-copy

[Roland Scheidegger]

Am 13.10.2011 05:29, schrieb Ilija Hadzic:
> 
> The following set of patches will improve the performance of
> blit-copy functions for Radeon GPUs based on R600, R700, Evergreen
> and NI ASICs.
> 
> The foundation for improvement is the use of tiled mode access (which
> for copying bo's can be used regardless of whether the content is
> tiled or not), and segmenting the memory block being copied into
> rectangles whose edge ratio is between 1:1 and 1:2. This maximizes
> the number of PCIe transactions that use maximum payload size
> (typically 128 bytes) and also creates a memory access pattern that
> is more favorable for both VRAM and host DRAM than what's currently
> in the kernel.
> 
> To come up with the new blit-copy code, I did a lot of PCIe traffic
> analysis with the bus analyzer and also had many discussions with
> Alex, trying to explain what's going on (thanks to Alex for his
> time).
> 
> Below (at the end of this note) are the results of some benchmarks 
> that I did with various GPUs (all in the same host: Intel i7 CPU, X58
> chipset, three DRAM channels). To run the tests on your machine load
> the radeon module with 'benchmark=1 pcie_gen2=1' parameters. Most
> significant improvement is in the upstream (VRAM to GART) direction
> because that's where the PCIe transactions were fragmented and also
> where memory access pattern was such that it created a lot of 
> backpressure from the host.
> 
> It is also interesting that high-end devices (e.g. Cayman) exhibit 
> the least improvement and were the worst to begin with. This is 
> because high-end devices copy more tiles in parallel which in turn
> can create bank conflicts on host memory and cause the host to do
> lots of bank-close/precharge/bank-open cycles.
Interesting stuff! Nice results showing the low-end devices completely
blowing away the high-end ones for VRAM->GTT blits :-).
I guess it isn't possible to temporarily disable some RBEs or otherwise
reconfigure the chip that you could get the same performance for the
high-end chips? Granted the high-end chips are only much slower for
VRAM->GTT according to these results but even the other way it's still
~20% or so.
Anyway, can't comment much on the patches, though the idea certainly
seems to make sense.

Roland



> As an added "bonus", I also did some code cleanup and consolidated 
> the repeated code into common function, so r600 and evergreen/NI 
> parts now share the blit-copy code. I also expanded on the benchmark
> coverage, so the module now takes benckmark parameter value between 1
> and 8 and each results in running a different benchmark.
> 
> For details, see the commit log messages and the code. I have been
> running with these patches for a few months (and I kept rebasing them
> to drm-core-next as the public git progressed) and I used them in a
> system setup that does *many* copying of this kind (and does them
> frequently); I have not seen instabilities introduced by these
> patches. I also verified the correctness of the copy using test=1
> parameter for each GPU that I had and the test passed.
> 
> I would welcome some feedback and if you run the benchmarks with the
> new blit code, I would very much like to hear what kind of
> improvement you are seeing.
> 

[PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Takashi Iwai]

At Thu, 13 Oct 2011 09:40:29 -0700,
Keith Packard wrote:
> 
> On Thu, 13 Oct 2011 10:57:35 +0200, Takashi Iwai  wrote:
> 
> > This patch fixes the bug by recording the backlight level always
> > when changed but only when dev_priv->backlight_enabled is set.
> > In this way, the bogus value for disabling backlight can be skipped.
> 
> I think this is better than what we have, but I'm not sure it's quite
> what we want -- the backlight level will only be remembered when it is
> enabled, so requested changes that happen while the backlight is off
> will have no effect. And, requested changes while the panel is disabled
> will still go through to the hardware, which can cause problems with
> panel power sequencing.
> 
> I think intel_panel_set_backlight should always record the level passed
> in, but that intel_panel_disable_backlight and
> intel_panel_enable_backlight should use a lower-level function, shared
> with intel_panel_set_backlight that doesn't record the value:
> 
> intel_panel_actually_set_backlight(dev, level) {
> 
> }
> 
> intel_panel_set_backlight(dev, level) {
> dev_priv->backlight_level = level;
> if (dev_priv->backlight_enabled)
> intel_panel_actually_set_backlight(dev, level);
> }
> 
> intel_panel_enable_backlight(dev) {
> dev_priv->backlight_enabled = true;
> intel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
> }
> 
> intel_panel_disable_backlight(dev) {
> dev_priv->backlight_enabled = false;
> intel_panel_actually_set_backlight(dev, 0);
> }

Yes, this looks more understandable, indeed.
Would you patch it by yourself or should I refresh the patch?
In either way, I'll test tomorrow, as I'm already at home without a
test machine.


thanks,

Takashi

Question on S3 on evergreen

[Huang, FrankR]

Hi, 
I have a question on S3 suspend/resume process for evergreen
chipset.
Generally introduction, I am developing WEC7 graphics driver on
evergreen chipset. Alex guide me on this. And right now I move to S3
part work. I have ported radeon_suspend_kms() and radeon_resume_kms()
functions from linux to CE. Actually I have validated that the
evergreen_suspend() and evergreen_resume() work already on CE. But when
the resume work is done and the screen is shown up, I found the 3D
engine works wrong. The HW acceleration of it is not correct anymore.
Misrendering is happening. By tracing the root cause, I suspect that the
problem may be in evergreen_gpu_init()( in evergreen_startup) call when
resume(), but I am not sure. Can you guys tell me which part I should
debug?
By the way, the linux kernel source I used is from 2010.10. So
quite a lot patches have been committed into community during this
period. Right now, the kernel source I used is around date
2011.7(Version 3.0.0). Is there any patches update for S3 during this
period?



Thanks,
Frank 

No subject

install libtxc_dxtn

-- 
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/radeon/kms: consolidate GART code, fix memory fault after GPU lockup

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

From: Jerome Glisse 

After GPU lockup VRAM gart table is unpinned and thus its pointer
becomes unvalid. This patch move the unpin code to a common helper
function and set pointer to NULL so that page update code can check
if it should update GPU page table or not. That way bo still bound
to GART can be unbound (pci_unmap_page for all there page) properly
while there is no need to update the GPU page table.

Signed-off-by: Jerome Glisse 
cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c   |   12 +-
 drivers/gpu/drm/radeon/ni.c  |   13 +--
 drivers/gpu/drm/radeon/r100.c|6 ++-
 drivers/gpu/drm/radeon/r300.c|   16 ++--
 drivers/gpu/drm/radeon/r600.c|   17 +++--
 drivers/gpu/drm/radeon/radeon.h  |   22 +++-
 drivers/gpu/drm/radeon/radeon_gart.c |   66 -
 drivers/gpu/drm/radeon/rs400.c   |5 ++-
 drivers/gpu/drm/radeon/rs600.c   |   16 ++--
 drivers/gpu/drm/radeon/rv770.c   |   13 ++-
 10 files changed, 72 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index c4ffa14f..fe5cf3e 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -893,7 +893,7 @@ int evergreen_pcie_gart_enable(struct radeon_device *rdev)
u32 tmp;
int r;

-   if (rdev->gart.table.vram.robj == NULL) {
+   if (rdev->gart.robj == NULL) {
dev_err(rdev->dev, "No VRAM object for PCIE GART.\n");
return -EINVAL;
}
@@ -942,7 +942,6 @@ int evergreen_pcie_gart_enable(struct radeon_device *rdev)
 void evergreen_pcie_gart_disable(struct radeon_device *rdev)
 {
u32 tmp;
-   int r;

/* Disable all tables */
WREG32(VM_CONTEXT0_CNTL, 0);
@@ -962,14 +961,7 @@ void evergreen_pcie_gart_disable(struct radeon_device 
*rdev)
WREG32(MC_VM_MB_L1_TLB1_CNTL, tmp);
WREG32(MC_VM_MB_L1_TLB2_CNTL, tmp);
WREG32(MC_VM_MB_L1_TLB3_CNTL, tmp);
-   if (rdev->gart.table.vram.robj) {
-   r = radeon_bo_reserve(rdev->gart.table.vram.robj, false);
-   if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev->gart.table.vram.robj);
-   radeon_bo_unpin(rdev->gart.table.vram.robj);
-   radeon_bo_unreserve(rdev->gart.table.vram.robj);
-   }
-   }
+   radeon_gart_table_vram_unpin(rdev);
 }

 void evergreen_pcie_gart_fini(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8c79ca9..529aaee 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -931,7 +931,7 @@ int cayman_pcie_gart_enable(struct radeon_device *rdev)
 {
int r;

-   if (rdev->gart.table.vram.robj == NULL) {
+   if (rdev->gart.robj == NULL) {
dev_err(rdev->dev, "No VRAM object for PCIE GART.\n");
return -EINVAL;
}
@@ -973,8 +973,6 @@ int cayman_pcie_gart_enable(struct radeon_device *rdev)

 void cayman_pcie_gart_disable(struct radeon_device *rdev)
 {
-   int r;
-
/* Disable all tables */
WREG32(VM_CONTEXT0_CNTL, 0);
WREG32(VM_CONTEXT1_CNTL, 0);
@@ -990,14 +988,7 @@ void cayman_pcie_gart_disable(struct radeon_device *rdev)
WREG32(VM_L2_CNTL2, 0);
WREG32(VM_L2_CNTL3, L2_CACHE_BIGK_ASSOCIATIVITY |
   L2_CACHE_BIGK_FRAGMENT_SIZE(6));
-   if (rdev->gart.table.vram.robj) {
-   r = radeon_bo_reserve(rdev->gart.table.vram.robj, false);
-   if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev->gart.table.vram.robj);
-   radeon_bo_unpin(rdev->gart.table.vram.robj);
-   radeon_bo_unreserve(rdev->gart.table.vram.robj);
-   }
-   }
+   radeon_gart_table_vram_unpin(rdev);
 }

 void cayman_pcie_gart_fini(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 7fcdbbb..8ad6769 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -474,7 +474,7 @@ int r100_pci_gart_init(struct radeon_device *rdev)
 {
int r;

-   if (rdev->gart.table.ram.ptr) {
+   if (rdev->gart.ptr) {
WARN(1, "R100 PCI GART already initialized\n");
return 0;
}
@@ -530,10 +530,12 @@ void r100_pci_gart_disable(struct radeon_device *rdev)

 int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
+   u32 *gtt = rdev->gart.ptr;
+
if (i < 0 || i > rdev->gart.num_gpu_pages) {
return -EINVAL;
}
-   rdev->gart.table.ram.ptr[i] = cpu_to_le32(lower_32_bits(addr));
+   gtt[i] = cpu_to_le32(lower_32_bits(addr));
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 55a7f19..6c62d88 

xf86-video-modesetting cursor patch

[James Simmons]

Hi!
I tried the xf86-video-modesetting driver with the new via KMS 
driver. It worked well but I had to turn off the cursor since I haven't 
finished the cursor in the kernel driver yet. By default the SWCursor 
option is set to false but when I placed that option in my xorg.conf file
it never set SWCursor to TRUE. Also a buffer was still being allocated 
even with the software curor. This patch address this issue. 

P.S
I also tried the xorg driver on a i915 device with a LVDS but the
screen was distored. It looks like a incorrect pitch size. I didn't see 
that with my via driver.

diff --git a/src/driver.c b/src/driver.c
index bde690c..1d62b7a 100644
--- a/src/driver.c
+++ b/src/driver.c
@@ -471,7 +471,7 @@ PreInit(ScrnInfoPtr pScrn, int flags)
 memcpy(ms->Options, Options, sizeof(Options));
 xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, ms->Options);

-if (xf86ReturnOptValBool(ms->Options, OPTION_SW_CURSOR, FALSE)) {
+if (xf86ReturnOptValBool(ms->Options, OPTION_SW_CURSOR, TRUE)) {
ms->SWCursor = TRUE;
 }

@@ -551,7 +551,8 @@ CreateScreenResources(ScreenPtr pScreen)

 drmmode_uevent_init(pScrn, >drmmode);

-drmmode_map_cursor_bos(pScrn, >drmmode);
+if (!ms->SWCursor)
+   drmmode_map_cursor_bos(pScrn, >drmmode);
 pixels = drmmode_map_front_bo(>drmmode);
 if (!pixels)
return FALSE;

[PATCH 12/12] Force always inline for gcc 4.5 when optimizing for size

[Andi Kleen]

From: Andi Kleen 

I found that gcc 4.5 didn't inline a lot of inlines with
CONFIG_OPTIMIZE_INLINING and CONFIG_CC_OPTIMIZE_FOR_SIZE. It was quite
common to have very small inlines to be out of line, or worse inline
statics in include files to be out of line with a copy for every file
using it too.

This is handily visible in a function graph trace for might_fault:

 10)   |might_fault() {
 10)   |  _cond_resched() {
 10)   |should_resched() {
 10)   |  need_resched() {
 10)   0.063 us|test_ti_thread_flag();
 10)   0.643 us|  }
 10)   1.238 us|}
 10)   1.845 us|  }
 10)   2.438 us|}

Note all of these functions are very small and should be definitely
inlined in each other. In many cases even copy_from_user
ends up out of line now which is really bad!

If I switch to -O2 it is also not quite as bad, but since a lot
of people use -Os I was trying to fix it up.

So this patch forces inlining with gcc 4.5 with -Os.

Unfortunately it costs some code size with just this patch.

   textdata bss dec hex filename
115070351940276 1191936 14639247 df608f vmlinux-O2
101898581908124 1187840 13285822 cab9be vmlinux-Os-force
9808525 1940204 1187840 12936569 c56579 vmlinux-Os-orig

It turned out most of this was because of unnecessary inlines.
With a lot of inlines removed I now get:

111758241977200 1191936 14344960 dae300 
vmlinux-inlines-removed-no-optimize
116425302018416 1191936 14852882 e2a312 
vmlinux-master-no-optimize
115304392001264 1191936 14723639 e0aa37 vmlinux-master-optimize

which is significantly smaller.

I haven't tested earlier gcc 4.x versions, but they may need
the same treatment.

Signed-off-by: Andi Kleen 
---
 include/linux/compiler-gcc.h |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 59e4028..e477a7c 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -44,9 +44,12 @@
 /*
  * Force always-inline if the user requests it so via the .config,
  * or if gcc is too old:
+ * When optimizing for size on gcc 4.5 always force inlining too.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
-!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
+!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) || \
+(defined(CONFIG_CC_OPTIMIZE_FOR_SIZE) && \
+   (__GNUC__ == 4 && __GNUC_MINOR__ == 5))
 # define inlineinline  __attribute__((always_inline))
 # define __inline____inline__  __attribute__((always_inline))
 # define __inline  __inline__attribute__((always_inline))
-- 
1.7.4.4

[PATCH 11/12] i915: Move i915_read/write out of line

[Andi Kleen]

From: Andi Kleen 

With the tracing code in there they are far too big to inline.

.text savings compared to a non force inline kernel:

i915_restore_display4393   12036   +7643
i915_save_display   4295   11459   +7164
i915_handle_error   2979   +3687
i915_driver_irq_handler 29235086   +2163
i915_ringbuffer_info 4581661   +1203
i915_save_vga  -1200   +1200
i915_driver_irq_uninstall4531624   +1171
i915_driver_irq_postinstall  9132078   +1165
ironlake_enable_drps 7191872   +1153
i915_restore_vga   -1142   +1142
intel_display_capture_error_state7842030   +1246
intel_init_emon  7192016   +1297

and more ...

[AK: these are older numbers, with the new SNB forcewake checks
it will be even worse]

Cc: keithp at keithp.com
Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/i915/i915_drv.c |   40 +++
 drivers/gpu/drm/i915/i915_drv.h |   22 ++--
 2 files changed, 43 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f07e425..c2de142 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -895,3 +895,43 @@ module_exit(i915_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+
+/* We give fast paths for the really cool registers */
+#define NEEDS_FORCE_WAKE(dev_priv, reg) \
+   (((dev_priv)->info->gen >= 6) && \
+   ((reg) < 0x4) && \
+   ((reg) != FORCEWAKE))
+
+#define __i915_read(x, y) \
+u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
+   u##x val = 0; \
+   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
+   gen6_gt_force_wake_get(dev_priv); \
+   val = read##y(dev_priv->regs + reg); \
+   gen6_gt_force_wake_put(dev_priv); \
+   } else { \
+   val = read##y(dev_priv->regs + reg); \
+   } \
+   trace_i915_reg_rw(false, reg, val, sizeof(val)); \
+   return val; \
+}
+
+__i915_read(8, b)
+__i915_read(16, w)
+__i915_read(32, l)
+__i915_read(64, q)
+#undef __i915_read
+
+#define __i915_write(x, y) \
+void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val) { \
+   trace_i915_reg_rw(true, reg, val, sizeof(val)); \
+   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
+   __gen6_gt_wait_for_fifo(dev_priv); \
+   } \
+   write##y(val, dev_priv->regs + reg); \
+}
+__i915_write(8, b)
+__i915_write(16, w)
+__i915_write(32, l)
+__i915_write(64, q)
+#undef __i915_write
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..7d171ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1354,18 +1354,7 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private 
*dev_priv);
((reg) != FORCEWAKE))

 #define __i915_read(x, y) \
-static inline u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
-   u##x val = 0; \
-   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
-   gen6_gt_force_wake_get(dev_priv); \
-   val = read##y(dev_priv->regs + reg); \
-   gen6_gt_force_wake_put(dev_priv); \
-   } else { \
-   val = read##y(dev_priv->regs + reg); \
-   } \
-   trace_i915_reg_rw(false, reg, val, sizeof(val)); \
-   return val; \
-}
+   u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);

 __i915_read(8, b)
 __i915_read(16, w)
@@ -1374,13 +1363,8 @@ __i915_read(64, q)
 #undef __i915_read

 #define __i915_write(x, y) \
-static inline void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, 
u##x val) { \
-   trace_i915_reg_rw(true, reg, val, sizeof(val)); \
-   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
-   __gen6_gt_wait_for_fifo(dev_priv); \
-   } \
-   write##y(val, dev_priv->regs + reg); \
-}
+   void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x 
val);
+
 __i915_write(8, b)
 __i915_write(16, w)
 __i915_write(32, l)
-- 
1.7.4.4

[PATCH 10/12] REISERFS: reiserfs drop unnecessary inlines

[Andi Kleen]

From: Andi Kleen 

Drop some inlines to shrink code size with force inline

Still some unfixed growth in:

balance_leaf71908766   +1576
search_by_key   19633317   +1354

Cc: viro at zeniv.linux.org.uk
Cc: fweisbec at gmail.com
Signed-off-by: Andi Kleen 
---
 fs/reiserfs/do_balan.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/reiserfs/do_balan.c b/fs/reiserfs/do_balan.c
index 60c0804..8b3c44c 100644
--- a/fs/reiserfs/do_balan.c
+++ b/fs/reiserfs/do_balan.c
@@ -21,7 +21,7 @@
 #include 
 #include 

-static inline void buffer_info_init_left(struct tree_balance *tb,
+static void buffer_info_init_left(struct tree_balance *tb,
  struct buffer_info *bi)
 {
bi->tb  = tb;
@@ -30,7 +30,7 @@ static inline void buffer_info_init_left(struct tree_balance 
*tb,
bi->bi_position = get_left_neighbor_position(tb, 0);
 }

-static inline void buffer_info_init_right(struct tree_balance *tb,
+static void buffer_info_init_right(struct tree_balance *tb,
   struct buffer_info *bi)
 {
bi->tb  = tb;
@@ -39,7 +39,7 @@ static inline void buffer_info_init_right(struct tree_balance 
*tb,
bi->bi_position = get_right_neighbor_position(tb, 0);
 }

-static inline void buffer_info_init_tbS0(struct tree_balance *tb,
+static void buffer_info_init_tbS0(struct tree_balance *tb,
  struct buffer_info *bi)
 {
bi->tb  = tb;
@@ -48,7 +48,7 @@ static inline void buffer_info_init_tbS0(struct tree_balance 
*tb,
bi->bi_position = PATH_H_POSITION(tb->tb_path, 1);
 }

-static inline void buffer_info_init_bh(struct tree_balance *tb,
+static void buffer_info_init_bh(struct tree_balance *tb,
struct buffer_info *bi,
struct buffer_head *bh)
 {
@@ -58,7 +58,7 @@ static inline void buffer_info_init_bh(struct tree_balance 
*tb,
bi->bi_position = 0;
 }

-inline void do_balance_mark_leaf_dirty(struct tree_balance *tb,
+void do_balance_mark_leaf_dirty(struct tree_balance *tb,
   struct buffer_head *bh, int flag)
 {
journal_mark_dirty(tb->transaction_handle,
@@ -1967,7 +1967,7 @@ static void check_internal_levels(struct tree_balance *tb)

 */

-static inline void do_balance_starts(struct tree_balance *tb)
+static void do_balance_starts(struct tree_balance *tb)
 {
/* use print_cur_tb() to see initial state of struct
   tree_balance */
@@ -1983,7 +1983,7 @@ static inline void do_balance_starts(struct tree_balance 
*tb)
 #endif
 }

-static inline void do_balance_completed(struct tree_balance *tb)
+static void do_balance_completed(struct tree_balance *tb)
 {

 #ifdef CONFIG_REISERFS_CHECK
-- 
1.7.4.4

[PATCH 09/12] Don't use inline node_page_state for sysfs output functions

[Andi Kleen]

From: Andi Kleen 

These are not time critical, and using an out of line function
saves about 2.5k text on a non force inline kernel.

I left the main hotpath user -- readahead -- inline for now.

Signed-off-by: Andi Kleen 
---
 drivers/base/node.c |   72 +++---
 1 files changed, 39 insertions(+), 33 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 793f796..0b8e7a2 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -58,6 +58,12 @@ static inline ssize_t node_read_cpulist(struct sys_device 
*dev,
 static SYSDEV_ATTR(cpumap,  S_IRUGO, node_read_cpumask, NULL);
 static SYSDEV_ATTR(cpulist, S_IRUGO, node_read_cpulist, NULL);

+/* Don't inline */
+static unsigned long my_node_page_state(int node, enum zone_stat_item item)
+{
+   return node_page_state(node, item);
+}
+
 #define K(x) ((x) << (PAGE_SHIFT - 10))
 static ssize_t node_read_meminfo(struct sys_device * dev,
struct sysdev_attribute *attr, char * buf)
@@ -82,16 +88,16 @@ static ssize_t node_read_meminfo(struct sys_device * dev,
   nid, K(i.totalram),
   nid, K(i.freeram),
   nid, K(i.totalram - i.freeram),
-  nid, K(node_page_state(nid, NR_ACTIVE_ANON) +
-   node_page_state(nid, NR_ACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_INACTIVE_ANON) +
-   node_page_state(nid, NR_INACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_ACTIVE_ANON)),
-  nid, K(node_page_state(nid, NR_INACTIVE_ANON)),
-  nid, K(node_page_state(nid, NR_ACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_INACTIVE_FILE)),
-  nid, K(node_page_state(nid, NR_UNEVICTABLE)),
-  nid, K(node_page_state(nid, NR_MLOCK)));
+  nid, K(my_node_page_state(nid, NR_ACTIVE_ANON) +
+   my_node_page_state(nid, NR_ACTIVE_FILE)),
+  nid, K(my_node_page_state(nid, NR_INACTIVE_ANON) +
+   my_node_page_state(nid, NR_INACTIVE_FILE)),
+  nid, K(my_node_page_state(nid, NR_ACTIVE_ANON)),
+  nid, K(my_node_page_state(nid, NR_INACTIVE_ANON)),
+  nid, K(my_node_page_state(nid, NR_ACTIVE_FILE)),
+  nid, K(my_node_page_state(nid, NR_INACTIVE_FILE)),
+  nid, K(my_node_page_state(nid, NR_UNEVICTABLE)),
+  nid, K(my_node_page_state(nid, NR_MLOCK)));

 #ifdef CONFIG_HIGHMEM
n += sprintf(buf + n,
@@ -123,30 +129,30 @@ static ssize_t node_read_meminfo(struct sys_device * dev,
   "Node %d AnonHugePages:  %8lu kB\n"
 #endif
,
-  nid, K(node_page_state(nid, NR_FILE_DIRTY)),
-  nid, K(node_page_state(nid, NR_WRITEBACK)),
-  nid, K(node_page_state(nid, NR_FILE_PAGES)),
-  nid, K(node_page_state(nid, NR_FILE_MAPPED)),
-  nid, K(node_page_state(nid, NR_ANON_PAGES)
+  nid, K(my_node_page_state(nid, NR_FILE_DIRTY)),
+  nid, K(my_node_page_state(nid, NR_WRITEBACK)),
+  nid, K(my_node_page_state(nid, NR_FILE_PAGES)),
+  nid, K(my_node_page_state(nid, NR_FILE_MAPPED)),
+  nid, K(my_node_page_state(nid, NR_ANON_PAGES)
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-   + node_page_state(nid, NR_ANON_TRANSPARENT_HUGEPAGES) *
+   + my_node_page_state(nid, 
NR_ANON_TRANSPARENT_HUGEPAGES) *
HPAGE_PMD_NR
 #endif
   ),
-  nid, K(node_page_state(nid, NR_SHMEM)),
-  nid, node_page_state(nid, NR_KERNEL_STACK) *
+  nid, K(my_node_page_state(nid, NR_SHMEM)),
+  nid, my_node_page_state(nid, NR_KERNEL_STACK) *
THREAD_SIZE / 1024,
-  nid, K(node_page_state(nid, NR_PAGETABLE)),
-  nid, K(node_page_state(nid, NR_UNSTABLE_NFS)),
-  nid, K(node_page_state(nid, NR_BOUNCE)),
-  nid, K(node_page_state(nid, NR_WRITEBACK_TEMP)),
-  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE) +
-   node_page_state(nid, NR_SLAB_UNRECLAIMABLE)),
-  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE)),
-  nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE))
+  nid, K(my_node_page_state(nid, NR_PAGETABLE)),
+  nid, K(my_node_page_state(nid, NR_UNSTABLE_NFS)),
+  nid, K(my_node_page_state(nid, NR_BOUNCE)),
+   

[PATCH 08/12] X86: Move alloc_intr_gate out of line

[Andi Kleen]

From: Andi Kleen 

This saves about 2.5k text on a non force inline kernel.

Cc: x86 at kernel.org
Signed-off-by: Andi Kleen 
---
 arch/x86/include/asm/desc.h |   17 +
 arch/x86/kernel/irqinit.c   |   20 
 2 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 41935fa..f7183e1 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -336,22 +336,7 @@ extern int first_system_vector;
 /* used_vectors is BITMAP for irq is not managed by percpu vector_irq */
 extern unsigned long used_vectors[];

-static inline void alloc_system_vector(int vector)
-{
-   if (!test_bit(vector, used_vectors)) {
-   set_bit(vector, used_vectors);
-   if (first_system_vector > vector)
-   first_system_vector = vector;
-   } else {
-   BUG();
-   }
-}
-
-static inline void alloc_intr_gate(unsigned int n, void *addr)
-{
-   alloc_system_vector(n);
-   set_intr_gate(n, addr);
-}
+void alloc_intr_gate(unsigned int n, void *addr);

 /*
  * This routine sets up an interrupt gate at directory privilege level 3.
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index b3300e6..b6e769b 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -162,6 +162,26 @@ void setup_vector_irq(int cpu)
__setup_vector_irq(cpu);
 }

+static void alloc_system_vector(int vector)
+{
+   if (!test_bit(vector, used_vectors)) {
+   set_bit(vector, used_vectors);
+   if (first_system_vector > vector)
+   first_system_vector = vector;
+   } else
+   BUG();
+}
+
+/*
+ * This could be made __init if xen didn't abuse it in its
+ * suspend path!
+ */
+void alloc_intr_gate(unsigned int n, void *addr)
+{
+   alloc_system_vector(n);
+   set_intr_gate(n, addr);
+}
+
 static void __init smp_intr_init(void)
 {
 #ifdef CONFIG_SMP
-- 
1.7.4.4

[PATCH 07/12] RADEON: Move more code out of line

[Andi Kleen]

From: Andi Kleen 

With this patch I'm only about 50k larger with DRM debugging
enables (why is that enabled by default?!?), and slightly
smaller without.

Cc: airlied at linux.ie
Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/radeon/r100.c |   39 ++
 drivers/gpu/drm/radeon/r300_cmdbuf.c  |2 +-
 drivers/gpu/drm/radeon/r600.c |4 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c|2 +-
 drivers/gpu/drm/radeon/radeon.h   |   39 +--
 drivers/gpu/drm/radeon/radeon_atombios.c  |4 +-
 drivers/gpu/drm/radeon/radeon_irq.c   |2 +-
 drivers/gpu/drm/radeon/radeon_legacy_tv.c |2 +-
 drivers/gpu/drm/radeon/radeon_object.c|   41 
 drivers/gpu/drm/radeon/radeon_object.h|   42 ++--
 drivers/gpu/drm/radeon/radeon_state.c |   16 +-
 11 files changed, 106 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 6720929..1bbed1f 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -4107,3 +4107,42 @@ void r100_io_wreg(struct radeon_device *rdev, u32 reg, 
u32 v)
iowrite32(v, rdev->rio_mem + RADEON_MM_DATA);
}
 }
+
+/* Better place? */
+u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
+{
+   struct radeon_cs_chunk *ibc = >chunks[p->chunk_ib_idx];
+   u32 pg_idx, pg_offset;
+   u32 idx_value = 0;
+   int new_page;
+
+   pg_idx = (idx * 4) / PAGE_SIZE;
+   pg_offset = (idx * 4) % PAGE_SIZE;
+
+   if (ibc->kpage_idx[0] == pg_idx)
+   return ibc->kpage[0][pg_offset/4];
+   if (ibc->kpage_idx[1] == pg_idx)
+   return ibc->kpage[1][pg_offset/4];
+
+   new_page = radeon_cs_update_pages(p, pg_idx);
+   if (new_page < 0) {
+   p->parser_error = new_page;
+   return 0;
+   }
+
+   idx_value = ibc->kpage[new_page][pg_offset/4];
+   return idx_value;
+}
+
+void radeon_ring_write(struct radeon_device *rdev, uint32_t v)
+{
+#if DRM_DEBUG_CODE
+   if (rdev->cp.count_dw <= 0) {
+   DRM_ERROR("radeon: writting more dword to ring than expected 
!\n");
+   }
+#endif
+   rdev->cp.ring[rdev->cp.wptr++] = v;
+   rdev->cp.wptr &= rdev->cp.ptr_mask;
+   rdev->cp.count_dw--;
+   rdev->cp.ring_free_dw--;
+}
diff --git a/drivers/gpu/drm/radeon/r300_cmdbuf.c 
b/drivers/gpu/drm/radeon/r300_cmdbuf.c
index c5c2742..1fe98b4 100644
--- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
+++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
@@ -791,7 +791,7 @@ static __inline__ int 
r300_emit_packet3(drm_radeon_private_t *dev_priv,
 /**
  * Emit the sequence to pacify R300.
  */
-static __inline__ void r300_pacify(drm_radeon_private_t *dev_priv)
+static void r300_pacify(drm_radeon_private_t *dev_priv)
 {
uint32_t cache_z, cache_3d, cache_2d;
RING_LOCALS;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 720dd99..c85047f 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3137,7 +3137,7 @@ int r600_irq_set(struct radeon_device *rdev)
return 0;
 }

-static inline void r600_irq_ack(struct radeon_device *rdev)
+static void r600_irq_ack(struct radeon_device *rdev)
 {
u32 tmp;

@@ -3238,7 +3238,7 @@ void r600_irq_disable(struct radeon_device *rdev)
r600_disable_interrupt_state(rdev);
 }

-static inline u32 r600_get_ih_wptr(struct radeon_device *rdev)
+static u32 r600_get_ih_wptr(struct radeon_device *rdev)
 {
u32 wptr, tmp;

diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index 9aa74c3..bbbafe6 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -450,7 +450,7 @@ set_default_state(struct radeon_device *rdev)
radeon_ring_write(rdev, sq_stack_resource_mgmt_2);
 }

-static inline uint32_t i2f(uint32_t input)
+static uint32_t i2f(uint32_t input)
 {
u32 result, i, exponent, fraction;

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8ac6cba..5ed7ef7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -601,32 +601,7 @@ struct radeon_cs_parser {

 extern int radeon_cs_update_pages(struct radeon_cs_parser *p, int pg_idx);
 extern int radeon_cs_finish_pages(struct radeon_cs_parser *p);
-
-
-static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
-{
-   struct radeon_cs_chunk *ibc = >chunks[p->chunk_ib_idx];
-   u32 pg_idx, pg_offset;
-   u32 idx_value = 0;
-   int new_page;
-
-   pg_idx = (idx * 4) / PAGE_SIZE;
-   pg_offset = (idx * 4) % PAGE_SIZE;
-
-   if (ibc->kpage_idx[0] == pg_idx)
-   return ibc->kpage[0][pg_offset/4];
-   if (ibc->kpage_idx[1] == pg_idx)
-   return 

[PATCH 06/12] RADEON: Remove more bogus inlines in the radeon driver.

[Andi Kleen]

From: Andi Kleen 

Remove bogus inlines in evergreen and r100.

Cc: airlied at linux.ie
Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/radeon/evergreen.c  |4 +-
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +-
 drivers/gpu/drm/radeon/r100.c   |  106 +-
 drivers/gpu/drm/radeon/r100_track.h |  110 ++-
 4 files changed, 114 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index c4ffa14f..1c5cd09 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2586,7 +2586,7 @@ int evergreen_irq_set(struct radeon_device *rdev)
return 0;
 }

-static inline void evergreen_irq_ack(struct radeon_device *rdev)
+static void evergreen_irq_ack(struct radeon_device *rdev)
 {
u32 tmp;

@@ -2697,7 +2697,7 @@ void evergreen_irq_suspend(struct radeon_device *rdev)
r600_rlc_stop(rdev);
 }

-static inline u32 evergreen_get_ih_wptr(struct radeon_device *rdev)
+static u32 evergreen_get_ih_wptr(struct radeon_device *rdev)
 {
u32 wptr, tmp;

diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 2eb2518..7eb78b3 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -584,7 +584,7 @@ set_default_state(struct radeon_device *rdev)

 }

-static inline uint32_t i2f(uint32_t input)
+static uint32_t i2f(uint32_t input)
 {
u32 result, i, exponent, fraction;

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9a1efac..6720929 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -68,6 +68,108 @@ MODULE_FIRMWARE(FIRMWARE_R520);
  * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
  */

+int r100_reloc_pitch_offset(struct radeon_cs_parser *p,
+   struct radeon_cs_packet *pkt,
+   unsigned idx,
+   unsigned reg)
+{
+   int r;
+   u32 tile_flags = 0;
+   u32 tmp;
+   struct radeon_cs_reloc *reloc;
+   u32 value;
+
+   r = r100_cs_packet_next_reloc(p, );
+   if (r) {
+   DRM_ERROR("No reloc for ib[%d]=0x%04X\n",
+ idx, reg);
+   r100_cs_dump_packet(p, pkt);
+   return r;
+   }
+   value = radeon_get_ib_value(p, idx);
+   tmp = value & 0x003f;
+   tmp += (((u32)reloc->lobj.gpu_offset) >> 10);
+
+   if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO)
+   tile_flags |= RADEON_DST_TILE_MACRO;
+   if (reloc->lobj.tiling_flags & RADEON_TILING_MICRO) {
+   if (reg == RADEON_SRC_PITCH_OFFSET) {
+   DRM_ERROR("Cannot src blit from microtiled surface\n");
+   r100_cs_dump_packet(p, pkt);
+   return -EINVAL;
+   }
+   tile_flags |= RADEON_DST_TILE_MICRO;
+   }
+
+   tmp |= tile_flags;
+   p->ib->ptr[idx] = (value & 0x3fc0) | tmp;
+   return 0;
+}
+
+int r100_packet3_load_vbpntr(struct radeon_cs_parser *p,
+struct radeon_cs_packet *pkt,
+int idx)
+{
+   unsigned c, i;
+   struct radeon_cs_reloc *reloc;
+   struct r100_cs_track *track;
+   int r = 0;
+   volatile uint32_t *ib;
+   u32 idx_value;
+
+   ib = p->ib->ptr;
+   track = (struct r100_cs_track *)p->track;
+   c = radeon_get_ib_value(p, idx++) & 0x1F;
+   if (c > 16) {
+   DRM_ERROR("Only 16 vertex buffers are allowed %d\n",
+ pkt->opcode);
+   r100_cs_dump_packet(p, pkt);
+   return -EINVAL;
+   }
+   track->num_arrays = c;
+   for (i = 0; i < (c - 1); i+=2, idx+=3) {
+   r = r100_cs_packet_next_reloc(p, );
+   if (r) {
+   DRM_ERROR("No reloc for packet3 %d\n",
+ pkt->opcode);
+   r100_cs_dump_packet(p, pkt);
+   return r;
+   }
+   idx_value = radeon_get_ib_value(p, idx);
+   ib[idx+1] = radeon_get_ib_value(p, idx + 1) + 
((u32)reloc->lobj.gpu_offset);
+
+   track->arrays[i + 0].esize = idx_value >> 8;
+   track->arrays[i + 0].robj = reloc->robj;
+   track->arrays[i + 0].esize &= 0x7F;
+   r = r100_cs_packet_next_reloc(p, );
+   if (r) {
+   DRM_ERROR("No reloc for packet3 %d\n",
+ pkt->opcode);
+   r100_cs_dump_packet(p, pkt);
+   return r;
+   }
+   ib[idx+2] = radeon_get_ib_value(p, idx + 2) + 
((u32)reloc->lobj.gpu_offset);
+   track->arrays[i + 1].robj = reloc->robj;
+   

[PATCH 05/12] FB_ATY: Move register accesses out of line

[Andi Kleen]

From: Andi Kleen 

This fixes size regressions like

radeon_set_suspend  17247873   +6149
radeon_reinitialize_M10 39749285   +5311
radeon_pm_disable_dynamic_mode   8686125   +5257
radeon_pm_enable_dynamic_mode9856065   +5080
radeon_pm_start_mclk_sclk  -4614   +4614
radeon_write_mode   12525377   +4125

among others compared to a non force inline kernel.

Cc: David Airlie 
Cc: benh at kernel.crashing.org
Signed-off-by: Andi Kleen 
---
 drivers/video/aty/radeon_accel.c |   88 ++
 drivers/video/aty/radeonfb.h |   96 +++---
 2 files changed, 95 insertions(+), 89 deletions(-)

diff --git a/drivers/video/aty/radeon_accel.c b/drivers/video/aty/radeon_accel.c
index a469a3d..0f1e367 100644
--- a/drivers/video/aty/radeon_accel.c
+++ b/drivers/video/aty/radeon_accel.c
@@ -326,3 +326,91 @@ void radeonfb_engine_init (struct radeonfb_info *rinfo)

radeon_engine_idle ();
 }
+
+
+void _OUTREGP(struct radeonfb_info *rinfo, u32 addr, u32 val, u32 mask)
+{
+   unsigned long flags;
+   unsigned int tmp;
+
+   spin_lock_irqsave(>reg_lock, flags);
+   tmp = INREG(addr);
+   tmp &= (mask);
+   tmp |= (val);
+   OUTREG(addr, tmp);
+   spin_unlock_irqrestore(>reg_lock, flags);
+}
+
+
+/*
+ * Note about PLL register accesses:
+ *
+ * I have removed the spinlock on them on purpose. The driver now
+ * expects that it will only manipulate the PLL registers in normal
+ * task environment, where radeon_msleep() will be called, protected
+ * by a semaphore (currently the console semaphore) so that no conflict
+ * will happen on the PLL register index.
+ *
+ * With the latest changes to the VT layer, this is guaranteed for all
+ * calls except the actual drawing/blits which aren't supposed to use
+ * the PLL registers anyway
+ *
+ * This is very important for the workarounds to work properly. The only
+ * possible exception to this rule is the call to unblank(), which may
+ * be done at irq time if an oops is in progress.
+ */
+void radeon_pll_errata_after_index(struct radeonfb_info *rinfo)
+{
+   if (!(rinfo->errata & CHIP_ERRATA_PLL_DUMMYREADS))
+   return;
+
+   (void)INREG(CLOCK_CNTL_DATA);
+   (void)INREG(CRTC_GEN_CNTL);
+}
+
+void radeon_pll_errata_after_data(struct radeonfb_info *rinfo)
+{
+   if (rinfo->errata & CHIP_ERRATA_PLL_DELAY) {
+   /* we can't deal with posted writes here ... */
+   _radeon_msleep(rinfo, 5);
+   }
+   if (rinfo->errata & CHIP_ERRATA_R300_CG) {
+   u32 save, tmp;
+   save = INREG(CLOCK_CNTL_INDEX);
+   tmp = save & ~(0x3f | PLL_WR_EN);
+   OUTREG(CLOCK_CNTL_INDEX, tmp);
+   tmp = INREG(CLOCK_CNTL_DATA);
+   OUTREG(CLOCK_CNTL_INDEX, save);
+   }
+}
+
+u32 __INPLL(struct radeonfb_info *rinfo, u32 addr)
+{
+   u32 data;
+
+   OUTREG8(CLOCK_CNTL_INDEX, addr & 0x003f);
+   radeon_pll_errata_after_index(rinfo);
+   data = INREG(CLOCK_CNTL_DATA);
+   radeon_pll_errata_after_data(rinfo);
+   return data;
+}
+
+void __OUTPLL(struct radeonfb_info *rinfo, unsigned int index, u32 val)
+{
+
+   OUTREG8(CLOCK_CNTL_INDEX, (index & 0x003f) | 0x0080);
+   radeon_pll_errata_after_index(rinfo);
+   OUTREG(CLOCK_CNTL_DATA, val);
+   radeon_pll_errata_after_data(rinfo);
+}
+
+void __OUTPLLP(struct radeonfb_info *rinfo, unsigned int index, u32 val, u32 
mask)
+{
+   unsigned int tmp;
+
+   tmp  = __INPLL(rinfo, index);
+   tmp &= (mask);
+   tmp |= (val);
+   __OUTPLL(rinfo, index, tmp);
+}
+
diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
index 7351e66..cde9c2e 100644
--- a/drivers/video/aty/radeonfb.h
+++ b/drivers/video/aty/radeonfb.h
@@ -393,98 +393,16 @@ static inline void _radeon_msleep(struct radeonfb_info 
*rinfo, unsigned long ms)
 #define INREG(addr)readl((rinfo->mmio_base)+addr)
 #define OUTREG(addr,val)   writel(val, (rinfo->mmio_base)+addr)

-static inline void _OUTREGP(struct radeonfb_info *rinfo, u32 addr,
-  u32 val, u32 mask)
-{
-   unsigned long flags;
-   unsigned int tmp;
-
-   spin_lock_irqsave(>reg_lock, flags);
-   tmp = INREG(addr);
-   tmp &= (mask);
-   tmp |= (val);
-   OUTREG(addr, tmp);
-   spin_unlock_irqrestore(>reg_lock, flags);
-}
+void _OUTREGP(struct radeonfb_info *rinfo, u32 addr, u32 val, u32 mask);
+void __OUTPLLP(struct radeonfb_info *rinfo, unsigned int index,
+u32 val, u32 mask);
+void __OUTPLL(struct radeonfb_info *rinfo, unsigned int index, u32 val);
+u32 __INPLL(struct radeonfb_info *rinfo, u32 addr);
+void radeon_pll_errata_after_data(struct radeonfb_info *rinfo);
+void 

[PATCH 04/12] RADEON: Remove now unused functions in radeon driver

[Andi Kleen]

From: Andi Kleen 

With the dropped inlines gccs starts warning about genuinely unused
functions. Remove r600_bpe_from_format, evergreen_cs_track_validate_cb,
evergreen-cs_packet_next_is_pkt3_nop which are all unused.

Cc: David Airlie 

Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |   28 
 drivers/gpu/drm/radeon/r600_cs.c  |   19 ---
 2 files changed, 0 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 35dce99..7fdfa8e 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -122,12 +122,6 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_bo = NULL;
 }

-static int evergreen_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
-{
-   /* XXX fill in */
-   return 0;
-}
-
 static int evergreen_cs_track_check(struct radeon_cs_parser *p)
 {
struct evergreen_cs_track *track = p->track;
@@ -236,28 +230,6 @@ static int evergreen_cs_packet_next_reloc(struct 
radeon_cs_parser *p,
 }

 /**
- * evergreen_cs_packet_next_is_pkt3_nop() - test if next packet is packet3 nop 
for reloc
- * @parser:parser structure holding parsing context.
- *
- * Check next packet is relocation packet3, do bo validation and compute
- * GPU offset using the provided start.
- **/
-static int evergreen_cs_packet_next_is_pkt3_nop(struct radeon_cs_parser *p)
-{
-   struct radeon_cs_packet p3reloc;
-   int r;
-
-   r = evergreen_cs_packet_parse(p, , p->idx);
-   if (r) {
-   return 0;
-   }
-   if (p3reloc.type != PACKET_TYPE3 || p3reloc.opcode != PACKET3_NOP) {
-   return 0;
-   }
-   return 1;
-}
-
-/**
  * evergreen_cs_packet_next_vline() - parse userspace VLINE packet
  * @parser:parser structure holding parsing context.
  *
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 7339c0b..0a2e023 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -223,25 +223,6 @@ static int fmt_get_nblocksy(u32 format, u32 h)
return (h + bh - 1) / bh;
 }

-static int r600_bpe_from_format(u32 *bpe, u32 format)
-{
-   unsigned res;
-
-   if (format >= ARRAY_SIZE(color_formats_table))
-   goto fail;
-
-   res = color_formats_table[format].blocksize;
-   if (res == 0)
-   goto fail;
-
-   *bpe = res;
-   return 0;
-
-fail:
-   *bpe = 16;
-   return -EINVAL;
-}
-
 struct array_mode_checker {
int array_mode;
u32 group_size;
-- 
1.7.4.4

[PATCH 03/12] RADEON: drop inlines in r600_blit.c

[Andi Kleen]

From: Andi Kleen 

Cc: David Airlie 

Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/radeon/r600_blit.c |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
b/drivers/gpu/drm/radeon/r600_blit.c
index 7f10434..3c031a4 100644
--- a/drivers/gpu/drm/radeon/r600_blit.c
+++ b/drivers/gpu/drm/radeon/r600_blit.c
@@ -41,7 +41,7 @@
 #define COLOR_5_6_5   0x8
 #define COLOR_8_8_8_8 0x1a

-static inline void
+static void
 set_render_target(drm_radeon_private_t *dev_priv, int format, int w, int h, 
u64 gpu_addr)
 {
u32 cb_color_info;
@@ -99,7 +99,7 @@ set_render_target(drm_radeon_private_t *dev_priv, int format, 
int w, int h, u64
ADVANCE_RING();
 }

-static inline void
+static void
 cp_set_surface_sync(drm_radeon_private_t *dev_priv,
u32 sync_type, u32 size, u64 mc_addr)
 {
@@ -121,7 +121,7 @@ cp_set_surface_sync(drm_radeon_private_t *dev_priv,
ADVANCE_RING();
 }

-static inline void
+static void
 set_shaders(struct drm_device *dev)
 {
drm_radeon_private_t *dev_priv = dev->dev_private;
@@ -184,7 +184,7 @@ set_shaders(struct drm_device *dev)
R600_SH_ACTION_ENA, 512, gpu_addr);
 }

-static inline void
+static void
 set_vtx_resource(drm_radeon_private_t *dev_priv, u64 gpu_addr)
 {
uint32_t sq_vtx_constant_word2;
@@ -220,7 +220,7 @@ set_vtx_resource(drm_radeon_private_t *dev_priv, u64 
gpu_addr)
R600_VC_ACTION_ENA, 48, gpu_addr);
 }

-static inline void
+static void
 set_tex_resource(drm_radeon_private_t *dev_priv,
 int format, int w, int h, int pitch, u64 gpu_addr)
 {
@@ -258,7 +258,7 @@ set_tex_resource(drm_radeon_private_t *dev_priv,

 }

-static inline void
+static void
 set_scissors(drm_radeon_private_t *dev_priv, int x1, int y1, int x2, int y2)
 {
RING_LOCALS;
@@ -282,7 +282,7 @@ set_scissors(drm_radeon_private_t *dev_priv, int x1, int 
y1, int x2, int y2)
ADVANCE_RING();
 }

-static inline void
+static void
 draw_auto(drm_radeon_private_t *dev_priv)
 {
RING_LOCALS;
@@ -311,7 +311,7 @@ draw_auto(drm_radeon_private_t *dev_priv)
COMMIT_RING();
 }

-static inline void
+static void
 set_default_state(drm_radeon_private_t *dev_priv)
 {
int i;
@@ -489,7 +489,7 @@ set_default_state(drm_radeon_private_t *dev_priv)
ADVANCE_RING();
 }

-static inline uint32_t i2f(uint32_t input)
+static uint32_t i2f(uint32_t input)
 {
u32 result, i, exponent, fraction;

@@ -515,7 +515,7 @@ static inline uint32_t i2f(uint32_t input)
 }


-static inline int r600_nomm_get_vb(struct drm_device *dev)
+static int r600_nomm_get_vb(struct drm_device *dev)
 {
drm_radeon_private_t *dev_priv = dev->dev_private;
dev_priv->blit_vb = radeon_freelist_get(dev);
@@ -526,7 +526,7 @@ static inline int r600_nomm_get_vb(struct drm_device *dev)
return 0;
 }

-static inline void r600_nomm_put_vb(struct drm_device *dev)
+static void r600_nomm_put_vb(struct drm_device *dev)
 {
drm_radeon_private_t *dev_priv = dev->dev_private;

@@ -534,7 +534,7 @@ static inline void r600_nomm_put_vb(struct drm_device *dev)
radeon_cp_discard_buffer(dev, dev_priv->blit_vb->file_priv->master, 
dev_priv->blit_vb);
 }

-static inline void *r600_nomm_get_vb_ptr(struct drm_device *dev)
+static void *r600_nomm_get_vb_ptr(struct drm_device *dev)
 {
drm_radeon_private_t *dev_priv = dev->dev_private;
return (((char *)dev->agp_buffer_map->handle +
-- 
1.7.4.4

[PATCH 02/12] RADEON: Move r100_*_*reg out of line

[Andi Kleen]

From: Andi Kleen 

This shrinks the sizes of a lot of functions in the radeon driver
dramatically.

With a non force inline + -Os kernel this is default anyways.

Cc: David Airlie 

Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/radeon/r100.c   |   40 
 drivers/gpu/drm/radeon/radeon.h |   43 +++---
 2 files changed, 44 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 7fcdbbb..9a1efac 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3965,3 +3965,43 @@ int r100_init(struct radeon_device *rdev)
}
return 0;
 }
+
+uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg)
+{
+   if (reg < rdev->rmmio_size)
+   return readl(((void __iomem *)rdev->rmmio) + reg);
+   else {
+   writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
+   return readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
+   }
+}
+
+void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v)
+{
+   if (reg < rdev->rmmio_size)
+   writel(v, ((void __iomem *)rdev->rmmio) + reg);
+   else {
+   writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
+   writel(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
+   }
+}
+
+u32 r100_io_rreg(struct radeon_device *rdev, u32 reg)
+{
+   if (reg < rdev->rio_mem_size)
+   return ioread32(rdev->rio_mem + reg);
+   else {
+   iowrite32(reg, rdev->rio_mem + RADEON_MM_INDEX);
+   return ioread32(rdev->rio_mem + RADEON_MM_DATA);
+   }
+}
+
+void r100_io_wreg(struct radeon_device *rdev, u32 reg, u32 v)
+{
+   if (reg < rdev->rio_mem_size)
+   iowrite32(v, rdev->rio_mem + reg);
+   else {
+   iowrite32(reg, rdev->rio_mem + RADEON_MM_INDEX);
+   iowrite32(v, rdev->rio_mem + RADEON_MM_DATA);
+   }
+}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index c1e056b..8ac6cba 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1252,45 +1252,10 @@ int radeon_device_init(struct radeon_device *rdev,
 void radeon_device_fini(struct radeon_device *rdev);
 int radeon_gpu_wait_for_idle(struct radeon_device *rdev);

-static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg)
-{
-   if (reg < rdev->rmmio_size)
-   return readl((rdev->rmmio) + reg);
-   else {
-   writel(reg, (rdev->rmmio) + RADEON_MM_INDEX);
-   return readl((rdev->rmmio) + RADEON_MM_DATA);
-   }
-}
-
-static inline void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, 
uint32_t v)
-{
-   if (reg < rdev->rmmio_size)
-   writel(v, (rdev->rmmio) + reg);
-   else {
-   writel(reg, (rdev->rmmio) + RADEON_MM_INDEX);
-   writel(v, (rdev->rmmio) + RADEON_MM_DATA);
-   }
-}
-
-static inline u32 r100_io_rreg(struct radeon_device *rdev, u32 reg)
-{
-   if (reg < rdev->rio_mem_size)
-   return ioread32(rdev->rio_mem + reg);
-   else {
-   iowrite32(reg, rdev->rio_mem + RADEON_MM_INDEX);
-   return ioread32(rdev->rio_mem + RADEON_MM_DATA);
-   }
-}
-
-static inline void r100_io_wreg(struct radeon_device *rdev, u32 reg, u32 v)
-{
-   if (reg < rdev->rio_mem_size)
-   iowrite32(v, rdev->rio_mem + reg);
-   else {
-   iowrite32(reg, rdev->rio_mem + RADEON_MM_INDEX);
-   iowrite32(v, rdev->rio_mem + RADEON_MM_DATA);
-   }
-}
+uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg);
+void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
+u32 r100_io_rreg(struct radeon_device *rdev, u32 reg);
+void r100_io_wreg(struct radeon_device *rdev, u32 reg, u32 v);

 /*
  * Cast helper
-- 
1.7.4.4

[PATCH 01/12] RADEON: Drop inlines from evergreen_cs.c / r600_cs.c

[Andi Kleen]

From: Andi Kleen 

Fixes

evergreen_cs_parse  4080   23124  +19044

and others compared to a non force inline kernel.

Cc: David Airlie 

Signed-off-by: Andi Kleen 
---
 drivers/gpu/drm/radeon/evergreen_cs.c |8 
 drivers/gpu/drm/radeon/r600_cs.c  |   24 
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index a134790..35dce99 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -122,7 +122,7 @@ static void evergreen_cs_track_init(struct 
evergreen_cs_track *track)
track->db_s_write_bo = NULL;
 }

-static inline int evergreen_cs_track_validate_cb(struct radeon_cs_parser *p, 
int i)
+static int evergreen_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
 {
/* XXX fill in */
return 0;
@@ -242,7 +242,7 @@ static int evergreen_cs_packet_next_reloc(struct 
radeon_cs_parser *p,
  * Check next packet is relocation packet3, do bo validation and compute
  * GPU offset using the provided start.
  **/
-static inline int evergreen_cs_packet_next_is_pkt3_nop(struct radeon_cs_parser 
*p)
+static int evergreen_cs_packet_next_is_pkt3_nop(struct radeon_cs_parser *p)
 {
struct radeon_cs_packet p3reloc;
int r;
@@ -414,7 +414,7 @@ static int evergreen_cs_parse_packet0(struct 
radeon_cs_parser *p,
  * if register is safe. If register is not flag as safe this function
  * will test it against a list of register needind special handling.
  */
-static inline int evergreen_cs_check_reg(struct radeon_cs_parser *p, u32 reg, 
u32 idx)
+static int evergreen_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u32 idx)
 {
struct evergreen_cs_track *track = (struct evergreen_cs_track 
*)p->track;
struct radeon_cs_reloc *reloc;
@@ -990,7 +990,7 @@ static inline int evergreen_cs_check_reg(struct 
radeon_cs_parser *p, u32 reg, u3
  * This function will check that the resource has valid field and that
  * the texture and mipmap bo object are big enough to cover this resource.
  */
-static inline int evergreen_check_texture_resource(struct radeon_cs_parser *p, 
 u32 idx,
+static int evergreen_check_texture_resource(struct radeon_cs_parser *p,  u32 
idx,
   struct radeon_bo *texture,
   struct radeon_bo *mipmap)
 {
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index cf83aa0..7339c0b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -162,7 +162,7 @@ static const struct gpu_formats color_formats_table[] = {
[V_038004_FMT_32_AS_32_32_32_32] = { 1, 1, 4, 0, CHIP_CEDAR},
 };

-static inline bool fmt_is_valid_color(u32 format)
+static bool fmt_is_valid_color(u32 format)
 {
if (format >= ARRAY_SIZE(color_formats_table))
return false;
@@ -173,7 +173,7 @@ static inline bool fmt_is_valid_color(u32 format)
return false;
 }

-static inline bool fmt_is_valid_texture(u32 format, enum radeon_family family)
+static bool fmt_is_valid_texture(u32 format, enum radeon_family family)
 {
if (format >= ARRAY_SIZE(color_formats_table))
return false;
@@ -187,7 +187,7 @@ static inline bool fmt_is_valid_texture(u32 format, enum 
radeon_family family)
return false;
 }

-static inline int fmt_get_blocksize(u32 format)
+static int fmt_get_blocksize(u32 format)
 {
if (format >= ARRAY_SIZE(color_formats_table))
return 0;
@@ -195,7 +195,7 @@ static inline int fmt_get_blocksize(u32 format)
return color_formats_table[format].blocksize;
 }

-static inline int fmt_get_nblocksx(u32 format, u32 w)
+static int fmt_get_nblocksx(u32 format, u32 w)
 {
unsigned bw;

@@ -209,7 +209,7 @@ static inline int fmt_get_nblocksx(u32 format, u32 w)
return (w + bw - 1) / bw;
 }

-static inline int fmt_get_nblocksy(u32 format, u32 h)
+static int fmt_get_nblocksy(u32 format, u32 h)
 {
unsigned bh;

@@ -223,7 +223,7 @@ static inline int fmt_get_nblocksy(u32 format, u32 h)
return (h + bh - 1) / bh;
 }

-static inline int r600_bpe_from_format(u32 *bpe, u32 format)
+static int r600_bpe_from_format(u32 *bpe, u32 format)
 {
unsigned res;

@@ -252,7 +252,7 @@ struct array_mode_checker {
 };

 /* returns alignment in pixels for pitch/height/depth and bytes for base */
-static inline int r600_get_array_mode_alignment(struct array_mode_checker 
*values,
+static int r600_get_array_mode_alignment(struct array_mode_checker *values,
u32 *pitch_align,
u32 *height_align,
u32 *depth_align,
@@ -331,7 +331,7 @@ static void r600_cs_track_init(struct r600_cs_track *track)

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

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

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

--- Comment #2 from Alex Deucher  2011-10-13 15:40:07 PDT 
---
Did this work in the past and if so, when?  Please attach your xorg log and
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.

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

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

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

--- Comment #1 from Pasi K?rkk?inen  2011-10-13 15:17:52 PDT 
---

Oh, I forgot to mention that changing the radeon "power_profile" fixes the
problem, ie doing:

echo low > /sys/class/drm/card0/device/power_profile

fixes the problem, and there's no flickering anymore!

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

[Bug 41766] New: radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

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

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

   Summary: radeon lvds panel heavy flickering after opening
laptop lid (Mobility Radeon HD 3650)
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pasik at iki.fi


I'm using a laptop with Mobility Radeon HD 3650 (HP EliteBook 8530p). Normally
the laptop is in a docking station, so I'm only using the external DVI monitor.
The laptop lid is closed and the laptop internal LVDS panel is disabled while
in the dock.

I just tried the new Fedora 16 beta liveCD on my laptop. Fedora 16
automatically enables all display outputs, which means also the internal LVDS
panel gets enabled, even when my laptop lid is closed. And the gnome desktop
gets extended to both the DVI monitor and internal LVDS panel. This means I
need to actually open the laptop lid to see the gnome menus, because they're
displayed only on the internal LVDS panel. This is a configuration/defaults
issue in Fedora 16, and that's not the bug I'm reporting.

While opening the laptop lid I noticed the internal LVDS display is heavily
flickering, and the screen is totally unreadable. 

I've uploaded a video of the heavily flickering LVDS panel here:
http://pasik.reaktio.net/fedora/f16/radeon/f16-beta-laptop-radeon-flicker-xvid.avi

Fedora 16 beta is using Linux 3.1.0-rc6. dmesg available here:
http://pasik.reaktio.net/fedora/f16/radeon/f16-beta-laptop-radeon-dmesg.txt

I tried rebooting the laptop a couple of times, and it seems the flickering
doesn't happen on every reboot.. but it happens on *most* reboots. Flickering
starts already when kernel is booting, before Xorg is started.

Any more info needed ?

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

[Bug 41762] New: radeon default power_profile "default" makes laptop overheat (Mobility Radeon HD 3650)

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

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

   Summary: radeon default power_profile "default" makes laptop
overheat (Mobility Radeon HD 3650)
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pasik at iki.fi


I'm using a laptop with Mobility Radeon HD 3650, and I've had overheating
problems for a quite some time, with multiple kernel versions.

The issue happens at least with Fedora 14, Fedora 15 and latest Fedora 16
(beta).

As a default radeon power_profile "default" is being used, and it causes laptop
overheating and emergency thermal shutdowns.. on a completely idle system! It
seems the power management doesn't work with the opensource radeon driver on
this laptop (HP EliteBook 8530p). See below for analysis and more info.

When I manually switch the radeon power_profile to "low" (see below) the
temperature of the laptop decreases over 10 degrees celsius, making the laptop
much cooler and also the fans will immediately slow down because the
temperature goes down. Any idea why the "default" power_profile doesn't
automatically run the card at lower engine/memory clock speeds?


Here's more information from Fedota 16 beta (x86_64) liveCD.. notice how the
temperature goes down from 84C to 72C when switching to power_profile "low":

# cat /etc/redhat-release 
Fedora release 16 (Verne)

# uname -a
Linux localhost.localdomain 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP Fri Sep 16
12:26:22 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

# lspci|grep -i vga
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650

$ cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 60 kHz
current engine clock: 594000 kHz
default memory clock: 70 kHz
current memory clock: 693000 kHz
voltage: 1100 mV
PCIE lanes: 16


# cat /sys/devices/virtual/thermal/thermal_zone3/device/path 
\_TZ_.CPUZ

$ cat /sys/devices/virtual/thermal/thermal_zone3/temp 
84000

# cat /sys/class/drm/card0/device/power_profile
default

# echo low > /sys/class/drm/card0/device/power_profile

(wait for 5 mins.. and notice how fans slow down)

$ cat /sys/devices/virtual/thermal/thermal_zone3/temp 
72000

# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 60 kHz
current engine clock: 334120 kHz
default memory clock: 70 kHz
current memory clock: 405000 kHz
voltage: 900 mV
PCIE lanes: 16


dmesg for the f16beta 3.1.0-rc6 kernel available here:
http://pasik.reaktio.net/fedora/f16/radeon/f16-beta-laptop-radeon-dmesg.txt

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

drm/radeon/kms: improve performance of blit-copy

[Ilija Hadzic]

On Thu, 13 Oct 2011, Roland Scheidegger wrote:

> I guess it isn't possible to temporarily disable some RBEs or otherwise
> reconfigure the chip that you could get the same performance for the
> high-end chips?

According to the conversation I had with Alex, this *is* possible but 
requires the pipeline and cache flush. So it is unclear what the overall 
gain will be given the flush penalty.

Also, this phenomena occurs only when GTT is involved in the copy. 
VRAM-to-VRAM copy in which there is no host memory involved (for which I 
added a benchmark, but didn't report in my note yesterday), high-end 
devices are beating low-end ones big time  they better be ;-)

So if we can get RBE-reduction to work, it should be turned on only when 
one of the BOs is in GTT domain. I looked at what it would take to do 
this, and it's doable, but requires hacks at many places.

-- Ilija

Question on S3 on evergreen

[Xavier Bestel]

On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
> On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel  
> wrote:
> > Hi,
> >
> > On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
> >> [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
> >> functions from linux to CE.
> >
> > I imagine you already have checked with your company's lawyers, but if I
> > understand correctly that means your drivers will be distributed under
> > the GPL ?
> 
> All the GPU driver code is licensed under MIT.

Oh, I thought "linux" meant "kernel", not "X11".

Xav

Question on S3 on evergreen

[Xavier Bestel]

Hi,

On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
> [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
> functions from linux to CE. 

I imagine you already have checked with your company's lawyers, but if I
understand correctly that means your drivers will be distributed under
the GPL ?

Thanks,
Xav

drm/radeon/kms: improve performance of blit-copy

[Ilija Hadzic]

Dave,

Alex pointed to me that the patches I sent last night under this thread 
may conflict with 003cefe0c238e683a29d2207dba945b508cd45b7 that currently 
resides on drm-fixes branch (my patches are based on drm-next or 
drm-core-next).

I'd like to make sure that the eventual merge goes smoothly:

If you merge drm-fixes before my patches, then I'll rebase my patches and 
resend them after that happens and make sure everything is resolved 
correctly.

If you merge my patches first and then follow with drm-fixes merge, two 
things should happen with 003cefe0c238e683a29d2207dba945b508cd45b7. Hunks 
related to evergreen.c file will fall out but that's expected and OK 
because my patches consolidate the blit code for r600 and evergreen into a 
common one. Then in r600.c, the hunks related to r600_blit_prepare_copy
and r600_kms_blit_copy function calls will show conflicts, which should be 
resolved such that the size argument is num_gpu_pages, not
num_gpu_pages * RADEON_GPU_PAGE_SIZE (this is because the new blit code
takes size argument in pages, not bytes). Everything else will merge 
smoothly.

For reference, pasted below is a patch that resulted after I cherry-picked 
003cefe0c238e683a29d2207dba945b508cd45b7 into drm-next augmented with my 
blit-improvement patches and resolved the conflicts correctly.

I guess the first option is less work for you (and I will be glad to 
rebase my patches if need be), but I hope that the info here is good 
enough to make the second path as easy as it can be

thanks,

Ilija

Question on S3 on evergreen

[Dave Airlie]

On Thu, Oct 13, 2011 at 1:07 PM, Xavier Bestel  wrote:
> On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
>> On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel  
>> wrote:
>> > Hi,
>> >
>> > On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
>> >> [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
>> >> functions from linux to CE.
>> >
>> > I imagine you already have checked with your company's lawyers, but if I
>> > understand correctly that means your drivers will be distributed under
>> > the GPL ?
>>
>> All the GPU driver code is licensed under MIT.
>
> Oh, I thought "linux" meant "kernel", not "X11".

The kernel drm driver code is all MIT licensed. The license is there
at the top of the files.

Dave.

Question on S3 on evergreen

[Dave Airlie]

On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel  
wrote:
> Hi,
>
> On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
>> [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
>> functions from linux to CE.
>
> I imagine you already have checked with your company's lawyers, but if I
> understand correctly that means your drivers will be distributed under
> the GPL ?

All the GPU driver code is licensed under MIT.

Dave.

[PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Keith Packard]

On Thu, 13 Oct 2011 20:05:49 +0200, Takashi Iwai  wrote:

> Yes, this looks more understandable, indeed.
> Would you patch it by yourself or should I refresh the patch?
> In either way, I'll test tomorrow, as I'm already at home without a
> test machine.

I don't have time before Monday to look at this further.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111013/ca051a74/attachment.pgp>

[Bug 41756] New: [wine] Alpha Prime crashes in u_upload_data

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

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

   Summary: [wine] Alpha Prime crashes in u_upload_data
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: sa at whiz.se


Created an attachment (id=52308)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=52308)
backtrace from gdb

The game Alpha Prime (running with Wine 1.3.30) crashes shortly after start
with latest git. With 7.11 I get another crash, so I'm not sure if this is a
regression or not.

The backtrace from Wine is below, I also attached a backtrace from gdb but I'm
not sure if it's good or not.

=>0 0xb7547aa0 in libc.so.6 (+0x10faa0) (0x0032fd80)
  1 0x7b33aae4 u_upload_data+0x73(upload=0x7caea288, min_out_offset=0x32fd80,
size=0x1200, data=0x5d16da0, out_offset=0x7cb5ce48, outbuf=0x7cb5ce4c,
flushed="?|")
[/home/sa/Programming/gfx/mesa/mesa/src/gallium/auxiliary/util/u_upload_mgr.c:220]
in r600_dri.so (0x0032fd80)
  2 0x7b33adce u_vbuf_upload_buffers+0x1dd(mgr=0x7cb5ccc0, min_index=0xcbf6,
max_index=0xcc3d, instance_count=0x1)
[/home/sa/Programming/gfx/mesa/mesa/src/gallium/auxiliary/util/u_vbuf_mgr.c:575]
in r600_dri.so (0x0032fd80)
  3 0x7b33bf04 u_vbuf_draw_begin+0x193(mgrb=0x7cb5ccc0, info=0xb9e98c)
[/home/sa/Programming/gfx/mesa/mesa/src/gallium/auxiliary/util/u_vbuf_mgr.c:652]
in r600_dri.so (0x00b9e98c)
  4 0x7b13ab1b r600_draw_vbo+0x5a(ctx=0x7ccd1908, info=0xb9e98c)
[/home/sa/Programming/gfx/mesa/mesa/src/gallium/drivers/r600/r600_state_common.c:571]
in r600_dri.so (0x0003)
  5 0x7b1fd5f1 st_draw_vbo+0x330(ctx=0x7cd079a0, arrays=0x7cd54fec,
prims=0xb9ea20, nr_prims=0x1, ib=0xb9ea34, index_bounds_valid=0, min_index=0,
max_index=0x47)
[/home/sa/Programming/gfx/mesa/mesa/src/mesa/state_tracker/st_draw.c:798] in
r600_dri.so (0x0003)
  6 0x7b2b8a1e vbo_validated_drawrangeelements+0x13d(ctx=0x7cd079a0, mode=0x4,
index_bounds_valid=0, start=0x, end=0x, count=0xc0,
type=0x1403, indices=0x3a4c7b4, basevertex=0xcbf6, numInstances=0x1)
[/home/sa/Programming/gfx/mesa/mesa/src/mesa/vbo/vbo_exec_array.c:860] in
r600_dri.so (0x00c0)
  7 0x7b2b8b34 vbo_exec_DrawElementsBaseVertex+0xa3(mode=0x4, count=0xc0,
type=0x1403, indices=0x3a4c7b4, basevertex=0xcbf6)
[/home/sa/Programming/gfx/mesa/mesa/src/mesa/vbo/vbo_exec_array.c:1040] in
r600_dri.so (0x03a4c7b4)
  8 0x7ea887e4 drawPrimitive+0x11e3(device=0x171740, index_count=0xc0,
StartIdx=0x53ca, idxSize=0x2, idxData=0x3a42020)
[/home/sa/Programming/wine-test/dlls/wined3d/drawprim.c:44] in wined3d
(0x0002)
  9 0x7ea6955b wined3d_device_draw_indexed_primitive+0xda(device=0x171740,
start_idx=0x53ca, index_count=0xc0)
[/home/sa/Programming/wine-test/dlls/wined3d/device.c:4158] in wined3d
(0x02a17b58)
  10 0x7eb72d5e IDirect3DDevice9Impl_DrawIndexedPrimitive+0xcd(iface=0x171710,
PrimitiveType=D3DPT_TRIANGLELIST, BaseVertexIndex=0xcbf6, MinVertexIndex=0,
NumVertices=0x48, startIndex=0x53ca, primCount=0x40)
[/home/sa/Programming/wine-test/dlls/d3d9/device.c:1941] in d3d9 (0x53ca)
  11 0x00451479 in alphaprime (+0x51478) (0x7eb8f100)
  12 0x7eb6c840 in d3d9 (+0xc83f) (0x7eb74440)
  13 0xe84c245c (0x895cec83)
err:mmtime:TIME_MMTimeStop Timer still active?!
err:d3d:wined3d_wndproc Window 0xc0024 is not registered with wined3d.


System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.2
-- xserver: 1.11.1
-- mesa: 349e4db99e938f8ee8826b0d27e490c66a1e8356
-- drm: 2.4.26
-- kernel: 3.0

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

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #2 from Sven Arvidsson  2011-10-13 11:04:23 PDT ---

[PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Takashi Iwai]

The commit 47356eb67285014527a5ab87543ba1fae3d1e10a introduced a
mechanism to record the backlight level only at disabling time, but it
also introduced a regression.  Since intel_lvds_enable() may be called
without disabling (e.g. intel_lvds_commit() calls it unconditionally),
the backlight gets back to the last recorded value.  For example, this
happens when you dim the backlight, close the lid and open the lid,
then the backlight suddenly goes to the brightest.

This patch fixes the bug by recording the backlight level always
when changed but only when dev_priv->backlight_enabled is set.
In this way, the bogus value for disabling backlight can be skipped.

Signed-off-by: Takashi Iwai 
---

Feel free to add Cc to stable kernel, as this is a regression fix.
I've tested only a few machines here so more tests would be
appreciated, because the backlight issue is SOOO sensitive :)


 drivers/gpu/drm/i915/intel_panel.c |   11 +--
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index a9e0c7b..269d526 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -233,6 +233,9 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 
level)

DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);

+   if (dev_priv->backlight_enabled)
+   dev_priv->backlight_level = level;
+
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);

@@ -258,11 +261,7 @@ void intel_panel_disable_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;

-   if (dev_priv->backlight_enabled) {
-   dev_priv->backlight_level = intel_panel_get_backlight(dev);
-   dev_priv->backlight_enabled = false;
-   }
-
+   dev_priv->backlight_enabled = false;
intel_panel_set_backlight(dev, 0);
 }

@@ -273,8 +272,8 @@ void intel_panel_enable_backlight(struct drm_device *dev)
if (dev_priv->backlight_level == 0)
dev_priv->backlight_level = intel_panel_get_max_backlight(dev);

-   intel_panel_set_backlight(dev, dev_priv->backlight_level);
dev_priv->backlight_enabled = true;
+   intel_panel_set_backlight(dev, dev_priv->backlight_level);
 }

 static void intel_panel_init_backlight(struct drm_device *dev)
-- 
1.7.7

[PATCH] drm/radeon/kms: Simplify I2C post_xfer function

[Jean Delvare]

There is no point in re-doing in post_xfer all the initialization
that was already done by pre_xfer. Instead, only do the work which
differs from pre_xfer.

Signed-off-by: Jean Delvare 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_i2c.c |   48 ---
 1 file changed, 22 insertions(+), 26 deletions(-)

--- linux-3.0.orig/drivers/gpu/drm/radeon/radeon_i2c.c  2011-10-06 
18:39:04.0 +0200
+++ linux-3.0/drivers/gpu/drm/radeon/radeon_i2c.c   2011-10-06 
18:45:27.0 +0200
@@ -81,8 +81,9 @@ bool radeon_ddc_probe(struct radeon_conn

 /* bit banging i2c */

-static void radeon_i2c_do_lock(struct radeon_i2c_chan *i2c, int lock_state)
+static int pre_xfer(struct i2c_adapter *i2c_adap)
 {
+   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
struct radeon_device *rdev = i2c->dev->dev_private;
struct radeon_i2c_bus_rec *rec = >rec;
uint32_t temp;
@@ -137,19 +138,30 @@ static void radeon_i2c_do_lock(struct ra
WREG32(rec->en_data_reg, temp);

/* mask the gpio pins for software use */
-   temp = RREG32(rec->mask_clk_reg);
-   if (lock_state)
-   temp |= rec->mask_clk_mask;
-   else
-   temp &= ~rec->mask_clk_mask;
+   temp = RREG32(rec->mask_clk_reg) | rec->mask_clk_mask;
WREG32(rec->mask_clk_reg, temp);
temp = RREG32(rec->mask_clk_reg);

+   temp = RREG32(rec->mask_data_reg) | rec->mask_data_mask;
+   WREG32(rec->mask_data_reg, temp);
temp = RREG32(rec->mask_data_reg);
-   if (lock_state)
-   temp |= rec->mask_data_mask;
-   else
-   temp &= ~rec->mask_data_mask;
+
+   return 0;
+}
+
+static void post_xfer(struct i2c_adapter *i2c_adap)
+{
+   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
+   struct radeon_device *rdev = i2c->dev->dev_private;
+   struct radeon_i2c_bus_rec *rec = >rec;
+   uint32_t temp;
+
+   /* unmask the gpio pins for software use */
+   temp = RREG32(rec->mask_clk_reg) & ~rec->mask_clk_mask;
+   WREG32(rec->mask_clk_reg, temp);
+   temp = RREG32(rec->mask_clk_reg);
+
+   temp = RREG32(rec->mask_data_reg) & ~rec->mask_data_mask;
WREG32(rec->mask_data_reg, temp);
temp = RREG32(rec->mask_data_reg);
 }
@@ -209,22 +221,6 @@ static void set_data(void *i2c_priv, int
WREG32(rec->en_data_reg, val);
 }

-static int pre_xfer(struct i2c_adapter *i2c_adap)
-{
-   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
-
-   radeon_i2c_do_lock(i2c, 1);
-
-   return 0;
-}
-
-static void post_xfer(struct i2c_adapter *i2c_adap)
-{
-   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
-
-   radeon_i2c_do_lock(i2c, 0);
-}
-
 /* hw i2c */

 static u32 radeon_get_i2c_prescale(struct radeon_device *rdev)

-- 
Jean Delvare
Suse L3

[Bug 41265] KMS does not work on Radeon HD6700M

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

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

--- Comment #4 from Varban  2011-10-13 10:36:48 PDT 
---
In Windows, if a monitor is connected to a port on the laptop then it is shown
as connected to the Intel card. If the monitor is connected to the external
media dock then Windows shows it as connected to the Radeon card.

I played around with the fglrx proprietary driver (latest version 11.9) and I
got two different results when my xorg.conf has 2 separate cards defined (fglrx
and intel) vs only 1 card (fglrx only)

When defining 2 cards in xorg.conf I get this:

[  2060.069] (II) Loading sub module "fglrxdrm"
[  2060.069] (II) LoadModule: "fglrxdrm"
[  2060.069] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[  2060.069] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[  2060.069] compiled for 1.4.99.906, module version = 8.89.4
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  2060.072] ukiOpenDevice: node name is /dev/ati/card0
[  2060.072] ukiOpenDevice: open result is 11, (OK)
[  2060.072] ukiOpenByBusid: ukiOpenMinor returns 11
[  2060.072] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  2060.073] (==) fglrx(0): NoAccel = NO
[  2060.073] (==) fglrx(0): ATI 2D Acceleration Architecture enabled
[  2060.073] (--) fglrx(0): Chipset: "AMD Radeon HD 6700M Series" (Chipset =
0x6740)
[  2060.073] (--) fglrx(0): (PciSubVendor = 0x104d, PciSubDevice = 0x9084)
[  2060.073] (==) fglrx(0): board vendor info: third party graphics adapter -
NOT original ATI
[  2060.073] (--) fglrx(0): Linear framebuffer (phys) at 0xb000
[  2060.073] (--) fglrx(0): MMIO registers at 0xc020
[  2060.073] (--) fglrx(0): I/O port at 0x5000
[  2060.073] (==) fglrx(0): ROM-BIOS at 0x000c
[  2060.073] (II) fglrx(0): AC Adapter is used
[  2060.084] (II) fglrx(0): Invalid ATI BIOS from int10, the adapter is not
VGA-enabled
[  2060.084] (EE) fglrx(0): Invalid video BIOS signature!
[  2060.084] (EE) fglrx(0): GetBIOSParameter failed
[  2060.084] (EE) fglrx(0): PreInitAdapter failed
[  2060.084] (EE) fglrx(0): PreInit failed


The invalid bios message.
However, when I only try to use 1 fglrx card (on pcibus 22:0:0), the driver
correctly detects there an intel card and loads drivers for it but then blows
up with another message:

[  1920.534] (WW) Falling back to old probe method for fglrx
[  1920.538] (II) Loading PCS database from /etc/ati/amdpcsdb
[  1920.538] (--) Chipset Supported AMD Graphics Processor (0x6740) found
[  1920.538] (WW) fglrx: No matching Device section for instance (BusID
PCI:0 at 22:0:1) found
[  1920.538] (II) fglrx: intel VGA device detected, load intel driver.
[  1920.538] (II) LoadModule: "intel"
[  1920.539] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  1920.539] (II) Module intel: vendor="X.Org Foundation"
[  1920.539] compiled for 1.11.0, module version = 2.16.0
[  1920.539] Module class: X.Org Video Driver
[  1920.539] ABI class: X.Org Video Driver, version 11.0
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  1920.540] ukiOpenDevice: node name is /dev/ati/card0
[  1920.540] ukiOpenDevice: open result is 8, (OK)
[  1920.540] ukiOpenByBusid: ukiOpenMinor returns 8
[  1920.540] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  1920.542] (WW) PowerXpress feature is not supported on A+I Mux platform.
Please uninstall fglrx driver.
[  1920.542] (EE) No devices detected.

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

Reply: Question on S3 on evergreen

[David Airlie]

- Original Message -
> From: "FrankR Huang" 
> To: "Xavier Bestel" , "Dave Airlie"  gmail.com>
> Cc: dri-devel at lists.freedesktop.org
> Sent: Thursday, 13 October, 2011 3:16:07 PM
> Subject: Reply: Question on S3 on evergreen
> 
> 
> Reply: Question on S3 on evergreen
> 
> Xav, thanks for your reminder. Actually our law leam has already
> checked the license. As Dave said, the DRM kernel driver is all
> MIT-licensed and we will be free to use them. When the drm uses
> linux kernel function calls, we will use freebsd(none-GPL)
> equivalent to replace.
> Dave, by the way, I want to ask you about some exceptions in DRM. you
> know in some files(i.e. drm_fb_helper.c), it includes
> MODULE_LICENSE("GPL and additional rights"). Does it mean it is GPL
> licensed? Is it free to use this file?

Those files are derived from the kernel fb layer so are not drm core 
infrastructure.

They make no sense on other OSes, since they don't have the same kernel fb 
layer.

Dave.

[RFC 2/2] dma-buf: Documentation for buffer sharing framework

[Semwal, Sumit]

Hi Randy,
On Thu, Oct 13, 2011 at 4:00 AM, Randy Dunlap  wrote:
> On 10/11/2011 02:23 AM, Sumit Semwal wrote:
>> Add documentation for dma buffer sharing framework, explaining the
>> various operations, members and API of the dma buffer sharing
>> framework.
>>
>> Signed-off-by: Sumit Semwal 
>> Signed-off-by: Sumit Semwal 
>> ---
>> ?Documentation/dma-buf-sharing.txt | ?210 
>> +

>> + ? ?if the new buffer-user has stricter 'backing-storage constraints', and 
>> the
>> + ? ?exporter can handle these constraints, the exporter can just stall on 
>> the
>> + ? ?get_scatterlist till all outstanding access is completed (as signalled 
>> by
>
> ? ? ? ? ? ? ? ? ? ? ? until
>
Thanks for your review; I will update all these in the next version.
>> + ? ?put_scatterlist).
>> + ? ?Once all ongoing access is completed, the exporter could potentially 
>> move
>> + ? ?the buffer to the stricter backing-storage, and then allow further
>> + ? ?{get,put}_scatterlist operations from any buffer-user from the migrated
>> + ? ?backing-storage.
>> +
>> + ? If the exporter cannot fulfill the backing-storage constraints of the new
>> + ? buffer-user device as requested, dma_buf_attach() would return an error 
>> to
>> + ? denote non-compatibility of the new buffer-sharing request with the 
>> current
>> + ? buffer.
>> +
>> + ? If the exporter chooses not to allow an attach() operation once a
>> + ? get_scatterlist has been called, it simply returns an error.
>> +
>> +- mmap file operation
>> + ? An mmap() file operation is provided for the fd associated with the 
>> buffer.
>> + ? If the exporter defines an mmap operation, the mmap() fop calls this to 
>> allow
>> + ? mmap for devices that might need it; if not, it returns an error.
>> +
>> +References:
>> +[1] struct dma_buf_ops in include/linux/dma-buf.h
>> +[2] All interfaces mentioned above defined in include/linux/dma-buf.h
>
>
> --
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
Best regards,
~Sumit.

[PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Keith Packard]

On Thu, 13 Oct 2011 10:57:35 +0200, Takashi Iwai  wrote:

> This patch fixes the bug by recording the backlight level always
> when changed but only when dev_priv->backlight_enabled is set.
> In this way, the bogus value for disabling backlight can be skipped.

I think this is better than what we have, but I'm not sure it's quite
what we want -- the backlight level will only be remembered when it is
enabled, so requested changes that happen while the backlight is off
will have no effect. And, requested changes while the panel is disabled
will still go through to the hardware, which can cause problems with
panel power sequencing.

I think intel_panel_set_backlight should always record the level passed
in, but that intel_panel_disable_backlight and
intel_panel_enable_backlight should use a lower-level function, shared
with intel_panel_set_backlight that doesn't record the value:

intel_panel_actually_set_backlight(dev, level) {

}

intel_panel_set_backlight(dev, level) {
dev_priv->backlight_level = level;
if (dev_priv->backlight_enabled)
intel_panel_actually_set_backlight(dev, level);
}

intel_panel_enable_backlight(dev) {
dev_priv->backlight_enabled = true;
intel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
}

intel_panel_disable_backlight(dev) {
dev_priv->backlight_enabled = false;
intel_panel_actually_set_backlight(dev, 0);
}

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111013/3393e76e/attachment.pgp>

Reply: Question on S3 on evergreen

[Ilija Hadzic]

Frank,

I have found this text particularly useful when it comes to using MIT (or 
BSD) code that resides in the GPL project (e.g. DRM in Linux)

http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

I think that sections 2.2 and 2.3 are the things to be careful about 
because there is a non-trivial probabilty that at least some out of many 
patches that come in from many authors were created by copying and pasting 
lines of code that may have come from some other GPL'd code (e.g. other 
parts of Linux). Nobody can guarantee that this has not happened.

P.S. The above is my personal opinion, I speak for myself, not for my 
company, I am not a lawyer.

-- Ilija

On Thu, 13 Oct 2011, Huang, FrankR wrote:

> Xav, thanks for your reminder. Actually our law leam has already checked the 
> license. As Dave said, the DRM kernel driver is all MIT-licensed and we will 
> be free to use them. When the drm uses linux kernel function calls, we will 
> use freebsd(none-GPL) equivalent to replace.
> Dave, by the way, I want to ask you about some exceptions in DRM. you know in 
> some files(i.e. drm_fb_helper.c), it includes MODULE_LICENSE("GPL and 
> additional rights"). Does it mean it is GPL licensed? Is it free to use this 
> file?
>
> Thanks,
> Frank
>
>
> -Original Message-
> From: Xavier Bestel [mailto:xavier.bestel at free.fr]
> Sent: 2011-10-13 (??) 20:07
> To: Dave Airlie
> Cc: Huang, FrankR; dri-devel at lists.freedesktop.org
> Subject: Re: Question on S3 on evergreen
>
> On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
>> On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel  
>> wrote:
>>> Hi,
>>>
>>> On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
 [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
 functions from linux to CE.
>>>
>>> I imagine you already have checked with your company's lawyers, but if I
>>> understand correctly that means your drivers will be distributed under
>>> the GPL ?
>>
>> All the GPU driver code is licensed under MIT.
>
> Oh, I thought "linux" meant "kernel", not "X11".
>
>   Xav
>
>
>
>

[Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2

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

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

--- Comment #7 from mirandir at orange.fr 2011-10-13 09:17:43 PDT ---
(In reply to comment #6)
> 
> When this happens, can you get a gdb backtrace of gnome-shell and/or the X
> server process, and attach them here?
> 

I will try, but the problem seems very randomly, and difficult to reproduce.

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

Question on S3 on evergreen

[Alex Deucher]

On Thu, Oct 13, 2011 at 5:54 AM, Huang, FrankR  wrote:
> Hi,
> ? ? ? ?I have a question on S3 suspend/resume process for evergreen
> chipset.
> ? ? ? ?Generally introduction, I am developing WEC7 graphics driver on
> evergreen chipset. Alex guide me on this. And right now I move to S3
> part work. I have ported radeon_suspend_kms() and radeon_resume_kms()
> functions from linux to CE. Actually I have validated that the
> evergreen_suspend() and evergreen_resume() work already on CE. But when
> the resume work is done and the screen is shown up, I found the 3D
> engine works wrong. The HW acceleration of it is not correct anymore.
> Misrendering is happening. By tracing the root cause, I suspect that the
> problem may be in evergreen_gpu_init()( in evergreen_startup) call when
> resume(), but I am not sure. Can you guys tell me which part I should
> debug?
> ? ? ? ?By the way, the linux kernel source I used is from 2010.10. So
> quite a lot patches have been committed into community during this
> period. Right now, the kernel source I used is around date
> 2011.7(Version 3.0.0). Is there any patches update for S3 during this
> period?
>

Does soft resetting the GPU during resume help
(evergreen_gpu_soft_reset()) ?  If so, try updating your version of
evergreen_cp_resume() to the latest upstream bits.

Alex

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

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

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

--- Comment #1 from Ga?per Sedej  2011-10-13 06:21:10 PDT 
---
Also, FrozenByte games are missing textures (ShadowGrounds and Trine)

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

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

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

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

Ga?per Sedej  changed:

   What|Removed |Added

  Alias|it  |

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

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

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

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

Ga?per Sedej  changed:

   What|Removed |Added

  Alias||it

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

[Bug 41744] New: Unigine Heaven shows black textures (Radeon HD4250)

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

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

   Summary: Unigine Heaven shows black textures (Radeon HD4250)
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: gsedej at gmail.com


Unigine Heaven benchmark shows black textures. It looks like this:
http://imageshack.us/photo/my-images/842/slika322.jpg/
It looks like it's problem with floating-point textures.

This is output of program: http://pastebin.com/GKWmbhV9
Here is my glxinfo: http://pastebin.com/BM9Vw8vm

I am using Ubuntu 11.04 with "oibaf" PPA build. Do I need to provide more data?

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #13 from Alex Deucher  2011-10-13 06:01:08 PDT 
---
Try the following options in the kernel command line in grub:
pci=nomsi
noapic
irqpoll
and see if any of them help.

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

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

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

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

--- Comment #2 from Jos van Wolput  2011-10-13 
03:52:54 PDT ---
(In reply to comment #1)
> Fixed in mesa/master with f1f7645f23bd11fb54a992cdbe9ef0a6ee0136f3.
Still some errors:
---
d3d11.cpp: In function ?HRESULT GalliumD3D11DeviceCreate(pipe_screen*,
pipe_context*, BOOL, unsigned int, IDXGIAdapter*, ID3D11Device**)?:
d3d11.cpp:224:200: error: new declaration ?HRESULT
GalliumD3D11DeviceCreate(pipe_screen*, pipe_context*, BOOL, unsigned int,
IDXGIAdapter*, ID3D11Device**)?
../gd3dapi/galliumd3d11.h:65:10: error: ambiguates old declaration ?HRESULT
GalliumD3D11DeviceCreate(pipe_screen*, pipe_context*, BOOL, unsigned int,
IDXGIAdapter*, ID3D11Device**)?
In file included from d3d11.cpp:220:0:
d3d11_context.h: In member function ?HRESULT
GalliumD3D11DeviceContext::Map(ID3D11Resource*, unsigned int,
D3D11_MAP, unsigned int, D3D11_MAPPED_SUBRESOURCE*) [with PtrTraits =
nonatomic_device_child_ptr_traits, HRESULT = int, ID3D11Resource =
ID3D11Resource, D3D11_MAP = D3D11_MAP, D3D11_MAPPED_SUBRESOURCE =
D3D11_MAPPED_SUBRESOURCE]?:
d3d11.cpp:231:1:   instantiated from here
d3d11_context.h:1482:12: warning: unused variable ?face? [-Wunused-variable]
d3d11_context.h: In member function ?void
GalliumD3D11DeviceContext::CopySubresourceRegion(ID3D11Resource*,
unsigned int, unsigned int, unsigned int, unsigned int, ID3D11Resource*,
unsigned int, const D3D11_BOX*) [with PtrTraits =
nonatomic_device_child_ptr_traits, ID3D11Resource = ID3D11Resource, D3D11_BOX =
D3D11_BOX]?:
d3d11.cpp:231:1:   instantiated from here
d3d11_context.h:1543:12: warning: unused variable ?dst_face?
[-Wunused-variable]
d3d11_context.h:1545:12: warning: unused variable ?src_face?
[-Wunused-variable]
make[5]: *** [d3d11.o] Error 1
make[5]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/d3d1x/gd3d11'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/d3d1x'
make[3]: *** [subdirs] Error 1
make[3]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src'
make: *** [default] Error 1
---

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

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

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

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

Christoph Bumiller  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Christoph Bumiller  
2011-10-13 02:09:40 PDT ---
Fixed in mesa/master with f1f7645f23bd11fb54a992cdbe9ef0a6ee0136f3.

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

[Bug 36777] radeon 0000:01:00.0: IH ring buffer overflow (0xFFFFFFFF, 15, 65550)

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

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

Cedric Sodhi  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[PATCH 9/9] drm/radeon/kms: rename a variable for consistency

[Ilija Hadzic]

blit copy functions deal with GPU pages, not CPU pages,
so rename the variables and parameters accordingly

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/r600_blit_kms.c |   27 ++-
 drivers/gpu/drm/radeon/radeon_asic.h   |4 ++--
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index 07e3df4..a9e1fde 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -628,14 +628,14 @@ static void r600_vb_ib_put(struct radeon_device *rdev)
radeon_ib_free(rdev, >r600_blit.vb_ib);
 }

-static unsigned r600_blit_create_rect(unsigned num_pages,
+static unsigned r600_blit_create_rect(unsigned num_gpu_pages,
  int *width, int *height, int max_dim)
 {
unsigned max_pages;
-   unsigned pages = num_pages;
+   unsigned pages = num_gpu_pages;
int w, h;

-   if (num_pages == 0) {
+   if (num_gpu_pages == 0) {
/* not supposed to be called with no pages, but just in case */
h = 0;
w = 0;
@@ -644,7 +644,7 @@ static unsigned r600_blit_create_rect(unsigned num_pages,
} else {
int rect_order = 2;
h = RECT_UNIT_H;
-   while (num_pages / rect_order) {
+   while (num_gpu_pages / rect_order) {
h *= 2;
rect_order *= 4;
if (h >= max_dim) {
@@ -674,7 +674,7 @@ static unsigned r600_blit_create_rect(unsigned num_pages,
 }


-int r600_blit_prepare_copy(struct radeon_device *rdev, unsigned num_pages)
+int r600_blit_prepare_copy(struct radeon_device *rdev, unsigned num_gpu_pages)
 {
int r;
int ring_size;
@@ -686,9 +686,10 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, 
unsigned num_pages)
return r;

/* num loops */
-   while (num_pages) {
-   num_pages -= r600_blit_create_rect(num_pages, NULL, NULL,
-  rdev->r600_blit.max_dim);
+   while (num_gpu_pages) {
+   num_gpu_pages -=
+   r600_blit_create_rect(num_gpu_pages, NULL, NULL,
+ rdev->r600_blit.max_dim);
num_loops++;
}

@@ -719,21 +720,21 @@ void r600_blit_done_copy(struct radeon_device *rdev, 
struct radeon_fence *fence)

 void r600_kms_blit_copy(struct radeon_device *rdev,
u64 src_gpu_addr, u64 dst_gpu_addr,
-   unsigned num_pages)
+   unsigned num_gpu_pages)
 {
u64 vb_gpu_addr;
u32 *vb;

DRM_DEBUG("emitting copy %16llx %16llx %d %d\n",
  src_gpu_addr, dst_gpu_addr,
- num_pages, rdev->r600_blit.vb_used);
+ num_gpu_pages, rdev->r600_blit.vb_used);
vb = (u32 *)(rdev->r600_blit.vb_ib->ptr + rdev->r600_blit.vb_used);

-   while (num_pages) {
+   while (num_gpu_pages) {
int w, h;
unsigned size_in_bytes;
unsigned pages_per_loop =
-   r600_blit_create_rect(num_pages, , ,
+   r600_blit_create_rect(num_gpu_pages, , ,
  rdev->r600_blit.max_dim);

size_in_bytes = pages_per_loop * RADEON_GPU_PAGE_SIZE;
@@ -777,6 +778,6 @@ void r600_kms_blit_copy(struct radeon_device *rdev,
rdev->r600_blit.vb_used += 4*12;
src_gpu_addr += size_in_bytes;
dst_gpu_addr += size_in_bytes;
-   num_pages -= pages_per_loop;
+   num_gpu_pages -= pages_per_loop;
}
 }
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index c8be1d3..e040de3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -364,11 +364,11 @@ void r600_hdmi_init(struct drm_encoder *encoder);
 int r600_hdmi_buffer_status_changed(struct drm_encoder *encoder);
 void r600_hdmi_update_audio_settings(struct drm_encoder *encoder);
 /* r600 blit */
-int r600_blit_prepare_copy(struct radeon_device *rdev, unsigned num_pages);
+int r600_blit_prepare_copy(struct radeon_device *rdev, unsigned num_gpu_pages);
 void r600_blit_done_copy(struct radeon_device *rdev, struct radeon_fence 
*fence);
 void r600_kms_blit_copy(struct radeon_device *rdev,
u64 src_gpu_addr, u64 dst_gpu_addr,
-   unsigned num_pages);
+   unsigned num_gpu_pages);

 /*
  * rv770,rv730,rv710,rv740
-- 
1.7.7

[PATCH 8/9] drm/radeon/kms: blit code commoning

[Ilija Hadzic]

factor out most of evergreen blit code and use the refactored code
from r600 that is now common for both r600 and evergreen

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/evergreen.c  |   25 +---
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |  260 ++-
 drivers/gpu/drm/radeon/ni.c |4 +-
 drivers/gpu/drm/radeon/radeon_asic.c|   16 +-
 drivers/gpu/drm/radeon/radeon_asic.h|   10 -
 5 files changed, 30 insertions(+), 285 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 5f0ecc7..69dded2 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3087,7 +3087,7 @@ static int evergreen_startup(struct radeon_device *rdev)

r = evergreen_blit_init(rdev);
if (r) {
-   evergreen_blit_fini(rdev);
+   r600_blit_fini(rdev);
rdev->asic->copy = NULL;
dev_warn(rdev->dev, "failed blitter (%d) falling back to 
memcpy\n", r);
}
@@ -3172,27 +3172,6 @@ int evergreen_suspend(struct radeon_device *rdev)
return 0;
 }

-int evergreen_copy_blit(struct radeon_device *rdev,
-   uint64_t src_offset, uint64_t dst_offset,
-   unsigned num_pages, struct radeon_fence *fence)
-{
-   int r;
-
-   mutex_lock(>r600_blit.mutex);
-   rdev->r600_blit.vb_ib = NULL;
-   r = evergreen_blit_prepare_copy(rdev, num_pages);
-   if (r) {
-   if (rdev->r600_blit.vb_ib)
-   radeon_ib_free(rdev, >r600_blit.vb_ib);
-   mutex_unlock(>r600_blit.mutex);
-   return r;
-   }
-   evergreen_kms_blit_copy(rdev, src_offset, dst_offset, num_pages);
-   evergreen_blit_done_copy(rdev, fence);
-   mutex_unlock(>r600_blit.mutex);
-   return 0;
-}
-
 /* Plan is to move initialization in that function and use
  * helper function so that radeon_device_init pretty much
  * do nothing more than calling asic specific function. This
@@ -3301,7 +3280,7 @@ int evergreen_init(struct radeon_device *rdev)

 void evergreen_fini(struct radeon_device *rdev)
 {
-   evergreen_blit_fini(rdev);
+   r600_blit_fini(rdev);
r700_cp_fini(rdev);
r600_irq_fini(rdev);
radeon_wb_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 68d0de2..dcf11bb 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -44,10 +44,6 @@
 #define COLOR_5_6_5   0x8
 #define COLOR_8_8_8_8 0x1a

-#define RECT_UNIT_H   32
-#define RECT_UNIT_W   (RADEON_GPU_PAGE_SIZE / 4 / RECT_UNIT_H)
-#define MAX_RECT_DIM  16384
-
 /* emits 17 */
 static void
 set_render_target(struct radeon_device *rdev, int format,
@@ -599,31 +595,6 @@ set_default_state(struct radeon_device *rdev)

 }

-static inline uint32_t i2f(uint32_t input)
-{
-   u32 result, i, exponent, fraction;
-
-   if ((input & 0x3fff) == 0)
-   result = 0; /* 0 is a special case */
-   else {
-   exponent = 140; /* exponent biased by 127; */
-   fraction = (input & 0x3fff) << 10; /* cheat and only
- handle numbers below 
2^^15 */
-   for (i = 0; i < 14; i++) {
-   if (fraction & 0x80)
-   break;
-   else {
-   fraction = fraction << 1; /* keep
-shifting left 
until top bit = 1 */
-   exponent = exponent - 1;
-   }
-   }
-   result = exponent << 23 | (fraction & 0x7f); /* mask
-   off top 
bit; assumed 1 */
-   }
-   return result;
-}
-
 int evergreen_blit_init(struct radeon_device *rdev)
 {
u32 obj_size;
@@ -632,6 +603,24 @@ int evergreen_blit_init(struct radeon_device *rdev)
u32 packet2s[16];
int num_packet2s = 0;

+   rdev->r600_blit.primitives.set_render_target = set_render_target;
+   rdev->r600_blit.primitives.cp_set_surface_sync = cp_set_surface_sync;
+   rdev->r600_blit.primitives.set_shaders = set_shaders;
+   rdev->r600_blit.primitives.set_vtx_resource = set_vtx_resource;
+   rdev->r600_blit.primitives.set_tex_resource = set_tex_resource;
+   rdev->r600_blit.primitives.set_scissors = set_scissors;
+   rdev->r600_blit.primitives.draw_auto = draw_auto;
+   rdev->r600_blit.primitives.set_default_state = set_default_state;
+
+   rdev->r600_blit.ring_size_common = 55; /* shaders + def state */
+   rdev->r600_blit.ring_size_common += 10; /* fence emit for VB IB */
+   rdev->r600_blit.ring_size_common += 5; /* done 

[PATCH 7/9] drm/radeon/kms: cleanup r600 blit code

[Ilija Hadzic]

reorganize the code such that only the primitives (i.e., the functions
that load the CP ring) are hardware specific; dynamically link the
primitives in a (new) pointer structure inside r600_blit at
blit initialization time so that the functions that control the blit
operations can be made common for r600 and evergreen parts

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/r600_blit_kms.c |   94 +---
 drivers/gpu/drm/radeon/radeon.h|   21 +++
 2 files changed, 70 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index 71fec92..07e3df4 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -44,7 +44,6 @@

 #define RECT_UNIT_H   32
 #define RECT_UNIT_W   (RADEON_GPU_PAGE_SIZE / 4 / RECT_UNIT_H)
-#define MAX_RECT_DIM  8192

 /* emits 21 on rv770+, 23 on r600 */
 static void
@@ -491,6 +490,27 @@ int r600_blit_init(struct radeon_device *rdev)
u32 packet2s[16];
int num_packet2s = 0;

+   rdev->r600_blit.primitives.set_render_target = set_render_target;
+   rdev->r600_blit.primitives.cp_set_surface_sync = cp_set_surface_sync;
+   rdev->r600_blit.primitives.set_shaders = set_shaders;
+   rdev->r600_blit.primitives.set_vtx_resource = set_vtx_resource;
+   rdev->r600_blit.primitives.set_tex_resource = set_tex_resource;
+   rdev->r600_blit.primitives.set_scissors = set_scissors;
+   rdev->r600_blit.primitives.draw_auto = draw_auto;
+   rdev->r600_blit.primitives.set_default_state = set_default_state;
+
+   rdev->r600_blit.ring_size_common = 40; /* shaders + def state */
+   rdev->r600_blit.ring_size_common += 10; /* fence emit for VB IB */
+   rdev->r600_blit.ring_size_common += 5; /* done copy */
+   rdev->r600_blit.ring_size_common += 10; /* fence emit for done copy */
+
+   rdev->r600_blit.ring_size_per_loop = 76;
+   /* set_render_target emits 2 extra dwords on rv6xx */
+   if (rdev->family > CHIP_R600 && rdev->family < CHIP_RV770)
+   rdev->r600_blit.ring_size_per_loop += 2;
+
+   rdev->r600_blit.max_dim = 8192;
+
/* pin copy shader into vram if already initialized */
if (rdev->r600_blit.shader_obj)
goto done;
@@ -608,9 +628,8 @@ static void r600_vb_ib_put(struct radeon_device *rdev)
radeon_ib_free(rdev, >r600_blit.vb_ib);
 }

-/* FIXME: the function is very similar to evergreen_blit_create_rect, except
-   that it different predefined constants; consider commonizing */
-static unsigned r600_blit_create_rect(unsigned num_pages, int *width, int 
*height)
+static unsigned r600_blit_create_rect(unsigned num_pages,
+ int *width, int *height, int max_dim)
 {
unsigned max_pages;
unsigned pages = num_pages;
@@ -628,12 +647,12 @@ static unsigned r600_blit_create_rect(unsigned num_pages, 
int *width, int *heigh
while (num_pages / rect_order) {
h *= 2;
rect_order *= 4;
-   if (h >= MAX_RECT_DIM) {
-   h = MAX_RECT_DIM;
+   if (h >= max_dim) {
+   h = max_dim;
break;
}
}
-   max_pages = (MAX_RECT_DIM * h) / (RECT_UNIT_W * RECT_UNIT_H);
+   max_pages = (max_dim * h) / (RECT_UNIT_W * RECT_UNIT_H);
if (pages > max_pages)
pages = max_pages;
w = (pages * RECT_UNIT_W * RECT_UNIT_H) / h;
@@ -659,36 +678,29 @@ int r600_blit_prepare_copy(struct radeon_device *rdev, 
unsigned num_pages)
 {
int r;
int ring_size;
-   /* loops of emits 64 + fence emit possible */
-   int dwords_per_loop = 76, num_loops = 0;
+   int num_loops = 0;
+   int dwords_per_loop = rdev->r600_blit.ring_size_per_loop;

r = r600_vb_ib_get(rdev);
if (r)
return r;

-   /* set_render_target emits 2 extra dwords on rv6xx */
-   if (rdev->family > CHIP_R600 && rdev->family < CHIP_RV770)
-   dwords_per_loop += 2;
-
/* num loops */
while (num_pages) {
-   num_pages -= r600_blit_create_rect(num_pages, NULL, NULL);
+   num_pages -= r600_blit_create_rect(num_pages, NULL, NULL,
+  rdev->r600_blit.max_dim);
num_loops++;
}

/* calculate number of loops correctly */
ring_size = num_loops * dwords_per_loop;
-   /* set default  + shaders */
-   ring_size += 40; /* shaders + def state */
-   ring_size += 10; /* fence emit for VB IB */
-   ring_size += 5; /* done copy */
-   ring_size += 10; /* fence emit for done copy */
+   ring_size += rdev->r600_blit.ring_size_common;
  

[PATCH 6/9] drm/radeon/kms: add more elaborate benchmarks

[Ilija Hadzic]

Lots of new (and hopefully useful) benchmark. Load the driver
with radeon_benchmark= and enjoy. Among tests
added are VRAM to VRAM blits and blits with buffer size sweeps.
The latter can be from GTT to VRAM, VRAM to GTT, and VRAM to VRAM
and there are two types of sweeps: powers of two and (probably
more interesting) buffers sizes that correspond to common modes.

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/radeon.h   |2 +-
 drivers/gpu/drm/radeon/radeon_benchmark.c |   91 +++--
 drivers/gpu/drm/radeon/radeon_device.c|2 +-
 3 files changed, 87 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ff5424e..5361dd7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -868,7 +868,7 @@ struct radeon_pm {
 /*
  * Benchmarking
  */
-void radeon_benchmark(struct radeon_device *rdev);
+void radeon_benchmark(struct radeon_device *rdev, int test_number);


 /*
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 6951426..5cafc90 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -30,6 +30,7 @@
 #define RADEON_BENCHMARK_COPY_DMA  0

 #define RADEON_BENCHMARK_ITERATIONS 1024
+#define RADEON_BENCHMARK_COMMON_MODES_N 17

 static int radeon_benchmark_do_move(struct radeon_device *rdev, unsigned size,
uint64_t saddr, uint64_t daddr,
@@ -126,7 +127,9 @@ static void radeon_benchmark_move(struct radeon_device 
*rdev, unsigned size,
}

/* r100 doesn't have dma engine so skip the test */
-   if (rdev->asic->copy_dma) {
+   /* also, VRAM-to-VRAM test doesn't make much sense for DMA */
+   /* skip it as well if domains are the same */
+   if ((rdev->asic->copy_dma) && (sdomain != ddomain)) {
time = radeon_benchmark_do_move(rdev, size, saddr, daddr,
RADEON_BENCHMARK_COPY_DMA, n);
if (time < 0)
@@ -167,10 +170,86 @@ out_cleanup:
}
 }

-void radeon_benchmark(struct radeon_device *rdev)
+void radeon_benchmark(struct radeon_device *rdev, int test_number)
 {
-   radeon_benchmark_move(rdev, 1024*1024, RADEON_GEM_DOMAIN_GTT,
- RADEON_GEM_DOMAIN_VRAM);
-   radeon_benchmark_move(rdev, 1024*1024, RADEON_GEM_DOMAIN_VRAM,
- RADEON_GEM_DOMAIN_GTT);
+   int i;
+   int common_modes[RADEON_BENCHMARK_COMMON_MODES_N] = {
+   640 * 480 * 4,
+   720 * 480 * 4,
+   800 * 600 * 4,
+   848 * 480 * 4,
+   1024 * 768 * 4,
+   1152 * 768 * 4,
+   1280 * 720 * 4,
+   1280 * 800 * 4,
+   1280 * 854 * 4,
+   1280 * 960 * 4,
+   1280 * 1024 * 4,
+   1440 * 900 * 4,
+   1400 * 1050 * 4,
+   1680 * 1050 * 4,
+   1600 * 1200 * 4,
+   1920 * 1080 * 4,
+   1920 * 1200 * 4
+   };
+
+   switch (test_number) {
+   case 1:
+   /* simple test, VRAM to GTT and GTT to VRAM */
+   radeon_benchmark_move(rdev, 1024*1024, RADEON_GEM_DOMAIN_GTT,
+ RADEON_GEM_DOMAIN_VRAM);
+   radeon_benchmark_move(rdev, 1024*1024, RADEON_GEM_DOMAIN_VRAM,
+ RADEON_GEM_DOMAIN_GTT);
+   break;
+   case 2:
+   /* simple test, VRAM to VRAM */
+   radeon_benchmark_move(rdev, 1024*1024, RADEON_GEM_DOMAIN_VRAM,
+ RADEON_GEM_DOMAIN_VRAM);
+   break;
+   case 3:
+   /* GTT to VRAM, buffer size sweep, powers of 2 */
+   for (i = 1; i <= 65536; i <<= 1)
+   radeon_benchmark_move(rdev, i*1024,
+ RADEON_GEM_DOMAIN_GTT,
+ RADEON_GEM_DOMAIN_VRAM);
+   break;
+   case 4:
+   /* VRAM to GTT, buffer size sweep, powers of 2 */
+   for (i = 1; i <= 65536; i <<= 1)
+   radeon_benchmark_move(rdev, i*1024,
+ RADEON_GEM_DOMAIN_VRAM,
+ RADEON_GEM_DOMAIN_GTT);
+   break;
+   case 5:
+   /* VRAM to VRAM, buffer size sweep, powers of 2 */
+   for (i = 1; i <= 65536; i <<= 1)
+   radeon_benchmark_move(rdev, i*1024,
+ RADEON_GEM_DOMAIN_VRAM,
+ RADEON_GEM_DOMAIN_VRAM);
+   break;
+   case 6:
+   /* GTT to VRAM, buffer size sweep, common modes */
+   for (i = 1; i < 

[PATCH 5/9] drm/radeon/kms: cleanup benchmark code

[Ilija Hadzic]

factor out repeated code into functions
fix units in which the throughput is reported (megabytes per second
and megabits per second make sense, others are kind of confusing)
make report more amenable to awk and friends (e.g. whitespace is
always the separator, unit is separated from the number, etc)
add #defines for some hard coded constants

besides "beautification" this reorg is done in preparation
for writing more elaborate benchmarks

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/radeon_benchmark.c |  156 -
 1 files changed, 86 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 10191d9..6951426 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -26,21 +26,80 @@
 #include "radeon_reg.h"
 #include "radeon.h"

-void radeon_benchmark_move(struct radeon_device *rdev, unsigned bsize,
-  unsigned sdomain, unsigned ddomain)
+#define RADEON_BENCHMARK_COPY_BLIT 1
+#define RADEON_BENCHMARK_COPY_DMA  0
+
+#define RADEON_BENCHMARK_ITERATIONS 1024
+
+static int radeon_benchmark_do_move(struct radeon_device *rdev, unsigned size,
+   uint64_t saddr, uint64_t daddr,
+   int flag, int n)
+{
+   unsigned long start_jiffies;
+   unsigned long end_jiffies;
+   struct radeon_fence *fence = NULL;
+   int i, r;
+
+   start_jiffies = jiffies;
+   for (i = 0; i < n; i++) {
+   r = radeon_fence_create(rdev, );
+   if (r)
+   return r;
+
+   switch (flag) {
+   case RADEON_BENCHMARK_COPY_DMA:
+   r = radeon_copy_dma(rdev, saddr, daddr,
+   size / RADEON_GPU_PAGE_SIZE,
+   fence);
+   break;
+   case RADEON_BENCHMARK_COPY_BLIT:
+   r = radeon_copy_blit(rdev, saddr, daddr,
+size / RADEON_GPU_PAGE_SIZE,
+fence);
+   break;
+   default:
+   DRM_ERROR("Unknown copy method\n");
+   r = -EINVAL;
+   }
+   if (r)
+   goto exit_do_move;
+   r = radeon_fence_wait(fence, false);
+   if (r)
+   goto exit_do_move;
+   radeon_fence_unref();
+   }
+   end_jiffies = jiffies;
+   r = jiffies_to_msecs(end_jiffies - start_jiffies);
+
+exit_do_move:
+   if (fence)
+   radeon_fence_unref();
+   return r;
+}
+
+
+static void radeon_benchmark_log_results(int n, unsigned size,
+unsigned int time,
+unsigned sdomain, unsigned ddomain,
+char *kind)
+{
+   unsigned int throughput = (n * (size >> 10)) / time;
+   DRM_INFO("radeon: %s %u bo moves of %u kB from"
+" %d to %d in %u ms, throughput: %u Mb/s or %u MB/s\n",
+kind, n, size >> 10, sdomain, ddomain, time,
+throughput * 8, throughput);
+}
+
+static void radeon_benchmark_move(struct radeon_device *rdev, unsigned size,
+ unsigned sdomain, unsigned ddomain)
 {
struct radeon_bo *dobj = NULL;
struct radeon_bo *sobj = NULL;
-   struct radeon_fence *fence = NULL;
uint64_t saddr, daddr;
-   unsigned long start_jiffies;
-   unsigned long end_jiffies;
-   unsigned long time;
-   unsigned i, n, size;
-   int r;
+   int r, n;
+   unsigned int time;

-   size = bsize;
-   n = 1024;
+   n = RADEON_BENCHMARK_ITERATIONS;
r = radeon_bo_create(rdev, size, PAGE_SIZE, true, sdomain, );
if (r) {
goto out_cleanup;
@@ -68,64 +127,23 @@ void radeon_benchmark_move(struct radeon_device *rdev, 
unsigned bsize,

/* r100 doesn't have dma engine so skip the test */
if (rdev->asic->copy_dma) {
-
-   start_jiffies = jiffies;
-   for (i = 0; i < n; i++) {
-   r = radeon_fence_create(rdev, );
-   if (r) {
-   goto out_cleanup;
-   }
-
-   r = radeon_copy_dma(rdev, saddr, daddr,
-   size / RADEON_GPU_PAGE_SIZE, fence);
-
-   if (r) {
-   goto out_cleanup;
-   }
-   r = radeon_fence_wait(fence, false);
-   if (r) {
-   goto out_cleanup;
-   }
-   radeon_fence_unref();
-   }
-   

[PATCH 4/9] drm/radeon/kms: demystify r600 blit code

[Ilija Hadzic]

some 3d register bits look like magic in r600 blit functions
use predefined constants to make it more intuitive what they are

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/r600_blit_kms.c |   30 +-
 drivers/gpu/drm/radeon/r600d.h |   22 ++
 2 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index d9994c9..71fec92 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -58,7 +58,9 @@ set_render_target(struct radeon_device *rdev, int format,
if (h < 8)
h = 8;

-   cb_color_info = ((format << 2) | (1 << 27) | (1 << 8));
+   cb_color_info = CB_FORMAT(format) |
+   CB_SOURCE_FORMAT(CB_SF_EXPORT_NORM) |
+   CB_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
pitch = (w / 8) - 1;
slice = ((w * h) / 64) - 1;

@@ -168,9 +170,10 @@ set_vtx_resource(struct radeon_device *rdev, u64 gpu_addr)
 {
u32 sq_vtx_constant_word2;

-   sq_vtx_constant_word2 = ((upper_32_bits(gpu_addr) & 0xff) | (16 << 8));
+   sq_vtx_constant_word2 = SQ_VTXC_BASE_ADDR_HI(upper_32_bits(gpu_addr) & 
0xff) |
+   SQ_VTXC_STRIDE(16);
 #ifdef __BIG_ENDIAN
-   sq_vtx_constant_word2 |= (2 << 30);
+   sq_vtx_constant_word2 |=  SQ_VTXC_ENDIAN_SWAP(SQ_ENDIAN_8IN32);
 #endif

radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 7));
@@ -206,18 +209,19 @@ set_tex_resource(struct radeon_device *rdev,
if (h < 1)
h = 1;

-   sq_tex_resource_word0 = (1 << 0) | (1 << 3);
-   sq_tex_resource_word0 |= pitch >> 3) - 1) << 8) |
- ((w - 1) << 19));
+   sq_tex_resource_word0 = S_038000_DIM(V_038000_SQ_TEX_DIM_2D) |
+   S_038000_TILE_MODE(V_038000_ARRAY_1D_TILED_THIN1);
+   sq_tex_resource_word0 |= S_038000_PITCH((pitch >> 3) - 1) |
+   S_038000_TEX_WIDTH(w - 1);

-   sq_tex_resource_word1 = (format << 26);
-   sq_tex_resource_word1 |= ((h - 1) << 0);
+   sq_tex_resource_word1 = S_038004_DATA_FORMAT(format);
+   sq_tex_resource_word1 |= S_038004_TEX_HEIGHT(h - 1);

-   sq_tex_resource_word4 = ((1 << 14) |
-(0 << 16) |
-(1 << 19) |
-(2 << 22) |
-(3 << 25));
+   sq_tex_resource_word4 = S_038010_REQUEST_SIZE(1) |
+   S_038010_DST_SEL_X(SQ_SEL_X) |
+   S_038010_DST_SEL_Y(SQ_SEL_Y) |
+   S_038010_DST_SEL_Z(SQ_SEL_Z) |
+   S_038010_DST_SEL_W(SQ_SEL_W);

radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 7));
radeon_ring_write(rdev, 0);
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 0245ae6..bfe1b5d 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -79,6 +79,11 @@
 #define CB_COLOR0_SIZE  0x28060
 #define CB_COLOR0_VIEW  0x28080
 #define CB_COLOR0_INFO  0x280a0
+#  define CB_FORMAT(x) ((x) << 2)
+#   define CB_ARRAY_MODE(x) ((x) << 8)
+#  define CB_SOURCE_FORMAT(x)  ((x) << 27)
+#  define CB_SF_EXPORT_FULL0
+#  define CB_SF_EXPORT_NORM1
 #define CB_COLOR0_TILE  0x280c0
 #define CB_COLOR0_FRAG  0x280e0
 #define CB_COLOR0_MASK  0x28100
@@ -417,6 +422,17 @@
 #defineSQ_PGM_START_VS 0x28858
 #define SQ_PGM_RESOURCES_VS 0x28868
 #define SQ_PGM_CF_OFFSET_VS 0x288d0
+
+#define SQ_VTX_CONSTANT_WORD0_00x3
+#define SQ_VTX_CONSTANT_WORD1_00x30004
+#define SQ_VTX_CONSTANT_WORD2_00x30008
+#  define SQ_VTXC_BASE_ADDR_HI(x)  ((x) << 0)
+#  define SQ_VTXC_STRIDE(x)((x) << 8)
+#  define SQ_VTXC_ENDIAN_SWAP(x)   ((x) << 30)
+#  define SQ_ENDIAN_NONE   0
+#  define SQ_ENDIAN_8IN16  1
+#  define SQ_ENDIAN_8IN32  2
+#define SQ_VTX_CONSTANT_WORD3_00x3000c
 #defineSQ_VTX_CONSTANT_WORD6_0 0x38018
 #defineS__SQ_VTX_CONSTANT_TYPE(x)  (((x) & 
3) << 30)
 #defineG__SQ_VTX_CONSTANT_TYPE(x)  (((x) 
>> 30) & 3)
@@ -1352,6 +1368,12 @@
 #define   S_038010_DST_SEL_W(x)(((x) & 0x7) << 25)
 #define   

[PATCH 3/9] drm/radeon/kms: demystify evergreen blit code

[Ilija Hadzic]

some bits in 3D registers used by blit functions look like
magic and this is hard to follow; change them to a little bit
more meaningful pre-defined constants

Signed-off-by: Ilija Hadzic 
---
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |   29 +--
 drivers/gpu/drm/radeon/evergreend.h |   42 +++
 2 files changed, 62 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 3b24137..68d0de2 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -60,7 +60,9 @@ set_render_target(struct radeon_device *rdev, int format,
if (h < 8)
h = 8;

-   cb_color_info = ((format << 2) | (1 << 24) | (2 << 8));
+   cb_color_info = CB_FORMAT(format) |
+   CB_SOURCE_FORMAT(CB_SF_EXPORT_NORM) |
+   CB_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
pitch = (w / 8) - 1;
slice = ((w * h) / 64) - 1;

@@ -137,12 +139,16 @@ set_vtx_resource(struct radeon_device *rdev, u64 gpu_addr)
u32 sq_vtx_constant_word2, sq_vtx_constant_word3;

/* high addr, stride */
-   sq_vtx_constant_word2 = ((upper_32_bits(gpu_addr) & 0xff) | (16 << 8));
+   sq_vtx_constant_word2 = SQ_VTXC_BASE_ADDR_HI(upper_32_bits(gpu_addr) & 
0xff) |
+   SQ_VTXC_STRIDE(16);
 #ifdef __BIG_ENDIAN
-   sq_vtx_constant_word2 |= (2 << 30);
+   sq_vtx_constant_word2 |= SQ_VTXC_ENDIAN_SWAP(SQ_ENDIAN_8IN32);
 #endif
/* xyzw swizzles */
-   sq_vtx_constant_word3 = (0 << 3) | (1 << 6) | (2 << 9) | (3 << 12);
+   sq_vtx_constant_word3 = SQ_VTCX_SEL_X(SQ_SEL_X) |
+   SQ_VTCX_SEL_Y(SQ_SEL_Y) |
+   SQ_VTCX_SEL_Z(SQ_SEL_Z) |
+   SQ_VTCX_SEL_W(SQ_SEL_W);

radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 8));
radeon_ring_write(rdev, 0x580);
@@ -153,7 +159,7 @@ set_vtx_resource(struct radeon_device *rdev, u64 gpu_addr)
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, 0);
radeon_ring_write(rdev, 0);
-   radeon_ring_write(rdev, SQ_TEX_VTX_VALID_BUFFER << 30);
+   radeon_ring_write(rdev, S__SQ_CONSTANT_TYPE(SQ_TEX_VTX_VALID_BUFFER));

if ((rdev->family == CHIP_CEDAR) ||
(rdev->family == CHIP_PALM) ||
@@ -180,14 +186,19 @@ set_tex_resource(struct radeon_device *rdev,
if (h < 1)
h = 1;

-   sq_tex_resource_word0 = (1 << 0); /* 2D */
+   sq_tex_resource_word0 = TEX_DIM(SQ_TEX_DIM_2D);
sq_tex_resource_word0 |= pitch >> 3) - 1) << 6) |
  ((w - 1) << 18));
-   sq_tex_resource_word1 = ((h - 1) << 0) | (2 << 28);
+   sq_tex_resource_word1 = ((h - 1) << 0) |
+   TEX_ARRAY_MODE(ARRAY_1D_TILED_THIN1);
/* xyzw swizzles */
-   sq_tex_resource_word4 = (0 << 16) | (1 << 19) | (2 << 22) | (3 << 25);
+   sq_tex_resource_word4 = TEX_DST_SEL_X(SQ_SEL_X) |
+   TEX_DST_SEL_Y(SQ_SEL_Y) |
+   TEX_DST_SEL_Z(SQ_SEL_Z) |
+   TEX_DST_SEL_W(SQ_SEL_W);

-   sq_tex_resource_word7 = format | (SQ_TEX_VTX_VALID_TEXTURE << 30);
+   sq_tex_resource_word7 = format |
+   S__SQ_CONSTANT_TYPE(SQ_TEX_VTX_VALID_TEXTURE);

radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 8));
radeon_ring_write(rdev, 0);
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index 7363d9d..b937c49 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -941,11 +941,15 @@
 #defineCB_COLOR0_SLICE 0x28c68
 #defineCB_COLOR0_VIEW  0x28c6c
 #defineCB_COLOR0_INFO  0x28c70
+#  define CB_FORMAT(x) ((x) << 2)
 #   define CB_ARRAY_MODE(x) ((x) << 8)
 #   define ARRAY_LINEAR_GENERAL 0
 #   define ARRAY_LINEAR_ALIGNED 1
 #   define ARRAY_1D_TILED_THIN1 2
 #   define ARRAY_2D_TILED_THIN1 4
+#  define CB_SOURCE_FORMAT(x)  ((x) << 24)
+#  define CB_SF_EXPORT_FULL0
+#  define CB_SF_EXPORT_NORM1
 #defineCB_COLOR0_ATTRIB0x28c74
 #defineCB_COLOR0_DIM   0x28c78
 /* only CB0-7 blocks have these regs */
@@ -1107,15 +,53 @@
 #defineCB_COLOR7_CLEAR_WORD3   0x28e3c

 #define SQ_TEX_RESOURCE_WORD0_0 0x3
+#  define TEX_DIM(x)   ((x) << 0)
+#  define SQ_TEX_DIM_1D0
+#  define SQ_TEX_DIM_2D

[PATCH 2/9] drm/radeon/kms: improve r6xx blit code

[Ilija Hadzic]

start with first-cut conceptual patch from Alex Deucher
(commit info below); turn on 1D tiling
make rectangular buffer always 2:1 or 1:2 ratio
make buffer dimenstions an integer multiple of unit
dimensionsmake sures that integral number of pages map
to the buffer fix a few bugs that resulted in incorrect
dimensions tidy up a little bit to get rid of an ugly
if/else parametrize some "magic" constants
add protections from illegal buffer sizes etc.

[PATCH 1/9] drm/radeon/kms: improve evergreen blit code

[Ilija Hadzic]

start with first-cut conceptual patch from Alex Deucher
(commit info below); turn on 1D tiling
make rectangular buffer always 2:1 or 1:2 ratio
make buffer dimenstions an integer multiple of unit dimensions
make sures that integral number of pages map to the buffer
fix a few bugs that resulted in incorrect dimensions
tidy up a little bit to get rid of an ugly if/else
parametrize some "magic" constants
add protections from illegal buffer sizes etc.

drm/radeon/kms: improve performance of blit-copy

[Ilija Hadzic]

The following set of patches will improve the performance
of blit-copy functions for Radeon GPUs based on 
R600, R700, Evergreen and NI ASICs.

The foundation for improvement is the use of tiled mode access
(which for copying bo's can be used regardless of whether the
content is tiled or not), and segmenting the memory block
being copied into rectangles whose edge ratio is between 1:1
and 1:2. This maximizes the number of PCIe transactions that
use maximum payload size (typically 128 bytes) and also 
creates a memory access pattern that is more favorable for
both VRAM and host DRAM than what's currently in the kernel.

To come up with the new blit-copy code, I did a lot of 
PCIe traffic analysis with the bus analyzer and also 
had many discussions with Alex, trying to explain what's 
going on (thanks to Alex for his time).

Below (at the end of this note) are the results of some benchmarks
that I did with various GPUs (all in the same host: Intel i7 CPU,
X58 chipset, three DRAM channels). To run the tests on your machine
load the radeon module with 'benchmark=1 pcie_gen2=1' parameters.
Most significant improvement is in the upstream (VRAM to GART)
direction because that's where the PCIe transactions were fragmented 
and also where memory access pattern was such that it created a lot of 
backpressure from the host.

It is also interesting that high-end devices (e.g. Cayman) exhibit
the least improvement and were the worst to begin with. This is
because high-end devices copy more tiles in parallel which 
in turn can create bank conflicts on host memory and cause the
host to do lots of bank-close/precharge/bank-open cycles. 

As an added "bonus", I also did some code cleanup and consolidated
the repeated code into common function, so r600 and evergreen/NI
parts now share the blit-copy code. I also expanded on the
benchmark coverage, so the module now takes benckmark parameter
value between 1 and 8 and each results in running a different 
benchmark.

For details, see the commit log messages and the code.
I have been running with these patches for a few months 
(and I kept rebasing them to drm-core-next as the public 
git progressed) and I used them in a system setup that does
*many* copying of this kind (and does them frequently); I 
have not seen instabilities introduced by these patches. I also
verified the correctness of the copy using test=1 parameter
for each GPU that I had and the test passed.

I would welcome some feedback and if you run the benchmarks
with the new blit code, I would very much like to hear
what kind of improvement you are seeing.


BENCHMARK RESULTS:
==

1) VRAM to GTT 
==

Card (ASIC) VRAMBefore  After
-
5570 (Redwood)  DDR3 1600MHZ 4543912
6450 (Caicos)   DDR5 3200MHz37185090
6570 (Turks)DDR3 1800MHz 4844144
5450 (Cedar)DDR3 1600MHz36795090
5450 (Cedar)DDR2  800MHz26954639
E4690 (RV730)   DDR3 1400MHZ 4854969
E6760 (Turks)   DDR5 3200MHz 4744177
V5700 (RV730)   DDR3 MHz 4884297
2260 (RV620)DDR2 MHz 4943093
6870 (Barts)DDR5 4200MHz 4751113
6970 (Cayman)   DDR5 4200MHz 473 710

2) GTT to VRAM
==

Card (ASIC) VRAMBefore  After
-
5570 (Redwood)  DDR3 1600MHz31583360
6450 (Caicos)   DDR5 3200MHz29953393
6570 (Turks)DDR3 1800MHz30393339
5450 (Cedar)DDR3 1600MHz32463404
5450 (Cedar)DDR2  800MHz26143371
E4690 (RV730)   DDR3 1400MHz30843426
E6760 (Turks)   DDR5 3200MHz24432570
V5700 (RV730)   DDR3 MHz31873506
2260 (RV620)DDR2 MHz 5843246
6870 (Barts)DDR5 4200MHz24722601
6970 (Cayman)   DDR5 4200MHz24602737

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #12 from dmotd  2011-10-12 
23:27:01 PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #6)
> > > > > running glxgears just shows an empty black box.. all other glx demos 
> > > > > are the
> > > > > same empty boxes.. 
> > > > 
> > > > Do they work with the environment variable vblank_mode=0? If yes, does 
> > > > the
> > > > number for radeon increase in /proc/interrupts once the problem occurs?
> > > 
> > > setting vblank_mode=0 works and displays an output.. but not much change 
> > > in
> > > /proc/interrupts (irq 46 for radeon)
> > 
> > Not much change for the radeon number, or none at all? If the latter,
> > apparently the IRQ for the radeon card stops working for some reason, which
> > would explain the core symptoms of the freeze.
> 
> no change to the radeon irq number.

is there a way i can debug this further?

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

[bugzilla-daemon]

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

--- Comment #12 from dmotd inaudi...@simplesuperlativ.es 2011-10-12 23:27:01 
PDT ---
(In reply to comment #11)
 (In reply to comment #10)
  (In reply to comment #6)
 running glxgears just shows an empty black box.. all other glx demos 
 are the
 same empty boxes.. 

Do they work with the environment variable vblank_mode=0? If yes, does 
the
number for radeon increase in /proc/interrupts once the problem occurs?
   
   setting vblank_mode=0 works and displays an output.. but not much change 
   in
   /proc/interrupts (irq 46 for radeon)
  
  Not much change for the radeon number, or none at all? If the latter,
  apparently the IRQ for the radeon card stops working for some reason, which
  would explain the core symptoms of the freeze.
 
 no change to the radeon irq number.

is there a way i can debug this further?

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

[PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Takashi Iwai]

The commit 47356eb67285014527a5ab87543ba1fae3d1e10a introduced a
mechanism to record the backlight level only at disabling time, but it
also introduced a regression.  Since intel_lvds_enable() may be called
without disabling (e.g. intel_lvds_commit() calls it unconditionally),
the backlight gets back to the last recorded value.  For example, this
happens when you dim the backlight, close the lid and open the lid,
then the backlight suddenly goes to the brightest.

This patch fixes the bug by recording the backlight level always
when changed but only when dev_priv-backlight_enabled is set.
In this way, the bogus value for disabling backlight can be skipped.

Signed-off-by: Takashi Iwai ti...@suse.de
---

Feel free to add Cc to stable kernel, as this is a regression fix.
I've tested only a few machines here so more tests would be
appreciated, because the backlight issue is SOOO sensitive :)


 drivers/gpu/drm/i915/intel_panel.c |   11 +--
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index a9e0c7b..269d526 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -233,6 +233,9 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 
level)
 
DRM_DEBUG_DRIVER(set backlight PWM = %d\n, level);
 
+   if (dev_priv-backlight_enabled)
+   dev_priv-backlight_level = level;
+
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
 
@@ -258,11 +261,7 @@ void intel_panel_disable_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
 
-   if (dev_priv-backlight_enabled) {
-   dev_priv-backlight_level = intel_panel_get_backlight(dev);
-   dev_priv-backlight_enabled = false;
-   }
-
+   dev_priv-backlight_enabled = false;
intel_panel_set_backlight(dev, 0);
 }
 
@@ -273,8 +272,8 @@ void intel_panel_enable_backlight(struct drm_device *dev)
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
 
-   intel_panel_set_backlight(dev, dev_priv-backlight_level);
dev_priv-backlight_enabled = true;
+   intel_panel_set_backlight(dev, dev_priv-backlight_level);
 }
 
 static void intel_panel_init_backlight(struct drm_device *dev)
-- 
1.7.7

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

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

[bugzilla-daemon]

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

Christoph Bumiller e0425...@student.tuwien.ac.at changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Christoph Bumiller e0425...@student.tuwien.ac.at 
2011-10-13 02:09:40 PDT ---
Fixed in mesa/master with f1f7645f23bd11fb54a992cdbe9ef0a6ee0136f3.

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

[PATCH] drm/radeon/kms: Simplify I2C post_xfer function

[Jean Delvare]

There is no point in re-doing in post_xfer all the initialization
that was already done by pre_xfer. Instead, only do the work which
differs from pre_xfer.

Signed-off-by: Jean Delvare jdelv...@suse.de
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon_i2c.c |   48 ---
 1 file changed, 22 insertions(+), 26 deletions(-)

--- linux-3.0.orig/drivers/gpu/drm/radeon/radeon_i2c.c  2011-10-06 
18:39:04.0 +0200
+++ linux-3.0/drivers/gpu/drm/radeon/radeon_i2c.c   2011-10-06 
18:45:27.0 +0200
@@ -81,8 +81,9 @@ bool radeon_ddc_probe(struct radeon_conn
 
 /* bit banging i2c */
 
-static void radeon_i2c_do_lock(struct radeon_i2c_chan *i2c, int lock_state)
+static int pre_xfer(struct i2c_adapter *i2c_adap)
 {
+   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
struct radeon_device *rdev = i2c-dev-dev_private;
struct radeon_i2c_bus_rec *rec = i2c-rec;
uint32_t temp;
@@ -137,19 +138,30 @@ static void radeon_i2c_do_lock(struct ra
WREG32(rec-en_data_reg, temp);
 
/* mask the gpio pins for software use */
-   temp = RREG32(rec-mask_clk_reg);
-   if (lock_state)
-   temp |= rec-mask_clk_mask;
-   else
-   temp = ~rec-mask_clk_mask;
+   temp = RREG32(rec-mask_clk_reg) | rec-mask_clk_mask;
WREG32(rec-mask_clk_reg, temp);
temp = RREG32(rec-mask_clk_reg);
 
+   temp = RREG32(rec-mask_data_reg) | rec-mask_data_mask;
+   WREG32(rec-mask_data_reg, temp);
temp = RREG32(rec-mask_data_reg);
-   if (lock_state)
-   temp |= rec-mask_data_mask;
-   else
-   temp = ~rec-mask_data_mask;
+
+   return 0;
+}
+
+static void post_xfer(struct i2c_adapter *i2c_adap)
+{
+   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
+   struct radeon_device *rdev = i2c-dev-dev_private;
+   struct radeon_i2c_bus_rec *rec = i2c-rec;
+   uint32_t temp;
+
+   /* unmask the gpio pins for software use */
+   temp = RREG32(rec-mask_clk_reg)  ~rec-mask_clk_mask;
+   WREG32(rec-mask_clk_reg, temp);
+   temp = RREG32(rec-mask_clk_reg);
+
+   temp = RREG32(rec-mask_data_reg)  ~rec-mask_data_mask;
WREG32(rec-mask_data_reg, temp);
temp = RREG32(rec-mask_data_reg);
 }
@@ -209,22 +221,6 @@ static void set_data(void *i2c_priv, int
WREG32(rec-en_data_reg, val);
 }
 
-static int pre_xfer(struct i2c_adapter *i2c_adap)
-{
-   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
-
-   radeon_i2c_do_lock(i2c, 1);
-
-   return 0;
-}
-
-static void post_xfer(struct i2c_adapter *i2c_adap)
-{
-   struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
-
-   radeon_i2c_do_lock(i2c, 0);
-}
-
 /* hw i2c */
 
 static u32 radeon_get_i2c_prescale(struct radeon_device *rdev)

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

Question on S3 on evergreen

[Huang, FrankR]

Hi, 
I have a question on S3 suspend/resume process for evergreen
chipset.
Generally introduction, I am developing WEC7 graphics driver on
evergreen chipset. Alex guide me on this. And right now I move to S3
part work. I have ported radeon_suspend_kms() and radeon_resume_kms()
functions from linux to CE. Actually I have validated that the
evergreen_suspend() and evergreen_resume() work already on CE. But when
the resume work is done and the screen is shown up, I found the 3D
engine works wrong. The HW acceleration of it is not correct anymore.
Misrendering is happening. By tracing the root cause, I suspect that the
problem may be in evergreen_gpu_init()( in evergreen_startup) call when
resume(), but I am not sure. Can you guys tell me which part I should
debug?
By the way, the linux kernel source I used is from 2010.10. So
quite a lot patches have been committed into community during this
period. Right now, the kernel source I used is around date
2011.7(Version 3.0.0). Is there any patches update for S3 during this
period?



Thanks,
Frank 

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

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

[bugzilla-daemon]

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

--- Comment #2 from Jos van Wolput wol...@onsneteindhoven.nl 2011-10-13 
03:52:54 PDT ---
(In reply to comment #1)
 Fixed in mesa/master with f1f7645f23bd11fb54a992cdbe9ef0a6ee0136f3.
Still some errors:
---
d3d11.cpp: In function ‘HRESULT GalliumD3D11DeviceCreate(pipe_screen*,
pipe_context*, BOOL, unsigned int, IDXGIAdapter*, ID3D11Device**)’:
d3d11.cpp:224:200: error: new declaration ‘HRESULT
GalliumD3D11DeviceCreate(pipe_screen*, pipe_context*, BOOL, unsigned int,
IDXGIAdapter*, ID3D11Device**)’
../gd3dapi/galliumd3d11.h:65:10: error: ambiguates old declaration ‘HRESULT
GalliumD3D11DeviceCreate(pipe_screen*, pipe_context*, BOOL, unsigned int,
IDXGIAdapter*, ID3D11Device**)’
In file included from d3d11.cpp:220:0:
d3d11_context.h: In member function ‘HRESULT
GalliumD3D11DeviceContextPtrTraits::Map(ID3D11Resource*, unsigned int,
D3D11_MAP, unsigned int, D3D11_MAPPED_SUBRESOURCE*) [with PtrTraits =
nonatomic_device_child_ptr_traits, HRESULT = int, ID3D11Resource =
ID3D11Resource, D3D11_MAP = D3D11_MAP, D3D11_MAPPED_SUBRESOURCE =
D3D11_MAPPED_SUBRESOURCE]’:
d3d11.cpp:231:1:   instantiated from here
d3d11_context.h:1482:12: warning: unused variable ‘face’ [-Wunused-variable]
d3d11_context.h: In member function ‘void
GalliumD3D11DeviceContextPtrTraits::CopySubresourceRegion(ID3D11Resource*,
unsigned int, unsigned int, unsigned int, unsigned int, ID3D11Resource*,
unsigned int, const D3D11_BOX*) [with PtrTraits =
nonatomic_device_child_ptr_traits, ID3D11Resource = ID3D11Resource, D3D11_BOX =
D3D11_BOX]’:
d3d11.cpp:231:1:   instantiated from here
d3d11_context.h:1543:12: warning: unused variable ‘dst_face’
[-Wunused-variable]
d3d11_context.h:1545:12: warning: unused variable ‘src_face’
[-Wunused-variable]
make[5]: *** [d3d11.o] Error 1
make[5]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/d3d1x/gd3d11'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/d3d1x'
make[3]: *** [subdirs] Error 1
make[3]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src'
make: *** [default] Error 1
---

-- 
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: Question on S3 on evergreen

[Xavier Bestel]

Hi,

On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
 [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
 functions from linux to CE. 

I imagine you already have checked with your company's lawyers, but if I
understand correctly that means your drivers will be distributed under
the GPL ?

Thanks,
Xav

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

Re: Question on S3 on evergreen

[Dave Airlie]

On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel xavier.bes...@free.fr wrote:
 Hi,

 On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
 [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
 functions from linux to CE.

 I imagine you already have checked with your company's lawyers, but if I
 understand correctly that means your drivers will be distributed under
 the GPL ?

All the GPU driver code is licensed under MIT.

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

Re: Question on S3 on evergreen

[Xavier Bestel]

On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
 On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel xavier.bes...@free.fr wrote:
  Hi,
 
  On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
  [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
  functions from linux to CE.
 
  I imagine you already have checked with your company's lawyers, but if I
  understand correctly that means your drivers will be distributed under
  the GPL ?
 
 All the GPU driver code is licensed under MIT.

Oh, I thought linux meant kernel, not X11.

Xav

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

Re: Question on S3 on evergreen

[Dave Airlie]

On Thu, Oct 13, 2011 at 1:07 PM, Xavier Bestel xavier.bes...@free.fr wrote:
 On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
 On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel xavier.bes...@free.fr 
 wrote:
  Hi,
 
  On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
  [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
  functions from linux to CE.
 
  I imagine you already have checked with your company's lawyers, but if I
  understand correctly that means your drivers will be distributed under
  the GPL ?

 All the GPU driver code is licensed under MIT.

 Oh, I thought linux meant kernel, not X11.

The kernel drm driver code is all MIT licensed. The license is there
at the top of the files.

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher ag...@yahoo.com 2011-10-13 06:01:08 PDT ---
Try the following options in the kernel command line in grub:
pci=nomsi
noapic
irqpoll
and see if any of them help.

-- 
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: Question on S3 on evergreen

[Alex Deucher]

On Thu, Oct 13, 2011 at 5:54 AM, Huang, FrankR frankr.hu...@amd.com wrote:
 Hi,
        I have a question on S3 suspend/resume process for evergreen
 chipset.
        Generally introduction, I am developing WEC7 graphics driver on
 evergreen chipset. Alex guide me on this. And right now I move to S3
 part work. I have ported radeon_suspend_kms() and radeon_resume_kms()
 functions from linux to CE. Actually I have validated that the
 evergreen_suspend() and evergreen_resume() work already on CE. But when
 the resume work is done and the screen is shown up, I found the 3D
 engine works wrong. The HW acceleration of it is not correct anymore.
 Misrendering is happening. By tracing the root cause, I suspect that the
 problem may be in evergreen_gpu_init()( in evergreen_startup) call when
 resume(), but I am not sure. Can you guys tell me which part I should
 debug?
        By the way, the linux kernel source I used is from 2010.10. So
 quite a lot patches have been committed into community during this
 period. Right now, the kernel source I used is around date
 2011.7(Version 3.0.0). Is there any patches update for S3 during this
 period?


Does soft resetting the GPU during resume help
(evergreen_gpu_soft_reset()) ?  If so, try updating your version of
evergreen_cp_resume() to the latest upstream bits.

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

[Bug 41744] New: Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-daemon]

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

   Summary: Unigine Heaven shows black textures (Radeon HD4250)
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: gse...@gmail.com


Unigine Heaven benchmark shows black textures. It looks like this:
http://imageshack.us/photo/my-images/842/slika322.jpg/
It looks like it's problem with floating-point textures.

This is output of program: http://pastebin.com/GKWmbhV9
Here is my glxinfo: http://pastebin.com/BM9Vw8vm

I am using Ubuntu 11.04 with oibaf PPA build. Do I need to provide more data?

-- 
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 41744] Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-daemon]

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

Gašper Sedej gse...@gmail.com changed:

   What|Removed |Added

  Alias||it

-- 
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 41744] Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-daemon]

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

--- Comment #1 from Gašper Sedej gse...@gmail.com 2011-10-13 06:21:10 PDT ---
Also, FrozenByte games are missing textures (ShadowGrounds and Trine)

-- 
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: Reply: Question on S3 on evergreen

[David Airlie]

- Original Message -
 From: FrankR Huang frankr.hu...@amd.com
 To: Xavier Bestel xavier.bes...@free.fr, Dave Airlie airl...@gmail.com
 Cc: dri-devel@lists.freedesktop.org
 Sent: Thursday, 13 October, 2011 3:16:07 PM
 Subject: Reply: Question on S3 on evergreen
 
 
 Reply: Question on S3 on evergreen
 
 Xav, thanks for your reminder. Actually our law leam has already
 checked the license. As Dave said, the DRM kernel driver is all
 MIT-licensed and we will be free to use them. When the drm uses
 linux kernel function calls, we will use freebsd(none-GPL)
 equivalent to replace.
 Dave, by the way, I want to ask you about some exceptions in DRM. you
 know in some files(i.e. drm_fb_helper.c), it includes
 MODULE_LICENSE(GPL and additional rights). Does it mean it is GPL
 licensed? Is it free to use this file?

Those files are derived from the kernel fb layer so are not drm core 
infrastructure.

They make no sense on other OSes, since they don't have the same kernel fb 
layer.

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

Re: Reply: Question on S3 on evergreen

[Ilija Hadzic]

Frank,

I have found this text particularly useful when it comes to using MIT (or 
BSD) code that resides in the GPL project (e.g. DRM in Linux)


http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

I think that sections 2.2 and 2.3 are the things to be careful about 
because there is a non-trivial probabilty that at least some out of many 
patches that come in from many authors were created by copying and pasting 
lines of code that may have come from some other GPL'd code (e.g. other 
parts of Linux). Nobody can guarantee that this has not happened.


P.S. The above is my personal opinion, I speak for myself, not for my 
company, I am not a lawyer.


-- Ilija

On Thu, 13 Oct 2011, Huang, FrankR wrote:


Xav, thanks for your reminder. Actually our law leam has already checked the 
license. As Dave said, the DRM kernel driver is all MIT-licensed and we will be 
free to use them. When the drm uses linux kernel function calls, we will use 
freebsd(none-GPL) equivalent to replace.
Dave, by the way, I want to ask you about some exceptions in DRM. you know in some 
files(i.e. drm_fb_helper.c), it includes MODULE_LICENSE(GPL and additional 
rights). Does it mean it is GPL licensed? Is it free to use this file?

Thanks,
Frank


-Original Message-
From: Xavier Bestel [mailto:xavier.bes...@free.fr]
Sent: 2011-10-13 (??) 20:07
To: Dave Airlie
Cc: Huang, FrankR; dri-devel@lists.freedesktop.org
Subject: Re: Question on S3 on evergreen

On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:

On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel xavier.bes...@free.fr wrote:

Hi,

On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:

[...] I have ported radeon_suspend_kms() and radeon_resume_kms()
functions from linux to CE.


I imagine you already have checked with your company's lawyers, but if I
understand correctly that means your drivers will be distributed under
the GPL ?


All the GPU driver code is licensed under MIT.


Oh, I thought linux meant kernel, not X11.

Xav



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

Reply: Question on S3 on evergreen

[Huang, FrankR]

Dave, actually Alex helps me a lot in AMD internal. I appreciated him very 
much. He supports me for this project for nearly a year. But sometimes, he is a 
little busy with community's stuff. So I'll ask some quesitons here directly. 
Hope you guys can give me some suggestion(i.e. this S3 issue.) :)

Thanks,
Frank

-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: 2011-10-13 (星期四) 20:08
To: Xavier Bestel
Cc: Huang, FrankR; dri-devel@lists.freedesktop.org
Subject: Re: Question on S3 on evergreen
 
On Thu, Oct 13, 2011 at 1:07 PM, Xavier Bestel xavier.bes...@free.fr wrote:
 On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
 On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel xavier.bes...@free.fr 
 wrote:
  Hi,
 
  On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
  [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
  functions from linux to CE.
 
  I imagine you already have checked with your company's lawyers, but if I
  understand correctly that means your drivers will be distributed under
  the GPL ?

 All the GPU driver code is licensed under MIT.

 Oh, I thought linux meant kernel, not X11.

The kernel drm driver code is all MIT licensed. The license is there
at the top of the files.

Dave.


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

xf86-video-modesetting cursor patch

[James Simmons]

Hi!
I tried the xf86-video-modesetting driver with the new via KMS 
driver. It worked well but I had to turn off the cursor since I haven't 
finished the cursor in the kernel driver yet. By default the SWCursor 
option is set to false but when I placed that option in my xorg.conf file
it never set SWCursor to TRUE. Also a buffer was still being allocated 
even with the software curor. This patch address this issue. 

P.S
I also tried the xorg driver on a i915 device with a LVDS but the
screen was distored. It looks like a incorrect pitch size. I didn't see 
that with my via driver.

diff --git a/src/driver.c b/src/driver.c
index bde690c..1d62b7a 100644
--- a/src/driver.c
+++ b/src/driver.c
@@ -471,7 +471,7 @@ PreInit(ScrnInfoPtr pScrn, int flags)
 memcpy(ms-Options, Options, sizeof(Options));
 xf86ProcessOptions(pScrn-scrnIndex, pScrn-options, ms-Options);
 
-if (xf86ReturnOptValBool(ms-Options, OPTION_SW_CURSOR, FALSE)) {
+if (xf86ReturnOptValBool(ms-Options, OPTION_SW_CURSOR, TRUE)) {
ms-SWCursor = TRUE;
 }
 
@@ -551,7 +551,8 @@ CreateScreenResources(ScreenPtr pScreen)
 
 drmmode_uevent_init(pScrn, ms-drmmode);
 
-drmmode_map_cursor_bos(pScrn, ms-drmmode);
+if (!ms-SWCursor)
+   drmmode_map_cursor_bos(pScrn, ms-drmmode);
 pixels = drmmode_map_front_bo(ms-drmmode);
 if (!pixels)
return FALSE;

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

Re: [PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Keith Packard]

On Thu, 13 Oct 2011 10:57:35 +0200, Takashi Iwai ti...@suse.de wrote:

 This patch fixes the bug by recording the backlight level always
 when changed but only when dev_priv-backlight_enabled is set.
 In this way, the bogus value for disabling backlight can be skipped.

I think this is better than what we have, but I'm not sure it's quite
what we want -- the backlight level will only be remembered when it is
enabled, so requested changes that happen while the backlight is off
will have no effect. And, requested changes while the panel is disabled
will still go through to the hardware, which can cause problems with
panel power sequencing.

I think intel_panel_set_backlight should always record the level passed
in, but that intel_panel_disable_backlight and
intel_panel_enable_backlight should use a lower-level function, shared
with intel_panel_set_backlight that doesn't record the value:

intel_panel_actually_set_backlight(dev, level) {
internals of current intel_panel_set_backlight
}

intel_panel_set_backlight(dev, level) {
dev_priv-backlight_level = level;
if (dev_priv-backlight_enabled)
intel_panel_actually_set_backlight(dev, level);
}

intel_panel_enable_backlight(dev) {
dev_priv-backlight_enabled = true;
intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
}

intel_panel_disable_backlight(dev) {
dev_priv-backlight_enabled = false;
intel_panel_actually_set_backlight(dev, 0);
}

-- 
keith.pack...@intel.com


pgpofYSVXAhGx.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-daemon]

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

--- Comment #4 from Varban weasalan...@yahoo.com 2011-10-13 10:36:48 PDT ---
In Windows, if a monitor is connected to a port on the laptop then it is shown
as connected to the Intel card. If the monitor is connected to the external
media dock then Windows shows it as connected to the Radeon card.

I played around with the fglrx proprietary driver (latest version 11.9) and I
got two different results when my xorg.conf has 2 separate cards defined (fglrx
and intel) vs only 1 card (fglrx only)

When defining 2 cards in xorg.conf I get this:

[  2060.069] (II) Loading sub module fglrxdrm
[  2060.069] (II) LoadModule: fglrxdrm
[  2060.069] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[  2060.069] (II) Module fglrxdrm: vendor=FireGL - ATI Technologies Inc.
[  2060.069] compiled for 1.4.99.906, module version = 8.89.4
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  2060.072] ukiOpenDevice: node name is /dev/ati/card0
[  2060.072] ukiOpenDevice: open result is 11, (OK)
[  2060.072] ukiOpenByBusid: ukiOpenMinor returns 11
[  2060.072] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  2060.073] (==) fglrx(0): NoAccel = NO
[  2060.073] (==) fglrx(0): ATI 2D Acceleration Architecture enabled
[  2060.073] (--) fglrx(0): Chipset: AMD Radeon HD 6700M Series (Chipset =
0x6740)
[  2060.073] (--) fglrx(0): (PciSubVendor = 0x104d, PciSubDevice = 0x9084)
[  2060.073] (==) fglrx(0): board vendor info: third party graphics adapter -
NOT original ATI
[  2060.073] (--) fglrx(0): Linear framebuffer (phys) at 0xb000
[  2060.073] (--) fglrx(0): MMIO registers at 0xc020
[  2060.073] (--) fglrx(0): I/O port at 0x5000
[  2060.073] (==) fglrx(0): ROM-BIOS at 0x000c
[  2060.073] (II) fglrx(0): AC Adapter is used
[  2060.084] (II) fglrx(0): Invalid ATI BIOS from int10, the adapter is not
VGA-enabled
[  2060.084] (EE) fglrx(0): Invalid video BIOS signature!
[  2060.084] (EE) fglrx(0): GetBIOSParameter failed
[  2060.084] (EE) fglrx(0): PreInitAdapter failed
[  2060.084] (EE) fglrx(0): PreInit failed


The invalid bios message.
However, when I only try to use 1 fglrx card (on pcibus 22:0:0), the driver
correctly detects there an intel card and loads drivers for it but then blows
up with another message:

[  1920.534] (WW) Falling back to old probe method for fglrx
[  1920.538] (II) Loading PCS database from /etc/ati/amdpcsdb
[  1920.538] (--) Chipset Supported AMD Graphics Processor (0x6740) found
[  1920.538] (WW) fglrx: No matching Device section for instance (BusID
PCI:0@22:0:1) found
[  1920.538] (II) fglrx: intel VGA device detected, load intel driver.
[  1920.538] (II) LoadModule: intel
[  1920.539] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  1920.539] (II) Module intel: vendor=X.Org Foundation
[  1920.539] compiled for 1.11.0, module version = 2.16.0
[  1920.539] Module class: X.Org Video Driver
[  1920.539] ABI class: X.Org Video Driver, version 11.0
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  1920.540] ukiOpenDevice: node name is /dev/ati/card0
[  1920.540] ukiOpenDevice: open result is 8, (OK)
[  1920.540] ukiOpenByBusid: ukiOpenMinor returns 8
[  1920.540] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  1920.542] (WW) PowerXpress feature is not supported on A+I Mux platform.
Please uninstall fglrx driver.
[  1920.542] (EE) No devices detected.

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

Re: [PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Takashi Iwai]

At Thu, 13 Oct 2011 09:40:29 -0700,
Keith Packard wrote:
 
 On Thu, 13 Oct 2011 10:57:35 +0200, Takashi Iwai ti...@suse.de wrote:
 
  This patch fixes the bug by recording the backlight level always
  when changed but only when dev_priv-backlight_enabled is set.
  In this way, the bogus value for disabling backlight can be skipped.
 
 I think this is better than what we have, but I'm not sure it's quite
 what we want -- the backlight level will only be remembered when it is
 enabled, so requested changes that happen while the backlight is off
 will have no effect. And, requested changes while the panel is disabled
 will still go through to the hardware, which can cause problems with
 panel power sequencing.
 
 I think intel_panel_set_backlight should always record the level passed
 in, but that intel_panel_disable_backlight and
 intel_panel_enable_backlight should use a lower-level function, shared
 with intel_panel_set_backlight that doesn't record the value:
 
 intel_panel_actually_set_backlight(dev, level) {
 internals of current intel_panel_set_backlight
 }
 
 intel_panel_set_backlight(dev, level) {
 dev_priv-backlight_level = level;
 if (dev_priv-backlight_enabled)
 intel_panel_actually_set_backlight(dev, level);
 }
 
 intel_panel_enable_backlight(dev) {
 dev_priv-backlight_enabled = true;
 intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
 }
 
 intel_panel_disable_backlight(dev) {
 dev_priv-backlight_enabled = false;
 intel_panel_actually_set_backlight(dev, 0);
 }

Yes, this looks more understandable, indeed.
Would you patch it by yourself or should I refresh the patch?
In either way, I'll test tomorrow, as I'm already at home without a
test machine.


thanks,

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

Re: drm/radeon/kms: improve performance of blit-copy

[Ilija Hadzic]

Dave,

Alex pointed to me that the patches I sent last night under this thread 
may conflict with 003cefe0c238e683a29d2207dba945b508cd45b7 that currently 
resides on drm-fixes branch (my patches are based on drm-next or 
drm-core-next).


I'd like to make sure that the eventual merge goes smoothly:

If you merge drm-fixes before my patches, then I'll rebase my patches and 
resend them after that happens and make sure everything is resolved 
correctly.


If you merge my patches first and then follow with drm-fixes merge, two 
things should happen with 003cefe0c238e683a29d2207dba945b508cd45b7. Hunks 
related to evergreen.c file will fall out but that's expected and OK 
because my patches consolidate the blit code for r600 and evergreen into a 
common one. Then in r600.c, the hunks related to r600_blit_prepare_copy
and r600_kms_blit_copy function calls will show conflicts, which should be 
resolved such that the size argument is num_gpu_pages, not

num_gpu_pages * RADEON_GPU_PAGE_SIZE (this is because the new blit code
takes size argument in pages, not bytes). Everything else will merge 
smoothly.


For reference, pasted below is a patch that resulted after I cherry-picked 
003cefe0c238e683a29d2207dba945b508cd45b7 into drm-next augmented with my 
blit-improvement patches and resolved the conflicts correctly.


I guess the first option is less work for you (and I will be glad to 
rebase my patches if need be), but I hope that the info here is good 
enough to make the second path as easy as it can be


thanks,

Ilija


From b12516c003cb35059f16ace774ef5a21170d6d78 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Fri, 16 Sep 2011 12:04:08 -0400
Subject: [PATCH 11/14] drm/radeon/kms: Make GPU/CPU page size handling
 consistent in blit code (v3)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The BO blit code inconsistenly handled the page size.  This wasn't
an issue on system with 4k pages since the GPU's page size is 4k as
well.  Switch the driver blit callbacks to take num pages in GPU
page units.

Fixes lemote mipsel systems using AMD rs780/rs880 chipsets.

v2: incorporate suggestions from Michel.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Michel D??nzer michel.daen...@amd.com
Cc: sta...@kernel.org
Signed-off-by: Dave Airlie airl...@redhat.com

v3: reconcile with changes due to blit-copy improvements on drm-next
branch

substitutes the v2 patch that currently resides on drm-fixes
branch

Conflicts:

drivers/gpu/drm/radeon/evergreen.c
drivers/gpu/drm/radeon/r600.c
drivers/gpu/drm/radeon/radeon_asic.h

Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
---
 drivers/gpu/drm/radeon/r100.c|   12 ++--
 drivers/gpu/drm/radeon/r200.c|4 ++--
 drivers/gpu/drm/radeon/r600.c|   10 ++
 drivers/gpu/drm/radeon/radeon.h  |7 ---
 drivers/gpu/drm/radeon/radeon_asic.h |6 +++---
 drivers/gpu/drm/radeon/radeon_ttm.c  |7 ++-
 6 files changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 5985cb0..df60803 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -724,11 +724,11 @@ void r100_fence_ring_emit(struct radeon_device *rdev,
 int r100_copy_blit(struct radeon_device *rdev,
   uint64_t src_offset,
   uint64_t dst_offset,
-  unsigned num_pages,
+  unsigned num_gpu_pages,
   struct radeon_fence *fence)
 {
uint32_t cur_pages;
-   uint32_t stride_bytes = PAGE_SIZE;
+   uint32_t stride_bytes = RADEON_GPU_PAGE_SIZE;
uint32_t pitch;
uint32_t stride_pixels;
unsigned ndw;
@@ -740,7 +740,7 @@ int r100_copy_blit(struct radeon_device *rdev,
/* radeon pitch is /64 */
pitch = stride_bytes / 64;
stride_pixels = stride_bytes / 4;
-   num_loops = DIV_ROUND_UP(num_pages, 8191);
+   num_loops = DIV_ROUND_UP(num_gpu_pages, 8191);

/* Ask for enough room for blit + flush + fence */
ndw = 64 + (10 * num_loops);
@@ -749,12 +749,12 @@ int r100_copy_blit(struct radeon_device *rdev,
DRM_ERROR(radeon: moving bo (%d) asking for %u dw.\n, r, ndw);
return -EINVAL;
}
-   while (num_pages  0) {
-   cur_pages = num_pages;
+   while (num_gpu_pages  0) {
+   cur_pages = num_gpu_pages;
if (cur_pages  8191) {
cur_pages = 8191;
}
-   num_pages -= cur_pages;
+   num_gpu_pages -= cur_pages;

/* pages are in Y direction - height
   page width in X direction - width */
diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c
index f240583..a1f3ba0 100644
--- a/drivers/gpu/drm/radeon/r200.c
+++ 

Re: drm/radeon/kms: improve performance of blit-copy

[Ilija Hadzic]

On Thu, 13 Oct 2011, Roland Scheidegger wrote:


I guess it isn't possible to temporarily disable some RBEs or otherwise
reconfigure the chip that you could get the same performance for the
high-end chips?


According to the conversation I had with Alex, this *is* possible but 
requires the pipeline and cache flush. So it is unclear what the overall 
gain will be given the flush penalty.


Also, this phenomena occurs only when GTT is involved in the copy. 
VRAM-to-VRAM copy in which there is no host memory involved (for which I 
added a benchmark, but didn't report in my note yesterday), high-end 
devices are beating low-end ones big time  they better be ;-)


So if we can get RBE-reduction to work, it should be turned on only when 
one of the BOs is in GTT domain. I looked at what it would take to do 
this, and it's doable, but requires hacks at many places.


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

Re: [PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Keith Packard]

On Thu, 13 Oct 2011 20:05:49 +0200, Takashi Iwai ti...@suse.de wrote:

 Yes, this looks more understandable, indeed.
 Would you patch it by yourself or should I refresh the patch?
 In either way, I'll test tomorrow, as I'm already at home without a
 test machine.

I don't have time before Monday to look at this further.

-- 
keith.pack...@intel.com


pgpeT2VvuUPxc.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

[Takashi Iwai]

At Thu, 13 Oct 2011 12:28:07 -0700,
Keith Packard wrote:
 
 On Thu, 13 Oct 2011 20:05:49 +0200, Takashi Iwai ti...@suse.de wrote:
 
  Yes, this looks more understandable, indeed.
  Would you patch it by yourself or should I refresh the patch?
  In either way, I'll test tomorrow, as I'm already at home without a
  test machine.
 
 I don't have time before Monday to look at this further.

OK, I'll refresh and test the patch tomorrow.


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

[PATCH] drm/radeon/kms: consolidate GART code, fix memory fault after GPU lockup

[j . glisse]

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

After GPU lockup VRAM gart table is unpinned and thus its pointer
becomes unvalid. This patch move the unpin code to a common helper
function and set pointer to NULL so that page update code can check
if it should update GPU page table or not. That way bo still bound
to GART can be unbound (pci_unmap_page for all there page) properly
while there is no need to update the GPU page table.

Signed-off-by: Jerome Glisse jgli...@redhat.com
cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c   |   12 +-
 drivers/gpu/drm/radeon/ni.c  |   13 +--
 drivers/gpu/drm/radeon/r100.c|6 ++-
 drivers/gpu/drm/radeon/r300.c|   16 ++--
 drivers/gpu/drm/radeon/r600.c|   17 +++--
 drivers/gpu/drm/radeon/radeon.h  |   22 +++-
 drivers/gpu/drm/radeon/radeon_gart.c |   66 -
 drivers/gpu/drm/radeon/rs400.c   |5 ++-
 drivers/gpu/drm/radeon/rs600.c   |   16 ++--
 drivers/gpu/drm/radeon/rv770.c   |   13 ++-
 10 files changed, 72 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index c4ffa14f..fe5cf3e 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -893,7 +893,7 @@ int evergreen_pcie_gart_enable(struct radeon_device *rdev)
u32 tmp;
int r;
 
-   if (rdev-gart.table.vram.robj == NULL) {
+   if (rdev-gart.robj == NULL) {
dev_err(rdev-dev, No VRAM object for PCIE GART.\n);
return -EINVAL;
}
@@ -942,7 +942,6 @@ int evergreen_pcie_gart_enable(struct radeon_device *rdev)
 void evergreen_pcie_gart_disable(struct radeon_device *rdev)
 {
u32 tmp;
-   int r;
 
/* Disable all tables */
WREG32(VM_CONTEXT0_CNTL, 0);
@@ -962,14 +961,7 @@ void evergreen_pcie_gart_disable(struct radeon_device 
*rdev)
WREG32(MC_VM_MB_L1_TLB1_CNTL, tmp);
WREG32(MC_VM_MB_L1_TLB2_CNTL, tmp);
WREG32(MC_VM_MB_L1_TLB3_CNTL, tmp);
-   if (rdev-gart.table.vram.robj) {
-   r = radeon_bo_reserve(rdev-gart.table.vram.robj, false);
-   if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev-gart.table.vram.robj);
-   radeon_bo_unpin(rdev-gart.table.vram.robj);
-   radeon_bo_unreserve(rdev-gart.table.vram.robj);
-   }
-   }
+   radeon_gart_table_vram_unpin(rdev);
 }
 
 void evergreen_pcie_gart_fini(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8c79ca9..529aaee 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -931,7 +931,7 @@ int cayman_pcie_gart_enable(struct radeon_device *rdev)
 {
int r;
 
-   if (rdev-gart.table.vram.robj == NULL) {
+   if (rdev-gart.robj == NULL) {
dev_err(rdev-dev, No VRAM object for PCIE GART.\n);
return -EINVAL;
}
@@ -973,8 +973,6 @@ int cayman_pcie_gart_enable(struct radeon_device *rdev)
 
 void cayman_pcie_gart_disable(struct radeon_device *rdev)
 {
-   int r;
-
/* Disable all tables */
WREG32(VM_CONTEXT0_CNTL, 0);
WREG32(VM_CONTEXT1_CNTL, 0);
@@ -990,14 +988,7 @@ void cayman_pcie_gart_disable(struct radeon_device *rdev)
WREG32(VM_L2_CNTL2, 0);
WREG32(VM_L2_CNTL3, L2_CACHE_BIGK_ASSOCIATIVITY |
   L2_CACHE_BIGK_FRAGMENT_SIZE(6));
-   if (rdev-gart.table.vram.robj) {
-   r = radeon_bo_reserve(rdev-gart.table.vram.robj, false);
-   if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev-gart.table.vram.robj);
-   radeon_bo_unpin(rdev-gart.table.vram.robj);
-   radeon_bo_unreserve(rdev-gart.table.vram.robj);
-   }
-   }
+   radeon_gart_table_vram_unpin(rdev);
 }
 
 void cayman_pcie_gart_fini(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 7fcdbbb..8ad6769 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -474,7 +474,7 @@ int r100_pci_gart_init(struct radeon_device *rdev)
 {
int r;
 
-   if (rdev-gart.table.ram.ptr) {
+   if (rdev-gart.ptr) {
WARN(1, R100 PCI GART already initialized\n);
return 0;
}
@@ -530,10 +530,12 @@ void r100_pci_gart_disable(struct radeon_device *rdev)
 
 int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr)
 {
+   u32 *gtt = rdev-gart.ptr;
+
if (i  0 || i  rdev-gart.num_gpu_pages) {
return -EINVAL;
}
-   rdev-gart.table.ram.ptr[i] = cpu_to_le32(lower_32_bits(addr));
+   gtt[i] = cpu_to_le32(lower_32_bits(addr));
return 0;
 }
 
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 55a7f19..6c62d88 100644
--- 

[Bug 41766] New: radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

[bugzilla-daemon]

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

   Summary: radeon lvds panel heavy flickering after opening
laptop lid (Mobility Radeon HD 3650)
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: pa...@iki.fi


I'm using a laptop with Mobility Radeon HD 3650 (HP EliteBook 8530p). Normally
the laptop is in a docking station, so I'm only using the external DVI monitor.
The laptop lid is closed and the laptop internal LVDS panel is disabled while
in the dock.

I just tried the new Fedora 16 beta liveCD on my laptop. Fedora 16
automatically enables all display outputs, which means also the internal LVDS
panel gets enabled, even when my laptop lid is closed. And the gnome desktop
gets extended to both the DVI monitor and internal LVDS panel. This means I
need to actually open the laptop lid to see the gnome menus, because they're
displayed only on the internal LVDS panel. This is a configuration/defaults
issue in Fedora 16, and that's not the bug I'm reporting.

While opening the laptop lid I noticed the internal LVDS display is heavily
flickering, and the screen is totally unreadable. 

I've uploaded a video of the heavily flickering LVDS panel here:
http://pasik.reaktio.net/fedora/f16/radeon/f16-beta-laptop-radeon-flicker-xvid.avi

Fedora 16 beta is using Linux 3.1.0-rc6. dmesg available here:
http://pasik.reaktio.net/fedora/f16/radeon/f16-beta-laptop-radeon-dmesg.txt

I tried rebooting the laptop a couple of times, and it seems the flickering
doesn't happen on every reboot.. but it happens on *most* reboots. Flickering
starts already when kernel is booting, before Xorg is started.

Any more info needed ?

-- 
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 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

[bugzilla-daemon]

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

--- Comment #1 from Pasi Kärkkäinen pa...@iki.fi 2011-10-13 15:17:52 PDT ---

Oh, I forgot to mention that changing the radeon power_profile fixes the
problem, ie doing:

echo low  /sys/class/drm/card0/device/power_profile

fixes the problem, and there's no flickering anymore!

-- 
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: Reply: Question on S3 on evergreen

[Huang, FrankR]

 -Original Message-
 From: David Airlie [mailto:airl...@redhat.com]
 Sent: 2011年10月13日 22:24
 To: Huang, FrankR
 Cc: dri-devel@lists.freedesktop.org; Xavier Bestel; Dave Airlie
 Subject: Re: Reply: Question on S3 on evergreen
 
 
 
 - Original Message -
  From: FrankR Huang frankr.hu...@amd.com
  To: Xavier Bestel xavier.bes...@free.fr, Dave Airlie
 airl...@gmail.com
  Cc: dri-devel@lists.freedesktop.org
  Sent: Thursday, 13 October, 2011 3:16:07 PM
  Subject: Reply: Question on S3 on evergreen
 
 
  Reply: Question on S3 on evergreen
 
  Xav, thanks for your reminder. Actually our law leam has already
  checked the license. As Dave said, the DRM kernel driver is all
  MIT-licensed and we will be free to use them. When the drm uses
  linux kernel function calls, we will use freebsd(none-GPL)
  equivalent to replace.
  Dave, by the way, I want to ask you about some exceptions in DRM. you
  know in some files(i.e. drm_fb_helper.c), it includes
  MODULE_LICENSE(GPL and additional rights). Does it mean it is GPL
  licensed? Is it free to use this file?
 
 Those files are derived from the kernel fb layer so are not drm core
 infrastructure.
 
 They make no sense on other OSes, since they don't have the same kernel fb
 layer.
Yup. CE does have fb layer, when I did the modeset part, there is no fb layer 
in it and none of fb functions will be used in our driver. So I understand that 
you said those files are derived from the kernel fb layer. So what's the 
relastionship between drm fb helper and real kernel fb ?


 
 Dave.

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

RE: Reply: Question on S3 on evergreen

[Huang, FrankR]

Ilija,
Your suggestion is very very important for us. Before we released the 
driver, we will check each file of what we used from linux community(Including 
KMS and DDX driver). As you said, there is no guarantee that some patches from 
other developers contain GPL's code. So we must be very careful on this. The 
good thing is that DRM architecture and DDX driver including Xserver part(our 
code also use Xserver) are MIT-licensed. So what we should be care is when 
those drivers call into kernel functions, we must use freebsd's code to 
re-implement. We are all not lawyers, actually evey for lawyers, it is 
impossible for them to check the code in detail. So I have the responsibility 
to make sure the code from me is non-GPL. So I will also ask more questions 
here for this stuff. Hope you guys give more suggestions, I appreciate it!

Thanks,
Frank

 -Original Message-
 From: dri-devel-bounces+frankr.huang=amd@lists.freedesktop.org
 [mailto:dri-devel-bounces+frankr.huang=amd@lists.freedesktop.org] On
 Behalf Of Ilija Hadzic
 Sent: 2011?10?13? 22:29
 To: Huang, FrankR
 Cc: dri-devel@lists.freedesktop.org
 Subject: Re: Reply: Question on S3 on evergreen
 
 
 Frank,
 
 I have found this text particularly useful when it comes to using MIT (or
 BSD) code that resides in the GPL project (e.g. DRM in Linux)
 
 http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-
 collaboration.html
 
 I think that sections 2.2 and 2.3 are the things to be careful about
 because there is a non-trivial probabilty that at least some out of many
 patches that come in from many authors were created by copying and pasting
 lines of code that may have come from some other GPL'd code (e.g. other
 parts of Linux). Nobody can guarantee that this has not happened.
 
 P.S. The above is my personal opinion, I speak for myself, not for my
 company, I am not a lawyer.
 
 -- Ilija
 
 On Thu, 13 Oct 2011, Huang, FrankR wrote:
 
  Xav, thanks for your reminder. Actually our law leam has already checked
 the license. As Dave said, the DRM kernel driver is all MIT-licensed and
 we will be free to use them. When the drm uses linux kernel function calls,
 we will use freebsd(none-GPL) equivalent to replace.
  Dave, by the way, I want to ask you about some exceptions in DRM. you
 know in some files(i.e. drm_fb_helper.c), it includes MODULE_LICENSE(GPL
 and additional rights). Does it mean it is GPL licensed? Is it free to
 use this file?
 
  Thanks,
  Frank
 
 
  -Original Message-
  From: Xavier Bestel [mailto:xavier.bes...@free.fr]
  Sent: 2011-10-13 (ÐÇÆÚËÄ) 20:07
  To: Dave Airlie
  Cc: Huang, FrankR; dri-devel@lists.freedesktop.org
  Subject: Re: Question on S3 on evergreen
 
  On Thu, 2011-10-13 at 13:04 +0100, Dave Airlie wrote:
  On Thu, Oct 13, 2011 at 12:56 PM, Xavier Bestel xavier.bes...@free.fr
 wrote:
  Hi,
 
  On Thu, 2011-10-13 at 17:54 +0800, Huang, FrankR wrote:
  [...] I have ported radeon_suspend_kms() and radeon_resume_kms()
  functions from linux to CE.
 
  I imagine you already have checked with your company's lawyers, but if
 I
  understand correctly that means your drivers will be distributed under
  the GPL ?
 
  All the GPU driver code is licensed under MIT.
 
  Oh, I thought linux meant kernel, not X11.
 
  Xav
 
 
 
 

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

RE: Question on S3 on evergreen

[Huang, FrankR]

 -Original Message-
 From: dri-devel-bounces+frankr.huang=amd@lists.freedesktop.org
 [mailto:dri-devel-bounces+frankr.huang=amd@lists.freedesktop.org] On
 Behalf Of Alex Deucher
 Sent: 2011?10?13? 21:06
 To: Huang, FrankR
 Cc: dri-devel@lists.freedesktop.org
 Subject: Re: Question on S3 on evergreen
 
 On Thu, Oct 13, 2011 at 5:54 AM, Huang, FrankR frankr.hu...@amd.com
 wrote:
  Hi,
         I have a question on S3 suspend/resume process for evergreen
  chipset.
         Generally introduction, I am developing WEC7 graphics driver on
  evergreen chipset. Alex guide me on this. And right now I move to S3
  part work. I have ported radeon_suspend_kms() and radeon_resume_kms()
  functions from linux to CE. Actually I have validated that the
  evergreen_suspend() and evergreen_resume() work already on CE. But when
  the resume work is done and the screen is shown up, I found the 3D
  engine works wrong. The HW acceleration of it is not correct anymore.
  Misrendering is happening. By tracing the root cause, I suspect that the
  problem may be in evergreen_gpu_init()( in evergreen_startup) call when
  resume(), but I am not sure. Can you guys tell me which part I should
  debug?
         By the way, the linux kernel source I used is from 2010.10. So
  quite a lot patches have been committed into community during this
  period. Right now, the kernel source I used is around date
  2011.7(Version 3.0.0). Is there any patches update for S3 during this
  period?
 
 
 Does soft resetting the GPU during resume help
 (evergreen_gpu_soft_reset()) ?  If so, try updating your version of
 evergreen_cp_resume() to the latest upstream bits.
Evergreen_gpu_soft_reset() has been used in my code.
I'm trying to update evergreen_cp_resume() function to latest. But from the 
comparison between the version 2010.10 and current version 2011.7, I think 
there is not too much change for this function.
You the code I used before was quite old, so when I port the new S3 code to CE 
currently, there must be some confliction between the old version and new 
version. I suspend the problem is there. Let me check more...

Thanks,
Frank

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

[PATCH 0/7] drm/exynos: add two devices support.

[Inki Dae]

the patch sets are as the following.
- updated common overlay structure to support hdmi.
- fixed page flip feature for two devices to be supported.
- fixed a bug that fbdev reinitialization is failed.
- added comments and code clean.

this patch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: b07759bf41d52aaecd5de92c7d725d6834b23349

Inki Dae (5):
  drm/exynos: fixed overlay data updating.
  drm/exynos: added device object as argument of subdrv_probe().
  drm/exynos: fixed bug to exynos_drm_fb_dev_reinit().
  drm/exynos: added comments and code clean.
  drm/exynos: fixed build warnings and comments.

Seung-Woo Kim (1):
  drm/exynos: fixed page flip bug.

Joonyoung Shim (1):
  drm/exynos: fixed overlay updating time at page flip.

 drivers/gpu/drm/exynos/exynos_drm_buf.h   |3 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  123 +++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  |1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   14 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   50 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   20 ++---
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   10 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   39 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   89 -
 10 files changed, 215 insertions(+), 136 deletions(-)
-- 
1.7.4.1

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

[PATCH 1/7] drm/exynos: fixed overlay data updating.

[Inki Dae]

this patch adds common members to overlay structure and
makes each driver such as fimd or hdmi driver set them to
its own structure.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |3 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  101 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   41 
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   20 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   10 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   31 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   59 -
 7 files changed, 162 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.h 
b/drivers/gpu/drm/exynos/exynos_drm_buf.h
index 9b1f0fb..045d59e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.h
@@ -43,6 +43,9 @@ struct exynos_drm_buf_entry {
 struct exynos_drm_buf_entry *exynos_drm_buf_create(struct drm_device *dev,
unsigned int size);
 
+/* get physical memory information of a drm framebuffer. */
+struct exynos_drm_buf_entry *exynos_drm_fb_get_buf(struct drm_framebuffer *fb);
+
 /* remove allocated physical memory. */
 void exynos_drm_buf_destroy(struct drm_device *dev,
struct exynos_drm_buf_entry *entry);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 683ceb0..654bf3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -32,23 +32,28 @@
 #include exynos_drm_drv.h
 #include exynos_drm_fb.h
 #include exynos_drm_encoder.h
+#include exynos_drm_buf.h
 
 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc,\
drm_crtc)
 
 /*
- * @fb_x: horizontal position from framebuffer base
- * @fb_y: vertical position from framebuffer base
- * @base_x: horizontal position from screen base
- * @base_y: vertical position from screen base
- * @crtc_w: width of crtc
- * @crtc_h: height of crtc
+ * Exynos specific crtc postion structure.
+ *
+ * @fb_x: offset x on a framebuffer to be displyed
+ * - the unit is screen coordinates.
+ * @fb_y: offset y on a framebuffer to be displayed
+ * - the unit is screen coordinates.
+ * @crtc_x: offset x on hardware screen.
+ * @crtc_y: offset y on hardware screen.
+ * @crtc_w: width of hardware screen.
+ * @crtc_h: height of hardware screen.
  */
 struct exynos_drm_crtc_pos {
unsigned int fb_x;
unsigned int fb_y;
-   unsigned int base_x;
-   unsigned int base_y;
+   unsigned int crtc_x;
+   unsigned int crtc_y;
unsigned int crtc_w;
unsigned int crtc_h;
 };
@@ -83,42 +88,56 @@ void exynos_drm_crtc_apply(struct drm_crtc *crtc)
exynos_drm_fn_encoder(crtc, NULL, exynos_drm_encoder_crtc_commit);
 }
 
-static void exynos_drm_overlay_update(struct exynos_drm_overlay *overlay,
+static int exynos_drm_overlay_update(struct exynos_drm_overlay *overlay,
   struct drm_framebuffer *fb,
   struct drm_display_mode *mode,
   struct exynos_drm_crtc_pos *pos)
 {
-   struct exynos_drm_buffer_info buffer_info;
-   unsigned int actual_w = pos-crtc_w;
-   unsigned int actual_h = pos-crtc_h;
-   unsigned int hw_w;
-   unsigned int hw_h;
-
-   /* update buffer address of framebuffer. */
-   exynos_drm_fb_update_buf_off(fb, pos-fb_x, pos-fb_y, buffer_info);
-   overlay-paddr = buffer_info.paddr;
-   overlay-vaddr = buffer_info.vaddr;
-
-   hw_w = mode-hdisplay - pos-base_x;
-   hw_h = mode-vdisplay - pos-base_y;
-
-   if (actual_w  hw_w)
-   actual_w = hw_w;
-   if (actual_h  hw_h)
-   actual_h = hw_h;
-
-   overlay-offset_x = pos-base_x;
-   overlay-offset_y = pos-base_y;
-   overlay-width = actual_w;
-   overlay-height = actual_h;
+   struct exynos_drm_buf_entry *entry;
+   unsigned int actual_w;
+   unsigned int actual_h;
+
+   entry = exynos_drm_fb_get_buf(fb);
+   if (!entry) {
+   DRM_LOG_KMS(entry is null.\n);
+   return -EFAULT;
+   }
+
+   overlay-paddr = entry-paddr;
+   overlay-vaddr = entry-vaddr;
+
+   DRM_DEBUG_KMS(vaddr = 0x%lx, paddr = 0x%lx\n,
+   (unsigned long)overlay-vaddr,
+   (unsigned long)overlay-paddr);
+
+   actual_w = min((mode-hdisplay - pos-crtc_x), pos-crtc_w);
+   actual_h = min((mode-vdisplay - pos-crtc_y), pos-crtc_h);
+
+   /* set drm framebuffer data. */
+   overlay-fb_x = pos-fb_x;
+   overlay-fb_y = pos-fb_y;
+   overlay-fb_width = fb-width;
+   overlay-fb_height = fb-height;
overlay-bpp = fb-bits_per_pixel;
+   overlay-pitch = fb-pitch;
+
+   /* set overlay 

[PATCH 2/7] drm/exynos: fixed overlay updating time at page flip.

[Inki Dae]

buffer addess is set to shadow register and then applied to
real register at vsync front porch time.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |4 +++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 --
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 654bf3a..0587b52 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -78,7 +78,7 @@ struct exynos_drm_crtc {
unsigned intpipe;
 };
 
-void exynos_drm_crtc_apply(struct drm_crtc *crtc)
+static void exynos_drm_crtc_apply(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_overlay *overlay = exynos_crtc-overlay;
@@ -279,6 +279,8 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}
 
+   exynos_drm_crtc_apply(crtc);
+
dev_priv-pageflip_event = true;
}
 out:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 452b62b..c584042 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -31,7 +31,6 @@
 
 struct exynos_drm_overlay *get_exynos_drm_overlay(struct drm_device *dev,
struct drm_crtc *crtc);
-void exynos_drm_crtc_apply(struct drm_crtc *crtc);
 int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
 int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
 void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 623ba33..9d1138e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -500,8 +500,6 @@ static void fimd_finish_pageflip(struct drm_device 
*drm_dev, int crtc)
 
spin_lock_irqsave(drm_dev-event_lock, flags);
 
-   exynos_drm_crtc_apply(dev_priv-crtc[crtc]);
-
list_for_each_entry_safe(e, t, dev_priv-pageflip_event_list,
base.link) {
do_gettimeofday(now);
-- 
1.7.4.1

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

[PATCH 3/7] drm/exynos: added device object as argument of subdrv_probe().

[Inki Dae]

sub drivers should refer to its own device object to access
its own context.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index edb0ee1..661a035 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -55,7 +55,7 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
 *
 * P.S. note that this driver is considered for modularization.
 */
-   ret = subdrv-probe(dev);
+   ret = subdrv-probe(dev, subdrv-manager.dev);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4ea1371..002f292 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -219,7 +219,7 @@ struct exynos_drm_subdrv {
struct list_head list;
struct drm_device *drm_dev;
 
-   int (*probe)(struct drm_device *dev);
+   int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
 
struct exynos_drm_manager manager;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9d1138e..b0afa84 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -538,7 +538,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static int fimd_subdrv_probe(struct drm_device *drm_dev)
+static int fimd_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
 {
struct drm_driver *drm_driver = drm_dev-driver;
 
-- 
1.7.4.1

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

[PATCH 4/7] drm/exynos: fixed bug to exynos_drm_fb_dev_reinit().

[Inki Dae]

this patch solves the problem that fb_helper is released
when exynos_drm_fbdev_reinit() was called. if this function call
is ok then just return.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 6134515..4366dc5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -432,6 +432,8 @@ int exynos_drm_fbdev_reinit(struct drm_device *dev)
return exynos_drm_fbdev_init(dev);
}
 
+   return ret;
+
 err:
/*
 * if drm_load() failed when drm load() was called prior
-- 
1.7.4.1

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

[PATCH 6/7] drm/exynos: fixed page flip bug.

[Inki Dae]

in case of using two drivers such as fimd and hdmi controller that
they have their own hardware interrupt, drm framework doesn't provide
pipe number corresponding to it. so the pipe should be set to event's
from specific crtc.

Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   14 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |3 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   15 +--
 4 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 8cd9d8e..9337e5e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -259,13 +259,21 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 
mutex_lock(dev-struct_mutex);
 
-   if (event  !dev_priv-pageflip_event) {
+   if (event) {
+   /*
+* the pipe from user always is 0 so we can set pipe number
+* of current owner to event.
+*/
+   event-pipe = exynos_crtc-pipe;
+
list_add_tail(event-base.link,
dev_priv-pageflip_event_list);
 
ret = drm_vblank_get(dev, exynos_crtc-pipe);
if (ret) {
DRM_DEBUG(failed to acquire vblank counter\n);
+   list_del(event-base.link);
+
goto out;
}
 
@@ -274,7 +282,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
if (ret) {
crtc-fb = old_fb;
drm_vblank_put(dev, exynos_crtc-pipe);
-   dev_priv-pageflip_event = false;
+   list_del(event-base.link);
 
goto out;
}
@@ -282,12 +290,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
/*
 * the values related to a buffer of the drm framebuffer
 * to be applied should be set at here. because these values
-* first, is set to shadow registers and then to
+* first, are set to shadow registers and then to
 * real registers at vsync front porch period.
 */
exynos_drm_crtc_apply(crtc);
-
-   dev_priv-pageflip_event = true;
}
 out:
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a190348..83810cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -124,6 +124,19 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
 }
 
+static void exynos_drm_preclose(struct drm_device *dev,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_private *dev_priv = dev-dev_private;
+
+   /*
+* drm framework frees all events at release time,
+* so private event list should be cleared.
+*/
+   if (!list_empty(dev_priv-pageflip_event_list))
+   INIT_LIST_HEAD(dev_priv-pageflip_event_list);
+}
+
 static void exynos_drm_lastclose(struct drm_device *dev)
 {
DRM_DEBUG_DRIVER(%s\n, __FILE__);
@@ -152,6 +165,7 @@ static struct drm_driver exynos_drm_driver = {
  DRIVER_MODESET | DRIVER_GEM,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
+   .preclose   = exynos_drm_preclose,
.lastclose  = exynos_drm_lastclose,
.get_vblank_counter = drm_vblank_count,
.enable_vblank  = exynos_drm_crtc_enable_vblank,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 63c1422..915f5cd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -187,9 +187,8 @@ struct exynos_drm_manager {
 struct exynos_drm_private {
struct drm_fb_helper *fb_helper;
 
-   /* for pageflip */
+   /* list head for new event to be added. */
struct list_head pageflip_event_list;
-   bool pageflip_event;
 
/*
 * created crtc object would be contained at this array and
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b0afa84..68446b3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -487,21 +487,24 @@ static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.disable = fimd_win_disable,
 };
 
-/* for pageflip event */
 static void fimd_finish_pageflip(struct