Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake vodoo

[Daniel Vetter]

On Wed, Jan 04, 2012 at 06:27:40PM -0800, Keith Packard wrote:
> On Wed,  4 Jan 2012 19:40:45 +0100, Daniel Vetter  
> wrote:
> 
> > Two things seem to do the trick on my ivb machine here:
> > - prevent the gt from powering down while waiting for seqno
> >   notification interrupts by grabbing the force_wake in get_irq (and
> >   dropping it in put_irq again).
> > - ordering writes from the ring's CS by reading a CS register, ACTHD
> >   seems to work.
> 
> If this works reliably, you'll deserve a medal...

I've removed the HWSTAM workaround on my branch and both my ivb and snb
seem to still work. So I'm still hopeful that this actually works ;-)

Ben promised to beat on it with his machines, too, but I fear Eric is way
too busy with the finishing touches for the OGL 3.0 frenzy atm.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake vodoo

[Eugeni Dodonov]

On Thu, Jan 5, 2012 at 09:13, Daniel Vetter  wrote:

> On Wed, Jan 04, 2012 at 06:27:40PM -0800, Keith Packard wrote:
> > On Wed,  4 Jan 2012 19:40:45 +0100, Daniel Vetter <
> daniel.vet...@ffwll.ch> wrote:
> >
> > > Two things seem to do the trick on my ivb machine here:
> > > - prevent the gt from powering down while waiting for seqno
> > >   notification interrupts by grabbing the force_wake in get_irq (and
> > >   dropping it in put_irq again).
> > > - ordering writes from the ring's CS by reading a CS register, ACTHD
> > >   seems to work.
> >
> > If this works reliably, you'll deserve a medal...
>
> I've removed the HWSTAM workaround on my branch and both my ivb and snb
> seem to still work. So I'm still hopeful that this actually works ;-)
>

Yep, it seems to work even without HWSTAM, I tried this too with base on
Ben's HWSTAM disabling patches.

So I think we have a winner :).

-- 
Eugeni Dodonov

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

Re: [Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

[Daniel Vetter]

On Wed, Jan 04, 2012 at 06:22:41PM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 19:12:57 +0100, Daniel Vetter  wrote:
> 
> > The "Correct?" was just to check my understanding of your concern, I still
> > think its invalid. You've cut away the second part of my mail where I
> > explain why and I don't see you responding to that here. Also
> > micro-optimizing the gpu reset code sounds a bit strange.
> 
> Sorry, I didn't explain things very well.
> 
> Right now, our register access looks like:
> 
> get(struct_mutex);
> if (++forcewake_count == 1)
> force_wake_get()
> 
> value = read32(reg) or  write32(reg, val)
> 
> if (--forcewake_count == 0)
> force_wake_put();
> 
> /* more register accesses may follow ... */
> put(struct_mutex);
> 
> All very sensible, the whole register sequence is covered by
> struct_mutex, which ensures that the forcewake is set across the
> register access.
> 
> The patch does:
> 
> get(spin_lock)
> if (++forcewake_count == 1)
> force_wake_get()
> put(spin_lock)
> value = read32(reg) or write32(reg, val)
> get(spin_lock)
> if (--forcewake_count == 0)
> force_wake_put()
> put(spin_lock)
> 
> I realize that all current users hold the struct_mutex across this whole
> sequence, aside from the reset path, but we're removing that requirement
> explicitly (the patch removes the WARN_ON calls).
> 
> Without a lock held across the whole sequence, it's easy to see how a
> race could occur. We're also dropping and re-acquiring a spinlock with a
> single instruction between, which seems wasteful. Instead, we should be
> doing:
> 
> get(spin_lock)
> force_wake_get();
> value = read32(reg) or  write32(reg,val)
> force_wake_put();
> put(spin_lock);
> 
> No need here to deal with the wake lock at reset time; the whole
> operation is atomic wrt interrupts. It's more efficient *and* correct,
> without depending on the old struct_mutex locking.
> 
> If you want to continue to expose the user-mode wake lock stuff, you
> could add:
> 
> get(spin_lock);
> if (!forcewake_count)
> force_wake_get();
> value = read32(reg) or  write32(reg,val)
> if (!forcewake_count)
> force_wake_put();
> put(spin_lock);
> 
> This would require that the reset code also deal with the
> forcewake_count to restore the user-mode force wake.
> 
> A further optimization would hold the force_wake active for 'a while' to
> avoid the extra bus cycles required, but we'd want to see a performance
> problem from this before doing that.

I think you've lost me ... A few random comments first, it looks like I
neeed more coffee:

- The reset code (running from a workqueue) does hold sturct mutex. It's
  the hangcheck and error state capture code running from softirq/timer
  context causing issues.

- Forcewake works like a reference counted resources. As long as all
  _get/_put calls are properly balanced, I don't see how somebody could
  sneak in in between (when we don't hold the spinlock) and cause havoc.
  For paranaoia we might want to drop a WARN_ON in the _put call to check
  whether it ever drops below 0. But all current users are clearly
  balanced, so I didn't bother with it.

- My missed IRQ w/a actually relies on this by grabbing a forcewake ref in
  get_irq and dropping it again in put_irq. In between there's usually a
  schedule().

- I've pondered with Chris whether we should do your proposed optimization
  but we then noticed that the gem code doesn't actually read from any
  forcewake protected registers in normal execution (I don't consider
  running the hangcheck timer normal ;-). With my missed irq w/a that now
  changes, so we might need to reconsider this. But imo that's material
  for a separate patch.

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

[Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Eugeni Dodonov]

This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.

Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.

This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).

Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s

Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s

Reviewed-by: Chris Wilson 
Reviewed-by: Keith Packard 
Tested-by: Sean Finney 
Tested-by: Soren Hansen 
Tested-by: Hernando Torque 
Tested-by: Mike Lothian 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov 
---
 drivers/gpu/drm/drm_edid.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3e927ce..fb6c26c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
}
};
ret = i2c_transfer(adapter, msgs, 2);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
+   adapter->name);
+   break;
+   }
} while (ret != 2 && --retries);
 
return ret == 2 ? 0 : -1;
-- 
1.7.8

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

[Intel-gfx] [PATCH 2/2] drm/i915: there is no pipe CxSR on ironlake

[Eugeni Dodonov]

After checking the specs and discussing with Jesse, turns out CxSR is not
available on Ironlake and gen5, and its advertisement on the device
description is misleading.

Acked-by: Jesse Barnes 
Signed-off-by: Eugeni Dodonov 
---
 drivers/gpu/drm/i915/i915_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a1103fc..4795edd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -198,7 +198,7 @@ static const struct intel_device_info intel_pineview_info = 
{
 
 static const struct intel_device_info intel_ironlake_d_info = {
.gen = 5,
-   .need_gfx_hws = 1, .has_pipe_cxsr = 1, .has_hotplug = 1,
+   .need_gfx_hws = 1, .has_hotplug = 1,
.has_bsd_ring = 1,
 };
 
-- 
1.7.8

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

Re: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Daniel Vetter]

On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-responding bus repeatedly until we
> finally timeout after 15 attempts. We can do this by catching the -ENXIO
> error, provided by i2c_algo_bit:bit_doAddress call.
> 
> Within the bit_doAddress we already try 3 times to get the edid data, so
> if the routine tells us that bus is not responding, it is mostly pointless
> to keep re-trying those attempts over and over again until we reach final
> number of retries.
> 
> This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
> and improve overall edid detection timing by 10-30% in most cases, and by
> a much larger margin in case of phantom outputs (up to 30x in one worst
> case).
> 
> Timing results for i915-powered machines for 'time xrandr' command:
> Machine 1: from 0.840s to 0.290s
> Machine 2: from 0.315s to 0.280s
> Machine 3: from +/- 4s to 0.184s
> 
> Timing results for HD5770 with 'time xrandr' command:
> Machine 4: from 3.210s to 1.060s
> 
> Reviewed-by: Chris Wilson 
> Reviewed-by: Keith Packard 
> Tested-by: Sean Finney 
> Tested-by: Soren Hansen 
> Tested-by: Hernando Torque 
> Tested-by: Mike Lothian 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
> Signed-off-by: Eugeni Dodonov 

Imo it's too late for such a change with decent potential to blow up to
land in 3.3. I think this needs some decent shakeout time in Dave's
drm-next tree (despite all r-b's and tested-bys it already gathered) and
hence is imo 3.4 material at this stage.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Atom 2000 series

[Jeffrey Moore]

Does anyone know if the latest Intel Linux graphics driver supports the new 
Atom 2000 series (cedar trail / cedar view) for GL and video acceleration?

Jeff





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

Re: [Intel-gfx] Atom 2000 series

[Adam Jackson]

On Thu, 2012-01-05 at 09:50 -0500, Jeffrey Moore wrote:
> Does anyone know if the latest Intel Linux graphics driver supports
> the new Atom 2000 series (cedar trail / cedar view) for GL and video
> acceleration?

That's a Poulsbo-like chip, so, no.  Intel insists on licensing that
chip design from Imagination, who don't like open source.

Feel free to let Intel know how you feel about their commitment to open
source driver support for their hardware, of course, but please do so in
a more appropriate forum (your sales rep, for instance).  The people on
this list are only responsible for gen-series graphics chips.

- ajax


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] [PULL] drm-intel-next

[Daniel Vetter]

On Wed, Jan 04, 2012 at 07:35:41PM -0800, Keith Packard wrote:
> 
> Here are the rest of the 3.3 pending changes.
> 
> This has a bunch of small bug fixes and overlay plane support for i915.
> 
> The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60:
> 
>   Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next 
> (2012-01-03 09:45:12 +)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-next

I'm not happy with Eric's missed IRQ workaround because
- it's incomplete, the BSD ring is similarly affected by these issues like
  the blitter ring, but not handled by his patches.
- it does a busy-loop wait until the gpu signals completion - in normal
  useage this can easily be a few msecs, especially since now semaphores
  are enabled by defailt on Ivybridge. With offscreen benchmarking it can
  easily reach seconds. This is imo unacceptable.

Furthermore
- Chris Wilson proposed an alternative approach quite a bit before these
  patches have been created that combines the irq signalling path with a
  short timer as a backup. This works really well because we only rarely
  miss irqs. See
  Message-Id: <1323978198-3501-1-git-send-email-ch...@chris-wilson.co.uk>
- Meanwhile I've discovered a magic set of tricks that seem to completely
  solve missed irq issues on both ivb and snb. This would render all this
  ducttape irrelevant.

Imo the minimal right thing to do is to revert the patch "drm/i915: Make
the fallback IRQ wait not sleep". This will regress piglit throughput (and
anything else stupid enough to crazily ping-pong between the gpu and cpu)
quite a bit, but honestly that's not something our userbase cares about.

I'd also like to express my frustration with the general -next process for
drm/i915:
- This drm-intel-next tree is less than 24h ours old (if you look at when
  it showed up at an official place where both our QA and the community
  can pick it up and test it). I fear we'll ship yet another disaster like
  the stack eating bug the vt-d/ilk w/a patch caused with an unbounded
  recursion. Our QA actually caught it in testing, but there was simply
  not enough time to fix things up before the buggy code landed in -linus.
- Because the drm-intel-next merge cycle started so late there has simply
  not been enough time to include quite a few bugfixes for serious issues
  like 20s delays in intial modeset, userspace-triggerable kernel OOPSes
  and deadlocks and reproducible hard hw hangs. For most of these there
  are testcases in intel-gpu-tools, and these issues span the entire set
  of hw generations drm/i915 currently supports. But this late it's imo
  no longer advisible to merge them, so we'll ship 3.3 with a bunch of
  known (and sometimes longstanding) serious issues that have fixes.

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

Re: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Eugeni Dodonov]

On Thu, Jan 5, 2012 at 12:43, Daniel Vetter  wrote:

> On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
> > This allows to avoid talking to a non-responding bus repeatedly until we
> > finally timeout after 15 attempts. We can do this by catching the -ENXIO
> > error, provided by i2c_algo_bit:bit_doAddress call.
> >
> > Within the bit_doAddress we already try 3 times to get the edid data, so
> > if the routine tells us that bus is not responding, it is mostly
> pointless
> > to keep re-trying those attempts over and over again until we reach final
> > number of retries.
> >
> > This change should fix
> https://bugs.freedesktop.org/show_bug.cgi?id=41059
> > and improve overall edid detection timing by 10-30% in most cases, and by
> > a much larger margin in case of phantom outputs (up to 30x in one worst
> > case).
> >
> > Timing results for i915-powered machines for 'time xrandr' command:
> > Machine 1: from 0.840s to 0.290s
> > Machine 2: from 0.315s to 0.280s
> > Machine 3: from +/- 4s to 0.184s
> >
> > Timing results for HD5770 with 'time xrandr' command:
> > Machine 4: from 3.210s to 1.060s
> >
> > Reviewed-by: Chris Wilson 
> > Reviewed-by: Keith Packard 
> > Tested-by: Sean Finney 
> > Tested-by: Soren Hansen 
> > Tested-by: Hernando Torque 
> > Tested-by: Mike Lothian 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
> > Signed-off-by: Eugeni Dodonov 
>
> Imo it's too late for such a change with decent potential to blow up to
> land in 3.3. I think this needs some decent shakeout time in Dave's
> drm-next tree (despite all r-b's and tested-bys it already gathered) and
> hence is imo 3.4 material at this stage.
>

I'd be happy to include it into any kernel out there, 3.4 would be fine. I
originally sent it for 3.1 merge though, and so far it haven't been picked
up by any tree. So I am a bit lost about what to do with this next, besides
re-sending the same patch over and over again...

-- 
Eugeni Dodonov

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

Re: [Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

[Keith Packard]

On Thu, 5 Jan 2012 12:29:08 +0100, Daniel Vetter  wrote:

> - The reset code (running from a workqueue) does hold sturct mutex. It's
>   the hangcheck and error state capture code running from softirq/timer
>   context causing issues.

Right, I mis-wrote; I meant the hangcheck timer (which I always think of
as part of the reset code).

> - Forcewake works like a reference counted resources. As long as all
>   _get/_put calls are properly balanced, I don't see how somebody could
>   sneak in in between (when we don't hold the spinlock) and cause havoc.
>   For paranaoia we might want to drop a WARN_ON in the _put call to check
>   whether it ever drops below 0. But all current users are clearly
>   balanced, so I didn't bother with it.

Right, I was just confused somehow. Still seems weird to me to drop a
spinlock, execute a single instruction, and then immediately re-acquire
it, along with bumping forcewake_count twice.

> - My missed IRQ w/a actually relies on this by grabbing a forcewake ref in
>   get_irq and dropping it again in put_irq. In between there's usually a
>   schedule().

This is essentially the same as the user-level forcewake and would be
handled in the same way -- keep forcewake_count, but use it only for
long-term values.

> - I've pondered with Chris whether we should do your proposed optimization
>   but we then noticed that the gem code doesn't actually read from any
>   forcewake protected registers in normal execution (I don't consider
>   running the hangcheck timer normal ;-). With my missed irq w/a that now
>   changes, so we might need to reconsider this. But imo that's material
>   for a separate patch.

Yeah, all sounds reasonable. That separate patch can actually use
per-chip functions to read/write from the chip so we can also avoid
checking the forcewake stuff on register reads for older generation
hardware.

Make it work, then make it work faster.

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


pgpIwsiibUbiB.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Keith Packard]

On Thu, 5 Jan 2012 13:37:50 -0200, Eugeni Dodonov  wrote:

> I'd be happy to include it into any kernel out there, 3.4 would be fine. I
> originally sent it for 3.1 merge though, and so far it haven't been picked
> up by any tree. So I am a bit lost about what to do with this next, besides
> re-sending the same patch over and over again...

I'll stick it in drm-intel-next, once Dave pulls for 3.3.

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


pgpNJqCdTcHmp.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[przanoni]

From: Paulo Zanoni 

This ioctl is used to signal the drivers that the screen is rotated,
not to make the drivers rotate the screen.
 - add a driver-specific "rotation_set" function
 - implement Intel's rotation_set by setting the right values to the
   PIPECONF registers.

The idea is that when user-space does rotation, it can call this ioctl
to inform the Kernel that we have a rotation. This feature is needed
by the KVMr feature of VPro.

Signed-off-by: Paulo Zanoni 
---

Hi

We need this feature for the KVMr feature of VPro. I'm not sure how useful this
will be for the non-Intel drivers, so maybe the current approach is not the
best. I'm open to suggestions.

I also have a patch to libdrm that just implements a wrapper for the ioctl
(drmModeCrtcSetRotation) and a patch for xf86-video-intel that callss the libdrm
function whenever needed.

I already have the libdrm and xf86-video-intel patches (they're simple) but I'll
wait until I get some comments on this one before I send the others.

 drivers/gpu/drm/drm_crtc.c   |   28 
 drivers/gpu/drm/drm_drv.c|3 ++-
 drivers/gpu/drm/i915/i915_reg.h  |5 +
 drivers/gpu/drm/i915/intel_display.c |   34 ++
 include/drm/drm.h|2 ++
 include/drm/drm_crtc.h   |8 +++-
 include/drm/drm_mode.h   |   15 +++
 7 files changed, 93 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f259a25..4a33ea1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3125,6 +3125,34 @@ out:
return ret;
 }
 
+int drm_crtc_rotation_set_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_mode_crtc_rotation *rotation = data;
+   struct drm_mode_object *obj;
+   struct drm_crtc *crtc;
+   int ret = 0;
+
+   DRM_DEBUG_KMS("changing rotation to %d\n", rotation->rotation);
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(&dev->mode_config.mutex);
+   obj = drm_mode_object_find(dev, rotation->crtc_id, 
DRM_MODE_OBJECT_CRTC);
+   if (!obj) {
+   ret = -EINVAL;
+   goto out;
+   }
+   crtc = obj_to_crtc(obj);
+
+   if (crtc->funcs->rotation_set)
+   crtc->funcs->rotation_set(crtc, rotation->rotation);
+out:
+   mutex_unlock(&dev->mode_config.mutex);
+   return ret;
+}
+
 int drm_mode_page_flip_ioctl(struct drm_device *dev,
 void *data, struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index bc5febe..ba0dac1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -159,7 +159,8 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETROTATION, drm_crtc_rotation_set_ioctl, 
DRM_MASTER|DRM_UNLOCKED)
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 194d987..3d9d46e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2323,6 +2323,11 @@
 #define   PIPECONF_INTERLACE_FIELD_0_ONLY  (7 << 21)
 #define   PIPECONF_INTERLACE_MASK  (7 << 21)
 #define   PIPECONF_CXSR_DOWNCLOCK  (1<<16)
+#define   PIPECONF_ROTATION_MASK   (3 << 14)
+#define   PIPECONF_ROTATION_0  (0 << 14)
+#define   PIPECONF_ROTATION_90 (1 << 14)
+#define   PIPECONF_ROTATION_180(2 << 14)
+#define   PIPECONF_ROTATION_270(3 << 14)
 #define   PIPECONF_BPP_MASK(0x00e0)
 #define   PIPECONF_BPP_8   (0<<5)
 #define   PIPECONF_BPP_10  (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 55a5b4c..08780f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6317,6 +6317,39 @@ static void intel_crtc_gamma_set(struct drm_crtc *crtc, 
u16 *red, u16 *green,
intel_crtc_load_lut(crtc);
 }
 
+static void intel_crtc_rotation_set(struct drm_crtc *crtc,
+   enum drm_crtc_rotation rotation)
+{
+   struct drm_device *dev = crtc->dev;
+   struct 

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Daniel Vetter]

On Thu, Jan 05, 2012 at 02:16:23PM -0200, przan...@gmail.com wrote:
> From: Paulo Zanoni 
> 
> This ioctl is used to signal the drivers that the screen is rotated,
> not to make the drivers rotate the screen.
>  - add a driver-specific "rotation_set" function
>  - implement Intel's rotation_set by setting the right values to the
>PIPECONF registers.
> 
> The idea is that when user-space does rotation, it can call this ioctl
> to inform the Kernel that we have a rotation. This feature is needed
> by the KVMr feature of VPro.
> 
> Signed-off-by: Paulo Zanoni 

Quick comments before I dig into this:
- Please post at least a link to the userspace patches, so that it's
  possible to check how this all fits together
- Please separate the generic infrastructre in drm from the changes to
  support this in i915. I know, this is a rather small feature, but still.

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

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Paulo Zanoni]

Hi

2012/1/5 Daniel Vetter :
> - Please post at least a link to the userspace patches, so that it's
>  possible to check how this all fits together

libdrm: 
http://people.freedesktop.org/~pzanoni/0001-Implement-drmModeCrtcSetRotation.patch
xf86-video-intel:
http://people.freedesktop.org/~pzanoni/0001-Call-drmModeCrtcSetRotation-after-we-apply-the-crtc-.patch

> - Please separate the generic infrastructre in drm from the changes to
>  support this in i915. I know, this is a rather small feature, but still.

Will do, but I'll wait for more reviews/comments first.

Cheers,
Paulo

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

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Chris Wilson]

On Thu,  5 Jan 2012 14:16:23 -0200, przan...@gmail.com wrote:
> From: Paulo Zanoni 
> 
> This ioctl is used to signal the drivers that the screen is rotated,
> not to make the drivers rotate the screen.
>  - add a driver-specific "rotation_set" function
>  - implement Intel's rotation_set by setting the right values to the
>PIPECONF registers.
> 
> The idea is that when user-space does rotation, it can call this ioctl
> to inform the Kernel that we have a rotation. This feature is needed
> by the KVMr feature of VPro.

I'm interested to see how the fb is laid out in memory and how does this
integrate with mode configuration?

Comment inline.

> +int drm_crtc_rotation_set_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_mode_crtc_rotation *rotation = data;
> + struct drm_mode_object *obj;
> + struct drm_crtc *crtc;
> + int ret = 0;
> +
> + DRM_DEBUG_KMS("changing rotation to %d\n", rotation->rotation);
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + mutex_lock(&dev->mode_config.mutex);
> + obj = drm_mode_object_find(dev, rotation->crtc_id, 
> DRM_MODE_OBJECT_CRTC);
> + if (!obj) {
> + ret = -EINVAL;
> + goto out;
> + }
> + crtc = obj_to_crtc(obj);
> +
> + if (crtc->funcs->rotation_set)
> + crtc->funcs->rotation_set(crtc, rotation->rotation);

In the absence of an implementation, return ENOTTY, otherwise return an
error code from crtc->rotation_set(). Then userspace can simply try to
set a rotation or take the same recovery paths for unsupported
configuations/kernels.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

[Daniel Vetter]

Looks like we managed to clear up our mutual confusion here ;-)

On Thu, Jan 05, 2012 at 07:49:12AM -0800, Keith Packard wrote:
> On Thu, 5 Jan 2012 12:29:08 +0100, Daniel Vetter  wrote:
> 
> > - The reset code (running from a workqueue) does hold sturct mutex. It's
> >   the hangcheck and error state capture code running from softirq/timer
> >   context causing issues.
> 
> Right, I mis-wrote; I meant the hangcheck timer (which I always think of
> as part of the reset code).
> 
> > - Forcewake works like a reference counted resources. As long as all
> >   _get/_put calls are properly balanced, I don't see how somebody could
> >   sneak in in between (when we don't hold the spinlock) and cause havoc.
> >   For paranaoia we might want to drop a WARN_ON in the _put call to check
> >   whether it ever drops below 0. But all current users are clearly
> >   balanced, so I didn't bother with it.
> 
> Right, I was just confused somehow. Still seems weird to me to drop a
> spinlock, execute a single instruction, and then immediately re-acquire
> it, along with bumping forcewake_count twice.

Absolutely agreed, it's really ugly. But especially for locking changes
I'd like a patch to do one thing, and one thing only. And I didn't see the
upside of a separate patch to fix things up, also because the current
I915_WRTE|READ macro maze is a bit hellish.

> > - My missed IRQ w/a actually relies on this by grabbing a forcewake ref in
> >   get_irq and dropping it again in put_irq. In between there's usually a
> >   schedule().
> 
> This is essentially the same as the user-level forcewake and would be
> handled in the same way -- keep forcewake_count, but use it only for
> long-term values.
> 
> > - I've pondered with Chris whether we should do your proposed optimization
> >   but we then noticed that the gem code doesn't actually read from any
> >   forcewake protected registers in normal execution (I don't consider
> >   running the hangcheck timer normal ;-). With my missed irq w/a that now
> >   changes, so we might need to reconsider this. But imo that's material
> >   for a separate patch.
> 
> Yeah, all sounds reasonable. That separate patch can actually use
> per-chip functions to read/write from the chip so we can also avoid
> checking the forcewake stuff on register reads for older generation
> hardware.
> 
> Make it work, then make it work faster.

Absolutely agreed, maybe with the adadendum to only try to make things
faster if it's actually a problem and shows up in a fast-path we care
about.

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

Re: [Intel-gfx] [PULL] drm-intel-next

[Ben Widawsky]

On 01/05/2012 07:24 AM, Daniel Vetter wrote:

On Wed, Jan 04, 2012 at 07:35:41PM -0800, Keith Packard wrote:


Here are the rest of the 3.3 pending changes.

This has a bunch of small bug fixes and overlay plane support for i915.

The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60:

   Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next 
(2012-01-03 09:45:12 +)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-next


I'm not happy with Eric's missed IRQ workaround because
- it's incomplete, the BSD ring is similarly affected by these issues like
   the blitter ring, but not handled by his patches.
- it does a busy-loop wait until the gpu signals completion - in normal
   useage this can easily be a few msecs, especially since now semaphores
   are enabled by defailt on Ivybridge. With offscreen benchmarking it can
   easily reach seconds. This is imo unacceptable.

Furthermore
- Chris Wilson proposed an alternative approach quite a bit before these
   patches have been created that combines the irq signalling path with a
   short timer as a backup. This works really well because we only rarely
   miss irqs. See
   Message-Id:<1323978198-3501-1-git-send-email-ch...@chris-wilson.co.uk>
- Meanwhile I've discovered a magic set of tricks that seem to completely
   solve missed irq issues on both ivb and snb. This would render all this
   ducttape irrelevant.

Imo the minimal right thing to do is to revert the patch "drm/i915: Make
the fallback IRQ wait not sleep". This will regress piglit throughput (and
anything else stupid enough to crazily ping-pong between the gpu and cpu)
quite a bit, but honestly that's not something our userbase cares about.

I'd also like to express my frustration with the general -next process for
drm/i915:
- This drm-intel-next tree is less than 24h ours old (if you look at when
   it showed up at an official place where both our QA and the community
   can pick it up and test it). I fear we'll ship yet another disaster like
   the stack eating bug the vt-d/ilk w/a patch caused with an unbounded
   recursion. Our QA actually caught it in testing, but there was simply
   not enough time to fix things up before the buggy code landed in -linus.
- Because the drm-intel-next merge cycle started so late there has simply
   not been enough time to include quite a few bugfixes for serious issues
   like 20s delays in intial modeset, userspace-triggerable kernel OOPSes
   and deadlocks and reproducible hard hw hangs. For most of these there
   are testcases in intel-gpu-tools, and these issues span the entire set
   of hw generations drm/i915 currently supports. But this late it's imo
   no longer advisible to merge them, so we'll ship 3.3 with a bunch of
   known (and sometimes longstanding) serious issues that have fixes.

Yours, Daniel


I'd like to echo my concerns regarding late merging and therefore lack 
of QA testing. I ended up looking like quite the fool last time around, 
and that would have been prevented with QA testing of intel-gpu-tools.


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

Re: [Intel-gfx] [PULL] drm-intel-next

[Jesse Barnes]

On Thu, 5 Jan 2012 16:24:08 +0100
Daniel Vetter  wrote:
> I'd also like to express my frustration with the general -next process for
> drm/i915:
> - This drm-intel-next tree is less than 24h ours old (if you look at when
>   it showed up at an official place where both our QA and the community
>   can pick it up and test it). I fear we'll ship yet another disaster like
>   the stack eating bug the vt-d/ilk w/a patch caused with an unbounded
>   recursion. Our QA actually caught it in testing, but there was simply
>   not enough time to fix things up before the buggy code landed in -linus.
> - Because the drm-intel-next merge cycle started so late there has simply
>   not been enough time to include quite a few bugfixes for serious issues
>   like 20s delays in intial modeset, userspace-triggerable kernel OOPSes
>   and deadlocks and reproducible hard hw hangs. For most of these there
>   are testcases in intel-gpu-tools, and these issues span the entire set
>   of hw generations drm/i915 currently supports. But this late it's imo
>   no longer advisible to merge them, so we'll ship 3.3 with a bunch of
>   known (and sometimes longstanding) serious issues that have fixes.

Yeah I have to second this and additionally complain about the patch
lossiness & latency.  Part of this is my fault for not reviewing things
as much as I should, but those reviews often get lost too...

Eugeni's i2c patches are a good example.  They've been out there since
early Oct, have received review and testing, and should have been in
-next for many months now (in previous releases!).

What can we do to improve the process to get trees updated more
regularly and get fixes integrated faster?

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


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

[Intel-gfx] panning support

[Bob Tennent]

I'm about to buy a new system with "Intel HD graphics 2000" integrated
in the CPU. Will xrandr panning be supported? The server version will be

xorg-x11-drv-intel-2.14.0

on a Centos 6.1 system.

In general, how does one discover which versions of Intel integrated
graphics support panning? I have a Lenovo laptop that does and desktop
systems that don't.

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

Re: [Intel-gfx] panning support

[Adam Jackson]

On Thu, 2012-01-05 at 15:42 -0500, Bob Tennent wrote:

> I'm about to buy a new system with "Intel HD graphics 2000" integrated
> in the CPU. Will xrandr panning be supported? The server version will be
> 
> xorg-x11-drv-intel-2.14.0
> 
> on a Centos 6.1 system.
> 
> In general, how does one discover which versions of Intel integrated
> graphics support panning? I have a Lenovo laptop that does and desktop
> systems that don't.

The intel driver supports panning for all chips it supports (excluding
the ancient i810 series I suppose).  If you're seeing variation among
chips it's because you're not running the same driver [1].

RHEL 6.1 includes support for Sandybridge chips, which is the useful
name corresponding to "HD Graphics 2000".  CentOS presumably does too if
they haven't broken what I put in RHEL.

[1] - or, in the extreme case, you're running a pre-RANDR-1.3 X server.

- ajax


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] drm/i915: rip out the HWSTAM missed irq workaround

[Daniel Vetter]

With the new ducttape of much finer quality, this seems to be no
longer necessary.

Tested on my ivb and snb machine with the usual suspects of testcases.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c |   11 ---
 1 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b9ba180..af54153 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1779,17 +1779,6 @@ static void ironlake_irq_preinstall(struct drm_device 
*dev)
INIT_WORK(&dev_priv->rps_work, gen6_pm_rps_work);
 
I915_WRITE(HWSTAM, 0xeffe);
-   if (IS_GEN6(dev) || IS_GEN7(dev)) {
-   /* Workaround stalls observed on Sandy Bridge GPUs by
-* making the blitter command streamer generate a
-* write to the Hardware Status Page for
-* MI_USER_INTERRUPT.  This appears to serialize the
-* previous seqno write out before the interrupt
-* happens.
-*/
-   I915_WRITE(GEN6_BLITTER_HWSTAM, ~GEN6_BLITTER_USER_INTERRUPT);
-   I915_WRITE(GEN6_BSD_HWSTAM, ~GEN6_BSD_USER_INTERRUPT);
-   }
 
/* XXX hotplug from PCH */
 
-- 
1.7.7.3

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

Re: [Intel-gfx] [PATCH] drm/i915: rip out the HWSTAM missed irq workaround

[Ben Widawsky]

On Thu, Jan 05, 2012 at 11:11:53PM +0100, Daniel Vetter wrote:
> With the new ducttape of much finer quality, this seems to be no
> longer necessary.
> 
> Tested on my ivb and snb machine with the usual suspects of testcases.
> 
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_irq.c |   11 ---
>  1 files changed, 0 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b9ba180..af54153 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1779,17 +1779,6 @@ static void ironlake_irq_preinstall(struct drm_device 
> *dev)
>   INIT_WORK(&dev_priv->rps_work, gen6_pm_rps_work);
>  
>   I915_WRITE(HWSTAM, 0xeffe);
> - if (IS_GEN6(dev) || IS_GEN7(dev)) {
> - /* Workaround stalls observed on Sandy Bridge GPUs by
> -  * making the blitter command streamer generate a
> -  * write to the Hardware Status Page for
> -  * MI_USER_INTERRUPT.  This appears to serialize the
> -  * previous seqno write out before the interrupt
> -  * happens.
> -  */
> - I915_WRITE(GEN6_BLITTER_HWSTAM, ~GEN6_BLITTER_USER_INTERRUPT);
> - I915_WRITE(GEN6_BSD_HWSTAM, ~GEN6_BSD_USER_INTERRUPT);
> - }
>  
>   /* XXX hotplug from PCH */
>  


I'd prefer just reverting the old commits instead of this, but that's
just me.

Reviewed-and-Tested-by: Ben Widawsky 


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

Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake vodoo

[Ben Widawsky]

On Wed, Jan 04, 2012 at 05:52:10PM +0100, Daniel Vetter wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
>   notification interrupts by grabbing the force_wake in get_irq (and
>   dropping it in put_irq again).
> - ordering writes from the ring's CS by reading a CS register, ACTHD
>   seems to work.
> 
> Only the blt&bsd ring on ivb seem to be massively affected by this,
> but for paranoia do this dance also on the render ring and on snb
> (i.e. all gpus with forcewake).
> 
> Tested with Eric's glCopyPixels loop which without this patch scores a
> missed irq every few seconds.
> 
> This patch needs my forcewake rework to use a spinlock instead of
> dev->struct_mutex.
> 
> Cc: sta...@kernel.org
> Cc: Eric Anholt 
> Cc: Kenneth Graunke 
> Cc: Eugeni Dodonov 
> Signed-Off-by: Daniel Vetter 
Reviewed-and-Tested-by: Ben Widawsky 


Please please please make it clear that we still don't understand exactly why
this works.

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

Re: [Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

[Keith Packard]

On Thu, 5 Jan 2012 17:59:47 +0100, Daniel Vetter  wrote:

> Absolutely agreed, maybe with the adadendum to only try to make things
> faster if it's actually a problem and shows up in a fast-path we care
> about.

Here's a longer series that does a bunch of cleanup before trying to fix
things. Patches marked with '***' fix bugs. The patch marked with '...'
is the optimization to inline the spinlocks.

The following changes since commit d8e70a254d8f2da141006e496a51502b79115e80:

  drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeeded 
(2012-01-03 14:55:52 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux forcewake-spinlock

Keith Packard (9):

  drm/i915: Split register access functions out from display functions

The forcewake functions are invoked unconditionally on >= gen6
hardware from the register read/write functions. Having these
initialized as a side-effect of display initialization seems
wrong to me. I've moved the functions out of the display
structure and into a separate structure, and moved the
initialization to driver load time.

  drm/i915: Access registers through function pointers

This makes register access go through function pointers,
following similar changes in many other parts of the driver.

  drm/i915: Split out reg read/write for pre/post gen6 hardware

Taking advantage of the previous indirection, this actually
creates separate register read/write functions for pre-gen6 and
post-gen6 hardware.

  drm/i915: Move forcewake_count to reg_access structure

Just moves the count into the new structure to keep things
together.

  drm/i915: hide forcewake_count behind i915_forcewake_count

Create a function to hide getting the forcewake_count value

  drm/i915: Switch forcewake from atomic to using a spinlock

This changes the type from atomic to u32 and wraps all users in
a new spinlock. The spinlock is held across calls to
->force_wake_put and ->force_wake_get.

***   drm/i915: Hold forcewake spinlock across reset process

Changes the reset process to hold the spinlock -- this will
ensure that all register operations will be correct wrt the
spinlock, even if the hardware gets reset.

***   drm/i915: Hold forcewake spinlock during register write operations

This protects the gt_fifo_count value under the spinlock and
keeps modifications to that tied to the actual register write.

...   drm/i915: inline spin_lock usage in register read macros

Here's the optimization I mentioned -- inlines the spinlocks
inside the register read operations.

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


pgpO1LijxUca4.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Eric Anholt]

On Thu,  5 Jan 2012 14:16:23 -0200, przan...@gmail.com wrote:
> From: Paulo Zanoni 
> 
> This ioctl is used to signal the drivers that the screen is rotated,
> not to make the drivers rotate the screen.
>  - add a driver-specific "rotation_set" function
>  - implement Intel's rotation_set by setting the right values to the
>PIPECONF registers.
> 
> The idea is that when user-space does rotation, it can call this ioctl
> to inform the Kernel that we have a rotation. This feature is needed
> by the KVMr feature of VPro.

So am I following this right, that these register bits are used to
communicate from one piece of software to another piece of software,
across the virtualization boundary?


pgphFuPQ6gCjO.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: add an "off-dvi" HDMI audio mode

[Wu Fengguang]

Andrea,

Would you test this patch at convenient time?

Thanks,
Fengguang

---
Subject: drm/i915: add an "off-dvi" HDMI audio mode
Date: Fri Jan 06 11:04:00 CST 2012

When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new "off-dvi" audio mode:

xrandr --output HDMI1 --set audio off-dvi

Reported-by: Andrea Arcangeli 
Signed-off-by: Wu Fengguang 
---
 drivers/gpu/drm/i915/i915_drv.h|7 +++
 drivers/gpu/drm/i915/intel_hdmi.c  |8 +---
 drivers/gpu/drm/i915/intel_modes.c |4 +++-
 3 files changed, 15 insertions(+), 4 deletions(-)

--- linux.orig/drivers/gpu/drm/i915/i915_drv.h  2011-12-22 10:53:26.0 
+0800
+++ linux/drivers/gpu/drm/i915/i915_drv.h   2012-01-06 11:20:03.0 
+0800
@@ -736,6 +736,13 @@ typedef struct drm_i915_private {
atomic_t forcewake_count;
 } drm_i915_private_t;
 
+enum hdmi_force_audio {
+   HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
+   HDMI_AUDIO_OFF, /* force turn off HDMI audio */
+   HDMI_AUDIO_AUTO,/* trust EDID */
+   HDMI_AUDIO_ON,  /* force turn on HDMI audio */
+};
+
 enum i915_cache_level {
I915_CACHE_NONE,
I915_CACHE_LLC,
--- linux.orig/drivers/gpu/drm/i915/intel_hdmi.c2011-12-22 
10:53:27.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_hdmi.c 2012-01-06 11:03:56.0 
+0800
@@ -335,7 +335,9 @@ intel_hdmi_detect(struct drm_connector *
if (edid) {
if (edid->input & DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
-   intel_hdmi->has_hdmi_sink = 
drm_detect_hdmi_monitor(edid);
+   if (intel_hdmi->force_audio != HDMI_AUDIO_OFF_DVI)
+   intel_hdmi->has_hdmi_sink =
+   drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
}
connector->display_info.raw_edid = NULL;
@@ -411,8 +413,8 @@ intel_hdmi_set_property(struct drm_conne
else
has_audio = i > 0;
 
-   if (has_audio == intel_hdmi->has_audio)
-   return 0;
+   if (i == HDMI_AUDIO_OFF_DVI)
+   intel_hdmi->has_hdmi_sink = 0;
 
intel_hdmi->has_audio = has_audio;
goto done;
--- linux.orig/drivers/gpu/drm/i915/intel_modes.c   2011-12-22 
10:53:27.0 +0800
+++ linux/drivers/gpu/drm/i915/intel_modes.c2012-01-06 11:21:19.0 
+0800
@@ -84,6 +84,7 @@ int intel_ddc_get_modes(struct drm_conne
 }
 
 static const char *force_audio_names[] = {
+   "off-dvi",
"off",
"auto",
"on",
@@ -106,7 +107,8 @@ intel_attach_force_audio_property(struct
return;
 
for (i = 0; i < ARRAY_SIZE(force_audio_names); i++)
-   drm_property_add_enum(prop, i, i-1, 
force_audio_names[i]);
+   drm_property_add_enum(prop, i, i-2,
+ force_audio_names[i]);
 
dev_priv->force_audio_property = prop;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

[Keith Packard]

On Thu, 05 Jan 2012 16:29:43 -0800, Keith Packard  wrote:

> Here's a longer series that does a bunch of cleanup before trying to fix
> things. Patches marked with '***' fix bugs. The patch marked with '...'
> is the optimization to inline the spinlocks.

I talked with Eric about this and we decided that the whole splitting
out of the i/o functions just doesn't make any sense. That makes this
series very similar to Daniel's patches, so I'll rebase my bug fixes on
top of those changes and send out a (shorter) series tomorrow.

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


pgp2ElK9xiAiW.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux intel and xorg status on i915GM hardware

[Knut Petersen]

Some comments related to linux and xorg git master on an AOpen i915GMm-hfs:

1: Xorg.0.log is full of (besides timestamp) identical EDID entries:
==

[  2502.358] (II) intel(0): EDID vendor "ENC", prod id 5769
[  2502.358] (II) intel(0): Using EDID range info for horizontal sync
[  2502.358] (II) intel(0): Using EDID range info for vertical refresh
[  2502.358] (II) intel(0): Printing DDC gathered Modelines:
[  2502.358] (II) intel(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
[  2502.358] (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz e)
[  2502.358] (II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz e)
[  2502.358] (II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  
400 412 414 449 -hsync +vsync (31.5 kHz e)
[  2502.358] (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)

The following bash script calculates the seconds between logged EDID reads:

y=0;
cat git/X11/var/log/Xorg.0.log | \
grep "EDID vendor"  | \
sed -e "s/\[\ //" -e "s/\.[[:print:]]*//" | \
while read x; do \
if [ $y -ne 0 ]; then \
echo -n "$[$x-$y] "; \
fi; \
y=$x; \
done;
echo

Output of the script:

1048  31  101  629  243  11  253  1613  72  30  254  782
122  487  375  213  295  537  396  81  152  213  264  142
1  1  69  355  2313  203  132  1136  527  213  467  101
102  385  11  172  10  1146  406  406  203  132  426  507
1390  1  1  1063  2820  2850  2  1  667  213  588  1309
710  304  1867  1349  700  1501  507  447  274  182
609  984  771  1562  1675

No, no monitor has been connected or disconnected ... I do not see any pattern.

2. https://bugs.freedesktop.org/show_bug.cgi?id=42300 has not been resolved


3. evdev: keyboard led problem, see 
http://lists.x.org/archives/xorg-devel/2012-January/028374.html


4. kernel: Polling occasionally distorts the framebuffer console
===
_Very_ old bug, but "echo N > /sys/module/drm_kms_helper/parameters/poll" helps.

5. Xorg fails to start without a manually created "Section Modules" in config
=
see: https://bugs.freedesktop.org/show_bug.cgi?id=41208

6. "Thank you" to opensuse:
=
11.3 has the last reliable Xorg version for my hardware, 11.4  crashes/locks 
and 12.1
has render problems ... a good way to increase the number of people that use 
and test
the git master tree ;-))

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