: Keith Packard
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 11 +
src/intel_driver.c | 114
4 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e066b3d
On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson
wrote:
> It appears that all users (crtc and encoders) are tracking dpms_mode, in
> one form or another. Should we move this to core?
Sounds like a good idea. Would you prefer to do that yourself?
> Is there any hardware that requires notificati
#ifdef HAVE_UDEV around some udev-specific declarations
Signed-off-by: Keith Packard
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
4 files changed, 133 insertions(+), 2
On Mon, 4 Oct 2010 06:33:01 +1000, Dave Airlie wrote:
> don't you do this already? both radeon/nouveau handle DP replug fine,
> I thought Intel would have been where I stole the code from.
There was a one-line bug. Patch already posted.
--
keith.pack...@intel.com
pgpVBHm0wwS9e.pgp
Descriptio
On Mon, 4 Oct 2010 01:15:08 +0200, Peter Stuge wrote:
> If there is the infrastructure to do so, then it seems that the 600ms
> delay while polling unconnected monitors could easily be removed.
Newer hardware generates interrupts for VGA and TV hotplug events; older
hardware doesn't.
--
keith.
Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files
#ifdef HAVE_UDEV around some udev-specific declarations
V3: document Hotplug option in man page
Signed-off-by: Keith Packard
---
configure.ac |5 ++
man/intel.man |6 +++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
On Mon, 4 Oct 2010 20:13:33 +1000, Dave Airlie wrote:
> We don't do dynamic connectors now, so adding locking with no way of
> actually really testing it would just mean you'd probably have just as
> much pain when you do add dyanamic connectors.
I looked in the radeon and nouveau drivers and bo
A physically mapped hardware status page is allocated at driver load
time but was never freed. Call the existing code to free this page at
driver unload time on hardware which uses this kind.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 files changed, 3
when we only
needed a single copy, but as 64-bit access requires its own version,
it makes sense to just split them out for each size.
Signed-off-by: Eric Anholt
Signed-off-by: Keith Packard
---
On Thu, 18 Nov 2010 10:05:00 +0800, Eric Anholt wrote:
> #define I915_READ8(
On Sat, 20 Nov 2010 16:17:40 +0100, Matthias Hopf wrote:
> I know, I know. The patch is (one of) the results of the Novell-HP-Intel
> workshop in Taipei this week. It turned out that rev07 is too unstable.
> Keith and Eric can probably comment on this. Better than I can.
There's a work-around in
On Thu, 25 Nov 2010 11:10:58 -0500, Nick Bowler
wrote:
> On 2010-11-25 16:58 +0100, Michal Hocko wrote:
> > [Let's add Rafael for regression tracking]
> >
> > On Tue 23-11-10 13:32:34, Michal Hocko wrote:
> > > Hi,
> > > since early 2.6.37 (I haven't bisected when exactly) my screen doesn't
> >
On Fri, 26 Nov 2010 11:45:38 +0300, Dan Carpenter wrote:
> Where are the patches? I pulled drm-next but I don't see them.
Looks like he hasn't merged them. I'm building drm-intel-next with this
and another patch.
I've pushed my bits to
git://people.freedesktop.org/~keithp/linux-2.6 drm-intel-
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc_helper.c |
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector->status
value instead of being discarded.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc_helper.c |7 ---
1 files changed, 4 insertions(+), 3 deleti
On Sun, 5 Dec 2010 13:27:43 +0100, Florian Mickler wrote:
> On Fri, 26 Nov 2010 10:45:59 -0800
> Keith Packard wrote:
>
> > In order to correctly report monitor connected status changes, the
> > previous monitor status must be recorded in the connector->status
&g
On Wed, 08 Dec 2010 17:08:04 +, Chris Wilson
wrote:
> On Wed, 8 Dec 2010 17:34:24 +0100, Florian Mickler
> wrote:
> > Does that mean that the kernel regression will not be
> > fixed/worked-around for old userspace?
>
> I think there is some confusion in that I believe there is more than o
On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski wrote:
> Enabling and disabling the vblank interrupt (on devices that
> support it) is cheap. So disable it quickly after each
> interrupt.
So, the concern (and reason for the original design) was that you might
lose count of vblank interrupts
On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski wrote:
> But five seconds is a *long* time, and anything short enough that the
> interrupt actually gets turned off in normal use risks the same race.
Right, so eliminating any race seems like the basic requirement. Can
that be done?
--
kei
On Tue, 21 Dec 2010 11:36:44 +, Chris Wilson
wrote:
> I think once upon a time I found a reliable method in the docs:
> intel_lvds_ddc_probe(). However that only seemed to work over GMBUS...
That probably depends on the panel having DDC, which many don't, right?
Maybe we can assume the SDV
On Tue, 21 Dec 2010 19:55:15 +, Chris Wilson
wrote:
> The test we do is simply whether the LVDS i2c pins are addressable. That
> requires differentiating between an IO error and a NAK, which at present
> is only possible using GMBUS. The reference to this method I found in the
> BIOS writers
On Thu, 20 Jan 2011 15:07:07 +, Chris Wilson
wrote:
> + if (dev_priv->is_vga) {
> + /* If we have > 1 VGA cards with a single output,
> + * then disable the radeon VGA resources.
> + */
Why does this say 'radeon'?
--
keith.pack...@intel.com
pgp4
On Mon, 28 Feb 2011 03:54:24 -0800 (PST), SD wrote:
> (II) intel(0): using SSC reference clock of 96 MHz
That's the spread-spectrum clock reference value; it forms the basis
From which the actual dot clock is computed using a PLL. It is *not* the
actual dot clock.
> [ 135.556] (II) intel(0):
On Fri, 18 Mar 2011 08:02:03 +, Chris Wilson
wrote:
> ... as wait_for_vblank (and friends) will do a flush of the MMIO writes
> anyway.
This one seems reasonable.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgppxraae0dbT.pgp
Description: PGP sig
On Fri, 18 Mar 2011 08:02:04 +, Chris Wilson
wrote:
> If the pipe or plane is already enabled, then we do not need to enable
> it again and can skip the delay.
This should mention that you're also skipping the operation on disable.
Otherwise,
Reviewed-by: Keith Packard
--
This comment is misleading -- the patch replaces a call to
intel_wait_for_vblank with a call to intel_flush_display_plane.
From my reading of the docs, enable requires two actions:
1) DSPACNTR with enable going from 0->1
2) wait for vblank
At disable, three actions are required:
1) DSPACNTR
On Fri, 18 Mar 2011 08:02:06 +, Chris Wilson
wrote:
> Later gen can proceed immediately with the modesetting as it is
> automatically double-buffered.
This comment is misleading -- the change is in intel_disable_plane, not
intel_enable_pipe.
--
keith.pack...@intel.com
pgpikAVhZf1TV.pgp
On Fri, 18 Mar 2011 08:02:08 +, Chris Wilson
wrote:
> As we may release the last reference, we need to store the device in a
> local variable in order to unlock afterwards.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpHcqpgV3keH.pgp
Description: PGP sig
hink the form
mask && (mask & (mask - 1)) == 0
is easier to reason about.
But, your fix is also correct as it finds the lowest bit set in 'mask'
and checks to see if that is the same as mask.
Reviewed-by: Keith Packard
--
keith.pack..
On Sat, 19 Mar 2011 07:44:24 +, Chris Wilson
wrote:
> I have an aversion to passing parameters around to control locking.
> Considering that we modify dev_private and adjust LP_RING during enable,
> wouldn't it be prudent to move that under the struct mutex? Especially in
> the future if we
Might be nice to have the patch message mention that the bulk of this
patch is simply renaming and moving i915_gem_execbuffer_sync_rings. In
fact, doing this in two patches would make the actual change a whole lot
easier to find.
--
keith.pack...@intel.com
pgpogFDNCbIgt.pgp
Description: PGP si
I'd love to see the API changes done in separate patches so they can be
reviewed without being mixed in with the actual fixes. This patch
conflates the changing of the sequence number management, ring
synchronization, elimination of the file argument to i915_add_request
with the changes in flush d
On Wed, 23 Mar 2011 10:21:07 +0800, Zhenyu Wang wrote:
> DSPARB is reserved on G33 and not available on Gen6.
Does this fix a reported problem? Or just spec compliance?
--
keith.pack...@intel.com
pgpSsTjeknBqr.pgp
Description: PGP signature
___
Int
On Wed, 23 Mar 2011 17:30:22 +, Chris Wilson
wrote:
> Right, so snooped pages goes through the shmem paths, nothing changes. Not
> everything is as nice as SNB and keeping the pages in the GTT is a benefit
> for everything else.
Where's the data.
--
keith.pack...@intel.com
pgplGbyHNcVEY
On Thu, 24 Mar 2011 02:02:56 +0100, Julien Cristau wrote:
> Hi Keith,
>
> a couple suggestions below from a quick look over these patches.
Thanks for your review!
> > static void
> > intel_vblank_handler(int fd, unsigned int frame, unsigned int tv_sec,
> > - unsigned int tv_u
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpS0hlmwj2Q7.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 24 Mar 2011 19:31:03 +0100, Julien Cristau wrote:
> This will cause a double free as the blit_fallback path does it too.
Argh! So we need to check before we reference the buffers and set
swap_info to NULL. This code is too twisty...
@@ -955,11 +960,16 @@ I830DRI2ScheduleSwap(ClientPtr c
On Fri, 25 Mar 2011 00:57:10 +0100, Julien Cristau wrote:
> With that change,
> Reviewed-by: Julien Cristau
Thanks for catching my bugs before they caused any damage...
Pushed.
ec133ab..7ccbec8 master -> master
--
keith.pack...@intel.com
pgpJ72WCEledy.pgp
Description: PGP signature
___
it_for_atomic is never used, so perhaps the _wait_for macro should
just be renamed wait_for and the W hard-coded to 1.
As a simple fix though,
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpLRhkv5NmEr.pgp
Description: PGP signature
___
On Tue, 29 Mar 2011 07:49:12 +0100, Chris Wilson
wrote:
> Yes, Oliver pointed out that we need to pass much more panel
> configuration data in order to configure a bare LVDS. Given the bizarre
> situation of the LVDS-attached-HDMI PNV boxes (how I love our market
> differentiate strategy!), I th
On Wed, 30 Mar 2011 17:07:11 +0100, Chris Wilson
wrote:
> +clear_err:
> + I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
> + POSTING_READ(GMBUS1 + reg_offset);
> + I915_WRITE(GMBUS1 + reg_offset, 0);
Any posting read needed here?
> +
> +done:
> + I915_WRITE(GMBUS0 + reg_off
On Wed, 30 Mar 2011 17:59:51 +0100, Chris Wilson
wrote:
> I'm not even sure we need the first posting read. Maybe it should be a
> wait_for(I915_READ(GMBUS1 + reg_offset) & GMBUS_SW_CLR_INT, 100)
> to be clearer that we are simply giving the hardware the chance to assert
> the bit and reset be
we don't clear the NAK, then all future GMBUS xfers will fail,
> including DDC probes and EDID retrieval.
>
> v2: Add some comments as suggested by Keith Packard.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781
> Signed-off-by: Chris Wilson
Revie
On Mon, 4 Apr 2011 07:26:44 +0100, Chris Wilson
wrote:
> Following the fix to reset the GMBUS controller after a NAK, we finally
> utilize the 0xa0 probe for a CRT connection. And discover that it is
> useless as it simply detects the presence of the controller and not the
> actual monitor. Giv
On Mon, 4 Apr 2011 07:26:45 +0100, Chris Wilson
wrote:
> Rather than proceed on to the next test, return the result from
> detecting a connection but to a digital panel and include some debug
> output as to why.
I'm worried that this will falsely reject some monitors with broken EDID
informati
On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson
wrote:
> Yes. I'm saying that that the controller accepts a write to port 0xa0.
So it's the GMBUS controller itself then, I guess. Weird.
Let me see if I understand how it used to work and why fixing the GMBUS
reset causes it to break in this ca
the context of the patch closely enough. This
looks good.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgptF0qYHGD34.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 5 Apr 2011 10:19:16 +1000, Dave Airlie wrote:
> On Tue, Apr 5, 2011 at 2:26 AM, Keith Packard wrote:
> > On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson
> > wrote:
> >
> >> Yes. I'm saying that that the controller accepts a write to port 0xa0.
&
On Mon, 4 Apr 2011 07:26:44 +0100, Chris Wilson
wrote:
> Following the fix to reset the GMBUS controller after a NAK, we finally
> utilize the 0xa0 probe for a CRT connection. And discover that it is
> useless as it simply detects the presence of the controller and not the
> actual monitor. Giv
On Tue, 5 Apr 2011 07:42:14 -0700, Linus Torvalds
wrote:
> Keith Cc'd, because that patch had better not show up in my tree.
Having experienced the delights of ACPI in the past, I have already
subscribed to your newsletter.
--
keith.pack...@intel.com
pgpEj4HSJ46EV.pgp
Description: PGP signa
On Tue, 5 Apr 2011 10:24:14 +0100, Chris Wilson
wrote:
> crtc = intel_get_crtc_for_plane(dev, plane);
> - if (crtc->fb == NULL || !crtc->enabled)
> + if (crtc->fb == NULL || !crtc->enabled) {
> + *cursor_wm = *plane_wm = display->guard_size;
> return fals
On Tue, 5 Apr 2011 10:24:15 +0100, Chris Wilson
wrote:
> Rather than proceed on and return false by default, return the result
> from detecting a connection but to a digital panel and include some
> debug output as to why.
This comment does not match the patch anymore; there is no new return
p
On Tue, 5 Apr 2011 10:24:18 +0100, Chris Wilson
wrote:
> Toggle the Software Clear Interrupt bit which resets the controller to
> clear any prior BUS_ERROR condition before we begin to use the
> controller in earnest.
We do this in two places now, do we want to share the code?
> + int reg_
On Tue, 05 Apr 2011 22:12:19 +0100, Chris Wilson
wrote:
> Indeed, I started by setting them to zero in the caller. Decided that
> there was some precedent to use the guard_size as the minimum value for
> unused planes (and so perhaps the unused planes on the unused pipes) and
> so it was then na
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson
wrote:
> This looks like it fixes two bugs:
>
> 1) What if there is an error recorded before we start and so we
> immediately service an IIR/EIR upon intalling the IRQ. Did we generate
> that error during initialisation or was that SEP? Now we do
On Wed, 06 Apr 2011 07:59:37 +0100, Chris Wilson
wrote:
> I'd prefer to keep the mucking around with intel_watermak_params in the
> one spot. How about:
My concern is that g4x_compute_wm0 is now different from
ironlake_compute_wm0, which seems like a potential trap for the
unwary.
> - *pla
On Wed, 06 Apr 2011 09:02:22 +0100, Chris Wilson
wrote:
> Looks like we can now indeed merge g4x_compute_wm0 and ironlake_compute_wm0
> and ignore the off-values for gen5+.
They do seem surprisingly similar at this point...
> So fix the use of uninitialised values for -fixes and remove the red
On Wed, 06 Apr 2011 07:52:27 +0100, Chris Wilson
wrote:
> So that I can separate out bug reports that are caused by us during
> initialisation from those that are caused by whatever was running before
> us.
Ok, sounds like good -next material to me then.
> Considering the difficulty in working
On Tue, 12 Apr 2011 09:30:22 -0700, Ben Widawsky wrote:
> I am going to spend at least a day tracking down, and hopefully fixing
> warnings if you agree with my next statement that it is in fact a
> problem. My hope is there aren't too many cases.
I can't see how we can survive without using exa
ths) instead.
Note that intel_sanitize_modesetting does not do anything on PCH
hardware yet. Otherwise, this looks like a reasonable plan.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpiMvU9734pI.pgp
Description: PGP signature
___
Intel-gfx
On Tue, 12 Apr 2011 18:21:23 +0100, Chris Wilson
wrote:
> Agreed. I had been working under the assumption that dev->struct_mutex was
> the sufficient lock. This may be entirely due to the false premise that we
> only needed i915_gt_read() for the ring registers. I still haven't looked
> through
On Tue, 12 Apr 2011 18:31:51 -0700, Ben Widawsky wrote:
> I think we have no other option since the first thing that
> i915_driver_irq_handler() does is read IIR, which according to the limited
> knowledge I have requires forcewake.
I think the eventual plan will be to figure out if there are an
On Wed, 13 Apr 2011 09:28:22 +0100, Chris Wilson
wrote:
> At the moment, only the first patch ("drm/i915: Initialise g4x watermarks for
> disabled pipe") looks ready. Keith, I think this reflects the consensus
> we reached for that particular patch; I have the second stage of
> unifying the iden
On Thu, 14 Apr 2011 10:03:35 +0100, Chris Wilson
wrote:
> ... to clarify just how we use it inside the driver. We still need to
> translate through agp_type for interface into the fake AGP driver.
agp_type has some really confusing semantics...
> - obj->agp_type = AGP_USER_MEMORY;
> + o
On Mon, 18 Apr 2011 10:31:43 -0700, Ben Widawsky wrote:
> gen6_gt_force_wake_get()
> while(foo)
> i915_read32_awake()
> gen6_gt_force_wake_put()
Uh. Anything looping on registers might not want to hold the lock...
--
keith.pack...@intel.com
pgpgKFMx6v8mp.pgp
Description: PGP signature
On Tue, 19 Apr 2011 21:32:02 +0100, Chris Wilson
wrote:
> We need to ensure that we feed valid memory into the display plane
> attached to the pipe when switching the pipe on. Otherwise, the display
> engine may read through an invalid PTE and so throw an PGTBL_ER
> exception.
This seems to rew
On Wed, 20 Apr 2011 16:42:08 +0100, Chris Wilson
wrote:
> Given that the hardware may be left in a random condition by the BIOS,
> it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
> without us ever enabling/attaching the DP encoder to a pipe. Thus
> causing a NULL deference
On Wed, 20 Apr 2011 10:22:17 +0100, Chris Wilson
wrote:
> +
> + if (!drm_crtc_helper_set_mode(crtc, mode, 0, 0, crtc->fb)) {
> + DRM_DEBUG_KMS("failed to set mode on load-detect
> pipe\n");
> + return false;
> + }
This seems like
m inside the common encoder structure.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpIyuZ6gZHYI.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 20 Apr 2011 10:22:19 +0100, Chris Wilson
wrote:
> ... and the no longer relevant comment. The code ceased stealing a pipe
> for load detection a long time ago.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpo4Jr0qCdEM.pgp
Description: PGP sig
On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson
wrote:
> Signed-off-by: Chris Wilson
Reviewed-by: Keith Packard
(this might be separately tested to see if it might fix some TV load
detection issues?)
--
keith.pack...@intel.com
pgpnWymRFWXkU.pgp
Description: PGP signat
On Wed, 20 Apr 2011 10:22:21 +0100, Chris Wilson
wrote:
> As we only allow the use of a disabled CRTC, we don't need to handle the
> case we are reusing an already enabled pipe.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpYSoJipl2cu.pgp
Description: PG
On Wed, 20 Apr 2011 10:22:22 +0100, Chris Wilson
wrote:
> For bonus amusement value, we perform the first load detect before even
> establishing our fbdev.
It seems like we need to be able to perform load detection in this
case to create a suitable frame buffer at boot time.
I also don't see a
On Wed, 20 Apr 2011 20:38:54 +0100, Chris Wilson
wrote:
> On Wed, 20 Apr 2011 11:23:01 -0700, Keith Packard wrote:
> > On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson
> > wrote:
> > > Signed-off-by: Chris Wilson
> >
> > Reviewed-by: Keith Packard
>
On Wed, 20 Apr 2011 19:55:10 +0100, Chris Wilson
wrote:
> I'll spin up a patch for a temporary buffer and see what you think.
Ok. I'd love to be able to use that code path all of the time, but I
don't like the thought of the cost of a temporary allocation every time
you do load detection.
--
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson
wrote:
> Whilst this may appear to be a big batch, it is actually only a few bug
> fixes from the last couple of weeks broken down into small steps.
Do you think any of these are needed in .39?
--
keith.pack...@intel.com
pgpAZG9Gv4Qio.pgp
Desc
On Fri, 22 Apr 2011 08:01:46 +1000, Dave Airlie wrote:
> My one is definitely, I've got a few people who can't use machines
> without it, I was going to push it myself, but I'm being nice ;-)
I'll review all of them for .39 then; it wasn't clear from the original
mail whether that was the desire
On Fri, 22 Apr 2011 22:22:28 +0100, Chris Wilson
wrote:
> fp = FP0(pipe);
> else
> fp = FP1(pipe);
> + fp = I915_READ(fp);
Please use different variables for the offset vs the value...
--
keith.pack...@intel.com
pgpaGbAUtaJf4.pgp
Description: PGP signat
On Tue, 26 Apr 2011 18:12:52 +0800, "Feng, Boqun" wrote:
> Signed-off-by: Feng, Boqun
Please add a description here of what the bug was and how this fixes it.
--
keith.pack...@intel.com
pgph19eyUhT0a.pgp
Description: PGP signature
___
Intel-gfx mai
On Tue, 26 Apr 2011 16:38:45 -0700, Jesse Barnes
wrote:
> We can treat PantherPoint as CougarPoint as far as display goes.
I'll note in passing that pch_type is never set to PCH_IBX explicitly,
which only works because PCH_IBX is zero.
--
keith.pack...@intel.com
pgpz4oSyZkoyH.pgp
Descriptio
On Tue, 26 Apr 2011 16:38:49 -0700, Jesse Barnes
wrote:
> A0 stepping chips need to use manual training, but the bits have all
> moved. So fix things up so we can at least train FDI for VGA links.
This patch should be before the auto-train patch so that we don't have
a broken driver between the
On Wed, 27 Apr 2011 15:41:18 +0800, "Feng, Boqun" wrote:
> Remove ring_put_irq/ring_get_irq:drivers/gpu/drm/i915/intel_ringbuffer.c
> , they are only used by bsd_ring_put_irq/bsd_ring_get_irq.
> Expand the code in bsd_ring_put_irq/bsd_ring_get_irq.
Why is this change useful?
--
keith.pack...@in
On Thu, 28 Apr 2011 10:06:51 +0800, "Feng, Boqun" wrote:
> I have discussed this with Chris in my earlier patch.
>
> This change is a clean-up, since ring_put_irq and ring_get_irq are only used
> by
> bsd_ring_put_irq and bsd_ring_get_irq.
>
> And once this change is made, it is more clear to
On Thu, 28 Apr 2011 15:12:47 -0700, Jesse Barnes
wrote:
> Rather than branching in ironlake_pch_enable, add a new train_fdi
> function to the display function pointer struct and use it instead.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
--
keith.pack.
On Thu, 28 Apr 2011 15:12:48 -0700, Jesse Barnes
wrote:
> Set the IRQ handling functions in driver load so they'll just be used
> directly, rather than branching over most of the code in the chipset
> functions.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgp
On Thu, 28 Apr 2011 15:12:49 -0700, Jesse Barnes
wrote:
> This makes the Ironlake+ code trivial and generally simplifies things.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpmUuBtFRc86.pgp
Description: PGP
On Thu, 28 Apr 2011 15:12:50 -0700, Jesse Barnes
wrote:
> Note: IS_GEN* are for render related checks. Display and other checks
> should use IS_MOBILE, IS_$CHIPSET or test for specific features.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
--
keith.pack.
On Thu, 28 Apr 2011 15:12:51 -0700, Jesse Barnes
wrote:
I don't see a patch in this series that sets this value from the PCI
ids. Is that still pending?
--
keith.pack...@intel.com
pgpfAzxA46ANr.pgp
Description: PGP signature
___
Intel-gfx mailing l
On Thu, 28 Apr 2011 15:12:52 -0700, Jesse Barnes
wrote:
> Ivy Bridge has a similar split display controller to Sandy Bridge, so
> use HAS_PCH_SPLIT. And gen7 also has the pipe control instruction, so
> use HAS_PIPE_CONTROL as well.
>
> Signed-off-by: Jesse Barnes
Reviewed-by
On Thu, 28 Apr 2011 15:12:53 -0700, Jesse Barnes
wrote:
> Treat it like Ironlake and Sandy Bridge.
>
> Signed-off-by: Jesse Barnes
Should use gen >= 5?
--
keith.pack...@intel.com
pgptprXAz4FhS.pgp
Description: PGP signature
___
Intel-gfx mailing
On Thu, 28 Apr 2011 15:12:54 -0700, Jesse Barnes
wrote:
> + if (IS_GEN6(dev)) {
> + temp &= ~FDI_LINK_TRAIN_NONE;
> + temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
> + } else if (IS_IVYBRIDGE(dev)) {
> + temp &= ~FDI_LINK_TRAIN_NONE_IVB;
>
On Thu, 28 Apr 2011 15:12:55 -0700, Jesse Barnes
wrote:
> Ivy Bridge supports auto-training on the CPU side, so add a separate
> training function to handle it.
Let's leave this out of the kernel until we have hardware that actually
uses it.
--
keith.pack...@intel.com
pgpBSTIApdDAP.pgp
Descr
On Thu, 28 Apr 2011 15:12:56 -0700, Jesse Barnes
wrote:
> - if (IS_GEN6(dev)) {
> + if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
IS_GEN6 for SNB and IS_IVYBRIDGE for IVB? More consistency, please.
--
keith.pack...@intel.com
pgpPesA8nYOAV.pgp
Description: PGP signature
__
On Thu, 28 Apr 2011 15:12:57 -0700, Jesse Barnes
wrote:
> - if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) {
> + if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
IS_G4X || gen >= 5 ?
Otherwise, this looks good (seems like it's just bit shuffling from SNB, right
On Thu, 28 Apr 2011 15:12:59 -0700, Jesse Barnes
wrote:
> Treat it like Sandy Bridge in a few places.
gen >= 6?
--
keith.pack...@intel.com
pgpqFHB2q8tev.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Thu, 28 Apr 2011 15:13:00 -0700, Jesse Barnes
wrote:
> Use Sandy Bridge paths in a few places.
gen >= 6 ?
--
keith.pack...@intel.com
pgp6Bmd9mjsyL.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://
On Thu, 28 Apr 2011 15:13:03 -0700, Jesse Barnes
wrote:
> There are several variants, set feature bits appropriately for both
> mobile and desktop parts.
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpgD7gICZi93.pgp
Description: P
On Thu, 28 Apr 2011 15:13:04 -0700, Jesse Barnes
wrote:
> This is a little less confusing than relying on the implicit zeroing of
> the dev_priv.
Thanks.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpFuOeuyyxOq.pgp
Description: PGP sig
On Sun, 01 May 2011 17:26:11 +0100, Chris Wilson
wrote:
> Perhaps if you do the s/IS_GEN6/IS_SNADYBRIDGE/ fixes first it will become
> much clearer? :)
The only question is one of regressions; getting the cleanups tested in
isolation from the IVB patches. That seems do-able for the 2.6.40 merge
On Thu, 14 Apr 2011 10:03:38 +0100, Chris Wilson
wrote:
> + obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
> + obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
I'll bet you want to modify the read_domain as well.
--
keith.pack...@intel.com
pgp2NzoJuMYNT.pgp
Description: PGP signatur
501 - 600 of 748 matches
Mail list logo
