date:20100913


- Nasa nas...@comcast.net wrote:

 Hi,
 
 Is there a way to tell the driver to use DisplaySize to pass the
 correct dimensions to
 the i915 driver?  from my searches, I saw the following note:
 
 News: xf86-video-intel only supports KMS now
 2010-02-11 - Jan de Groot
 
 With the move of xf86-video-intel 2.10.0 to extra, support for UMS has
 been removed from the intel driver. This means that KMS is a
 requirement now.
 
 
 Does this mean that there's no way to override incorrect (or in my
 case) missing EDID info?  I am assuming so, 
 which is why I am asking about quirks.  Thanks in advance,
 
So...

Given the lack of a response, I am guessing this means the drivers don't
support this capability.  Is there a reason for limiting user capabilities?  
Removing users ability to work around hardware issues just seems like the 
wrong way to go.  At least in my humble opinion.

Nasa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Using quirks to fix incorrect Monitor physical size

2010-09-13 Thread Felix Miata

On 2010/09/13 10:10 (GMT) Nasa composed:

 Is there a way to tell the driver to use DisplaySize to pass the
 correct dimensions to
 the i915 driver?  from my searches, I saw the following note:

 News: xf86-video-intel only supports KMS now
 2010-02-11 - Jan de Groot

 With the move of xf86-video-intel 2.10.0 to extra, support for UMS has
 been removed from the intel driver. This means that KMS is a
 requirement now.

 Does this mean that there's no way to override incorrect (or in my
 case) missing EDID info?  I am assuming so, 
 which is why I am asking about quirks.  Thanks in advance,

 So...

 Given the lack of a response, I am guessing this means the drivers don't
 support this capability.  Is there a reason for limiting user capabilities?  
 Removing users ability to work around hardware issues just seems like the 
 wrong way to go.  At least in my humble opinion.

I'm not implying what you're asking for is unreasonable or too much to ask,
but have you tried Meego's vesa or fbdev drivers with KMS disabled? If those
don't cut it for you, maybe you just need to wait a while longer for the
Intel devs to replace more of what got discarded when UMS got dumped from its
driver. Maybe you need to file an xorg bug to help that along.

What was on the laptop when you bought it? You'd think the vendor would have
shipped something works with its hardware. I can't tell from
http://lists.freedesktop.org/archives/intel-gfx/2010-August/007907.html what
it was you bought.
-- 
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Using quirks to fix incorrect Monitor physical size


- Felix Miata mrma...@earthlink.net wrote:

 On 2010/09/13 10:10 (GMT) Nasa composed:
 
  Is there a way to tell the driver to use DisplaySize to pass the
  correct dimensions to
  the i915 driver?  from my searches, I saw the following note:
 
  News: xf86-video-intel only supports KMS now
  2010-02-11 - Jan de Groot
 
  With the move of xf86-video-intel 2.10.0 to extra, support for UMS
 has
  been removed from the intel driver. This means that KMS is a
  requirement now.
 
  Does this mean that there's no way to override incorrect (or in my
  case) missing EDID info?  I am assuming so, 
  which is why I am asking about quirks.  Thanks in advance,
 
  So...
 
  Given the lack of a response, I am guessing this means the drivers
 don't
  support this capability.  Is there a reason for limiting user
 capabilities?  
  Removing users ability to work around hardware issues just seems
 like the 
  wrong way to go.  At least in my humble opinion.
 
 I'm not implying what you're asking for is unreasonable or too much to
 ask,
 but have you tried Meego's vesa or fbdev drivers with KMS disabled? If
 those
 don't cut it for you, maybe you just need to wait a while longer for
 the
 Intel devs to replace more of what got discarded when UMS got dumped
 from its
 driver. Maybe you need to file an xorg bug to help that along.
 
 What was on the laptop when you bought it? You'd think the vendor
 would have
 shipped something works with its hardware. I can't tell from
 http://lists.freedesktop.org/archives/intel-gfx/2010-August/007907.html
 what
 it was you bought.
 -- 
Actually,

This isn't a laptop.  It's a 7 monitor (http://www.lilliput.cn/EBY701-NP.html),
that I am using in my carpc.  I am presently try this with the IVI 
version of meego (with it's own issues).  Lilliput does provided drivers
for Windows, but nothing directly for Linux.  I have also verified that the 
monitor doesn't provide EDID data as the file size (I found were it's dump to, 
just can't recall right now) was 0.  Talking to Lilliput themselves hasn't 
been very helpful (I don't speak a 2nd language, and neither did the rep I
tried to talk too).

Nasa

BTW: thanks for the reply.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Using quirks to fix incorrect Monitor physical size

2010-09-13 Thread The Fungi

On Mon, Sep 13, 2010 at 11:42:22AM +, Nasa wrote:
[...]
 I have also verified that the monitor doesn't provide EDID data as
 the file size (I found were it's dump to, just can't recall right
 now) was 0.
[...]

You checked the size of the /sys/devices/*/*/drm/*/*/edid structure
(remember to cat it and redirect or pipe that through something,
since it's not a real file)?

   fu...@hastur:~$ cat 
'/sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI Type A-1/edid' | wc 
-c
   256

If memory serves, there was a commit to the driver a kernel rev or
two after KMS went in allowing explicit mode timings to be supplied
on as a kernel/driver parameter, though I'm having trouble digging
up the details now (I could also be misremembering and it just
allows you to pick among the additional non-preferred modes detected
by the driver).

For a while, I was stuck editing the kernel source and hacking the
default display timings to match my monitor, which was ugly but
definitely worked.

If you're using Xorg and can survive with no visible display until
after it starts (using a mode your driver supports but your monitor
does not), xrandr can be used to manually insert additional
modelines and switch to those (I used to do that in my ~/.xinitrc
until mode detection for my HDTV's HDMI input improved).
-- 
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Using quirks to fix incorrect Monitor physical size


- Felix Miata mrma...@earthlink.net wrote:

 On 2010/09/13 11:42 (GMT) Nasa composed:
 
  This isn't a laptop.  It's a 7 monitor
 (http://www.lilliput.cn/EBY701-NP.html),
  that I am using in my carpc.  I am presently try this with the IVI 
  version of meego (with it's own issues).  Lilliput does provided
 drivers
  for Windows, but nothing directly for Linux.  I have also verified
 that the 
  monitor doesn't provide EDID data as the file size (I found were
 it's dump to, 
  just can't recall right now) was 0.  Talking to Lilliput themselves
 hasn't 
  been very helpful (I don't speak a 2nd language, and neither did the
 rep I
  tried to talk too).
 
 Anything that is neither a standard format (4:3, 16:10 or 16:9) nor
 provides
 valid EDID is just plain broken. I'd return it. If it's too late for
 free
 return, maybe the vendor would allow exchange. If not, then try
 warranty
 repair. Maybe a Lilliput support manager can authorize an attempt to
 get it
 to output valid EDID either with a firmware update or otherwise.
 
 Again, what about VESA or FBDEV drivers? No help?
 -- 

I haven't tried those drivers yet (have to do it after work).  I'll have
to make sure these drivers will work with meego.  And I can't really return/
warranty exchange this monitor as it's been *modified* (ie removed from 
case) so that it fits nicely in my car.

Nasa

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 0/2] i915 brightness control

2010-09-13 Thread Matthew Garrett

On Wed, Jun 02, 2010 at 03:11:40PM -0700, Kamal Mostafa wrote:

 In order to avoid the often-dysfunctional native acpi brightness control
 methods, a new acpi_brightness_hook interface is made available.
 
 The i915 driver uses the new hook to take over brightness control.
 Boot with i915.brightness=0 to disable.

I've looked into this issue more closely and think I've worked out the 
underlying problem. The system in question appears to have two GPUs and 
exposes two ACPI backlight devices. Both of these are associated with 
existing PCI devices, so we don't ignore either of them because of that. 
Further, one of them (the AMD one) implements the spec properly and 
should work. We don't seem to perform a more fine-grained check to 
identify whether every ACPI backlight has all the required methods, and 
so as a result we provide both the working one and the non-working one.

Having thought about this some more, I don't think this is the right 
approach. We should be ensuring that every backlight ahs all the 
required methods and then dropping the one that doesn't. This should be 
replaced with a native i915 backlight, and I sent patches to do that 
last week.

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

[Intel-gfx] vsync problems with recent graphics stack and 945gm

Hi there, I've just built graphics stack (xf86-video-intel, libdrm, mesa) from 
git (but I'm on 2.6.35.x kernel) and still experiencing vsync troubles without 
composite manager, here's output of glxgears:

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
243 frames in 5.0 seconds = 48.124 FPS
157 frames in 5.0 seconds = 31.300 FPS
155 frames in 5.0 seconds = 30.864 FPS

But I'm pretty sure that vertical refresh is 60 hz! And gears are jerky (not 
smooth at all). If I move mouse cursor over glxgears window FPS goes up to 60. 
And main problem is that keyboard events are also jerky, i.e. I press key and 
system receives press event in 0.1-0.5 sec or so (tested via xev).

There's no such problem when composition manager is running (i.e. effects are 
enabled in KDE)

Is there any solution for this problem? It really annoys me.

Regards
Vasily


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

Re: [Intel-gfx] vsync problems with recent graphics stack and 945gm

On Mon, 13 Sep 2010 23:36:11 +0300
Vasily Khoruzhick anars...@gmail.com wrote:

 Hi there, I've just built graphics stack (xf86-video-intel, libdrm, mesa) 
 from 
 git (but I'm on 2.6.35.x kernel) and still experiencing vsync troubles 
 without 
 composite manager, here's output of glxgears:
 
 $ glxgears
 Running synchronized to the vertical refresh.  The framerate should be
 approximately the same as the monitor refresh rate.
 243 frames in 5.0 seconds = 48.124 FPS
 157 frames in 5.0 seconds = 31.300 FPS
 155 frames in 5.0 seconds = 30.864 FPS
 
 But I'm pretty sure that vertical refresh is 60 hz! And gears are jerky (not 
 smooth at all). If I move mouse cursor over glxgears window FPS goes up to 
 60. 
 And main problem is that keyboard events are also jerky, i.e. I press key and 
 system receives press event in 0.1-0.5 sec or so (tested via xev).
 
 There's no such problem when composition manager is running (i.e. effects are 
 enabled in KDE)
 
 Is there any solution for this problem? It really annoys me.

I remember seeing a similar problem on an Eee PC I had; it seemed to be
timer/interrupt related somehow.  If I booted with clocksource=tsc
(or maybe it was pit) I got nice smooth animations, but if I used the
HPET things were really slow.

Does the same work for you?

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

[Intel-gfx] Interrupt latency on some 945GM platforms

On Tue, 14 Sep 2010 00:10:08 +0300
Vasily Khoruzhick anars...@gmail.com wrote:

 В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
  I remember seeing a similar problem on an Eee PC I had; it seemed to be
  timer/interrupt related somehow.  If I booted with clocksource=tsc
  (or maybe it was pit) I got nice smooth animations, but if I used the
  HPET things were really slow.
  
  Does the same work for you?
 
 Yeah, it works for me (will use it as temporary workaround). But it 
 definitely 
 is not clean solution, as I can't use nohz mode with tsc clocksource :)

Thomas, does this ring any bells for you?

I think the root symptom of the issue is that we get a much reduced i915
interrupt frequency (or no interrupts) on some 945GM platforms when
using HPET as our clock source.

In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't
generate interrupts at all when HPET was used.  But shaking the mouse or
generating network traffic was enough to get i915 interrupts coming in,
even though neither of those interrupts were shared with the i915
device.

Here's hoping you have some ideas to try...

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

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
On Tue, 14 Sep 2010 00:10:08 +0300

Vasily Khoruzhick anars...@gmail.com wrote:
В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
I remember seeing a similar problem on an Eee PC I had; it seemed to be
timer/interrupt related somehow. If I booted with clocksource=tsc
(or maybe it was pit) I got nice smooth animations, but if I used the
HPET things were really slow.

Does the same work for you?

Yeah, it works for me (will use it as temporary workaround). But it
definitely is not clean solution, as I can't use nohz mode with tsc
clocksource :)

Thomas, does this ring any bells for you?

I think the root symptom of the issue is that we get a much reduced i915
interrupt frequency (or no interrupts) on some 945GM platforms when
using HPET as our clock source.

In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't
generate interrupts at all when HPET was used. But shaking the mouse or
generating network traffic was enough to get i915 interrupts coming in,
even though neither of those interrupts were shared with the i915
device.

Here's hoping you have some ideas to try...

Thanks,

Jesse, is it possible to disable wait for vsync somehow? cpufreq is not
working for me with nohz=no for some reason, as result cpu temperature and
power usage are higher. I prefer to see tearing but with low power usage and
without jerky keyboard :)

Regards
Vasily

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

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

On Tue, 14 Sep 2010 00:41:18 +0300
Vasily Khoruzhick anars...@gmail.com wrote:

В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
On Tue, 14 Sep 2010 00:10:08 +0300

Does the same work for you?

Yeah, it works for me (will use it as temporary workaround). But it
definitely is not clean solution, as I can't use nohz mode with tsc
clocksource :)

Thomas, does this ring any bells for you?

I think the root symptom of the issue is that we get a much reduced i915
interrupt frequency (or no interrupts) on some 945GM platforms when
using HPET as our clock source.

Here's hoping you have some ideas to try...

Thanks,

Yes, you can set vblank_mode=0 in your environment or drirc. At least
I think 0 is no vsync. :)

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

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:

 Yes, you can set vblank_mode=0 in your environment or drirc.  At least
 I think 0 is no vsync. :)

That doesn't help, glxgears shows ~1000fps, but it's output is jerky.


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

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

On Tue, 14 Sep 2010 00:52:31 +0300
Vasily Khoruzhick anars...@gmail.com wrote:

 В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
 
  Yes, you can set vblank_mode=0 in your environment or drirc.  At least
  I think 0 is no vsync. :)
 
 That doesn't help, glxgears shows ~1000fps, but it's output is jerky.

Is it smooth with clocksource=tsc?  I wonder if the GPU batch
interrupts are also getting delayed, and possibly timer ticks...

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

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал:
 On Tue, 14 Sep 2010 00:52:31 +0300
 
 Vasily Khoruzhick anars...@gmail.com wrote:
  В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
   Yes, you can set vblank_mode=0 in your environment or drirc.  At least
   I think 0 is no vsync. :)
  
  That doesn't help, glxgears shows ~1000fps, but it's output is jerky.
 
 Is it smooth with clocksource=tsc?  I wonder if the GPU batch
 interrupts are also getting delayed, and possibly timer ticks...


Yes, it's smooth with clocksource=tsc nohz=off

Regards
Vasily


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

[Intel-gfx] [PATCH 01/17] intel-gtt: initialize our own scratch page

The intel gtt fake agp driver is the only agp driver to use dma
address remapping. So it makes sense to fold this code back into the
only user (and thus reduce the reliance on the agp code).

This patch does the first step by initializing (and remapping) the
scratch page in a new function intel_gtt_setup_scratch_page.
Unfortunately intel_gtt_cleanup had to move to avoid a forward
declaration. The new scratch page is not yet used, though.

v2: Refactor out scratch page teardown.  Suggested by Chris Wilson on
irc. This makes it clear what's going on and results in a nice
symmetry between setup and teardown.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |   81 +-
 1 files changed, 64 insertions(+), 17 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 9cb7c98..af920b5 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -35,6 +35,8 @@
  */
 #ifdef CONFIG_DMAR
 #define USE_PCI_DMA_API 1
+#else
+#define USE_PCI_DMA_API 0
 #endif
 
 /* Max amount of stolen space, anything above will be returned to Linux */
@@ -107,6 +109,8 @@ static struct _intel_private {
struct page *i8xx_page;
struct resource ifp_resource;
int resource_valid;
+   struct page *scratch_page;
+   dma_addr_t scratch_page_dma;
 } intel_private;
 
 #define INTEL_GTT_GEN  intel_private.driver-gen
@@ -114,7 +118,7 @@ static struct _intel_private {
 #define IS_PINEVIEWintel_private.driver-is_pineview
 #define IS_IRONLAKEintel_private.driver-is_ironlake
 
-#ifdef USE_PCI_DMA_API
+#if USE_PCI_DMA_API
 static int intel_agp_map_page(struct page *page, dma_addr_t *ret)
 {
*ret = pci_map_page(intel_private.pcidev, page, 0,
@@ -539,6 +543,32 @@ static unsigned long intel_i810_mask_memory(struct 
agp_bridge_data *bridge,
return addr | bridge-driver-masks[type].mask;
 }
 
+static int intel_gtt_setup_scratch_page(void)
+{
+   struct page *page;
+   dma_addr_t dma_addr;
+
+   page = alloc_page(GFP_KERNEL | GFP_DMA32 | __GFP_ZERO);
+   if (page == NULL)
+   return -ENOMEM;
+   get_page(page);
+   set_pages_uc(page, 1);
+
+   if (USE_PCI_DMA_API  INTEL_GTT_GEN  2) {
+   dma_addr = pci_map_page(intel_private.pcidev, page, 0,
+   PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+   if (pci_dma_mapping_error(intel_private.pcidev, dma_addr))
+   return -EINVAL;
+
+   intel_private.scratch_page_dma = dma_addr;
+   } else
+   intel_private.scratch_page_dma = page_to_phys(page);
+
+   intel_private.scratch_page = page;
+
+   return 0;
+}
+
 static struct aper_size_info_fixed intel_fake_agp_sizes[] =
 {
{128, 32768, 5},
@@ -795,6 +825,29 @@ static unsigned int intel_gtt_mappable_entries(void)
return aperture_size  PAGE_SHIFT;
 }
 
+static void intel_gtt_teardown_scratch_page(void)
+{
+   set_pages_wb(intel_private.scratch_page, 1);
+   pci_unmap_page(intel_private.pcidev, intel_private.scratch_page_dma,
+  PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+   put_page(intel_private.scratch_page);
+   __free_page(intel_private.scratch_page);
+}
+
+static void intel_gtt_cleanup(void)
+{
+   if (intel_private.i9xx_flush_page)
+   iounmap(intel_private.i9xx_flush_page);
+   if (intel_private.resource_valid)
+   release_resource(intel_private.ifp_resource);
+   intel_private.ifp_resource.start = 0;
+   intel_private.resource_valid = 0;
+   iounmap(intel_private.gtt);
+   iounmap(intel_private.registers);
+   
+   intel_gtt_teardown_scratch_page();
+}
+
 static int intel_gtt_init(void)
 {
u32 gtt_map_size;
@@ -828,6 +881,12 @@ static int intel_gtt_init(void)
return -ENOMEM;
}
 
+   ret = intel_gtt_setup_scratch_page();
+   if (ret != 0) {
+   intel_gtt_cleanup();
+   return ret;
+   }
+
return 0;
 }
 
@@ -1175,18 +1234,6 @@ static int intel_i9xx_configure(void)
return 0;
 }
 
-static void intel_gtt_cleanup(void)
-{
-   if (intel_private.i9xx_flush_page)
-   iounmap(intel_private.i9xx_flush_page);
-   if (intel_private.resource_valid)
-   release_resource(intel_private.ifp_resource);
-   intel_private.ifp_resource.start = 0;
-   intel_private.resource_valid = 0;
-   iounmap(intel_private.gtt);
-   iounmap(intel_private.registers);
-}
-
 static void intel_i915_chipset_flush(struct agp_bridge_data *bridge)
 {
if (intel_private.i9xx_flush_page)
@@ -1413,7 +1460,7 @@ static const struct agp_bridge_driver intel_915_driver = {
.agp_destroy_pages  = agp_generic_destroy_pages,
.agp_type_to_mask_type  = intel_i830_type_to_mask_type,
.chipset_flush  = intel_i915_chipset_flush,
-#ifdef

[Intel-gfx] [PATCH 02/17] intel-gtt: introduce pte write function for i8xx/i915/i945

And put it to use in the gtt configuration code that writes
the scratch page addr in all gtt ptes. This makes intel_i830_configure
generic, hence rename it to intel_fake_agp_configure.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |   41 -
 1 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index af920b5..59fad22 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -90,6 +90,10 @@ struct intel_gtt_driver {
unsigned int is_ironlake : 1;
/* Chipset specific GTT setup */
int (*setup)(void);
+   void (*write_entry)(dma_addr_t addr, unsigned int entry, unsigned int 
flags);
+   /* Flags is a more or less chipset specific opaque value.
+* For chipsets that need to support old ums (non-gem) code, this
+* needs to be identical to the various supported agp memory types! */
 };
 
 static struct _intel_private {
@@ -956,6 +960,23 @@ static void intel_i830_chipset_flush(struct 
agp_bridge_data *bridge)
printk(KERN_ERR Timed out waiting for cache flush.\n);
 }
 
+static void i830_write_entry(dma_addr_t addr, unsigned int entry,
+unsigned int flags)
+{
+   u32 pte_flags = I810_PTE_VALID;
+   
+   switch (flags) {
+   case AGP_DCACHE_MEMORY:
+   pte_flags |= I810_PTE_LOCAL;
+   break;
+   case AGP_USER_CACHED_MEMORY:
+   pte_flags |= I830_PTE_SYSTEM_CACHED;
+   break;
+   }
+
+   writel(addr | pte_flags, intel_private.gtt + entry);
+}
+
 static void intel_enable_gtt(void)
 {
u32 ptetbl_addr, gma_addr;
@@ -1012,7 +1033,7 @@ static int intel_fake_agp_free_gatt_table(struct 
agp_bridge_data *bridge)
return 0;
 }
 
-static int intel_i830_configure(void)
+static int intel_fake_agp_configure(void)
 {
int i;
 
@@ -1020,13 +1041,12 @@ static int intel_i830_configure(void)
 
agp_bridge-gart_bus_addr = intel_private.gma_bus_addr;
 
-   if (agp_bridge-driver-needs_scratch_page) {
-   for (i = intel_private.base.gtt_stolen_entries;
-   i  intel_private.base.gtt_total_entries; i++) {
-   writel(agp_bridge-scratch_page, intel_private.gtt+i);
-   }
-   readl(intel_private.gtt+i-1);   /* PCI Posting. */
+   for (i = intel_private.base.gtt_stolen_entries;
+   i  intel_private.base.gtt_total_entries; i++) {
+   
intel_private.driver-write_entry(intel_private.scratch_page_dma,
+ i, 0);
}
+   readl(intel_private.gtt+i-1);   /* PCI Posting. */
 
global_cache_flush();
 
@@ -1414,7 +1434,7 @@ static const struct agp_bridge_driver intel_830_driver = {
.size_type  = FIXED_APER_SIZE,
.num_aperture_sizes = 4,
.needs_scratch_page = true,
-   .configure  = intel_i830_configure,
+   .configure  = intel_fake_agp_configure,
.fetch_size = intel_fake_agp_fetch_size,
.cleanup= intel_gtt_cleanup,
.mask_memory= intel_i810_mask_memory,
@@ -1441,7 +1461,7 @@ static const struct agp_bridge_driver intel_915_driver = {
.size_type  = FIXED_APER_SIZE,
.num_aperture_sizes = 4,
.needs_scratch_page = true,
-   .configure  = intel_i9xx_configure,
+   .configure  = intel_fake_agp_configure,
.fetch_size = intel_fake_agp_fetch_size,
.cleanup= intel_gtt_cleanup,
.mask_memory= intel_i810_mask_memory,
@@ -1570,10 +1590,13 @@ static const struct agp_bridge_driver intel_g33_driver 
= {
 static const struct intel_gtt_driver i8xx_gtt_driver = {
.gen = 2,
.setup = i830_setup,
+   .write_entry = i830_write_entry,
 };
 static const struct intel_gtt_driver i915_gtt_driver = {
.gen = 3,
.setup = i9xx_setup,
+   /* i945 is the last gpu to need phys mem (for overlay and cursors). */
+   .write_entry = i830_write_entry, 
 };
 static const struct intel_gtt_driver g33_gtt_driver = {
.gen = 3,
-- 
1.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/17] intel-gtt: generic (insert|remove)_entries for i915

Beef up the generic version to support dmar. Otherwise like for the i830.

v2: Don't try to DMA remap on resume for already remapped pages.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |   60 ++---
 1 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 0555e16..8273b2b 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -123,7 +123,6 @@ static struct _intel_private {
 #define IS_PINEVIEWintel_private.driver-is_pineview
 #define IS_IRONLAKEintel_private.driver-is_ironlake
 
-#if USE_PCI_DMA_API
 static void intel_agp_free_sglist(struct agp_memory *mem)
 {
struct sg_table st;
@@ -143,6 +142,9 @@ static int intel_agp_map_memory(struct agp_memory *mem)
struct scatterlist *sg;
int i;
 
+   if (mem-sg_list)
+   return 0; /* already mapped (for e.g. resume */
+
DBG(try mapping %lu pages\n, (unsigned long)mem-page_count);
 
if (sg_alloc_table(st, mem-page_count, GFP_KERNEL))
@@ -174,6 +176,7 @@ static void intel_agp_unmap_memory(struct agp_memory *mem)
intel_agp_free_sglist(mem);
 }
 
+#if USE_PCI_DMA_API
 static void intel_agp_insert_sg_entries(struct agp_memory *mem,
off_t pg_start, int mask_type)
 {
@@ -1052,6 +1055,31 @@ static bool i830_check_flags(unsigned int flags)
return false;
 }
 
+static void intel_gtt_insert_sg_entries(struct scatterlist *sg_list,
+   unsigned int sg_len,
+   unsigned int pg_start,
+   unsigned int flags)
+{
+   struct scatterlist *sg;
+   unsigned int len, m;
+   int i, j;
+
+   j = pg_start;
+
+   /* sg may merge pages, but we have to separate
+* per-page addr for GTT */
+   for_each_sg(sg_list, sg, sg_len, i) {
+   len = sg_dma_len(sg)  PAGE_SHIFT;
+   for (m = 0; m  len; m++) {
+   dma_addr_t addr = sg_dma_address(sg) + (m  
PAGE_SHIFT);
+   intel_private.driver-write_entry(addr,
+ j, flags);
+   j++;
+   }
+   }
+   readl(intel_private.gtt+j-1);
+}
+
 static int intel_fake_agp_insert_entries(struct agp_memory *mem,
 off_t pg_start, int type)
 {
@@ -1083,11 +,21 @@ static int intel_fake_agp_insert_entries(struct 
agp_memory *mem,
if (!mem-is_flushed)
global_cache_flush();
 
-   for (i = 0, j = pg_start; i  mem-page_count; i++, j++) {
-   intel_private.driver-write_entry(page_to_phys(mem-pages[i]),
- j, type);
+   if (USE_PCI_DMA_API  INTEL_GTT_GEN  2) {
+   ret = intel_agp_map_memory(mem);
+   if (ret != 0)
+   return ret;
+
+   intel_gtt_insert_sg_entries(mem-sg_list, mem-num_sg,
+   pg_start, type);
+   } else {
+   for (i = 0, j = pg_start; i  mem-page_count; i++, j++) {
+   dma_addr_t addr = page_to_phys(mem-pages[i]);
+   intel_private.driver-write_entry(addr,
+ j, type);
+   }
+   readl(intel_private.gtt+j-1);
}
-   readl(intel_private.gtt+j-1);
 
 out:
ret = 0;
@@ -1110,6 +1148,9 @@ static int intel_fake_agp_remove_entries(struct 
agp_memory *mem,
return -EINVAL;
}
 
+   if (USE_PCI_DMA_API  INTEL_GTT_GEN  2)
+   intel_agp_unmap_memory(mem);
+
for (i = pg_start; i  (mem-page_count + pg_start); i++) {

intel_private.driver-write_entry(intel_private.scratch_page_dma,
  i, 0);
@@ -1466,8 +1507,8 @@ static const struct agp_bridge_driver intel_915_driver = {
.cache_flush= global_cache_flush,
.create_gatt_table  = intel_fake_agp_create_gatt_table,
.free_gatt_table= intel_fake_agp_free_gatt_table,
-   .insert_memory  = intel_i915_insert_entries,
-   .remove_memory  = intel_i915_remove_entries,
+   .insert_memory  = intel_fake_agp_insert_entries,
+   .remove_memory  = intel_fake_agp_remove_entries,
.alloc_by_type  = intel_fake_agp_alloc_by_type,
.free_by_type   = intel_i810_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
@@ -1476,10 +1517,6 @@ static const struct agp_bridge_driver intel_915_driver = 
{
.agp_destroy_pages  = agp_generic_destroy_pages,
.agp_type_to_mask_type  = intel_i830_type_to_mask_type,
.chipset_flush

[Intel-gfx] [PATCH 10/17] intel-gtt: generic (insert|remove)_entries for sandybridge

Like before, but now with the added bonus of being able to kill
quite a bit of no-longer useful code (the old dmar support stuff).

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |  144 +++---
 1 files changed, 8 insertions(+), 136 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 225b791..6b20396 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -176,61 +176,6 @@ static void intel_agp_unmap_memory(struct agp_memory *mem)
intel_agp_free_sglist(mem);
 }
 
-#if USE_PCI_DMA_API
-static void intel_agp_insert_sg_entries(struct agp_memory *mem,
-   off_t pg_start, int mask_type)
-{
-   struct scatterlist *sg;
-   int i, j;
-
-   j = pg_start;
-
-   WARN_ON(!mem-num_sg);
-
-   if (mem-num_sg == mem-page_count) {
-   for_each_sg(mem-sg_list, sg, mem-page_count, i) {
-   writel(agp_bridge-driver-mask_memory(agp_bridge,
-   sg_dma_address(sg), mask_type),
-   intel_private.gtt+j);
-   j++;
-   }
-   } else {
-   /* sg may merge pages, but we have to separate
-* per-page addr for GTT */
-   unsigned int len, m;
-
-   for_each_sg(mem-sg_list, sg, mem-num_sg, i) {
-   len = sg_dma_len(sg) / PAGE_SIZE;
-   for (m = 0; m  len; m++) {
-   
writel(agp_bridge-driver-mask_memory(agp_bridge,
-  
sg_dma_address(sg) + m * PAGE_SIZE,
-  
mask_type),
-  intel_private.gtt+j);
-   j++;
-   }
-   }
-   }
-   readl(intel_private.gtt+j-1);
-}
-
-#else
-
-static void intel_agp_insert_sg_entries(struct agp_memory *mem,
-   off_t pg_start, int mask_type)
-{
-   int i, j;
-
-   for (i = 0, j = pg_start; i  mem-page_count; i++, j++) {
-   writel(agp_bridge-driver-mask_memory(agp_bridge,
-   page_to_phys(mem-pages[i]), mask_type),
-  intel_private.gtt+j);
-   }
-
-   readl(intel_private.gtt+j-1);
-}
-
-#endif
-
 static int intel_i810_fetch_size(void)
 {
u32 smram_miscc;
@@ -1267,81 +1212,6 @@ static void intel_i915_chipset_flush(struct 
agp_bridge_data *bridge)
writel(1, intel_private.i9xx_flush_page);
 }
 
-static int intel_i915_insert_entries(struct agp_memory *mem, off_t pg_start,
-int type)
-{
-   int num_entries;
-   void *temp;
-   int ret = -EINVAL;
-   int mask_type;
-
-   if (mem-page_count == 0)
-   goto out;
-
-   temp = agp_bridge-current_size;
-   num_entries = A_SIZE_FIX(temp)-num_entries;
-
-   if (pg_start  intel_private.base.gtt_stolen_entries) {
-   dev_printk(KERN_DEBUG, intel_private.pcidev-dev,
-  pg_start == 0x%.8lx, gtt_stolen_entries == 
0x%.8x\n,
-  pg_start, intel_private.base.gtt_stolen_entries);
-
-   dev_info(intel_private.pcidev-dev,
-trying to insert into local/stolen memory\n);
-   goto out_err;
-   }
-
-   if ((pg_start + mem-page_count)  num_entries)
-   goto out_err;
-
-   /* The i915 can't check the GTT for entries since it's read only;
-* depend on the caller to make the correct offset decisions.
-*/
-
-   if (type != mem-type)
-   goto out_err;
-
-   mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
-
-   if (INTEL_GTT_GEN != 6  mask_type != 0 
-   mask_type != AGP_PHYS_MEMORY 
-   mask_type != INTEL_AGP_CACHED_MEMORY)
-   goto out_err;
-
-   if (!mem-is_flushed)
-   global_cache_flush();
-
-   intel_agp_insert_sg_entries(mem, pg_start, mask_type);
-
- out:
-   ret = 0;
- out_err:
-   mem-is_flushed = true;
-   return ret;
-}
-
-static int intel_i915_remove_entries(struct agp_memory *mem, off_t pg_start,
-int type)
-{
-   int i;
-
-   if (mem-page_count == 0)
-   return 0;
-
-   if (pg_start  intel_private.base.gtt_stolen_entries) {
-   dev_info(intel_private.pcidev-dev,
-trying to disable local/stolen memory\n);
-   return -EINVAL;
-   }
-
-   for (i = pg_start; i  (mem-page_count + pg_start); i++)
-   writel(agp_bridge-scratch_page, intel_private.gtt+i);
-
-   readl(intel_private.gtt+i-1);
-
-   return 0;
-}

[Intel-gfx] [PATCH 09/17] intel-gtt: generic (insert|remove)_entries for g33/i965

Like for the i915.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |   21 +
 1 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 8273b2b..225b791 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1533,8 +1533,8 @@ static const struct agp_bridge_driver intel_i965_driver = 
{
.cache_flush= global_cache_flush,
.create_gatt_table  = intel_fake_agp_create_gatt_table,
.free_gatt_table= intel_fake_agp_free_gatt_table,
-   .insert_memory  = intel_i915_insert_entries,
-   .remove_memory  = intel_i915_remove_entries,
+   .insert_memory  = intel_fake_agp_insert_entries,
+   .remove_memory  = intel_fake_agp_remove_entries,
.alloc_by_type  = intel_fake_agp_alloc_by_type,
.free_by_type   = intel_i810_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
@@ -1543,10 +1543,6 @@ static const struct agp_bridge_driver intel_i965_driver 
= {
.agp_destroy_pages  = agp_generic_destroy_pages,
.agp_type_to_mask_type  = intel_i830_type_to_mask_type,
.chipset_flush  = intel_i915_chipset_flush,
-#if USE_PCI_DMA_API
-   .agp_map_memory = intel_agp_map_memory,
-   .agp_unmap_memory   = intel_agp_unmap_memory,
-#endif
 };
 
 static const struct agp_bridge_driver intel_gen6_driver = {
@@ -1593,8 +1589,8 @@ static const struct agp_bridge_driver intel_g33_driver = {
.cache_flush= global_cache_flush,
.create_gatt_table  = intel_fake_agp_create_gatt_table,
.free_gatt_table= intel_fake_agp_free_gatt_table,
-   .insert_memory  = intel_i915_insert_entries,
-   .remove_memory  = intel_i915_remove_entries,
+   .insert_memory  = intel_fake_agp_insert_entries,
+   .remove_memory  = intel_fake_agp_remove_entries,
.alloc_by_type  = intel_fake_agp_alloc_by_type,
.free_by_type   = intel_i810_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
@@ -1603,10 +1599,6 @@ static const struct agp_bridge_driver intel_g33_driver = 
{
.agp_destroy_pages  = agp_generic_destroy_pages,
.agp_type_to_mask_type  = intel_i830_type_to_mask_type,
.chipset_flush  = intel_i915_chipset_flush,
-#if USE_PCI_DMA_API
-   .agp_map_memory = intel_agp_map_memory,
-   .agp_unmap_memory   = intel_agp_unmap_memory,
-#endif
 };
 
 static const struct intel_gtt_driver i8xx_gtt_driver = {
@@ -1627,28 +1619,33 @@ static const struct intel_gtt_driver g33_gtt_driver = {
.is_g33 = 1,
.setup = i9xx_setup,
.write_entry = i965_write_entry,
+   .check_flags = i830_check_flags,
 };
 static const struct intel_gtt_driver pineview_gtt_driver = {
.gen = 3,
.is_pineview = 1, .is_g33 = 1,
.setup = i9xx_setup,
.write_entry = i965_write_entry,
+   .check_flags = i830_check_flags,
 };
 static const struct intel_gtt_driver i965_gtt_driver = {
.gen = 4,
.setup = i9xx_setup,
.write_entry = i965_write_entry,
+   .check_flags = i830_check_flags,
 };
 static const struct intel_gtt_driver g4x_gtt_driver = {
.gen = 5,
.setup = i9xx_setup,
.write_entry = i965_write_entry,
+   .check_flags = i830_check_flags,
 };
 static const struct intel_gtt_driver ironlake_gtt_driver = {
.gen = 5,
.is_ironlake = 1,
.setup = i9xx_setup,
.write_entry = i965_write_entry,
+   .check_flags = i830_check_flags,
 };
 static const struct intel_gtt_driver sandybridge_gtt_driver = {
.gen = 6,
-- 
1.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 11/17] intel-gtt: kill mask_memory functions

That indirection mess can now go. Add a dummy i81x gtt_driver to
avoid a NULL pointer check.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |  105 +
 1 files changed, 13 insertions(+), 92 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 6b20396..8e149a8 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -69,20 +69,6 @@ static struct gatt_mask intel_i810_masks[] =
 #define INTEL_AGP_CACHED_MEMORY_LLC_MLC3
 #define INTEL_AGP_CACHED_MEMORY_LLC_MLC_GFDT   4
 
-static struct gatt_mask intel_gen6_masks[] =
-{
-   {.mask = I810_PTE_VALID | GEN6_PTE_UNCACHED,
-.type = INTEL_AGP_UNCACHED_MEMORY },
-   {.mask = I810_PTE_VALID | GEN6_PTE_LLC,
- .type = INTEL_AGP_CACHED_MEMORY_LLC },
-   {.mask = I810_PTE_VALID | GEN6_PTE_LLC | GEN6_PTE_GFDT,
- .type = INTEL_AGP_CACHED_MEMORY_LLC_GFDT },
-   {.mask = I810_PTE_VALID | GEN6_PTE_LLC_MLC,
- .type = INTEL_AGP_CACHED_MEMORY_LLC_MLC },
-   {.mask = I810_PTE_VALID | GEN6_PTE_LLC_MLC | GEN6_PTE_GFDT,
- .type = INTEL_AGP_CACHED_MEMORY_LLC_MLC_GFDT },
-};
-
 struct intel_gtt_driver {
unsigned int gen : 8;
unsigned int is_g33 : 1;
@@ -286,34 +272,6 @@ static void i8xx_destroy_pages(struct page *page)
atomic_dec(agp_bridge-current_memory_agp);
 }
 
-static int intel_i830_type_to_mask_type(struct agp_bridge_data *bridge,
-   int type)
-{
-   if (type  AGP_USER_TYPES)
-   return type;
-   else if (type == AGP_USER_CACHED_MEMORY)
-   return INTEL_AGP_CACHED_MEMORY;
-   else
-   return 0;
-}
-
-static int intel_gen6_type_to_mask_type(struct agp_bridge_data *bridge,
-   int type)
-{
-   unsigned int type_mask = type  ~AGP_USER_CACHED_MEMORY_GFDT;
-   unsigned int gfdt = type  AGP_USER_CACHED_MEMORY_GFDT;
-
-   if (type_mask == AGP_USER_UNCACHED_MEMORY)
-   return INTEL_AGP_UNCACHED_MEMORY;
-   else if (type_mask == AGP_USER_CACHED_MEMORY_LLC_MLC)
-   return gfdt ? INTEL_AGP_CACHED_MEMORY_LLC_MLC_GFDT :
- INTEL_AGP_CACHED_MEMORY_LLC_MLC;
-   else /* set 'normal'/'cached' to LLC by default */
-   return gfdt ? INTEL_AGP_CACHED_MEMORY_LLC_GFDT :
- INTEL_AGP_CACHED_MEMORY_LLC;
-}
-
-
 static int intel_i810_insert_entries(struct agp_memory *mem, off_t pg_start,
int type)
 {
@@ -1287,35 +1245,6 @@ static int i9xx_setup(void)
return 0;
 }
 
-/*
- * The i965 supports 36-bit physical addresses, but to keep
- * the format of the GTT the same, the bits that don't fit
- * in a 32-bit word are shifted down to bits 4..7.
- *
- * Gcc is smart enough to notice that (addr  28)  0xf0
- * is always zero on 32-bit architectures, so no need to make
- * this conditional.
- */
-static unsigned long intel_i965_mask_memory(struct agp_bridge_data *bridge,
-   dma_addr_t addr, int type)
-{
-   /* Shift high bits down */
-   addr |= (addr  28)  0xf0;
-
-   /* Type checking must be done elsewhere */
-   return addr | bridge-driver-masks[type].mask;
-}
-
-static unsigned long intel_gen6_mask_memory(struct agp_bridge_data *bridge,
-   dma_addr_t addr, int type)
-{
-   /* gen6 has bit11-4 for physical addr bit39-32 */
-   addr |= (addr  28)  0xff0;
-
-   /* Type checking must be done elsewhere */
-   return addr | bridge-driver-masks[type].mask;
-}
-
 static const struct agp_bridge_driver intel_810_driver = {
.owner  = THIS_MODULE,
.aperture_sizes = intel_i810_sizes,
@@ -1350,8 +1279,6 @@ static const struct agp_bridge_driver intel_830_driver = {
.configure  = intel_fake_agp_configure,
.fetch_size = intel_fake_agp_fetch_size,
.cleanup= intel_gtt_cleanup,
-   .mask_memory= intel_i810_mask_memory,
-   .masks  = intel_i810_masks,
.agp_enable = intel_fake_agp_enable,
.cache_flush= global_cache_flush,
.create_gatt_table  = intel_fake_agp_create_gatt_table,
@@ -1364,7 +1291,6 @@ static const struct agp_bridge_driver intel_830_driver = {
.agp_alloc_pages= agp_generic_alloc_pages,
.agp_destroy_page   = agp_generic_destroy_page,
.agp_destroy_pages  = agp_generic_destroy_pages,
-   .agp_type_to_mask_type  = intel_i830_type_to_mask_type,
.chipset_flush  = intel_i830_chipset_flush,
 };
 
@@ -1376,8 +1302,6 @@ static const struct agp_bridge_driver intel_915_driver = {
.configure  = intel_fake_agp_configure,
.fetch_size =

[Intel-gfx] [PATCH 12/17] intel-gtt: move chipset flush to the gtt driver struct

This is the last differentiator between the different fake agp drivers.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |   28 +---
 1 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 8e149a8..e6d69ef 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -81,6 +81,7 @@ struct intel_gtt_driver {
 * For chipsets that need to support old ums (non-gem) code, this
 * needs to be identical to the various supported agp memory types! */
bool (*check_flags)(unsigned int flags);
+   void (*chipset_flush)(void);
 };
 
 static struct _intel_private {
@@ -840,7 +841,7 @@ static void intel_i830_setup_flush(void)
  * that buffer out, we just fill 1KB and clflush it out, on the assumption
  * that it'll push whatever was in there out.  It appears to work.
  */
-static void intel_i830_chipset_flush(struct agp_bridge_data *bridge)
+static void i830_chipset_flush(void)
 {
unsigned int *pg = intel_private.i8xx_flush_page;
 
@@ -1063,6 +1064,11 @@ static int intel_fake_agp_remove_entries(struct 
agp_memory *mem,
return 0;
 }
 
+static void intel_fake_agp_chipset_flush(struct agp_bridge_data *bridge)
+{
+   intel_private.driver-chipset_flush();
+}
+
 static struct agp_memory *intel_fake_agp_alloc_by_type(size_t pg_count,
   int type)
 {
@@ -1164,7 +1170,7 @@ static void intel_i9xx_setup_flush(void)
can't ioremap flush page - no chipset flushing\n);
 }
 
-static void intel_i915_chipset_flush(struct agp_bridge_data *bridge)
+static void i9xx_chipset_flush(void)
 {
if (intel_private.i9xx_flush_page)
writel(1, intel_private.i9xx_flush_page);
@@ -1291,7 +1297,7 @@ static const struct agp_bridge_driver intel_830_driver = {
.agp_alloc_pages= agp_generic_alloc_pages,
.agp_destroy_page   = agp_generic_destroy_page,
.agp_destroy_pages  = agp_generic_destroy_pages,
-   .chipset_flush  = intel_i830_chipset_flush,
+   .chipset_flush  = intel_fake_agp_chipset_flush,
 };
 
 static const struct agp_bridge_driver intel_915_driver = {
@@ -1314,7 +1320,7 @@ static const struct agp_bridge_driver intel_915_driver = {
.agp_alloc_pages= agp_generic_alloc_pages,
.agp_destroy_page   = agp_generic_destroy_page,
.agp_destroy_pages  = agp_generic_destroy_pages,
-   .chipset_flush  = intel_i915_chipset_flush,
+   .chipset_flush  = intel_fake_agp_chipset_flush,
 };
 
 static const struct agp_bridge_driver intel_i965_driver = {
@@ -1337,7 +1343,7 @@ static const struct agp_bridge_driver intel_i965_driver = 
{
.agp_alloc_pages= agp_generic_alloc_pages,
.agp_destroy_page   = agp_generic_destroy_page,
.agp_destroy_pages  = agp_generic_destroy_pages,
-   .chipset_flush  = intel_i915_chipset_flush,
+   .chipset_flush  = intel_fake_agp_chipset_flush,
 };
 
 static const struct agp_bridge_driver intel_gen6_driver = {
@@ -1360,7 +1366,7 @@ static const struct agp_bridge_driver intel_gen6_driver = 
{
.agp_alloc_pages= agp_generic_alloc_pages,
.agp_destroy_page   = agp_generic_destroy_page,
.agp_destroy_pages  = agp_generic_destroy_pages,
-   .chipset_flush  = intel_i915_chipset_flush,
+   .chipset_flush  = intel_fake_agp_chipset_flush,
 };
 
 static const struct agp_bridge_driver intel_g33_driver = {
@@ -1383,7 +1389,7 @@ static const struct agp_bridge_driver intel_g33_driver = {
.agp_alloc_pages= agp_generic_alloc_pages,
.agp_destroy_page   = agp_generic_destroy_page,
.agp_destroy_pages  = agp_generic_destroy_pages,
-   .chipset_flush  = intel_i915_chipset_flush,
+   .chipset_flush  = intel_fake_agp_chipset_flush,
 };
 
 static const struct intel_gtt_driver i81x_gtt_driver = {
@@ -1394,6 +1400,7 @@ static const struct intel_gtt_driver i8xx_gtt_driver = {
.setup = i830_setup,
.write_entry = i830_write_entry,
.check_flags = i830_check_flags,
+   .chipset_flush = i830_chipset_flush,
 };
 static const struct intel_gtt_driver i915_gtt_driver = {
.gen = 3,
@@ -1401,6 +1408,7 @@ static const struct intel_gtt_driver i915_gtt_driver = {
/* i945 is the last gpu to need phys mem (for overlay and cursors). */
.write_entry = i830_write_entry, 
.check_flags = i830_check_flags,
+   .chipset_flush = i9xx_chipset_flush,
 };
 static const struct intel_gtt_driver g33_gtt_driver = {
.gen = 3,
@@ -1408,6 +1416,7 @@ static const struct intel_gtt_driver g33_gtt_driver = {
.setup = i9xx_setup,
.write_entry = i965_write_entry,
.check_flags = i830_check_flags,
+

[Intel-gfx] [PATCH 14/17] agp: kill agp_(unmap|map)_memory

DMA remapping was only used by the intel-gtt driver. With that
code now folded into the driver, kill the agp generic support for
it.

Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/agp.h |3 ---
 drivers/char/agp/generic.c |8 
 2 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 04ad0bb..5259065 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -121,9 +121,6 @@ struct agp_bridge_driver {
void (*agp_destroy_pages)(struct agp_memory *);
int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
void (*chipset_flush)(struct agp_bridge_data *);
-
-   int (*agp_map_memory)(struct agp_memory *mem);
-   void (*agp_unmap_memory)(struct agp_memory *mem);
 };
 
 struct agp_bridge_data {
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index d2abf51..78235ce 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -437,11 +437,6 @@ int agp_bind_memory(struct agp_memory *curr, off_t 
pg_start)
curr-is_flushed = true;
}
 
-   if (curr-bridge-driver-agp_map_memory) {
-   ret_val = curr-bridge-driver-agp_map_memory(curr);
-   if (ret_val)
-   return ret_val;
-   }
ret_val = curr-bridge-driver-insert_memory(curr, pg_start, 
curr-type);
 
if (ret_val != 0)
@@ -483,9 +478,6 @@ int agp_unbind_memory(struct agp_memory *curr)
if (ret_val != 0)
return ret_val;
 
-   if (curr-bridge-driver-agp_unmap_memory)
-   curr-bridge-driver-agp_unmap_memory(curr);
-
curr-is_bound = false;
curr-pg_start = 0;
spin_lock(curr-bridge-mapped_lock);
-- 
1.7.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 17/17] intel-gtt add a cleanup function for chipset specific stuff

The old code didn't clean up the i830 chipset flush page. And it
looks nicer.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |   39 +++
 1 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index b0ba00c..616502b 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -76,6 +76,9 @@ struct intel_gtt_driver {
unsigned int dma_mask_size : 8;
/* Chipset specific GTT setup */
int (*setup)(void);
+   /* This should undo anything done in -setup() save the unmapping
+* of the mmio register file, that's done in the generic code. */
+   void (*cleanup)(void);
void (*write_entry)(dma_addr_t addr, unsigned int entry, unsigned int 
flags);
/* Flags is a more or less chipset specific opaque value.
 * For chipsets that need to support old ums (non-gem) code, this
@@ -733,12 +736,8 @@ static void intel_gtt_teardown_scratch_page(void)
 
 static void intel_gtt_cleanup(void)
 {
-   if (intel_private.i9xx_flush_page)
-   iounmap(intel_private.i9xx_flush_page);
-   if (intel_private.resource_valid)
-   release_resource(intel_private.ifp_resource);
-   intel_private.ifp_resource.start = 0;
-   intel_private.resource_valid = 0;
+   intel_private.driver-cleanup();
+
iounmap(intel_private.gtt);
iounmap(intel_private.registers);

@@ -769,6 +768,7 @@ static int intel_gtt_init(void)
intel_private.gtt = ioremap(intel_private.gtt_bus_addr,
gtt_map_size);
if (!intel_private.gtt) {
+   intel_private.driver-cleanup();
iounmap(intel_private.registers);
return -ENOMEM;
}
@@ -778,6 +778,7 @@ static int intel_gtt_init(void)
/* we have to call this as early as possible after the MMIO base 
address is known */
intel_private.base.gtt_stolen_entries = intel_gtt_stolen_entries();
if (intel_private.base.gtt_stolen_entries == 0) {
+   intel_private.driver-cleanup();
iounmap(intel_private.registers);
iounmap(intel_private.gtt);
return -ENOMEM;
@@ -811,7 +812,7 @@ static int intel_fake_agp_fetch_size(void)
return 0;
 }
 
-static void intel_i830_fini_flush(void)
+static void i830_cleanup(void)
 {
kunmap(intel_private.i8xx_page);
intel_private.i8xx_flush_page = NULL;
@@ -833,7 +834,7 @@ static void intel_i830_setup_flush(void)
 
intel_private.i8xx_flush_page = kmap(intel_private.i8xx_page);
if (!intel_private.i8xx_flush_page)
-   intel_i830_fini_flush();
+   i830_cleanup();
 }
 
 /* The chipset_flush interface needs to get data that has already been
@@ -1175,6 +1176,16 @@ static void intel_i9xx_setup_flush(void)
can't ioremap flush page - no chipset flushing\n);
 }
 
+static void i9xx_cleanup(void)
+{
+   if (intel_private.i9xx_flush_page)
+   iounmap(intel_private.i9xx_flush_page);
+   if (intel_private.resource_valid)
+   release_resource(intel_private.ifp_resource);
+   intel_private.ifp_resource.start = 0;
+   intel_private.resource_valid = 0;
+}
+
 static void i9xx_chipset_flush(void)
 {
if (intel_private.i9xx_flush_page)
@@ -1218,6 +1229,10 @@ static void gen6_write_entry(dma_addr_t addr, unsigned 
int entry,
writel(addr | pte_flags, intel_private.gtt + entry);
 }
 
+static void gen6_cleanup(void)
+{
+}
+
 static int i9xx_setup(void)
 {
u32 reg_addr;
@@ -1312,6 +1327,7 @@ static const struct intel_gtt_driver i81x_gtt_driver = {
 static const struct intel_gtt_driver i8xx_gtt_driver = {
.gen = 2,
.setup = i830_setup,
+   .cleanup = i830_cleanup,
.write_entry = i830_write_entry,
.dma_mask_size = 32,
.check_flags = i830_check_flags,
@@ -1320,6 +1336,7 @@ static const struct intel_gtt_driver i8xx_gtt_driver = {
 static const struct intel_gtt_driver i915_gtt_driver = {
.gen = 3,
.setup = i9xx_setup,
+   .cleanup = i9xx_cleanup,
/* i945 is the last gpu to need phys mem (for overlay and cursors). */
.write_entry = i830_write_entry, 
.dma_mask_size = 32,
@@ -1330,6 +1347,7 @@ static const struct intel_gtt_driver g33_gtt_driver = {
.gen = 3,
.is_g33 = 1,
.setup = i9xx_setup,
+   .cleanup = i9xx_cleanup,
.write_entry = i965_write_entry,
.dma_mask_size = 36,
.check_flags = i830_check_flags,
@@ -1339,6 +1357,7 @@ static const struct intel_gtt_driver pineview_gtt_driver 
= {
.gen = 3,
.is_pineview = 1, .is_g33 = 1,
.setup = i9xx_setup,
+   .cleanup = i9xx_cleanup,
.write_entry = i965_write_entry,
.dma_mask_size = 36,
.check_flags =

Re: [Intel-gfx] Using quirks to fix incorrect Monitor physical size